Meccano Rubik's Shrine

Links:

• Project page

Introduction

Overall look of the machine

Although our FAC Solver has gathered 120K+ views on YouTube, we felt that this was only the beginning. By the time we finished it, we had a bunch of ideas in mind that we were eager to realize. So we came up with another 3-gripper machine, this time assembled with Meccano construction set.

While FAC Solver was more of an experimental creation, this time we had lotsof experience, so we could address fundamental weaknesses of the FAC Solver,at the same time focusing on the look and feel of the machine, making it morefriendly and appealing. We didn’t want to make yet another hacky DIY machine,but something that would combine technology with decorative design, somethingnice to build, to see, and to own.

It took us almost half a year to finish the project: the first VirtualMEC model was made in February 2016, and we had a working prototype by June. The model is meant to pay tribute to Ernő Rubik and hence its name: Rubik’s Shrine.

Mechanical Design: Less Wiring, More Art

Having several decades of Meccano experience, Wilbert managed to design the machinethat is much more compact than the FAC solver. To achieve the cleanest look possible,all the wiring and unnecessary details are hidden inside the metal body.If necessary, the PCB board and other electronics areeasily accessible through the door on the back side. Moreover, the whole machine isassembled using normal Meccano parts that are available on the internet.

Wilbert was inspired by the Dark Tower from the Lord of The Rings,so the look of the Shrine is meant to be quite pompous :)

Rubik’s Shrine appearance was inspired by the Dark Tower from Lord of The Rings

The basic setup of the machine has 3 identical grippers, mounted on a rigid frame.Each gripper is driven by 2 steppermotors. One steppermotor actuates the satelliteto which an armdevice is mounted, capable of grabbing a cube. The other steppermotoractuates the wormgear for opening and closing the armdevice. Around the bottomgripper a positioning table has been designed, which can be lowered once the cubeis grabbed by the 3 grippers.

all three gripper devices are completely identical

Being very careful about the details, Wilbert made sure all parts matchedeach other: all original rounded shiny Meccano strips, with 3-layered custom airbrushfinish on the plates. Brass gears put the final touch to the appearance of the machine.

Gripper design

The large gear mounted on the satellite is a 76t gear (Stuart Borrill production)and engages with a 38t gear. Each arm of the armdevice is mounted on a modified57t brass gear - similar to the 3 axle nr 27dp, yet in brass - which is engagedby a double threaded wormgear (Stuart Borrill production). With this setup wehave been able to solve a cube in 10 seconds, based on 19 cuberotations.

The arms of the gripper are mounted on the satellite through a number of carefullyassembled brassparts, secured on a bushwheel at one end and a 95t gearwheel on theother end. The satellite can freely rotate around the rotoraxle to which the wormis mounted. The 95t gearwheel is engaged with a 19t gear, which is directly mountedon the rotor of the other steppermotor to enable rotational movements. The 19t gearin the centre of the satellite doesn’t engage with any other gear. It was merelya tool to operate the centre rotor manually during the testing phase.

Note that the 95/19t gearset has been replaced by a 76/38t gearset. With thissetup we have reached the best mechanical configuration in relationship with theoperational speed of the solver. It is obvious, that all the rotors to drive theworm must be exactly centered relative to each other and to the cube, otherwisethe cube might lose it’s position relative to the grippers.

In spite of the rectangular shaped forms of the Meccano parts - one of its keycharacteristics - it was quite a challenge to keep the assembly of the framestrictly rectangular. Special measurement tools were needed in order to keep pure90 degree angles between several parts of the frame. A precise assembly when itcomes to the afore mentioned angles is thus essential.

3d-printed gripper tip is the only non-Meccano part

The tip of the gripper is a 3D printed part, designed in AutoCAD and printed by a local member of the 3DHubs community.

To this part a small rubber strip was attached for extra friction between thegripperarm and the cube. This is the only non-Meccano part in the assembly.

Positioning table

The positioning table is surprisingly simple

The function of this device is to keep the cube in a correct position relativeto the grippers. Once the grippers grab the cube the positioning table islowered all the way to the bottom.

This device of the solver is apart from the grippers probably our favoritemechanical assembly. The table is assembled with standard parts onlyand it’s appearance is of a disconcerting simplicity.

The free space within the table accommodates the bottomgripper and once thetable is in a raised position, the bottomgripper can be opened or closed.

When the cube is placed - which dimensions is by the way based on the half inchmodular - it will be put and kept in position by the 4 corner brackets (133) andthe 8 large washers. The roundings of the large washers automatically will placethe cube into its correct position, relative to the grippers and without the riskof damaging the cube.

