Lynxmotion Tech Support

Holy COW! Enough typing?!?!

_________________
When in doubt, go with your first instinct.
Get that mistake out of the way.

Spacejunk

Hi Alan,

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 will come back soon with more information.

Bye!

Hi Luis,

Thought I'd post your drawing.



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.

Alan KM6VV

Correct me if I'm wrong, but I believe it is because each leg of both sides are 30 degrees from each other when viewed from the top...

Perhaps Laurent can contribute to this thread... It would be very helpful if he can add some explanation behind his code.

Beth: Can we keep this thread as a sticky? I found it VERY helpful for anyone with a round hexapod or any hexapods in general...

_________________
------------------------------
Sponsors:
Wallet
Bank Account
Job (for now)
------------------------------

Hi Tom,

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.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

Yes, what I meant to say is there is a +/- 30 degrees offset from leg to leg and this extra 30 degrees is perhaps the offset from the "center." By "center" I mean the nose of the H3-R, the mid point between the two "front" legs if the three holes for the switches are considered to be the "rear."

I'm just theorizing this portion. The IK calculation still has not fully permeated my understanding of what is going on from a logic flow stand point...

For the moment, I am using my own code, which is just a gaiting code to make the hexapod walk. This is a sequence-based code so it's inferior to the one that Laurent wrote, but it is used as a morale booster (to watch my hexapod do something other then sit on the bucket/stand with a DB9 umbilical all the time) when I get frustrated trying to understand his awesome code

Let's keep this thread going so we can all have a better understanding of the IK calculations that is going on. I am still very confused at the "movement" point of view of things. There seems to be two SETS of reference system. One set is each individual reference system that fixes its origin at the Hip Horizontal servo. The other set of reference system seems to be the body of the H3-R? Am I viewing this correctly?

In order to determine where to move the hexapod, one has to assume that you want to ultimately move the body/chassis to coordinate (X,Z) and use the IK calculation to move the legs into certain positions to accomplish this?

I'm really hoping that Laurent can shed some light if he has any free time to explain his code... Meanwhile, I am searching for books and literature that explains IK calculations more on the general level (theory) to gain a better understanding of what perspective/angle I should be viewing from to even start throwing trigonometry at it... I believe that ultimately, this general sense of IK can be and should be applied to robots of any kind (except for wheeled/tracked I suppose)...

_________________
------------------------------
Sponsors:
Wallet
Bank Account
Job (for now)
------------------------------

Hi Tom,



Also recall that "0 degrees" on the 'bot is aft (to the rear).



Yeah, it's great to see some moves for the first time! I ran for quite a while "up on blocks" with a friend's DIY 'bot, trying to get code to run for it.



True, but you don't have to give much thought to the body of the 'bot. Just revolve the input (commanded vector) direction around to the orientation of each leg, and then work in the leg "frame" of reference.



You could say that. I just get into the "leg frame", and the IK moves the foot of the leg in response to the input vector.




Do the research! There are plenty of books on robots, and papers on the internet. Just a little trig will get you the IK.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

Ok, so I went through several articles explaining IK, and it looks basic enough, just need to use the knowns and solve for the unknowns, which in this case, is the angles that the joints needs to be so that we can send the appropriate corresponding angles to the servo after converting it to a pulse width.

What I don't get is, even if the tips are commanded to move to a location after the IK calculation are done, doesn't the legs still have to be commanded to move again in order for the chassis to move?

For instance, wouldn't you need to do two IK calculations in order for the body to move?

1) Do the IK calculations and command three legs in a tripod to move to Location X,Z

2) Do another set of IK calculations to this same planted tripod in order to push/pull from the location set in 1) in order to move the body?


I don't get this higher-level flow of the diagram. I know that the array Xpos() and Ypos() and Zpos() is current position of the hexapod, while Xpos2() and Ypos2() and Zpos2() is the position to move to.

Does that mean that after the leg tips of the planted tripod is commanded to move to Xpos2() and Zpos2(), of course with the tips above the ground while transitioning to this position, that the tips of the legs have to be moved back to Xpos() and Zpos() (original position), but this time, move back to this location with the tips touching/contacting the ground?

