I have just built up from scratch (by cutting lexan panels, etc…) a CH3R Hexapod.
I know that by using the POWERPOD Program, we can generate automatically the software needed to control the Hex by different means (PS, RC, Auto, Serial…).
In any case, I am quite obsesive with software and understanding. I have gone through the code and almost understood many of its parts. But as far as I have not a clear idea on what some variables are used for and also on the particular coordinates reference system location, it is really difficult to understand the software completely.
There are some parts (in particular with angle transformations) that are not completely clear to me.
I think that some more comments about the software would really help me out (maybe commented on the code itself).
Does anyone have such a information??
It is just for shake of a good understanding and learning.
I could deduct the equations used in POWERPOD program for the Hexapod CH3R. It was not really easy (i wanted to gain some time with my question from yesterday). The point is that when it is not known which is the reference coordinate system and how the angles have been choosen, is not so easy with the software.
In any case, I am commenting the program and I will be glad to send it to anyone interested.
The main fact is not forgetting about the cosines law in one of the angle calculations… for the IK (I had very forgotten this law and this caused me trouble yesterday).
I’m interested in gaining a better understanding of the program generated by PowerPod as well. I’d appreciate hearing about your progress. I’d like to write an equivalent program in C for execution on either an 18F PIC or Atmel ARM7 processor, my proposed 'bot computer. I’ve also been considering a C interpreter (C terp).
I have not had time enough yet to write comments on the program created by Lynxmotion (PowerPod), but I have understood most of the geometric transformations made to calculate the angles.
I still have some problems with a couple of formulas (giving basically the increments for the movements of the legs), but concerning the transformations is more or less clear.
I will try to work this out during this week if possible (commenting the PowerPod program and making a few drawings. If you give me your e-mail address, I will try to send you some of my progress.
But basically this concerns to Inverse Kinematics angle calculations. You set up the positions for the tips of the legs and then you just calculate which angles you need to use at the Knee joint, Hip Vertical joint and Hip Horizontal joint.
The program uses several variables that are not 100% clear to me (I´m still working out on them.
If you guess something about the global variables, I will be also glad to receive your comments.
Thanks for the Reply! Good to find someone with a similar interest in better understanding of the programs.
I did find an animation of a leg, and some C code for IR on the Lynxmotion website. Now to study it. Does the PowerPod program actually calculate IK, or just “alter” the parameters of a gait generator, as I believe the Gait Generator in SSC32 does? I’ve written CNC controller programs, and generated tool paths for it (Gcode programs). CNC MIGHT be a little similar, however I run 3 or 4 Cartesian axis, while a robot leg might be thought of more as a rho-theta mechanism. Just a little trig. ;>)
That would be great! I’m KM6VV at ARRL dot net (just to fool the spam robots). I also sent you a private message with my email address.
The basic program created by PowerPod does calculate the IK for each of the six legs in real time. 8) In fact it continouously updates the end point of each leg as it’s in motion. That’s why you can change direction or any other property in real time. (You don’t need to wait for a sequence to finish moving)
The program, (as far as I could see) is actually calculating 3 angles: HIP HORIZONTAL, HIP VERTICAL and KNEE angle. These angles are calculated through geometrical (sines and cosines) transformations of the 3 dimensional coordinates (X, Y, Z). So that, in fact, the program is calculating the IK and not using any sequence by means of the SSC-32. You can see on the last part (bottom end) of the program that the parameters for the leg movements are given in function of some variables related to the calculations.
If the program was using just the SSC-32 sequencer, then the Serial Command to the SSC-32 would include some of the special commands for HEXAPOD sequencing.
Actually I am waiting to receive a Basic Atom for my Hex and I could not make some more tests. I was trying with a BX24, but the instructions set and some of the variable types were quite limiting and it meant a lot of re-programming work. As I did not understood some of the variables in the program, I could not translate properly the program to my BX24.
As soon as I get the Basic Atom I will try to revert also with some more information on some of these unknown variables (as I will be able to check them).
The SSC-32 is just an advanced servo controller. With the 1.06 firmware, it is just that, not a sequencer of any sort. All the SSC-32 does is execute servo moves in commands sent to it from a microcontroller or PC.
The SSC-32 does not process information calculated using IK. It just executes commands.
I’m still plodding along trying to get the BASIC Atom code to compile under PBP (PIC BASIC PRO). The SBYTE, LONG and SWORD variable types are hanging me up at this time.
I just found out from PBP that they DON’T have a long, and they don’t have signed bytes or words (or FLOAT/DOUBLE, either). The IK3DOF.C program (author?) uses FLOAT. I’m used to more code/data space; I’d probably start off with DOUBLE!
Oh well, I can either buy an Atom or do it in C on one of my own boards. Another Mega8, Mega16 or Mega168 processor and the CodeVision C compiler (used for SSC32 code) might make an interesting 'Bot board (I like using what I have on hand and am familiar with). I ordered this compiler from Priio, along with a nice MegaAVR-DEV-16 board. I know, maybe we can get Gay Laurent to make a PowerPod program for generating code for a Mega 8,16,168 processor! ANYONE INTERESTED IN THIS?
I see the three angles. And some XYZ positions. Just adding (HipV_HipH + Femur_Length) bothers me for the time being, as the two portions are of the leg are not in line. Also (Tibia_Length + Height) for the same reason. Maybe they gets corrected somewhere with a cos() function. As I said, I haven’t fully studied the code yet.
I did find AorB_Up & Down interesting. They fill up the XYZ positions for the 6 legs in either the UP or DOWN position. It’ll be interesting to see (learn) how this all works out!
Yeah, the IK and gait generation calculations are all running in interpreted BASIC on the ATOM. The SSC32’s job is to take these sets of commanded positions (waypoints) of the robot’s gait and to smoothly sweep the 18 servos between these waypoints. An Arccosine table is used for some calculations, and the calculations appear to be in longs, not floats. That would speed up things.
That could make the job easier! And then the BASIC Micro IDE would fully run (It wants an Atom connected). What variables do you have questions about?
I did find some spread sheet (XLS) models of arms, but no legs. I liked the animated one I found. Looks like a good project for Visual Basic (VB6), if I were a windoz programmer. ;>)
We can also take this off list if desired (by anyone).
First of all, I have had a look to the recent posts on this thread. I have a reply to Linuxguy concerning the SSC-32. First of all, the SSC-32 is an advanced servo controller (no doubt, that is right). This board holds an ATMEGA8 Chip which is in fact programmed with the firmware 1.06. Thanks to this sequencer program you can send group commands to the servos or even you can make the Hexapod walk using tripod gaits by means of a couple of serial commands (otherwise you would need one command per single movement… just make your calculations for a tripod gait).
Comming to your last post Alan, most of the comments seem quite interesting, but I think I have a similar problem to you concerning the programming. I have been a long time not so involved with programming and I am having some trouble. My decision to go for the ATOM chip is just based on time. The translation of the original program in ATOM to another BASIC IDE for any of the available basic interfaced chips is possible (with a bit of time, of course).
In any case, it seems quite elegant, clean and fast the way in which some variables (SWORD types mainly) deal with the variable ranges (-127 to +128). IF these variables and their influence in the overall program are not understood properly, then any translation to other BASIC IDE Based chip would mean a considerable time investment. This is the main reason for me to go for the ATOM and make some testings with the Chip working and with modifications in some of the variables not fully understood.
In my following post I will try to explain what I have guessed about the program. I could not comment the program properly yet, but I will try to do it during this weekend and I will send it by e-mail to everyone requesting it. I will also try to prepare the mentioned pictures depicting the angles, etc…
I’ve actually got the SSC-32 code compiled and running on an SDK-500 (Atmel) Development board, but I still haven’t built up the SPI-interfaced chips (74HC595) that buffer out the 32 bits to drive the R/C servos. (an SSC32 should arrive tomorrow!) I even designed and laid out a PIC powered board to do a similar task. Not built; as I hadn’t fully figured out how to implement the ISR to service the SPI bus.
Mike’s code for that ISR is very tightly tied to the ATMega8 chip used, making it a difficult port to another family of processor. An elegant piece of code, to say the least!
I work with C programming daily (PIC and Atmel) so no worries there. The PBP BASIC was a little discouraging. We might still use it for some simple test software. The use of signed and unsigned variables of different sizes is one of the main properties of a good computer language. Yes, they have to be used wisely (accurately sized), or errors will result! In C some of them would be signed and unsigned; byte, integer, and long integer. After that are floating point variables of different precisions. It would be useful to “get comfortable” with the original code on a BASIC Atom, (that was my plan for the SSC32), but I don’t have the $100 to get one. It would be nice to be able to borrow one! But I think I can do without. More comments would be great, but remember that this code is “generated” by another program. Canned pieces are combined to create programs for a variety of different hexapod configurations! Maybe the extra comments would have “just taken up too much room”, and “nobody will read them anyway”. ;>)
I want to become fully familiar with IK and the generation of gaits, so this is a good place to start. I have two additional papers on IK, (both in C!), so now I have the material I need to start my study. Basically it’s working backwards from the foot location. The intersection of two arcs is used. That and the scaling to servo pulse width values
I look forward to that post!
Best Regards,
Alan KM6VV
P.S. Ancient Discoveries : “Robots” is on the History Channel as I write this! Seems Leonardo built a “robotic lion”, that exhibited quadruped locomotion, and even stood up on it’s hind feet! Spring driven, no less!
Dear Alan,
I tried to place this post in the forum before, but I really could not due to so much work during the last week. Anyway, it is better late than never! Ok, following I will describe what I know concerning the PowerPod self-generated program. I will not concentrate on particular variables but basically in the geometric transformations for the IK to work out the right Hexapod angles. I will describe my doubts and unclear points in case that you could see anything else and explain to other readers in the forum. I cannot place in this post the picture concerning the right axis reference system, but I am sending to your e-mail an image of it (I will send it also to anyone requesting this information).
First of all we have the variables definition. Here we must concentrate on the fact that some variables are defined with special ranges of -127 to 127. We also must notice that the real dimensions from the Hex Legs are defined under the names of the variables HipV_HipH (distance from Horizontal shoulder Servo axis to Vertical shoulder Servo axis), FemurLength (distance from Vertical shoulder Servo axis to Knee servo axis) and TibiaLength (distance from the Knee servo axis to the end point of the leg). These real measures (you can check the distances in your Hexapods) are critical for the later transformations concerning IK.
Second we can see the ARCCOS table. This table is scaled to 128 values comprising an angle of 90 degrees. We can see from the table that a cos x = 0 would mean a real angle of 90 degrees, and hence a value from the table of 64 (first position in the table or array). As the BASICATOM will process the angles like 7bits numbers, this is a good and fast approximation. On the other hand, a cos x = 1 would mean a real angle of 0 degrees and a value of 0 (in 7bits numbering for the microcontroller). We will later see that we make two real COS calculations with the BASIC ATOM.
Later on the program we can see conventional initializations. I.e. we can see the offsets for the servos and also a call to the routine H3Init. This routine is particularly interesting because we are fixing the INITIAL positions for the tip ends of the legs. We are defining their real positions in the true space. We see following the assignments for each variable:
XPos(Index) = HipV_HipH + Femur_Length
YPos(Index) = - Tibia_Length
ZPos(Index) = 0
As it can be noticed, by the use of these variables we are defining the Axis Reference System in one particular point (i.e. in the axis of the Horizontal Shoulder or Hip Servo). If we place the Reference System there, we can see that the above variables are quite logical. We do this for the six legs, so we actually know the exact position (in each of the 6 individual reference systems) in the true space. There is something else to do so that everything here is right. We should call somewhere the routine All1500 so that the Hex gets to the position described by the above variables. I think this is done in the Shunt routine and (depending on the control selected for the self-generated program) on other places.
Now that we have defined the initial position for the Hex and placed it into the right position, we have to face the movement. Depending on the type of control selected for our Hex, we will have increments in direction and distance which will be added to the actual legs position. These direction/distance increments can be given in different ways. I was checking the program self-generated with a PS2 controller. In this case, the angle given by the PS2 stick is calculated and later used for step calculations (or new position calculations of the leg tips). In other programs this method can vary. For the particular case of the PS2 controller, we can focus on the H3 label in the program (I omit the positions instructed to the Hex by means of the different buttons, etc… as this is out of the scope of the IK (they are direct commands to the SSC-32).
From the H3 label we can see that XSpeed and YSpeed represent the coordinates of the Stick movement in the PS2 controller. From these two coordinates we use the well known Pythagoras Theorem to calculate the Hypotenuse of the triangle made. With this Hypotenuse, we can easily calculate the Tangent of the angle formed by the stick and hence, the angle which is desired for the movement of the HEX. The ARCOS table is used to calculate this angle with good approximated values (we do not need too much precision here and we improve the speed of the program by lowering the calculating time of the BASICATOM with trigonometric functions). The final angle is Dangle variable which we can think of like DistanceAngle (indicating the intended movement for the HEX). Right after this angle calculation we can see the distance of the movement (the mentioned Hypotenuse) intended by the variable DCoord. But in this case it is not used the exact distance of the hypotenuse always. We can see that the value of DCoord is limited and will only be chosen when its value is bellow that of (128 - ABS(Height) - ABS(TibiaAngle * 2)). I really do not fully understand this limitation, but I did not care to much about it as I was focused on the IK transformations.
I did not study either the deck or grip movements.
Right after the grip and deck movement part of the program, we can find the following variables assignations:
XPos2(Index) = -(DCoord * COS(DAngle + (Index * 43 + 21)) / 300) ; 43 => 60 degrees
ZPos2(Index) = -(DCoord * SIN(DAngle + (Index * 43 + 21)) / 300) ; 43 => 60 degrees
Here is where we are starting to calculate the NEW positions for the 6 legs’ endpoints. This is denoted by the name of the variables (XPos2 and ZPos2). We may ask why the YPos2 is not calculated. In my opinion, YPos2 will be either UP or DOWN at fixed variables depending on the status of the leg (i.e. depending if the tripod belonging to that leg is UP or DOWN). Therefore, no new position calculation is needed here. The only variables affecting the new position are X and Z as the plane that they form is the one in which the movement (angle and distance) for the HEX is considered. Lets think about these two variables as the END position in this plane for each leg tip. Concerning the above mentioned variables, we can see the REAL Cos and Sin calculations in the program. The DCoord (Distance) is projected over each axis (X and Z) to calculate the new positions. The angle used is DAngle (calculated and explained before) + the index of this leg *43 (60 degrees) + 21. Ok, this is to be clarified. When we have the new positions calculated for each leg, we have to keep the axis reference system for each leg in the same direction (orientation), or otherwise opposite legs would move in a completely opposite pattern. Therefore we have to account for the 60 degrees of difference between each leg (round HEX) by means of the 43 value (7bits), but we are adding an additional angle of 30 degrees (21) which I do not fully understand. Finally we can see that the positions are scaled by dividing the result by 300 (this must be only to keep the movements controlled in a particular range, it can be studied by changing the figure and see what happens on real movements).
After all this, the program forwards us to the routines AorBDown and AorBUp. In these two routines we can see the calculations for the exact end positions of the leg tips in our HEX. Each routine takes care of a different (alternate) tripod. The calculations made there are just based on the addition of the intermediate values XPos2 and ZPos2 to the previous XPos and ZPos, accounting also for the YPos of the leg depending on the tripod (this can bee seen easily by tracking the variables LegupShift, Freeze and HeightShift.
Now we have real positions for our legs (XPos, YPos, ZPos). We cannot move the legs to these new positions if we have not calculated previously the HipHorizontal Angle, HipVertical Angle and the Knee Angle. This is done after the label in the program: Distance and HipH_Angle with XZ. The calculations are easy. First of all the distance in the plane XZ is calculated by the hypotenuse of the triangle formed by the XPos and ZPos coordinates. From this information, we can calculate the HipHorizontal Angle. After the angle calculation, notice that the Distance value is corrected with the TibiaAngle variable for special 3DOF-C legs. The only meaning I find to the variable TibiaAngle is that it means the small increment in the X direction from its top left side to its bottom right side when placed vertically due to the curvature of the leg. This would be meaningful in my opinion at the time of making this correction.
Following in the program we find the label Set Angle. After this label we can find the pending angle calculations. The first angle to be calculated is the HipVertical one. To calculate this angle we have to take two thinks into consideration. First is that we have to calculate the angle upon the basis that we have to make a triangle between the HipVertical Servo axis and the leg tip together with the FemurLength and TibiaLength. We can follow these steps:
a. Take the Distance (on plane XZ) and take out the HipH_HipV distance. There we have our new triangle whose hypotenuse is just the distance between the HipVertical Servo axis and the leg end tip. This hypotenuse is called in the program TmpSEW.
b. With the above information, we can use the Cosines Law (c2=a2+b2-2abcos(x)) to calculate the Knee Angle of the leg. We are calculating in the program cos(x) from the above mentioned equation. We call the ARCOS routine to calculate the Knee Angle.
c. Following we need to calculate the HipVertical angle. To calculate it, we have to calculate first the angle formed by the triangle described before on the cosines law. This is the TmpAngle. After this step, we calculated the other part of the angle by using the cosines law with the triangle formed by TmpSEW, TibiaLength and FemurLength. We have to add this last angle to TmpAngle to have the final HipVertical angle.
The above angle calculations can be seen better in some drawings that I have prepared. I will send them to everyone requesting these pictures/explanations.
Finally, we know the Three necessary angles for each leg and we only need to calculate the pulses to be sent to the servos. With these pulses we go to the last part of the program where the appropriate commands are sent to the SSC-32.
I hope this information is useful anyhow for all of you people!
I haven’t received the pix yet. I do have a view of a leg, with parts labeled, and some dimensions for the 3DOF-C leg. Could be other legs as well, but I need to verify my understanding. Also to realize the “right axis reference system” you mention.
Other places real sin() and cos() functions are used. I suspect it saves time.
I discovered that YPos] is signed char (+127 -128), Tibia_Length for 3DOF-C is 141.
I can see Xpos] and Zpos] = 0, but why - Tibia_Length for Ypos]?
All1500 (all 1500) would be the center of each of the servo’s ranges. Seems like Ypos] should be 0, it’s perpendicular to the axis of the 'bot at this time. Where is Shunt?
So all 6 foot contact points get “moved” by vector addition of the speed vector.
I follow the Dangle and Dcoord calcs. I don’t see the reason for (128 - ABS(Height) - ABS(TibiaAngle * 2)) either.
YPos2 is vertical? I thought ZPos2 was. Zpos is = 0 to start. I can see that the vert axis would just be up/down (height?).
DCord projected along both forward and lateral via cos() and sin() functions. 43 is 60 degrees, that answers one question, and 21 is 30 degrees as well. Seems like the moves would just be 180 degrees out for opposite sides. But the 300, I don’t see that.
Can you see what TibiaAngle does? Why it’s added to Distance? Oh wait, TibiaAngle is for correcting the angle that the leg is at relative to the body. LegUpShift then is the distance the leg is raised. Or is that HeightShift?
“due to bug in Basic” seems to indicate a problem, do you follow that?
There are a couple of other constants in there, /4 and *2 the aren’t obvious to me.
TibiaAngle is related to the curvature of the leg? I don’t see that yet.
That’s probably the “TmpCos = (Femur_Length * Femur_Length - Tibia_Length * Tibia_Length + TmpSEWSEW)” I see.
That answers the question of what TmpSEW is.
This instead of intersecting arcs!
Is this Rotate[index] ?
That part I can follow OK.
Thanks for all your efforts in explaining the IK. I’ve just been getting it to compile so that I can push some numbers through and see how it works. Tibia_Length appears to be a problem for this 3DOF-C leg. I’d also like to get a handle on this “bug in Basic”. Your revelation of what axis is UP explains my confusion. I had been reading another program with IK; and in CNC Z is up!
I hope you have received the picture with the Axis reference system for each leg. This was a fast drawing indicating the main information about the Lengths of the segments in the legs, the angles needed, etc… Sorry for not depicting properly the legs, but I thought this picture was enough to understand my explanations.
Following, I clarify your questions:
No, it does not save so much time to use Sin() Cos(), it saves basically memory. You would need to make up new tables to calculate them, what would add up to the existing table of ARCOS and also to the several variables declared in the program. In my opinion, the use of (only 6 times in a position calculation cycle) of Sin Cos, reduces the complexity of the program and does not dramatically reduce the speed performance of the program. If you should make all the ARCCOS operations in each cycle, then you would (for sure) notice the low speed performance of the program.
There is no particular reason to use -TibiaLength for YPos. It just depends on where you place your Axis Reference System. In this case, as it is just placed on the HIP HORIZONTAL SERVO Axis, then the leg end is just in the negative direction of the Y axis in our reference system. Just that Alan, you can change it and say that Y axis is possitive in the downwards direction to the leg end, but then you have to change all the convention made in the program concerning the new possitive coordinates in Y direction.
Well, as explained before, YPos cannot be 0 when all the servos are at 1500 (center possition). In this situation, the Tibia of the leg is making almost a 90degrees angle with the FemurLength of the leg. Therefore, if we place the reference system in the HIPHORIZONTAL SERVO Axis, then the YPos must be negative. Concerning the Shunt label, it comes out when using the PowerPod Generation for Autonomous control option. Anyway it is just close to the MAIN label for the program.
That´s it Alan. The new positions (X,Y,Z) are calculated for each leg (6 as you know). The positions are the endpoints (tips) of the legs. It is added a direction and a module (properly scaled). This is the basic idea. If you try to control the HEX by means only of the SSC-32 commands for tripod walking you will notice that you can only rotate, move ahead, move ahead+right or left or move backwards, backwards+right or left. This is a limitation of the SSC-32 commands. With the IK control, you can move (theoretically, I have to check this) the HEX in any direction with a PS2 controller for instance (it should be possible to move it even by side movement to right or left).
Well, this is a kind of an small mistery that can be solved with some time. I will try to double check and revert.
Yes Alan, YPos2 is vertical. ZPos is 0 at the begining because Z means the movement of the whole leg around the axis of the HIPHORIZONTAL servo (i.e. leg ahead, leg backwards). At the beginning (1500 neutral), the legs are centered with no position ahead or backwards.
It makes sense to hav 180 degrees out of phase for each opposite sides (we want to keep the right direction for the HEX and this is only possible when we invert the direction for opposite legs). The other 30 degrees are still frustrating to me, I cannot find a coherent explanation.
I did not invest too much time in LegUpShift or HeightShift as they were not critical in my description of the program. But TibiaAngle is different. Try to thing the following: Look at the HEX from upwards. You could see a round body with the FemurLength comming radialy out from this circle. But you also will see an small part after the femurlength due to the curvature of the special 3DOF-C legs (which are curved and when projecting this distance over the XZ plane, you get about 10 or 20 milimiters). This is the reason for adding this variable where mentioned. In my opinion, its name does not help as it is not an angle, but a distance.
Well, in most of the cases, the constants /4 and *2 are not relevant. If you notice the formulas correctly, you will see that they are cancelled in one or other means. I am not informed about these BASIC Bugs. I will have to check this later on. I explained TibiaAngle already.
You are missing the: TmpCos = TmpCos * 127 / (2 * Femur_Length * Tibia_Length), which is the last part of the COSINES LAW calculation.
Rotate(Index) seems to be anything different. It is added to the HipHorizontal angle (which is the exact angle we want to move the leg to in the XZ plane). The Rotate(index) looks like an additional rotation factor composed with the desired direction (i.e. translation + rotation), but I am not sure yet. I will revert.
I hope this helps! I was trying to place the picture that I sent you on the forum, but I wasn´t able. If you know how to do it, just post it in order that other people can find sense to these explanations and help us out in any way.
I’ve got code running on my processor, and I’ve worked through all the calculations. I’ve still got the BASIC 127 scaling factor to get rid of, and I want to shift to floating point for the servo angles, but basically I’m waiting for my hardware to be able to test more. I’ve got a friend’s home-made 'bot to work with, but the servos are connected differently, and I’ve yet to be able to “unravel” it in the software. I’ve got plenty of notes!
I’m still trying to figure out the “300” parameter in the XPos2 equation, if you’ve got any ideas.
the legs are 60 degrees apart (360 / 60). I must have missed Luis’ question. The 30 degrees, I have figured out, is the 1/2 space offset of the first leg to the ‘0’ angle. This way, there are a pair of legs facing ‘forward’, and a pair of legs facing ‘backward’. Oh, maybe that’s what you mean!
That’d be nice!
What I still haven’t figured out is the ‘300’ parameter in the “revolve” equation.
8) In fact it continouously updates the end point of each leg as it’s in motion. That’s why you can change direction or any other property in real time. (You don’t need to wait for a sequence to finish moving)
