Self-solving Rubik's Cube
media.dmm-make.com
media.dmm-make.com
Either way, it's extremely cool.
I notice also that it appears to not be able to move the middles sections, so instead it twists the middle and one side and then twists the side back again - so that adds an extra inefficiency.
EDIT if you look at the first video, the first move the solver makes is not the inverse of the last one the player made, so I'm sure it has its own solver. Also, there are pretty standard solver algorithms (I've never looked them up because I don't want to spoil the game for myself but I have a really inefficient one I've figured out myself).
For finding a solution by computer, it has the advantage of being almost completely a rote application of algorithms.
Solving the cube with a computer is a solved problem for a long time and there are myriads of algorithms. Granted the solutions are not perfect (i.e. using the minimum number of steps needed which is always <= 20), but mostly come close (~25 steps).
It's one thing to have an object that violates expectations by taking action that an outwardly similar object does not. It's a surprise move that turns the tables on the person interacting with the object. (You could almost view it as a threat or a power dynamic thing.)
Having those actions be as intelligent as possible raises this surprise to another level. If I fiddled with it for 5 minutes and it put it back in 30 seconds, I'd feel even more like I just got owned by the object.
- first human shuffle move was rotate around white side
- last cube movement was rotation around green side
Ergo the cube did not just follow the same steps in reverse order
From the video it looks like a solver algorithm by the way, and not going for least amount of movements either, it seems to move much more during the solve than the movements the person did. To save battery they should go for optimal amount of moves!
The C++ snippet includes permutations for the Fridrich method's first two layers (F2L), which wouldn't be required for a reverse-replay.
Kinda feel like this is a pretty good example of how solutions to problems can be counterintuitive to people.
I imagine theres some protocol to tell the controller the cube is solved (e.g. only turn it on in a solved state) and it just tracks moves from there to determine the current state.
It was “solved” with 56 moves.
Seems like a solve algo to me.
Stranger still, it might turn out that the cube decides that it's fine the way it already is and it doesn't need to conform to a "right" configuration based on our expectations. In which case; perhaps we're already invented what you're looking for?
Next step: a solving algorithm that minimizes maximum net horizontal displacement from the starting position, to avoid falling off the table.
(the demonstration video has the cube almost fall off the table. A human had to interfere to push it away from the edge)
https://www.aliexpress.com/store/product/Xiaomi-Giiker-Cube/...
The solving algorithm is no big deal at this point. Experienced cubers can solve them in under 10 seconds. There are machines that can solve them in < 1s. [1] Again, the innovation there is the accuracy and precision of the machinery involved.
That's a significant time/cost, and typically out of reach for home electronics hobbyists.
To make it feel "normal", you could "assist" the user with the motors, but I'm guessing speed would be severely limited compared to a normal cube.
I'm not sure it's relevant to the difficulty of the scramble for a human, though. Most solving methods follow an approach that isn't even trying to find the minimum possible number of moves. The one that most of the fastest speedcubers use is, IIRC, the least move-efficient of all the standard methods. It just manages to be faster in terms of time because it's such rote method that, if you learn it well and get it burned into your muscle memory, you don't really have to ever even stop to think about what you're doing in the middle of a solve.
This does bring Clarke's third law to mind, though.
https://www.kickstarter.com/projects/1928372437/gocube-the-c...
They have like 2 things, a cube that measures its configuration and some matchmaking platform where you can cube against others.
If one wants to learn how to solve the cube using instructions (although I think finding it out on your own is a nice exercise), there are 1000s on the internet and even apps that use your phone's camera to give specific instructions.
On the other hand if you want to do speed-cubing (that's actually a thing) it is impossible to avoid cheating over the internet (granted that's also true for chess and other games that have been solved using computers).
The linked project however is really cool - completely useless, but extremely nice. Kudos to the maker.
Can anyone tell which CAD software they’re using just by looking at the screenshots?
Example image of wiring an assembly in Creo:
http://www.arbortext.com/-/media/Images/CAD/PTC-Creo-PCX---1...
I am not aware of the interface method Creo uses for wiring or resolving connections, it could be purely graphical with no resolving at all. If so I would assume that the electronics/pcbs you can see in the original article are likely just 3D STEP models exported from the ECAD package into Creo.
Sadly, the market does not currently (to my knowledge) present engineers with one single software solution for ecad->mcad>wiring>assembly>release, instead relying on various software packages, licenses and extensions on these with each user (company) forging their own local workarounds to bridge or replace specific steps of the process.
Most algorithm to solve the cube use some family of predefined blocks of moves. Each block of moves does something simple but interesting, like swapping two edges, or rotating two corners, without changing the rest of the cube. So you can start building one face and then slowly extend the solved part until all the cube is solved.
This is easy to memorize and to use, because all the decisions to use a block of moves are "greedy", you just fix another edge or you fix another corner, one by one.
The problem is that this approach doesn't provide the shorter solution. It's funny to make tree or four moves and then watch someone else use a few hundreds of moves to solve the cube.
So, if you flip a single edge or corner piece, it'll just solve itself into a state where every cubelet is in the correct position, but that edge or corner piece is rotated.
There's two ways you could model a piece's orientation in the code: Either relative to its initial state, or relative to some external/objective reference point. The latter would allow you to say, "The initial state looks like the traditional solved state except that this one piece is flipped." Otherwise, though, it wouldn't really be useful, and I'm pretty sure that it would make both the math and the programming more complicated, so I'd assume (or at least hope) that that's not how it's being done.
There's a lot of room in a bowling ball so I think it should be possible.
Let's put a camera in the finger holes (no idea if there is a "right" name for them, sorry) and make the ball steer itself.
After that works, start to reduce the hardware size and go for golf balls and the big money ;)
I believe you're talking about the the optimal shortest path to the solution, which while true, relevant and interesting, isn't contrary to the point.
(AFAIK, we don’t know God’s number if we count moves that way. I would guess it’s larger than 20)
You can see from the videos that it is not doing that though. The solution is not the trivial reverse of the scramble.
Also had this cube been a retail best seller a decade ago then I think Edward Snowden would have had to have chosen another toy to hide his SD cards in.
Nonetheless, Christmas is coming up, I hope Santa has one of these for me...