inverse kinematics
Britannicus
Posts: 98
Well, I'm just about to bolt the legs on my bigger hexapod this Friday - key milestone as I get all 12 Sevos in place. I'll be posting some pics soon. Ultimately I hope to go to independant 3DOF legs and 18 servos, but one thing at a time !
I have a Prop based servo controller with which I plan to wiggle them in the appropriate order to do the usual hexapod dance we all love to see on youtube.
I'd simply thought to define a series of constants for each servo (forward/ back/centre up/down/centre for a 2DOF leg) then to string each step command with 12 out of the 36 options. This seems to fit with how the PROP servo controller likes things, if I understand it right. I found this quite easy for the 3Servo hexapod I posted a bit back.
BUT !....
I hear discussions from time to time about Inverse Kinematics. I think I understand the concept ("I want to move the leg to position A - go calculate the angles of the servos") . What I'm uncertain of is how (or if) the IK approach is really implemented with kit like the STAMP - is there anywhere I can get my hands on some "IK for Dummies" type stuff? I'm figuring this might take me into the realm of something more complex than SPIN - so I might get scared at this point - but hey ! nothing ventured nothing gained they say
Maybe some of you good chaps out there have code you could share either for STAMP (which I use now) or Props with SPIN, (which I intend to dabble with once I get my head above the inbox).
I have a Prop based servo controller with which I plan to wiggle them in the appropriate order to do the usual hexapod dance we all love to see on youtube.
I'd simply thought to define a series of constants for each servo (forward/ back/centre up/down/centre for a 2DOF leg) then to string each step command with 12 out of the 36 options. This seems to fit with how the PROP servo controller likes things, if I understand it right. I found this quite easy for the 3Servo hexapod I posted a bit back.
BUT !....
I hear discussions from time to time about Inverse Kinematics. I think I understand the concept ("I want to move the leg to position A - go calculate the angles of the servos") . What I'm uncertain of is how (or if) the IK approach is really implemented with kit like the STAMP - is there anywhere I can get my hands on some "IK for Dummies" type stuff? I'm figuring this might take me into the realm of something more complex than SPIN - so I might get scared at this point - but hey ! nothing ventured nothing gained they say
Maybe some of you good chaps out there have code you could share either for STAMP (which I use now) or Props with SPIN, (which I intend to dabble with once I get my head above the inbox).
Comments
http://rtss.sourceforge.net/docs/index.
Arm.spin
I probably have a newer version of that code now. It's possible to do trigonometric transforms in PBasic, but the lack of properly signed arithmetic will drive you nuts. If you want to use a stamp consider getting the floating point co-processor Parallax sells as there are inverse kinematic samples for it.
Inverse kinematics are nearly an absolute requirement for an arm, but a leg might be able to get away with a hard coded motion script. Basically the leg has a lift up motion, and a push down and back motion.
Love,
Cranky old man erco
Martin I'll have a quick squint at your code - really appreciate your sharing.I've no experience of Spin, but it doesn't look so scary.
Leon - I'm getting the dreaded 404 when I try your link, but I can already see that I'm going to have to brush up my triganometry - last time I used it in anger was 25 years ago as a student doing mapping. I think for the moment I'll stick with a fairly "stompy" up/down/ centre approach with thecurrent bot before I try doing anything more fancy. When I get to mor DOF on each leg they start behaving more like an arm (but six of them !), so I'm seriously going to have to look at and understand this to move on.
Erco - I appreciate your zeal for the stamp, but I still prefer a glass for my beer !
http://rtss.sourceforge.net/
I think it was Beau who posted an incredibly ingenious scheme for reading an analog servo's position using lower voltage and a frequency sweep. I can never find that post when I need it. PLEASE MAKE THAT POST A STICKY AT THE TOP OF THIS FORUM. It should be required reading for any would-be roboteer!
Once you record a few critical frames of robot arm/leg positions, you could connect them all with IK.
And a STAMP!
Edit: Found it at http://forums.parallax.com/showthread.php?84991-Propeller-Application-Proportional-feedback-from-a-Standard-Hobby-Servo-(Upda&highlight=read+analog+servo
Cheers LEon - seems to work, just ned some time to look at this and understand it !
It's likely I'll stick with brute force canned scripts, simple processors & cheap servos in the near future, but I want to make sure I'm not missing out on anything juicy.
The reason I like inverse kinematics is that they let you work in Cartesian coordinates which are easier to programmatically generate. So my tower of Hanoi can support any number of disks (when I solve the gripper problem). I think you could also add a g code front end. At that point use CAM software to generate gripper paths, but I am still learning about this.
I can see the appeal of motion scripts because you trade away complexity, but generation of the scripts seems like a fair amount of work too.
Far more importantly, Inverse Kinematics is just a cooler buzzword.
Sorry, I haven't been following this thread lately. (I think this is my first post to it.)
Yesterday, I was trying to figure out how many floating point trig calculations I could do within the 20ms refresh period of servos. (I want to add a pendulum type motion to my servo demo.) It turns out there's enough time to do several FP trig calculations on 32 servos within 20ms. Lonesock has really sped up the Propeller's ability to do floating point calculations with his object F32.
So if you're only using the 18 servos most hexapods use, there should be plenty of time to compute inverse kinematics with a Prop.
I haven't looked at Martin's code yet, but some sort of inverse kinematic pseudo sinudoidal beast is in my future. I didn't buy all those servos to leave them taped to a board.
I would like to comment on this because I have made a bunch of walking robots with propellers and I have experimented with IK code, interpolating from a table of positions, and a technique called central pattern generation. By the way, they all work. IK is probably the most versatile. But when you get to twelve or more servos the calculations are not that fast and the code and variables really eat up space on the chip. You need the FP library, a lot of code to do IK, and a bunch of memory to store the position and orientation of each joint.
The other part of the problem is, once you have an IK system what are you going to do with it? If you are going to cycle six legs through the same relative positions as you walk you are going to be doing the same complicated calculations over and over again. You might as well store the results in a table. You will save on memory and free up the processor to calculate. IK is potentially really useful if you are integrating the position of the legs and body with sensors like an accelerometer and touch sensors to alter your stance dynamically. That's more complicated then writing code to get three joint positions from three coordinates. I can't say for sure, but I think that is getting beyond the processing power of a prop chip. I think it would make more sense if you were using the prop for IO and doing your dynamic position calculations on a small ARM board.
George,
Thanks for your comments. I've been hesitant to reply since I have very little experience with trying to build a walking robot When you made your post I hadn't any experience.
I've been working on a hexapod over the last few weeks. As I've tried writing code for the bot I realized three legs are making very similar movements with each step so instead of having to compute the servo position for all 18 servos, one only needs to compute the positions for 6 of them (and 6 mirror positions which are simple to calculate).
With my attempt at IK, these 6 servo calculations take about 7ms including all the overhead to make updates to the servo object. I personally think all 18 servo positions could probably be calculated within the 20ms servo refresh period. I'm not very confident I'm using the optimal calculations for IK. There may be some tricks I don't know to simplify the calculations. I wanted to try writing my own IK algorithms so I haven't looked much to see if there are faster ways of computing the needed angles.
I'm relatively sure the calculations could be sped up by not using floating point calculations for the legs return movement through the air. When the feet of the robot are on the ground, I want the feet to move in a straight line and at a constant speed with respect to the robot. These movements require the computation intense floating point calculations. However, the position and speed of the feet as they move through the air is not very important so these positions could be calculated with normal integer math. My current program uses the same computation intense IK algorithms for the return movement as it does for movement of the feet on the ground. Using integer math for the return movement is a way to cut the needed floating point calculations in half. So the current 7ms computation time should be able to be significantly reduced.
I wonder if you have used the souped up version of the floating point object? Lonesock's F32 (the souped up version I just mentioned) runs in a single cog (it used to take two cogs for the full floating point library). Not only does F32 only use one cog but Lonesock has also optimized many of the algorithms so it runs much faster than the original floating point library.
So far, my program uses three of the eight cogs. The main program uses one cog. F32 requires a single cog as does the servo object, bringing the total to three cogs. (I frequently use a couple of extra cogs while debugging.) My confidence in thinking the Propeller can handle all the IK calculations needed for most walking robots has been steadily increasing. I'd think the remaining five cogs would be enough to handle monitoring many of the common robot sensors and controlling many additional devices that are common in a hobby robot.
I'll agree there are plenty of tasks that are beyond the abilities of the Propeller (such some machine vision tasks) but I'm now pretty confident that IK is a task the Propeller can handle.
I built my robot out of popsicle sticks and small cheap servos. I'm afraid it's woefully too weak for its long legs. It might be able to walk tethered to a power supply, but my first attempts at having it carry NiMH batteries as a power supply have been failures. Hopefully I'll post pictures and video of my first attempt at a walking robot later today. While the robot has yet to walk, I'm relatively confident I have the IK calculations working. The legs look like they are making the correct movements through space.
Pretty heady math you're getting into there, Pal. Sounds like you're on the right track. When I see a hexapod or other walker, I watch how the feet contact the ground while walking. The good ones plant their feet and they stay in one place as the leg pivots around them. When they skid around (sideways or forward/back), there is clearly some more work to do...
Lots of tethered walkers out there, don't be shy. Servos need lots of current and batteries are heavy. Big stresses and deflections when servos support lots of weight and lightweight flexible legs are put to the task. The robot arm I built showed me that just moving itself around (no payload) is not a trivial task.
So don't wait until it's perfect. Start a thread and share what you've done so far!
Now you got me wanting to get on my Altoids quadropod...
Roger that.