Subject:
|
Re: RCX+PC=Rubik's Cube Solver
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 19 Apr 2001 03:06:53 GMT
|
Viewed:
|
1184 times
|
| |
|
|
Gordon --
> I'm not "having a go", I'm just intrigued to see if it is possible. This is
> the main reason I'm not buying a Lego-Cam. It won't talk to the RCX.
> When will we see the RCX-only version?
> I'm not "having a go", I'm just intrigued to see if it is possible. This is
> the main reason I'm not buying a Lego-Cam. It won't talk to the RCX.
No offence taken. I think it's almost certainly doable completely onboard the
RCX, and I considered this as an option. The reasons I didn't do this are as
follows:
1. Couldn't think of a another good way of reading the cube facelets.
Color discrimination of the LEGO light sensor is too poor to read the face
colors accurately. Of course, one could retrofit the cube faces with
gray-scale patches or other aids to proper discrimination, but I was aiming at
a general solution to all 3^3 cubes, rather than a solution only for specially
retrofitted cubes.
One other way would be to use homebrew CdS sensors -- that looks doable from my
early experiments on sensor response to the cube patches (indeed, it may well
be a better way than using the cam). However, since I'd been given a preview
copy of the VC, and it had been kicking around unused for a couple of months,
and I'd just seen Michael Gasperi's link to the Logitech SDK, it seemed silly
not to try and extend the VC's use. [Ironically, this is the part which is
proving most intractable at the moment.]
2. I was looking for code that produced a low number of rotation steps.
I'll try and do some timing on the solution period -- at the moment almost all
the time is taken: a. inputing the initial state of the cube by hand (as I do
at the moment since it's more reliable than my current video-interpretation
code) and b., the RCXs repositioning the cube to get the next face in the
solution sequence into a position where it can be twisted.
There are definitely ways to reduce the number of repositioning steps used in
the (fairly trivial) NQC programs I wrote for physically implementing the
solution. However, if you want to actually calculate the solution onboard the
RCX, I think you'll have to you'll have to go to an heuristic solution, and
that's going to at least double the number of face rotations required. The
solution code I'm using (which is a port of Mike Reid's implementation of
Herbert Kociemba's method) hasn't yet produced a solution longer than 35 face
rotations, but it requires PC-sized quantities of RAM for the permutation
tables it scans to arrive at a solution. The heuristic methods ("first solve
the top, then the middle slice, then the bottom," or whatever) require way less
RAM since they are a series of pre-coded response steps, but they produce
significantly longer move sequences (more like 60-120 face rotations). I don't
see any inherent problem with implementing these heuristic methods onboard the
RCX using LegOS or pbForth, and when I had to make the choice between solving
on the PC and solving on the RCX it was a tough one. One reason I went with
the PC is because I had already decided to use the Vision Command camera, and
so I was already tethered to the PC.
3. Intended audience
I am a Host in the Mindstorms forums and NQC is the most widely understood of
the non-LEGO brick languages used there. Onboard heuristic solution methods
are (I suspect, but have not confirmed) not possible given the limitations
imposed on NQC by the LEGO firmware. Given that NQC was going to be my
language for the RCXs, what I hoped for, by uplaoding CubeSolver and drawing
it to the attention of lugnet.robotics, is that it would give people a
decent first iteration (like Joe Nagata's Walker2) to show that it was doable,
and then people would go on come up with more and better approaches to the
problem.
Over to you all :)
Cheers
JP
|
|
Message has 2 Replies:
 | | Re: RCX+PC=Rubik's Cube Solver : eyeball & turbo 'RCX'
|
| (...) We have started to plan an autonomous "eyeball" using a modest color CMOS sensor 100x100 to 200x200 pixels. With 128x128 and 8 bit color, that's "only" 16 KBytes per image, with no compression. With some simple data reduction it could be much (...) (24 years ago, 19-Apr-01, to lugnet.robotics)
| | | Re: RCX+PC=Rubik's Cube Solver
|
| (...) I have been sort of heading that way for the last few weeks. Mainly due to the cost, and the fact that I usually use the Light Sensor with the IR as sonar, and I was thinking that I might get better distance with a passive (CdS) sensor. My (...) (24 years ago, 19-Apr-01, to lugnet.robotics)
|
Message is in Reply To:
| | Re: RCX+PC=Rubik's Cube Solver
|
| (...) I'm not "having a go", I'm just intrigued to see if it is possible. This is the main reason I'm not buying a Lego-Cam. It won't talk to the RCX. Regards Gordon (24 years ago, 19-Apr-01, to lugnet.robotics)
|
29 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
