Since Jim has started making his own Lynxmotion version of T-Hex I thought it would be appropriate to share the current code I’m using on T-Hex. There are some modifications left on the IK part and some other adjustments. But its fully functional (this is the code I used in the T-Hex video). The Ripple 12 and Tripod 8 gaits gives the best performance.
;Tars angle
TarsAngle1(LegIKLegNr) = (TarsToGroundAngle + FemurAngle1(LegIKLegNr)- TibiaAngle1(LegIKLegNr))
I’m planning to do some improvements to the formula that calc the “TarsToGroundAngle”.
Thats it.
EDIT: Oh, I forgot… The code are based on Xan’s Phoenix V2.0 code. All credit to Xan!! 4DofHex_V20.zip (18.1 KB)
iv been looking at using the tars vector section of the code to get my feet to point down at all times.
im using 1.3 and my leg config can been seen here. im looking to get the feet to always remain flat at all times. i531.photobucket.com/albums/dd35 … 0_1968.jpg
i have tried to add parts of the code that include “tar” along with anything relitive. i soon realise this wouldnt work!
i have one problem. as im using 1.3 and i have the femur and tibia servos working correctly and as expected so how can i add tars without replacing the leg IK and body IK? or in doing so 'will it work?
im guessing a simple short independent equation that refects what the Femur and tibia servos are doing would work?
Lately I’ve been working on the T-Hex code. Currently using the latest XBee code and binary mode (SSC32). There was some weak spots in the leg IK for the 4.DOF, especially when the leg are raised over the zero point (IKFeetPosY<0). The TarsToGroundAngle are based upon several conditions, and it gets a bit tricky but the code work fine for about IKFeetPosY > -55 and that should be ok. After all most of these changes isn’t visible under normal walking though. But there are some improvements visible under extreme translations.
For those who are interested these are the main modifications to the IK part:
;Calc the TarsToGroundAngle1:
TarsToGroundAngle1 = -cTarsConst + cTarsMulti*IKFeetPosY + (IKFeetPosXZ*cTarsFactorA)/c1DEC - ((IKFeetPosXZ*IKFeetPosY)/(cTarsFactorB))
IF IKFeetPosY < 0 THEN ;Always compensate TarsToGroundAngle1 when IKFeetPosY it goes below zero
TarsToGroundAngle1 = TarsToGroundAngle1 - ((IKFeetPosY*cTarsFactorC)/c1DEC); TGA base, overall rule
ENDIF
IF TarsToGroundAngle1 > 400 THEN ;
TGA_B_H3 = 200 + (TarsToGroundAngle1/2)
ELSE
TGA_B_H3 = TarsToGroundAngle1
ENDIF
IF TarsToGroundAngle1 > 300 THEN ;
TGA_A_H4 = 240 + (TarsToGroundAngle1/5)
ELSE
TGA_A_H4 = TarsToGroundAngle1
ENDIF
IF IKFeetPosY > 0 THEN ;Only compensate the TarsToGroundAngle1 when it exceed 30 deg (A, H4 PEP note)
TarsToGroundAngle1 = TGA_A_H4
ELSEIF ((IKFeetPosY <= 0) & (IKFeetPosY > -10)); linear transition between case H3 and H4 (from PEP: H4-K5*(H3-H4))
TarsToGroundAngle1 = (TGA_A_H4 -((IKFeetPosY*(TGA_B_H3-TGA_A_H4))/c1DEC))
ELSE ;IKFeetPosY <= -10, Only compensate TGA1 when it exceed 40 deg
TarsToGroundAngle1 = TGA_B_H3
ENDIF
And the cTarsFactorB are reduced from 70 to 60. If I ever find time for it I’ll try to explain the algorithms.
I’ll have to clean up the code a little more before I post all of it. And I was hoping to post a new video and some pics too.
How do you keep up with all the varaible names, and how do you remember what letters to capitalize such as an example, “IKFeetPosY” when it can be written this way also “ikfeetposY” or IKfeetPosY" etc…
I think you’ve to ask Xan about that, since he is the one that came up with that name. But its pretty logic. For every new word it starts with a capital. Like the “TarsToGroundAngle”. I feel its easier to read. Another option is to use the underline between the words/letters: TGA_A_H4.
I used to be a lot better at naming conventions, when I worked with a group of programmers on a project, but now that I am just dabbling well…
Some of the things I like to do include the same stuff that Zenta mentioned, with starting each word with a capital. But in addition to that I often precede the variable name with something about it’s type in lower case:
Things like:
a - Array of somethings
f - Flag (bit)
b - Byte
w - Word
(something I got really lazy about sign: s - signed, u - unsigned)
I think Xan has a convention in his code that a number at the end of the name says something about how many decimal points the value has in fixed point math.
example: awServoOffsets1 - If I were following the conventions would tell me that the variable is an array of words with 1 decimal point. IE if one of the elements had a value of 102, it is logically 10.2.
It’s been a while since I wrote any code but that’s the one thing I had trouble with, which was staying consistent with the variable format and remembering the names of the variables that I created. Parallax IDE seems to keep track of case sensitive variable names, where the atom pro IDE doesn’t care.
Anyway, I was just curious as how you did it, but, since Xan is the one behind the code, perhaps he’s the man to ask.
I’ve done some more work on the T-Hex code based on Kurt’s hacked XBee/binary SSC version of Xan’s V20 code. I decided to post the code in Kurts DIY Remote Control XBee controller for Robotics thread.
The code are not tested using a PS2 controller, since mine are broken (hint hint Jim )
Beside the modifications I’ve done to the V20/21k code (I’ll post info about that in Xan’s thread) I’ve added mechanical limit function for the tars (4.DOF) too. If you look at this part from the limit part in the config file:
;[MIN/MAX ANGLES]
cRRCoxaMin1 con -650 ;Mechanical limits of the Right Rear Leg, decimals = 1
cRRCoxaMax1 con 650
cRRFemurMin1 con -1050
cRRFemurMax1 con 750
cRRTibiaMin1 con -530
cRRTibiaMax1 con 900
cRRTarsMin1 con -1300 ;In theory the kinematics can reach about -160 deg
cRRTarsMax1 con 500 ;The kinematics will never exceed 23 deg though..
Jim/James, pay attention to the values for the tars. Thats the reason for why I’m using relative large offset values. And this could be a little trouble when doing the calibrations. At this moment I’m not sure how to solve this using the register offset. Maybe adding an offset in the IK part? Just snapping out the servohorn won’t solve the problem completely since the code need to know what pwm value are refered as the 0 deg postion.
hi zenta, i was playing about with the code and i noticed that i had one of my servos connected to Pin0 (cLRTarsPin) and it started playing up. in fact it was reacting slightly differently to the others and from what was expected. here are my pin numbers.
[code];[SSC PIN NUMBERS]
cRRCoxaPin con P19 ;Rear Right leg Hip Horizontal
cRRFemurPin con P18 ;Rear Right leg Hip Vertical
cRRTibiaPin con P17 ;Rear Right leg Knee
cRRTarsPin con P16
cRFCoxaPin con P28 ;Front Right leg Hip Horizontal
cRFFemurPin con P29 ;Front Right leg Hip Vertical
cRFTibiaPin con P30 ;Front Right leg Knee
cRFTarsPin con P31
cLRCoxaPin con P3 ;Rear Left leg Hip Horizontal
cLRFemurPin con P2 ;Rear Left leg Hip Vertical
cLRTibiaPin con P1 ;Rear Left leg Knee
cLRTarsPin con P0
cLFCoxaPin con P12 ;Front Left leg Hip Horizontal
cLFFemurPin con P13 ;Front Left leg Hip Vertical
cLFTibiaPin con P14 ;Front Left leg Knee
cLFTarsPin con P15[/code]
after going thought the controls i started to look at single leg mode. here is where i solved the problem…
i cycled though to the nuisance leg (Rear Left) and started playing. it soon became clear that the cLRTarsPin on P0 was not moving. then i cycled the single leg mode again till it was on the Left Middle. bingo… the tar on the LR was moving. i then moved the cLRTarsPin to Pin4 and all was ok.
why do you think Pin0 was defining as the left middle leg tar?
I’m not sure what you mean, was my code defined like that?
The pin definitions I use for T-Hex are like this:
[code];[SSC PIN NUMBERS]
cPanHeadPin con P31
cTiltHeadPin con P32
cRRCoxaPin con P24 ;Rear Right leg Hip Horizontal
cRRFemurPin con P25 ;Rear Right leg Hip Vertical
cRRTibiaPin con P26 ;Rear Right leg Knee
cRRTarsPin con P27
cRMCoxaPin con P20 ;Middle Right leg Hip Horizontal
cRMFemurPin con P21 ;Middle Right leg Hip Vertical
cRMTibiaPin con P22 ;Middle Right leg Knee
cRMTarsPin con P23
cRFCoxaPin con P16 ;Front Right leg Hip Horizontal
cRFFemurPin con P17 ;Front Right leg Hip Vertical
cRFTibiaPin con P18 ;Front Right leg Knee
cRFTarsPin con P19
cLRCoxaPin con P8 ;Rear Left leg Hip Horizontal
cLRFemurPin con P9 ;Rear Left leg Hip Vertical
cLRTibiaPin con P10 ;Rear Left leg Knee
cLRTarsPin con P11
cLMCoxaPin con P4 ;Middle Left leg Hip Horizontal
cLMFemurPin con P5 ;Middle Left leg Hip Vertical
cLMTibiaPin con P6 ;Middle Left leg Knee
cLMTarsPin con P7
cLFCoxaPin con P0 ;Front Left leg Hip Horizontal
cLFFemurPin con P1 ;Front Left leg Hip Vertical
cLFTibiaPin con P2 ;Front Left leg Knee
cLFTarsPin con P3[/code]
The code are based on Xan’s Phoenix V2.0 code. All credit to Xan!!
(hint hint Jim 
I’m not sure what you mean, was my code defined like that?