This is only my second post although I’ve been lurking around the forums for about a year now, being constantly dazzled by everything that’s being done around here!
I’m looking at developing a closed-loop, adaptive terrain adaption system for a 4DOF hexapod (24 servos!). My idea is to play with code for a while and maybe get to a point of running a simulation.
I have developed the understanding that many around here tackled writing their own “IK solver”. I know at least Zenta and Xan did
Since I’m aiming to tackle a 3 joints leg (instead of the common design of two), I would imagine that there would be a slight difference to resolver equations. Besides, It’s going to be necesary to play with a lot of math integrating the AI with the IK equations.
Not to make it any longer, I was wondering if any of you guys who developed their IK solver engines from scratch can point me to resources that would help me develop my own. To be honest, googling the subject has proven itself to be a bit challenging and many results that I found looked quite out-dated.
Another thing that I would love to understand (even a very brief explanation would be appreciated) is what’s called “The Balance mode” in Pheonix. After watching the video when balance mode is off, I can notice some changes when it’s off but I can’t quite figure out what. Is it something that guarantees a fixed height of the body? A fixed tilt? Both?
Sorry if my questions don’t make much sense. After all, I’m a newbie
Very fun and interesting that you mention ideas for a project like that, because I’m actually thinking about doing the same
I would recommend taking a look at this sheet made by Mike Keesling.
The 3 joints are going to be a challenge since they give an endless amount of different solutions. I’ve found a way around it by using a little algoritme that define the angle of the end effector (the wrist) has to the ground. I can’t say much more about it until I’m finished with my own project… (I’ve not even started building it either…, this should be one of my next projects.) Maybe you beat me to it though.
Try to imagine the legs as imaginary springs between the coxa joint and the tars (foot). The body are constantly balanced between the six springs. I solved that by calculating the necessary amount of rotation and translation the body needed to do for holding the balanced position.
Thanks and cool! Is it the 4DOF configuration or terrain adaption that you are after? Or both?
Thanks for linking that. It sure is handy. But isn’t it just a simplified version (in addition that it’s for an arm-though obviously the same concept) of your IK generation sheet? Do you know of any papers/books that would describe the whole solution approach(s) mathematically?
EDIT: Funny how I did not notice that Mike’s sheet facilitates 3 joints. Which, for my setup, would proof more than handy. Thanks for linking.
Heh. No problem And I can almost see what you’re saying, I’m considering using pre-calcuations by applying some Fuzzy logic learning. Something like what’s applied here: mathworks.com.au/products/fu … depad.html
I doubt that my current budget will allow me to do that A lot of things will need to be done before spending a couple of grands on an awesome robot.
Ah. Thanks for clarifying that. I can understand now why the tripod gait looks funny while balance mode is on
Hi, yes. I have created my own IK solver engine from scratch. I had to go through pages of calculations before I got the handle of IK. Here’s the thread that shows you want I have done with the engine.
One key step is to know how to model the limb using Denavit-Hartenberg Parameters. After that its a matter multiplying matrices to arrive at the equations.
Yes. The math does seem very intimidating. But try to get a grasp on the Denavit-Hartenberg Parameters first. That was how I started and that was 3 months ago.
Don’t worry. We’re all here to learn from each other. Sorry if my answer seems too vague. Let me know if you need more clarification.
Your project is quite brilliant. And thanks for pointing me to a point to start with (Denavit-Hartenberg Parameters).
Reading about your future intentions to integrate servo step generator reminded me of the other question that I had; Normally, the target joint angles are almost never identical. And I would assume that in order to achieve a smooth transition between one leg state to another would require each joint’s angular speed to be different. Am I correct? And if yes, do you achieve that by dividing the movement into steps and feeding them to the servos?
Thanks. As I mentioned, I’ve been lurking around the forums for some time now and it’s amazing how everybody around here is always willing to help and share the knowledge.
Yes, that is correct. Of course it’s up to you to determine the number of steps between the start position and the end position.
Also, looking back on my IK notes, I actually used trigonometry to derive the equations. I would like to correct myself that I used the DH parameters to solve for the Forward Kinematic equations. I did the derivation for both FK and IK just to check if they gave consistent results, and they did.
If you’re having a hard time with IK, if I could find the time, I’ll try to document my calculation notes (they’re scattered all over the place) into a neat document so at least you and others would have some idea on how to I derived my IK equations.
Great. And I understand that the number of steps may depend on the physical constraints of the leg at certain point. I’d like to tackle that and I think it’s going to be fun!
Having said that, did you (or anyone else) ever tried modifying the speed of the servo (only applicable in digital servos - eg Dynamixel) instead of dividing movement into steps? It looks like it might work in theory when using such servos but I have no idea how if it would in the real world.
If you ever get around doing that, it would be ultra super awesome! I understand how scattered the derivations can be, so it’s cool if you don’t get around organizing them.
Then again, if you ever do, I would personally owe you a beer!
Theory of Applied Robotics: Kinematics, Dynamic, and Control
by Reza N. Jazar
This is THE book that I use as a reference for figuring out how to apply kinematics…
It mainly talks about robot arms and its end effector like all other robot-related kinematic books, but the concept and the theory is the same weather it’s an arm or a leg…
4DOF will be quite a challenge but not impossible…
The first task is to come up with an engine where you feed it end coordinates and try to figure out and model out the trigonometry that’s involved in how to solve for the servo angles in order for the end effector (the tip of the leg) to arrive at those coordinates…
Once you solve for the angle, figuring out how to convert angles to servo pulses is a snap (it’s just simple algebra)…
Once you have that tackled, then it’s time to translate your body (body of the hexapod) to each local (legs) coordinates… Then you feed it into your engine where servo pulses are calculated, and then “step” it finely to that end point.
One tip is, even if you calculated the servo pulse needed for the end point, you’ll have to step it or else your hexapod will seem like it’s twitching… If you finely step it, then it’ll seem like it’s walking…
This books looks exactly like the material that I was looking for. Thanks a lot.
Thanks for the explanation. And I can see what you mean about why the angular displacement should be stepped. However, I do intend to try out the speed control in a DYNAMIXEL servo. I don’t know how low can the angular velocity be though and if it would work in a real world scenario. But theoretically, if I’m going to calculate thetas and giving that both servos need to get to their designated position at the same time, speeds (or rather, speed multipliers) can be derived and sent to the servos.
If you are thinking about using the “speed” regulation built into the dynamixel servo - don’t. The speed regulation is very crude, it simply limits the max voltage output, it is more intended for using dynamixel servos in continuous rotation. If you use the speed regulation built into the servo in a walking bot, you will end up limiting the strength of each joint.
(My mech, Issydunnyet, had exactly this problem, it wasnt until after mech wars that i found out how the speed regulation is implemented and when I started doing interpolation myself, Issy became 2-3x stronger)
Try to implement lookup tables rather then actually solving for sin/tan/cos values
I believe that’s what Xan is doing in his latest code. The code for the phoenix… I think I read somewhere “cant remember where” but someone said that the current 1.3 code on the phoenix is near maximum cpu usage “16mhz” and that’s heavily weighted on the calculation of sin/tan/cos values were a lookup table would save valuable cpu time!
Since these robots are so small you could probably getaway with solving for single degree’s rather then fractions of a degree.
I think Zenta and I are the only people with a t7c controlled pheonix “Radio Controlled” and I see it slow down quite a bit do to solving of the IK values… mainly because pulsin command is sucking up time / resources
Ah. Now I see why they don’t specifically state the minimum speed limit in the AX-12 manual. Well, I guess that takes down one of my main reasons of considering the AX-12 in the first place. I guess controlling 24 servos via a single, half-duplex port might result in some performance issues. Not to go more off-topic here, but since you already have an experience with the AX-12 in a multi-leg, do you think that a hex with these servos can move its joins as fast as other star hexapods, like Pheonix for example?
Indeed. A lookup table would make a world of difference especially for a limited CPU. Besides, such tables are really a snap to generate. And yes I do remember reading a todo in Xan’s code to implement that.
I can’t say for sure. I don’t have the slightest idea of how accurate things should be at this point. After all, these things comes only after practical experience. It’s worth noting, however, that if using whole degrees instead of fractions is possible, deriving the lookup tables would be much easier.
I think the original Powerpod code had at least one trig look up table. So 128 values would give slightly less then a degree. Remember that the servo command word (byte) is limited as well. So integers are the rule. However I did use floats in my first hexapod robot code…
Cool, well 128 should be enough indeed… “as its already working”
Anyway I base this theory on simply a guess… these robots are so small 1-2 degree errors on a foot print of about 2-4 inch maximum reach for each leg would not be as noticeable compared to a 2-4 foot reach.
Another note someone mentioned to me a programmer who has been doing C code a while told me that a lookup table can be 100-100k values yet the speed of the actual look-up remains the same.
Also based on the size of the robot the values wouldn’t even have to be that accurate, floating to the 100th place 13.45 vs 13.45234235 <-- seems like its a waste of memory space.
Granted this is all based on the accuracy of the IK and the physical size of the robot… I don’t have my bot in front of me or the code I’ve been poking around with but I know Xan’s Phoenix code was quite accurate! and I don’t recall what it floated out too “all said and done” after the IK equation was complete… someone else can chime in here.
all said and done smaller the robot the sloppier you can be with the IK before you see physical walking issues.
I’m only basing this off the AtomPro module also.
–Aaron
KM6VV – on another note… It seems like the IK should be designed based on the limitations of the movement of a servo. No point of having IK more accurate then the servo can display… Vastly dependent on which servos you use… I’m no servo expert.
Not like were using .1deg pulse stepper motors geared at 1000:1 .
It’s not really that the 'bots are small, these angles are all about the scale. Well, mostly. You get down to the granularity of moves your “servo” is capable of making. We don’t get all that much for our R/C servos. “Commercial” servos would be a different matter… you’re right.
On the tables, Indeed all we do typically is calculate an offset from a memory address. But the SIZE overhead of a large table would quickly kill us for much more resolution. An in the case of the '876 and family, half of the table is WASTED, as table look-ups are often implemented as a call and return i.e., subroutines (the same way in the Basic Atom, unless I’m mistaken).
13.45: an integer could be one byte, a float is usually 4 bytes, and a double a full 8 bytes. Take your pick! And of course the float and double calculations take a LONGER time to compute, as we don’t have FP instructions available to us. I do like to study the calcs with FP and the resolution “turned up” so that I can follow the numbers better. And of course with integer-only calculations you can get some round-offs in the calculations pretty fast. And again, we don’t have to do PID calculations in our “servo” calcs.
Yes, Xan’s Phoenix code is closely tailored to the available resolution in the R/C servos. And he’s proven that the work!
Yeah I WISH I could user stepper motors in a 'bot of this size! ( I like stepper motors) The weight-to-power ration of steppers just won’t allow it. The other choice would be industrial servos and their attendant controllers; you think our R/C servos are expensive!
Clearly the acceptable resolution tolerance does to some point depend on the dimensions of the leg itself. Consider that in my particular case, I’m designing a 4 DOF leg, which means an extra leg element and hence a longer leg. Still, rounding to the nearest full degree would definitely not affect the gait itself.
Having said that, and I may be very well mistaken here as I need to experiment, I think rounding should be done at the end of the process. Meaning that you use FP calculations for the math, and when you get to the point of sending it to the servo, you round (or trim rather) the fractions.
Obviously the design of the program itself will depend on which chip you’ll be using and what power it can give. But for the common micro-controllers wouldn’t it be better to retrieve an element from an array (the lookup table) than having to evaluate many trigonometric functions?
I think it all depends on the setup. My initial plan is to code and test the initial solver on a Pentium and then optimize for speed if/when another processor/controller is intended to be used.
A lot of things will need to be done before spending a couple of grands on an awesome robot.