You can always slam in a BS2 just to get 'er goin'! I'm also a fan of Pololu's $20 micro Maesto controller.
You can always slam in a BS2 just to get 'er goin'! I'm also a fan of Pololu's $20 micro Maesto controller.
@Erco, with this 32 bit floating point MCU I could probably do the whole project with the BS2:
http://www.parallax.com/Store/Compon...1/Default.aspx
Add that servo controller and who needs the Propeller chip!
@doggiedoc, thanks for the compliment. I am lucky to have an amazing old fashioned hardware store near me. It's owned by two brothers who have nearly everything tucked away somewhere. Usually on the stairs behind one of the ladders. They often get a kick hearing about what I'm building because I often ask for uncommon items.
Martin, you'll need an amazingly large humanoid to accommodate two of those powerful arms!
After a month of distractions on other things which are generally known as life (i.e work, parenting, family, etc). I finally got my inverse kinematic transform working! So I put together a motion script of the arm solving Air Tower of Hanoi. It's what robots do instead of Air Guitar!
Let's just say inverse kinematic transform bugs would make a pretty interesting out take reel if I had the presence of mind to video tape them.
Sa-Weet, Martin_H! Theoretically, anyway! Let's see some real disks get moved around soon. Make 'em lightweight to minimize dynamic effects; your arm is moving nice & fast. My cheap little arm had some shoulder shudder, so I programmed it to move slowly & stately: http://www.youtube.com/ercost60#p/u/14/-Z8lTSX4PHs
Erco, thanks. I shall work on the posts and disks as soon as time permits.
I never noticed the shoulder shudder on your arm, but watching the video again I see it ever so slightly. Do you think it's related to gearing in the servo or just a large rotational inertia?
Right on both counts, plus I didn't do any velocity ramping (decelerating) there. I rushed that code back then to "git 'er done" but now have it operating more smoothly, with ramping and damping. I have unlearned much that I have learned...
Hey, virtual Hanoi Brother: there may be a movement error in your sequence. You move disks 1 & 2 sequentially to the far left post properly, then you move disk 3 to the middle post properly, then at ~40 seconds, you drop disk 1 on top of disk 3 in the middle instead of going to the far right post. Let me know if I'm going senile early...
One of the ToH descriptions I read says that disk 1 (the smallest disk) gets moved every other time. Further, it always moves one position in the same direction, except when it jumps back to the beginning. For instance:
left center right left center right etc or right center left right center left etc...
Since you're doing inverse kinematics, this may be an easy pattern for you to code.
check this for repeatability: http://www.youtube.com/watch?v=8jajn...eature=related
and this: http://www.youtube.com/watch?v=1qpc4G3NQhk&NR=1
and this: http://www.youtube.com/watch?v=8jajnIBX2cU&NR=1
You can find details on their site (http://www.01mech.com/supermodified).
I quickly used three pieces of paper and twice followed the virtual post to post moves. The solution does move a three disk stack from our right to our left, and moves the small disk ever other time. It looked to me like the small disk moves across the three posts in the same direction, hits an end post, and it reverses direction. But with virtual disks and shadowing moves it is possible I missed something. It will become more apparent when I switch to real disks.
You're correct that inverse kinematics will make fixing any glitches like that simple. The coordinates of the moves are all computed, at the moment the only hard coding is the post to post move sequence (1 to 2, 2 to 3, 2 to 3, etc). I'm going to add code to generate that, but I didn't want to deal with recursion in Spin just yet. I'll post the code when I am done.
The ultimate one plus would be adding some kind of sensor to the gripper, have it count the disks, and solve the problem in the general case for any number placed on the first stack.
The sooner you get it going, and the faster it can move (as long as it can handle 64 disks), the sooner we are to the world ending. From
http://en.wikipedia.org/wiki/Tower_of_Hanoi :
The puzzle was invented by the French mathematician Édouard Lucas in 1883. There is a legend about an Indian temple which contains a large room with three time-worn posts in it surrounded by 64 golden disks. Brahmin priests, acting out the command of an ancient prophecy, have been moving these disks, in accordance with the rules of the puzzle, since that time. The puzzle is therefore also known as the Tower of Brahma puzzle. According to the legend, when the last move of the puzzle is completed, the world will end.[1] It is not clear whether Lucas invented this legend or was inspired by it.
If the legend were true, and if the priests were able to move disks at a rate of one per second, using the smallest number of moves, it would take them 264−1 seconds or roughly 585 billion years;[2] it would take 18,446,744,073,709,551,615 turns to finish.
A spin on Arthur C. Clarke's "The 9 Billion names of God"? :-)
http://downlode.org/Etext/nine_billi...es_of_god.html
Amanda, thanks for the compliment.
I had to work yesterday, so today I've been making the disks and pegs. I'm only planning on moving 4 disks because 64 would require much better batteries!
So last weekend I made the posts and disks, and glued a large washer to each disk's top. I also hot melt glued some magnets to the tip of the gripper fingers. The robot will grab by touching its magnets to the washer and lifting. It will drop by opening the gripper and breaking contact with the washer. I also ported a recursive version of tower of Hanoi to Spin and it works fine. So far so good.
But when I tried to get the robot to play a game this weekend, I hit a snag. My my kinematics look good, but there are still some lurking bugs. Basically the kinematics are internally consistent, but not aligned with the real world. So while I know the disk height and post spacing, the arms isn't lining up. So I have more debugging to do.
WHAT??? Real-world physics/kinematics/repeatability issues not meeting your expectations and simulations? HEAVENS to Murgatroyd!
That's robotics, my friend!![]()
Erco, are sure you don't want to change your avatar to this guy:
![]()
Martin, very nice project. If there's some depth to the hardened object to be picked up, a short sweep with ultrasonics will isolate its center position. I'm also thinking that something could be accomplished with some HALL effect sensors.
Martin: At some point, we have to have dueling robot arms doing a swordfight. How retro/cool would that be?
Lightweight Nerf swords, but cool nonetheless!
Erco, it would be cool, but we're going to have to build bigger arms to reach from the East to West coasts! :^)
Bookmarks