This is probably the first assembly where we found a good purpose for thelarge washers. They are very applicable in a way we couldn’t have achieved withother Meccano parts.

Electronics: Use the right tool for the job

PCB board behind the door on the back side. The neodymium magnets in the corners of the opening keep the lid firmly on its place once closed.

Arduino, Teensy, and Raspberry Pi

In our previous project, the FAC Solver, (almost) everything was controlled by Raspberry Pi, including solving algorithm, color recognition, movement scheduling, and pulse generation for the stepper motors. We used Arduino only for reading the analog signal from LDRs in scanner device.

While it did work quite well eventually, it turned out to be tricky when it comesto controlling the motors. On the lower level, you can’t precisely control the time thatprocessor gives to your process on RPi. Due to the presence of other processes,and, actually, the operating system itself, your program might be given differentchunks of CPU time, which makes the generated pulse train unstable. For lower speeds,it is not a problem, but if the motor speed is high enough, it can be killing forperformance: motors start hesitating. To overcome this problem, we decided to usean Arduino board for the actual motor control.

Arduino Pro Mini and Teensy 3 have the same form-factor, but the latter is much faster

Arduino gave us much more stable pulse train, which allowed to reach higher speeds. We also used the great AccelStepper library that made movements smoother and more reliable. We used the MIN protocol for RPi-Arduino communication.

Originally, we chose Arduino Pro Mini because it is probably the most compact one. We made the first working prototype with it, but later replaced it with the Teensy 3.2, which looks and feels almost identical, but has better performance: 72 MHz ARM processor on Teensy vs 16MHz processor on Arduino. The difference was huge (see the Memory management section).

Stepper drivers and motors

We’ve done quite a lot of research on stepper motors and stepper drivers. After some timeconsuming testings the DRV8825 driver proved to be very a good fit for the job. Designed for being used in affordable 3D printers, they are incredibly cheap and very small. And they are perfectly compatible with NEMA 14 motors that we used in this project. One minor detail though, the DRV8825 driver can get easily damaged and become useless after that.

Camera: Come on, it’s the 21st century!

Apart from the motor controlling, the biggest technical change in Rubik’s Shrine, compared to the FAC Solver, was the scanning part. While it was fun to play with the low-end scanner made from LDRs and LEDs, it was quite a challenge to deal with ambient light and do the color balancing. It did fit well the brutal nature of the machine but obviously was not the most modern approach.

Pi Camera with the flashlight on. Flashlight is required to have stable readings under bright ambient conditions.

This time, we went fancy and used the Raspberry Pi Camera for color scanning the cube.Since it automatically adapts to the lighting conditions, it solved pretty muchall of those color recognition problems (we had to use bright LED flashlight though).All we needed to do was to carefully pick the average colors from specific regions on the photos.

The photo of the cube with marked regions for color recognition

As a bonus, each run is recorded on video and available on the Archive page in thetouch interface. It was also quite handy during debugging.

Every run is captured on video

Pi Display: the Final Touch

Not so long before we started this project, Pi Foundation announced an awesome 7-inch touch screen for Raspberry Pi that perfectly fitted our model. We were pleasantly surprised that it just worked: after a couple of nights we had a nice-looking touch UI written in Kivy.

Having a touch screen, we were able to add some extra functionality to the machine. In addition to a nice presentation of the scanning and solving results, it is possible to make some pretty patterns.

Pattern mode allows to solve the cube to some pretty patterns

We also implemented a special debug screen for manual control that practically made itunnecessary to use a laptop for testing.

In Debug mode manual control is possible

Fine tuning

The whole machine is powered by a Mean Well 220-240V AC to 24V DC powersupply.The 24V is needed for the motorpins on the DRV8825 stepperdrivers.These drivers become pretty hot as the trimpot is adjusted to 0.7V, giving 1.4Ato the output. We had to remove the adhesive tape which comes as a standardbetween the coolribs and the processor’s driver, and substitute it by ceramic glue.Otherwise the ribs would float away because of the heat due to it’s vertical position.

From the 24V DC circuit a bypass 12V and 5V circuit was made with voltageregulators(7800 series) for enlighting the 12V LEDs and to power the low voltage pins onthe stepperdrivers. The 12V LEDs are operated from the Raspberry Pi. The Pi canonly give 3,3V on it’s GPIO and for this reason a 1 channel analog level triggerhad to be used to operate the LEDs from the Pi directly.

Software: What can we do better?

