会玩魔方的机器人[视频]
<p>说起来他也算是魔方机器人二代了，名字叫做“RuBot II ”，从他身上应该能感受到科学家的惊人智慧。<br/><br/><br/><img alt="" src="http://www.dglife.cn/upload/2006_09/06092915325965.jpg" border="0"/><br/><br/> 拿一个魔方，随你尽情的玩，各个面怎么打乱都没问题。这个家伙拿过去会仔细的观察，然后就施展绝活了，我敢说他完成这项任务的速度不会比你刚才破坏六个面的时间长多少。<br/><br/> 完工后他还会向你显摆劳动成果呢，并且“开口讲话”，非常有趣。</p><p><br/><br/></p><p><font size="5"><font color="#0000ff"><strong>视频地址</strong></font>： </font></p><p><font size="5"> </font><a href="http://www.dglife.cn/html/2006-09/1470.html"><font color="#be0ebe" size="5"><strong>http://www.dglife.cn/html/2006-09/1470.html</strong></font></a></p><p></p><p></p><p>.<br/></p>[此贴子已经被作者于2006-11-8 2:54:39编辑过]
<p><font color="#a329a3" size="3"><strong>另外还有一种，虽然作者进行了再次优化但效率目前来说和上边的比速度是差太多了</strong></font></p><p>魔方终结者——CubeSolver （英文）<br/>使用乐高做一个解魔方的机器人？很多人连想都不敢想，而JP Brown成功了，几乎发挥了乐高RCX的极限。因为这个模型，而JP Brown也成为乐高迷心目中的偶像。<br/> </p><p>[原文地址] <a href="http://jpbrown.i8.com/cubesolver.html">http://jpbrown.i8.com/cubesolver.html</a><br/></p><p><table cellspacing="0" cellpadding="10" width="100%" border="0"><tbody><tr valign="top"><td width="1"><img height="277" alt="" src="http://jpbrown.i8.com/CubeSolver1_sm.jpg" width="400" border="0"/><br/> <p><img height="277" alt="" src="http://jpbrown.i8.com/CubeSolver2.jpg" width="400" border="0"/><br/> <!--Element not supported - Type: 8 Name: #comment--></p></td><td><font face="verdana,arial,helvetica" size="2"><b>PREAMBLE</b><br/> <p>This robot solves the 3x3x3 <a href="http://jpbrown.i8.com/cubesolver.html#RB_DISC">Rubik's Cube®</a>. </p><p>I started to think about this problem in about August of 2000. In Jan 2001 fellow Mindstorms forums user 'agiecco' announced his intention to work on a robotic solution and, simultaneously, I saw that Rubik's Cubes were on sale at www.target.com. So I bought a couple of cubes and started getting down to business... </p><p>I produced a 'late beta' version in mid-April 2001 that was a little clunky. The final version (presented here) is smooth and fairly reliable. </p><p></p><p><b>MECHANICS</b><br/> </p><p>To achieve a cube solution, you must be able to rotate the whole cube by 90° in two orthogonal axes, <i>and</i> be able to turn a face by 90° relative to the rest of the cube. </p><p>I opted to use the left and right grabbers to turn the faces; the yellow grabber can rotate the left face by an 90°; the green grabber can rotate the right face by 90°; or they can both turn simultaneously while the bottom grab is open to rotate the whole cube through 90°. </p><p>The bottom gabber holds the center 'slice' of the cube when the left or right grabber is turning a single face, and also provides a 90° turn for rotating the whole cube. </p><p>The tricky part is to re-orient the cube between moves to present the next face to be turned by the left or right grabber. </p></font></td><td></td></tr></tbody></table></p><p><br/></p><p><table cellspacing="0" cellpadding="10" width="100%" border="0"><tbody><tr valign="top"><td><img height="328" alt="Lubricating cube" src="http://jpbrown.i8.com/Cs_lube.jpg" width="250" border="0"/><br/> </td><td><font face="verdana,arial,helvetica" size="2"><b>PROBLEMS SOLVED</b><br/> <p><b>1. The cube faces are generally too stiff for LEGO elements to turn</b><br/> </p><p>This problem was solved by a tip I found on Lars Petrus's <a href="http://lar5.com/cube/speed.html">Speed Cubing page</a>: lubricate the cube with silicone spray lubricant. I got an aerosol can of <i>LubriMatic Heavy Duty Silicone Lubricant</i> from my local ACE hardware store and squirted some inside the cube. After wiping off the excess spray you must rotate the cube faces for about 30 minutes to prevent the solvent in the spray dissolving the cube body and sticking it solid. Once you have done this, the result is a fairly slick cube. </p><p></p><dir><img height="144" alt="Wedging the cube open" src="http://jpbrown.i8.com/Cs_knives.jpg" width="350" border="0"/></dir>However, I found that some of the faces still got stuck because the springs inside the cube were too stiff, so I pushed some wedges (actually, plastic knives) in between the cube slices and left them over night to force the springs inside the cube to loosen up. After this treatment the cubes handled very well. </font></td></tr></tbody></table></p><p><br/></p><p><table cellspacing="0" cellpadding="10" width="100%" border="0"><tbody><tr valign="top"><td><font face="verdana,arial,helvetica" size="2"><b>2. Getting enough torque</b><br/> <p>Even with a treated cube, getting enough torque to turn the cube faces was going to be a problem. I remembered the system that Jin Sato used on the thigh joints of <a href="http://207.236.16.161/JinSato/MindStorms/TryAndError/Mibo/no11.html">MIBO</a> -- worm gear to the outer 56t ring of the large Technic turntable. This gives torque to spare for turning the faces of a treated cube. </p><p><b>3. LEGO grabbers don't grip strongly enough</b><br/> </p><p>My early attempts at building a cube solver were all stymied by grips that slipped. The worm-56t gave enough torque to turn, but the fingers couldn't hang on and the grip was simply pried apart as the grabber rotated around the stationary cube face. I thought about changing the device's name to <i>ButterFingers</i>. </p><p>I rebuilt the left and right grabbers six times (and the bottom grabber four times) trying elastic bands, Technic shocks, and pneumatics, before I came up with an adequate grip mechanism. In the present version, an axle runs from a motor through the center of the large Technic turntable to a worm screw. The worm screw turns two 24t gears mounted either side of the worm inside the body of the grabber. Each end of the 24t axles terminates with an 8t gear outside the body of the grabber, and these 8ts engage with 24t-s on either end of the axles which carry the grabber's fingers. This system can be strained quite tight without risk of gear slippage, and also allows the large turntables to rotate 180° without any significant loss of grip. </p><p>For the bottom grabber I had to use a slightly different arrangement (same gear combinations) because the fingers of the green and yellow grabs kept catching on the external 24ts of the bottom grab. Eventually I managed to work out how to mount all the gears internally in the 4-stud width of large Technic turntable. </p><p></p></font></td><td><img height="317" alt="Side grab gear train (typical for 2)" src="http://jpbrown.i8.com/Cs_grab.gif" width="337" border="0"/><br/><img height="315" alt="Bottom grab gear train" src="http://jpbrown.i8.com/Cs_bgrab.gif" width="339" border="0"/><br/> </td></tr></tbody></table></p><p><br/></p><p><table cellspacing="0" cellpadding="10" width="100%" border="0"><tbody><tr valign="top"><td><font face="verdana,arial,helvetica" size="2"><b>4. Precision of movement</b><br/> <p>Having solved these problems, there was still the problem of 'slop' or 'gear lash' in the left and right drive trains. </p><p>Most of this was absorbed in the beta version by putting rotation sensors on the worm drive axles that rotate the grabs. However, the worm screws are a *tiny* bit too short to fit snugly -- they travel a little when the motor direction is reversed. To cure this I tried a <a href="http://news.lugnet.com/robotics/?n=14854">suggestion from John Barnes</a> and cut thin shims out of the plastic insert tray from inside a LEGO box. Two shims on each drive axle fixed the worm gear nicely in position so that the gear lash (although still detectable) was *nearly* within the tolerance of the cube for repeated turning. </p><p>However, the rotation sensors for the LEFT and RIGHT grabbers occasionally lost track of their position and had to be manually tweaked during a solution. There was also the problem that the rotation sensors were on the same axle as the worm screw turning the turntable. This meant that when the cube was a little stiff, even if the worm screw had performed the correct number of rotations to turn the cube face 90°, the LEGO pieces of the grabber had enough flex that the grabber was slightly twisted and the face did not make it all the way around to the 90° point. </p><p>Therefore, I abandoned rotation sensors and put two touch sensors at the limits of the quarter turn of the turntable (similar to the bottom grabber). I built a 'toucher' attached to the rotating part of the large turntable, and this seemed to compensate better for the twisting of the other LEGO elements of the grabber during stiff turns. </p><p>The disadvantage of the touch sensor approach, of course, is that the grabbers can no longer make a full 180° turn, so there is more time taken repositioning the side grabbers. The robot averages one face rotation every 30 seconds (i.e., a 20 rotation solution takes about 10 minutes). The final problem is making sure that the faces of the cube are kept in orthogonal alignment. A standard Rubik's Cube has side dimensions *just* larger than 7 LEGO studs. Fortunately there is enough flex in the joints of LEGO Technic to absorb the tiny additional dimension. Each grabber arm is fitted with reverse slopes that force the cube into the correct orthogonal alignment as the grabbers close. </p><p></p></font></td></tr></tbody></table></p><p><br/></p><p><table cellspacing="0" cellpadding="10" width="100%" border="0"><tbody><tr valign="top"><td><font face="verdana,arial,helvetica" size="2"><img height="326" alt="CubeScan software screenshot" src="http://jpbrown.i8.com/CubeScan1.jpg" width="441" border="0"/><br/> </font></td><td><font face="verdana,arial,helvetica" size="2"><b>5. Establishing the initial (unsolved) state of the cube</b><br/> <p>The longest part of the this project involved writing the color-recognition software. I downloaded the Logitech Quick Cam SDK from the <a href="http://developer.logitech.com/">Logitech Developer's</a> site (the LEGO Vision Cam is a repackaged Logitech Quick Cam) and used VB5 to write a fairly decent program (click the Code link for source). The color recognition is fairly robust (about one error every two cubes when well-calibrated), but not perfect, so I incorporated a feature that requires you to confirm that each face has been correctly scanned (and, optionally, allows you to correct the input manually) before it scans the next face. </p><p></p></font></td></tr></tbody></table></p><p><br/></p><p><table cellspacing="0" cellpadding="10" width="100%" border="0"><tbody><tr><td><font face="verdana,arial,helvetica" size="2">The software requires calibration with a solved cube under the particular lighting conditions, and it is quite finicky about changes in lighting conditions. I also left in the earlier manual input option so that you can get a solved cube for calibration, or in case anyone who doesn't have a Vision Cam wants to try this. <p>Briefly, the software sends a message to the top RCX asking it to present one face of the cube to the video camera. The computer captures a frame from the video camera, and scans a 50x50 pixel area of each color patch to find the median red, green and blue (RGB) color values for each color patch on the face. The RGB values are converted to CIE X Y y coordinates, and then the CIE values are trigonometrically compared to the calibration values to find the closest match. The computer then asks the robot to show it the next face, and the process is repeated until all the faces have been scanned. </p></font></td><td><img height="266" alt="CubeSolver, lighting" src="http://jpbrown.i8.com/Cs_lx.jpg" width="350" border="0"/><br/> </td></tr></tbody></table></p><p><br/></p><p><table cellspacing="0" cellpadding="10" width="100%" border="0"><tbody><tr><td><font face="verdana,arial,helvetica" size="2"><b>6. General solution to the Rubik's cube</b><br/> <p>There are any many general solutions to the 3^3 Rubik's Cube on the internet (see <a href="http://www.rubikscube.com/cubesolutionother.html">here</a> for a partial list). However, most of these produce a sequence of moves involving 50 or 60 face rotations. Given that CubeSolver moves quite slowly (averages about 30 seconds between face rotations), I wanted a relatively short sequence of moves. Fortunately, I found some <a href="ftp://ftp.externet.hu/pub/mirror/sac/educult/miker.zip">C source code by Mike Reid</a> on the internet which implements Herbert Kociemba's solution method: it provides short solutions (< 40 face rotations). I ported this code to Microsoft Visual C++ and recompiled it as an OCX for use in Visual Basic. I must say that Mike did a very decent job with his code -- move sequences are generated quickly, with a length usually about 20 moves or less. </p></font></td></tr></tbody></table></p>
[此贴子已经被作者于2006-11-8 3:04:35编辑过]
<p>长见识了～～～～～～～</p> 顶啊~~ 顶，太强了 那个小朋友打乱的步骤太少了，看不出来这个机器人用什么方法还原的。从视频上来看好像用了8步，应该是穷举计算的最小步吧。如果打乱的步骤多了，就不能用这种办法了，没准也会用层先法或者CFOP？ 我是新人,连图都看不明白,郁闷 不知道最快速度是多少 顶啊 太牛了 呵呵...強....頂一個!
页:
[1]
2