_________________
------------------------------
Sponsors:
Wallet
Bank Account
Job (for now)
------------------------------

I'm no programming guru, but I get the flow of it. The IK for the destination positions are calculated on the fly in real time. (Is that redundant?) So the code Laurent wrote sends these destination positions to the SSC-32 using the group move function. As the legs are moving the IK is calculated again and the new updated destination positions are sent before the legs reach the last commanded positions. This ensures a continuous movement without stuttering, or going off track. This is also how straight line interpolation is acomplished with the end effector of an arm. Hope this helps.

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...

Ahhh, I see what you mean, but ultimately, the servos will have to swing back to some position in order for it move again?

Does anyone have an edited code for the Atom Pro to use in "serial" mode? I know that the code is originally intended for the BS2, but if someone can post or send me the code generated by Powerpod for the Atom Pro, I would appreciate it.

I've begun editing it, but it seems there are many syntaxual (is that even a word?) differences between the two...

_________________
------------------------------
Sponsors:
Wallet
Bank Account
Job (for now)
------------------------------

gulp... Why would they need to do that?



BS2? PowerPod generates Basic Atom code, not BS2 code. The BS2 can not... um, do the math.



Kurt has the best Atom Pro hack of the Atom 28 code created by PowerPod, but it's not for serial. We are working on it...

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...

I can easily send/post my version, which had defines to work for both round and inline.

My guess is that most of the code is the same for the serial and the PS2 code, just some sections different for input. So it would not be hard for someone to have Powerpod generate both versions (serial vs PS2) and see where the differences are and then take the version I modified and cut out the PS2 functions and insert the serial functions. You would then have to do some conversions on those sections (serin baud constants or the like, maybe a few nap instructions, but it should not be overly difficult)

There are some threads in either this forum on what most of the code differences were.

That's about it. Just a couple of "cosine law" calcs, and a right triangle or two to solve. Once you have the servo angles, they are scaled to the working range of the servos.



There are two tripods, and they work in alternating fashion. One tripod "flies", the other moves the body over the ground.



You do an IK calc for each leg in each tripod, the difference is basically if you "lift" the leg, which requires different angles, of course. You've got it.



That's it. And the "pos2" are added to the "pos" set (well, most of 'em). You'll also see that the pos2 set is added "incrementally" to pos set, resulting in a smooth move. The number of "steps" in this incremental move determines the speed of the gait; as the servo speeds and the loop delays are left constant (due to very coarse delay in BASIC).



The "flying" tripod moves the feet forward, The "ground" tripod moves the feet aft at the same time thus they make a loop in the vertical plane, first going forward (fly) and then then backward (ground). I guess you could say the ground triangle flips around.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

Yes, that is exactly the flow I was thinking of. After I study Kurte's code (since it has the right syntax for an Atom Pro), I'm going to try to incrementally build up my own IK code from scratch, so that I can fully understand what needs to happen in order to move my bot...

Kurte,

can you please send me the code either through PM or on the next reply to this thread? I think posting it in a new thread might land you a sticky post since it'll be quite helpful for all h3-r owners with Atom Pro.

Perhaps in the Atom Pro section?

_________________
------------------------------
Sponsors:
Wallet
Bank Account
Job (for now)
------------------------------

I have been following this thread with great interest, because i wanted to understand the code as well. And i must say that it was really helpfull up to a point.

My main reason for wanting to understand the code is the fact that i have build a somewhat modified version of the BH3 (normally inline). I have used the BH3 body and the C-legs. I also added a via epia pico itx (main reason for choosing the BH3 instead of BH3R) and of course some extra battery.

I changed the position of the front and rear legs because it makes the robot i whole lot more stable. The frontlegs are 30 degrees off to the front and the rear legs 30 degrees off to the rear.

This results in a body that needs the code for the round body, but with some modifications. And to be honest i cannot get al the details in the code right..... Corrected walking is not the problem, but the turning gives me a lot of problems.

Could somebody help me on this?