Pure RPi/Python implementation of our previous Cube Solver proved to have a numberof nasty caveats, so we wanted to do it right this time.We braced myself and prepared for the challenge of embedded systems programming,ready to implement things from scratch to save a few bytes of RAM.

Solving algorithm

In our opinion, the best Rubik’s Cube solving algorithm at the moment is the Two-Phase algorithm by Herbert Kociemba. It is important to understand that it is suboptimal, which means it will not give you the best possible solution. But it is way faster than the optimal algorithm, which makes it more suitable for real projects like this. This will probably change in near future when we have faster computers.

For this project, we’ve made a Python/C implementation of the Two-Phase algorithm. It is freely available on GitHub.

Movements

Probably the most difficult part was the movement optimization. The solving algorithmproduces a solution sequence on Raspberry Pi, which then needs to be translated intoa sequence of gripper movements. Then this data has to be transferred to the Arduinoboard because actual electrical pulses are generated there. We wanted to makethe algorithm generic so that we could use it in other machine configurations(with 4 or even 6 grippers). This added to the complexity of the problem.

Minimizing the overall solving time is not obvious. For example,in a 3-gripper setup like this, to rotate the Front side of the cube we need torotate the whole cube first. We can rotate it around the vertical or horizontal axis.Whichever is better (leads to faster solution) depends on the current state ofthe grippers and on subsequent moves.

Synchronization

Generally, all grippers can move simultaneously. To do this, we need to have multiple parallel execution flows. Since Arduino is single-threaded, it has to be done with coroutine-like mechanism. On the other hand, due to the mechanical construction, some movements require the other grippers to be in specific positions, which means that parallel workers need to be able to block each other. Average solving process requires about 200 blocking operations.

Movement scheduling for 4-gripper setup. Scheduling motor movements is quite tricky

Memory management

Arduino Pro Mini, which we used initially, has only 2KB of RAM. After initializing objects for serial communication and motor control, there are approximately 200 bytes (!) left for local variables in actual business logic. With such limited resources, we could afford to store only absolutely vital data. Everything else had to be buffered in Raspberry Pi and pushed to Arduino via serial connection during the run. Pure serial communication is quite expensive, so it was causing an additional slowdown of the solving process.

Arduino Pro Mini compilation result. We have to cope with a limited amount of memory

It is possible to write C++ code for Arduino, but the dialect is very limited:due to memory limitations it doesn’t have the C++ standard library, exceptions, etc.,and in most cases it is a bad idea to use advanced tools such as dynamic allocation.It might be tough to refrain from using abstract classes with a bunch of virtualmethods and dynamically allocated arrays. It is also hard to debug because younever see the exceptions: it never fails explicitly, it just starts working weird at some point, and you can only guess what went wrong, especially if you have memory-relatedproblems. We ended up with quite hacky virtual method implementation based onswitch statements and static variables, which was not that clean, but straightforward.

Later, we changed the Arduino Pro Mini with Teensy 3.2 which was a great improvement. Not only it is way faster (thanks to ARM processor), and has 64KB of RAM, but it has exactly the same form-factor as Arduino Pro Mini. We didn’t even need to change the PCB connectors!

Well, 64K ought to be enough for anybody, at least in Arduino world. With all thismemory available, we could easily store information about the whole movement sequence at once.No additional serial communication + increased speed = faster and smoother solving.

Putting it all together

After all the parts are connected together, the machine is ready.The whole solving process consists of the following stages:

• Via the touch interface, user triggers the solving process
• Raspberry Pi makes photos of each side of the cube
• Photos are analyzed, and the data is sent to the Two-Phase solving algorithm
• The solution is translated into a sequence of gripper moves
• Moves are pushed to Arduino (Teensy) board via Serial interface
• Arduino, in turn, makes sure that all the motor movements are executed in the correct order, with proper acceleration and deceleration.

Public demonstrations

When the Rubik’s Shrine was almost finished, we presented it on SkegEx 2016, the annual Meccano exhibition in Skegness, England. We even managed to win the 5th prize, which is quite something considering that SkegEx is generally more about traditional mechanics rather than robotics and electronics.

Rubik’s Shrine at SkegEx 2016

Rubik’s Shrine at SkegEx 2016

Make your own Cube Solver!

An inquisitive reader might already have enough information to make a replica of this machine. And we encourage you to do so!

However, it might also be difficult to get all the parts, since they have to be ordered from different places. To make things easier, we are considering to offer a kit with essentials for those who want their own version of a Rubik’s Cube Solver. Check the Project page for more details