i felt this might be worth posting here. its not the complete solution, nor is it the right way to do it but…
Hi Jonny,
Would you mind posting the v20 code you have modified and are trying to use? (just zip all the project files).
I’ve been looking at your code, but I can’t see any obvious reason for why you get that bug. I don’t have the correct hardware to test it right now. But the only thing to do here is to start debugging. It does sound a bit strange that the RR leg is the only one that are faulty. What would be interesting to see is the IK result from the RR and the LR leg. Does this fault occour all the time, random or at a spesific position?
thanks for looking into it. its very strange. works fine with 1.3! 
its all the time and when walking or body moves its travel length is almost double the other servos. it also doesn’t seem in sync with the rest of the code. ??
im happy using 1.3 for this hex as it is slower code and that’s an advantage as the legs are not as strong or ridged. gentle movements are best. 
ill have a vid later tonight once the wife has stopped sunning herself. 
lol
I downloaded the code as well. I added a simple debug output at the end of LegIK that output the angles for each of the servos
[code]#ifdef DEBUG_OUT
if (HexOn) then
serout s_out, i9600, [sdec CoxaAngle1(LegIKLegNr),",", sdec FemurAngle1(LegIKLegNr), “,”, sdec TibiaAngle1(LegIKLegNr)," "]
endif
[/code]
I also output a CR at the end of the calls to LegIK. The legs are in the order (RR, RM, RF, LR, LM, LF)
Just hitting the start button I see a lot of lines that look like:
0,-526,201 0,-526,-325 0,-526,-325 0,-526,-325 0,-526,-325 0,-526,-325
0,-526,201 0,-526,-325 0,-526,-325 0,-526,-325 0,-526,-325 0,-526,-325
So it looks like it’s tibia angle is off as it is 201 and the other 5 legs are at -325. Now to backtrack and see what this value is based on.
Kurt
Found the problem I think! 
8)
Kurt.
P.S. - Just in case you want to know…
In LegIK:
;new rotation cals for ID3h-r leg
TibiaAngle1 = TibiaAngle1 - FemurAngle1
You need to put the array index in…
;new rotation cals for ID3h-r leg
TibiaAngle1(LegIKLegNr) = TibiaAngle1(LegIKLegNr) - FemurAngle1(LegIKLegNr)
ah… why didn’t I see that. 
funny, I did see it but didn’t pay attention to it… 
great Kurt!
its always the simplest of things. well done.
ill try that later today. i feel a new video coming on.
thanks kurt, V2.0 is now up and running.
Yah
You are welcome.
Kurt
Hey Guys! 
I got some problems with Xan´s code on Meangreen. I combine the chr-3_cfg.bas, phoenix_v20.bas and the phoenix_controll_ps2.bas to one programm and send it to the Atom-Pro. Now the robot only sound like my alarm clock in the morning! 
What make I wrong???
Could you please help me?
If you are turning it on and all you hear is a bunch of sounds out of the speaker. It usually implies that PS2 receiver is not properly being detected and setup. That is the code checks to see if you are in the proper mode, if not it beeps and tries to put it in the proper mode and tries again…
So I would check your hookup of the PS2. Things that bit me in the past is I forgot to set to jumper correctly to pass +5v instead of VS to it. Are you using standard pins for the PS2?
Kurt
Thanks for your tip!
I checked it and the only thing i make different is the connection to the ssc-32.
i used “pin 7 for tx” and “pin 8 for rx”. what is"cEyes pin??
The PS2 receiver is standart plugged on bb2.
Brown 12
Orange 13
Blue 14
White 15
and the Green wire is on Power.
with the “standart prog.” the robot woks.
Hi Mirage,
just replug your connection to the SSC-32 as advised in the 2.0 file and check again.
;[SERIAL CONNECTIONS]
cSSC_OUT con P11 ;Output pin for (SSC32 RX) on BotBoard (Yellow)
cSSC_IN con P10 ;Input pin for (SSC32 TX) on BotBoard (Blue)
cSSC_BAUD con i38400 ;SSC32 BAUD rate
Further question is it necessary to put the servo offsets to the register on the SSC-32? I think Xan explain that the code loads the offsets directly from the register.
Hi, there are several ways of handling the servo offset issues. I have seen or used at least three different ways. All of which have their pluses and minus.
-
Set the SSC-32 registers to the appropriate values: Plus is once set you can forget it. The tutorial has nice instructions for this. Downside is that if you need to make adjustments later, you have reconfigure the SSC-32 back talk to PC… Note: I am slightly lying here as you could also have a program on your processor set these registers as well… Also downside is that the offsets are restricted to ±100, which for most things is fine
-
Use the SSC-32 Software Position Offset command (PO) - This is the old way. When your program starts up you issue these commands. Where your program gets these offsets? Could be hard coded in program, could read from your processors EEPROM… Plus is easy to update. If you find some servo is a little off, simply update your offset a little and continue… One downside and/or upside: These commands are additive, so for example if your program resets and reissues the commands, your offsets will now be doubled. Other Downside again restricted to ±100. But from the above you can get around this by issuing multiple offsets…
-
Do the offsetting in the software. That is store your own offsets in your program, could be constants (bytetable/wordtable), Could be dynamic by using arrays. Can hard code and/or read from EEPROM… Then change the code in ServoDriver to add in your own offsets when you issue the command. This is not hard, I did this with my port to the Arc32. I did this there as I am not using an SSC-32… Pluses: Not restricted on how big the offsets can be. Can be dynamic… As the SSC-32 knows nothing about it, if you do something like run a General Purpose Sequence, it will not know anything about these offsets…
-
Combination - Could use 1) or 2) to get everything setup for normal running, Could also then use part of 3) to add in some additional static or dynamic offsetings…
I hope I answered the question?
Kurt
I disagree with some of your conclusions. First off the whole concept of offsets are to keep them as small as required, and still do the job. For Hitec servos it’s 15°. The Hitec servo has 24 teeth and therefore can be adjusted in 15° increments. In order to line up the servos output shaft to a known straight vertical or horizontal alignment, it will never be necessary to adjust it more than 15°. Remember all we are trying to do is have the servo be aligned to some standard while it is receiving 1500uS pulses. The best method is to use the registers. They are there, rock solid, no matter what the host micro does. The servos, and the SSC-32 have become one calibrated machine waiting for the program. When offsets are handled in this way, all programs are sharable with similar assembled and calibrated robots. The practice of mixing register and software offsets is specifically warned against. The results would be considered unpredictable!
Good morning,
Sorry I should have made it clear the #1 was the preferred solution. :!
I just mentioned the limitation as I think it was Zenta who wanted more… I believe on the T-HEX… I think he got around this later by having to move the Servo horns off the zero points ± 1 tick… Before that I think he was leaving all of the servos in the standard horizontal or vertical positions and using the offsets to get to the proper alignment of the legs…
Actually mixing modes was mentioned more for another conversation where for example terrain adaptation may need some dynamic offsetting. What I was trying to state is you could setup the robot using the standard offset registers and if your dynamics code could generate a secondary offsetting depending on what it is walking on it could… Sorry about mixing the conversations.
Again use the SSC-32 registers!
Kurt
Hi Kurt and Jim,
at the moment I use my CH3-R with an modified code created by powerpod. In this code the servo offsets loaded softwarebased directly from the code.
;------------------------------
;Init SSC-32 with pulse offsets
;------------------------------
serout SSC32,i38400,"#", |
RRHH,RRHH2,"po-36 #",RRHV,RRHV2,"po-26 #",RRK,RRK2,"po8 #", |
MRHH,MRHH2,"po40 #",MRHV,MRHV2,"po34 #",MRK,MRK2,"po2 #", |
FRHH,FRHH2,"po72 #",FRHV,FRHV2,"po56 #",FRK,FRK2,"po-80 #", |
RLHH,RLHH2,"po-56 #",RLHV,RLHV2,"po54 #",RLK,RLK2,"po-40 #", |
MLHH,MLHH2,"po-76 #",MLHV,MLHV2,"po26 #",MLK,MLK2,"po-30 #", |
FLHH,FLHH2,"po38 #",FLHV,FLHV2,"po10 #",FLK,FLK2,"po-62",13]If I use the 2.0 code from Xan on my CH3-R hexapod I must set these values into the SSC-32 register and the code load this offsets directly from the SSC-32 correct? If thats correct which array of the code is responsible to read out the register?
No… After you align the servos using the registers, sending a 1500uS pulse will move the servo to a perfectly aligned “centered” position. The “code” doesn’t need to know about these offsets. The offsets should be transparent to any code…
For example, if two people built the exact same robot, and aligned the servos using registers, both bots could use the same “code” and they should act exactly the same.
Why on earth would you need to know what offset a certain servo has? That information is not useful for anything.