Hello,
I’m looking to build a Rubik’s cube solving device.
Ideally this will be run off a Raspberry Pi system, the optical sensing will be done through the Raspberry Pi camera module or a CMUcam. The arms will rotate the cube past the camera, software will generate a 2D array of squares then use an optimal solution algorithm to create an array of movements.
As you can see from the hypothetical design it will be a 4 (maybe 6) arm system structured within an extruded aluminum frame. The caveat is that it requires linear and rotational movement in the arms. So I will need to find some way of combining linear and rotational actuators (hybrid devices exist but they are expensive).
If you wouldn’t mind I could use some help:
Choosing rotational actuators with enough torque to turn a R.Cube face
Choosing linear actuators and connecting them to the rotational actuators
Interfacing these actuators with a Raspberry-Pi (mux/demux? driver boards?)
@RobotRookie123 Don’t have a cube on hand to get an idea of the torque needed for rotation. If you have one, can you get an idea of what’s needed? If not, there are many Rubik’s Cube robots online, so perhaps be inspired by the actuators they chose? Given that the rotation seems much more than 180 degrees in certain cases, you’ll either need a DC gear motor with encoder, or a smart servo like:
Small linear actuator like:
There are variations which are 2-wire (limit switch), potentiometer feedback or RC…
The choice of interface will depend on the choice of actuators. For example the Lynxmotion Smart servos:
You could use the servos for linear movement as well if you’d like, making the overall setup easier, but requiring more mechanics.
If you’re aiming for speed (as we have seen in many videos), you’ll need something entirely different.
Right now I’m pursuing linear solenoids rather than actuators. The simpler on/off state should make code easier.
Also a good choice, so long as you can find the travel. Note that you might need an on/off relay since the Pi cannot provide much current.
I’ll get an exact force on a standard cube ASAP.
Smaller stepper motors don’t have much torque, so when you choose one, try to get one with a torque vs. speed curve. The slower the rotation, the higher the torque.
In the meantime do you think it would be better to user stepper motors? I think it would be easier to output a perfect 90/180/360 degree rotation.
Stepper motors are an excellent choice, but are more difficult to understand, choose and program. The issue is if one of the motors starts off-center, without some additional hardware and/or software, there’s no way of “knowing” the angle at which it starts (there are ways of course).
Attached are two hypothetical circuits for servos and stepper configurations.
If you want speed, the stepper + solenoid approach is the way to go. Not enough time to look at the circuit in detail to spot any issues. Keep in mind the Pi’s pins are 3.3V rather than 5V. The RC servo approach for the first image shows servos which are limited to 180 degrees, which may or may not be problematic and can be resolved in “approach” (like grip-rotate-release-repeat).
Careful about using only one power supply - it’s teh way to go, but quite a bit to consider.
Hello,
Sorry for the lack of updates, but the project has made some progress.
I printed off a frame from O.T Vinta, modified to fit the servos I’m using. I was not satisfied with the claw armature models they used so I printed off my own, you can see how they grab the cube when pressed against it, when finished they will have a spring between the claw and frame so they will open when retracted.
Attached is a short video of the scanning protocol. A Raspberry-Pi camera will be used to develop a 2D array of square colors as each face passes, current version pauses every turn, will likely have to drill a hole in the head of the claw so the camera can see the cube face underneath. We have also demonstrated that the servos have enough torque to turn a single face.
As you can see, however, without proper positional feedback the continuous rotation servos have some error that compounds over time. If you have any suggestions on how to mitigate this I would love to hear! My current plan is to use hinge-lever limit switches:
which will be activated when pressed against by a 4-arm servo head which will be placed on the head behind the armature, i.e instead of turning for a certain number of milliseconds it will turn until the limit switch activates.
I am still coding the solving algorithm, hoping to use the Kociemba algorithm to solve in as few moves as possible.
