I do see a difference. Notice our ST1 lables on the tibia servo… The one where my LED is on. Notice the orientation of my ST1 sticker is going in the opposite direction. I should probably double check that my servos match what others did…
actually think i am wrong if I want to use the right leg servo:
That probably is a good point for assembly instructions on which way the label should be pointed for the left and right side of spidey.
1 Like
@cyberpalin - Math is hard 
As I mentioned earlier I think for example that ROS uses right hand coordinates
Not that that requires us to do the same
@kurte - Right hand rule is interesting for several reasons. For instance, typically, I would assume, using the right hand rule that
- z points up, x points forward and y points to the left, but you can also have
- y pointing up, z pointing to the right and x pointing forward, and
- z pointing down, x pointing forward and y pointing to the right etc,
Learned the hard way all those years I was playing with IMUs and magwick/mahoney algorithms.
So I guess the real question what directions are the axes pointing in when we deal we hexapods.
I was thinking this for the servos but thinking i could be wrong now:
Of course is not the body axis just the leg?
Oh in that picture I posted which way is forward? For the body I am assuming x is forward, z is up and y is to the left
@cyberpalin Again I am just one of many, but from the second link of ROS we have:
Axis Orientation
In relation to a body the standard is:
- x forward
- y left
- z up
Which maybe makes sense to me… But not sure what other think
For body axis I would agree but looks like I wasn’t the only trying to understand axes and the pep spreadsheet (looks like @madmax, @xan, @zenta were the prime suspects in that discussion thread):
Hexapod femur angle explanation - Help & Support / Robot Parts - RobotShop Community
and just for reference on the PEP spreadsheet: Project Phoenix Excel program + Manual - Lynxmotion / Legged Robots - RobotShop Community
Still reading through everything but 
Oh for the right front leg my tibia servo needs to turned to match yours will do that next.
@madmax looks like I am in the same boat as you were in with trying to understand the equations etc in Jan/2020 and earlier this year from that other thread
@cyberpalin
Yes… I gave up on the PEP sheet and just decided to do it on my own… In the end that was better as I understood it a lot more.
The way I did was using the Y +ve as up, Z +ve as forward and x to the right hand side for body axis and for the leg axis.
That meant when I was looking at the bot from front I could atleast work out the angles in my head. atan2 then becomes a bit obvious and easy to understand. You might have to sit with atan2 and beat it until it clicks.
I haven’t read the paper but it looks like the Z axis selection is not according to DH parameters. In DH you have the Z axis along the rotation of motion
TIP: I learnt it the hard way. The problem is that there are may different choices for axis selection and you start looking at papers and get more confused. I would suggest stick to one choice and work it out. That is the best way out. Axis selection can be quite personal choice as well.
Hence, in my post(I don’t know which one, some post above) I was ask about the coordinate axis choice. So that we all start off with on the same page. I was thinking we could use the one in ROS so the code can be easily ported.
Also, I didn’t go the conventional way of using Denavit-Hartenberg kinematic frames. Since, we have a very fast processor. We could actually derive the Homogenous transform of the leg in the base frame and use that. Matrix inversion will be better off on this one as compared to what I had used, an 8 bit AVR. I guess there should be some libraries which allow us to do that on the Teensy.
1 Like
Actually in that paper it, I agree, its not according to DH. In my one of my previous posts I showed what I was assuming (but that looks like it for the left leg now according to @kurte). I just threw it up there to get the conversation started.
Which I think follows along with DH papers and the right hand rule.
Tell me about it - got burnt a few times. I would agree to make a choice of axis convention and then stick with it. I think if we agree on the axes then you can use one set of base equations - for instance if I look at your tripod gait and then look at zenta’s gait engine or the pep I get totally confused.
Yes there are few things that you can use Used matrix inversion for an OpenGL lib I have for the T4.1.
Have a feeling when you all dig deeper into the ROS code you will probably see them transform leg coordinates into world or body coordinates.
OH On another note when you are assembling the legs for lynxmotion spidey the brackets get assembled to the servo when the servo angle is set to 0 degs - this one is for everyone.
1 Like
@cyberpalin Keep in mind the phot in your last image was during the original LSS BETA, so the design has changed.
@kurte “Here is my high priced stand:”
Jim used 50-pack (fully) transparent CD containers which were left over from burning various programs. Worked quite well actually. Yours works well 
Here is the reason I am asking. If I remove all offsets and just put the servos in my setup as 0 degs this is the position I wind up in (using LSS Config)
Somehow I don’t think this probably the way you all oriented your legs
1 Like
Actually for my rovers I used a large can of tomato sauce which raised it enough - so bottom line anything that is handy
Early morning all (5AM),
Yes I used to use the same or more fancy DVD cases back with rovers and maybe even with the original Lynxmotion Phoenix
But surprised I did not get any comment on which book was under the container. This was the one always mentioned when working on things like IK back then.
Or if it matches the left legs, than we just need to change servo numbers…
Sorry but as I said before, I have forgotten most of my math. Like 1+1=?
Again the reason I mention ROS and their standards is for a couple of reasons. The first being that they have a hopefully complete definition, such that you can do higher level things. Note It has been awhile since I looked at it, so it would take me awhile to remember details. But for example again standards on coordinates systems, and also you had definitions of everything in something like .yaml files (maybe different on ROS2), but for example you then define things like, my Camera or my LIDAR is at position X, Y, Z at angle a and as such when you receive data from lets say the LIDAR, its data can be mapped back to a standard frame, that then can be used by navigation or …
But will leave this for the Math people
There are several different ways to handle this and often is different by different servo manufactures. Most will tell you to startup and power up your servos and tell it to go the center point.
Then some servos are physically marked what their zero point is as a reference that is often shown in assembly instructions, like:
Some don’t have markings… Luckily we are not like the older Lynxmotion builds where, in some cases you would be asked to then undo the screw and remove wheel and rotate it N splines clockwise or counter clockwise to offset the servo…)…
For these, I again used now our test program, center all servos (1) command to make sure they were all back to logical 0)… I then assembled each leg to try to get the 0 to be close to some configuration. Right now if I run the 1 command it looks like:
But there is another logical method/way to accomplish this as well and I believe was mentioned a long time ago. That is one could assemble the servos in any logical manor you wanted to…
Then have a one or two step process to handle this. The gross adjustment.
You layout the hexapod on some flat surface. You then manually arrange all of the legs such that they are in some fixed configuration. I think we discussed laying flat (could also do as two servos are completely parallel to ground and the leg is at a complete right angle to ground…
One in this position, you query all of the servos for their current positions and use that as their new zero points… Note one could extend this as well to have user move each joint in some direction and determine if the values should be reversed or not…
The second step one might want to do, is to have a fine tuning function, where maybe we did the lay it flat method, and then have code where you put on stand, and can check each servo/leg and adjust such that for example the Femur and Tibia servo centers are exactly parallel to the ground and the Tibia is at right angle and the Coxa is properly aligned … and then save away these settings…
Hope that makes sense… I see doing a combination of both… But my initial point was as close to the right angles…
Forgot to mention, when assembling the legs, I have been known to mistake from time to time 
and not remember to zero the servo…
But everything is not lost. Simply unscrew the 4 screws holding the servo bracket to the horn, then while the servo is still zeroed, simply rotate until you get it close to what you think is the right position (to the nearest screw holes in the servo horn), and then put the screws back in…
@kurte - you are up early today and reading posts already - oh boy
No comment to that one - you know me and wiring things up
Already changed it this morning to right leg Thats when I started asking myself the question well what will be the default assembly process for these legs. I can do it one way set the offsets to what I want but that may not be the way other folks are doing it - what got me was the problem you were having with my config setup. So going to change to match yours. This is probably a question RobotShop is going to have to address.
Looked at the link you posted this morning and the YAML’s seem kind of light compared to what you all do in the code so maybe someplace else - but didn’t really dig that deep and it was real early - couldn’t sleep.
Yep saw that this morning as well when I was reviewing other spidey assembly instructions.
Ok - I used LSS and put them all in 0deg positions. Looks like you do that with your center servos broadcast message.
Yeah you may wind up having to adjust offsets to get it to where you really want it be with that approach.
Makes perfect sense to me and going to go that way as a start and see how things work out.
Hi Guys,
About calibration and alignment…
For the phoenix code math model, the best way for 0 would be if both the tibia axis and femur axis is in a horizontal line to each other. So don’t look at the brackets since there is an angle in them. The tibia to the tip of the foot should make a vertical line.
The reason for this is that this angle is closer to the actual working range of the servo and it makes calibrating way easier. If you place the bot on the (famous) spindle of CDs you create a parallel space between the workbench and the body of the bot. Now you can calibrate both the tibia and femur axis to perfectly parallel to the workbench.
I hope this helps.
Xan
Morning still!
Actually the dogs sort of let me stay in bed a little longer today… Yesterday they got both of us up near 4am… Funny thing is they feel like they have a duty to be my alarm clock, now around 4:30, I think they actually listen to the chimes of the clocks). Then they expect to go out and then have their breakfast and several rounds of begging for treats… Then once they finish their task… They go back to sleep!
Yes agree… Note the approach of asking the servos their position… Is not totally new. When Orion Robotics (Basic Micro) for a short time sold some robots (a couple of Hex, an Ant and a Rover), Nathan setup the original code, to do the lay the Hex out flat and read in the positions… Worked reasonably OK, but I never could get it just right, probably due to older eyes and 10 left thumbs. So again I added in a fine tune function, that for example if I started it up and one leg was slightly off the ground, I would manually adjust the different servos, until it felt right…
Actually this brings up another fine tuning possibility. Sort of like Self adjusting car shocks… I don’t remember if added this or not, I think we discussed it, but don’t remember (think it was around 2012-2013
But the idea is that suppose you did the first method to get close… And then you instruct the robot to get up to a default standing position. Now suppose you detect how much torque each of the servos are under.
With this you might then detect that lets say the left center leg does not have a very low torque… Maybe it means leg is up to high, so you instruct it to go down a bit… Likewise if it is under more torque the front and rear, maybe it is too low so you raise it up a little… Also if you have sensors like gyro… maybe you can detect the robot is leaning…
You are right there is a lot more to it. I am not sure the ROS stuff works much with the IK type stuff or walking gait… More of the higher level stuff was more like, I want you to start moving in direction Y and I want your logical tires to be moving a some angle per second (radians)? And then it is up to you to then convert this to how to walk at that speed. At least at the time it was geared to like a rover wheel where you were told lets say move one half rotation per second and your wheel has a diameter of N so that implies you are moving in direction Y and you then translate that into how do you walk at the right speed to do that…
As for then working with ROS Logical Frames and Transformations. I know there are/were tutorials on this, plus other web sites like:
But of course some of this is sort of getting the cart before the horse… Probably would help if it actually could stand up first Maybe even crawl!
EDIT: Note: I know some of this how to properly align the servos was discussed earlier. I found some of this discussion was around I think May 20th last year. Where it was discussed about laying it flat. And some talking about what does that mean? Things like, with or wirthout the Rubber pads under the body.
Well maybe almost there. I just pushed up the changes to match your config. Will be easy enough to set up for all the legs - probably just have to change gyre and offset signs going to the left side. Sorry can’t test that part. But one leg does stand from the low position - not sure it will work with all legs in play
Oh - good reference doc. You have to see what I had to deal with when trying to VFH++ working - which I never did by the way.
Was thinking about trying to adapt something to generate the gait from within your test sketch - was looking at this last night and this morning - finding that yours and Zenta’s name is in a lot of the hexapod code since they all seem to come from yours code base
1 Like
Looks good, I synced and leg works… May play in awhile and add the other 5 legs.
Very cool. real curious if spidey will stand then we can say “It lives…”
@cyberpalin It Lives!
I pushed up a version that moves all 6 legs, but I did not yet update code to check for completion
Will do that in a bit. Hacked up some new data structures…
But if anyone wishes to see what it does… It is up there.