But all legs are on the ground right? There isn’t one leg sticking out?
Pretty strange, I’ve never seen or hear this before.
Try to write the body rotation values to the terminal to see what values are and whey they change.
Xan
Euh… That’s a little bit too fast. Can you explain a bit more on how to do that?
No they’re all on the ground just one side hanging lower…
or did you mean a debug??
It probably would be solved by adjusting it in the code. But that shouldn’t be the way to do it.
It looks like the servos have a deviation. Like they’re not centered or the the middle is not the middle. When i put the joints one click further, its too far! While calibrating they where fine though. I only have this problem with the phoenix code.
Could it be that i have to adjust the offsets in the phoenix code? Maybe it has something to do with using futaba servos?
The best thing to solve such errors is to take a peek in the realtime values when the bot is up and running. You can do this by writing the values for the body rotation to the PC and see if they are what they are supposed to be.
To write the body rotation values to the pc you need to add this line in the main loop. Right after the Gosub Controlinput
serout s_out, i38400, [sdec BodyRotX1, " ", sdec BodyRotY1, " ", sdec BodyRotZ1, 13]This will return the angle of the body. They should be zero on startup. If not, there probably is something wrong with your remote.
Xan
Hi Xan
Thanks for this crazy new version!
My Phoenix is dead and an Atrax is born
nsa11.casimages.com/img/2009/11/29/mini_091129063146357132.jpg
My Atrax spider is ready to receive your code now!(V1.3 at first) I have to implement 2 more legs in it. To allow this, just 3 questions:
Is your V2.0 Phoenix code easily adaptable for 2 more legs implementation?
In the Min/Max Angles program block, the limit coxa angles seem not symetric between Front and Back: 26 deg for rear and 58 deg for front. The zero should be at 60 deg in front and -60 deg in rear, right?
[code];[MIN/MAX ANGLES]
RRCoxa_MIN con -26 ;Mechanical limits of the Right Rear Leg
RRCoxa_MAX con 74
RFCoxa_MIN con -58 ;Mechanical limits of the Right Front Leg
RFCoxa_MAX con 74
[/code]
- sign means servo clock rotation, isn’t it?
My Atrax Spider has 27 servos (24 for legs, 2 for ven. hooks and 1 for the abdomen) instead of 18 for the Phoenix, connected to the SSC32. Will be everything else that I have to change in your program, beside the 2 extra legs implementation and gait blocks? (something like [Timer] or SSCTime in [main] or other Timer part in your code? Thanks in advance for your help.
Hi McSpider,
Wow, you should post a thread with more info about you octopod, it looks awesome! Did you add foot sensors too (microswitches). Would be interested in a closeup picture of that. Also the 2 ven needs a closeup 
Or did you already post a thread about your project? 
It should be realtive easy to add two legs to Xan’s code. The 0 deg point is the calibrated position you set each coxa for being the reference (coxaoffset). There would probably be necessary to adjust a timer value lock. You probably have to experiment or do some measurements to get the accurate timing.
When i use this in the code it gives me this output when compiling:
Error: FILE \\.PSF\HOME\DOCUMENTS\HEXAPOD\PHOENIX_CONTROL_PS2.BAS(LINE 407) : [TOKEN ,] : Unexpected token type
Hi Mano,
What have you tried to do to resolve this? Have you looked over the code in this file to try to understand it?
My quick refresher look at the code showed me that these variables don’t exist. If you have read through Xans recent posts you will see that he is working on adding another decimal place of precision to the body rotation calculations to make the walking over obstacles work better. So a hint would be to drop the 1 at the end of variable names.
Kurt
Oh lol, You’re right. Sharp eye Kurt! 
Hi McSpider,
Good build! It’s hard to see how the ven hooks come together. It would be fun to see some aditional pictures of that together with the pressure switches on the legs. I think your build deserves it’s own topic in the project page. This will keep all your mods and builds together 
Now to your questions:
Why do you want to start with 1.3 if 2.0 is already available? I suggest you get it up and running with 2.0 to prevent doing things twice
Nope, Adding 2 aditional angles isn’t to hard if you get trough the code step by step. Most of the parts can be copied from the other legs. You do need to figure out some new gaits. I should start getting the IK ready and make sure you can get it to rotate and shift it’s body pretty nice before start working on the gait. The hardest part will be the bodyIK. You will need to add 2 aditional legs in the matrix calculations.
The zero values for front and back are indeed 60 and -60. The mechanical limits are a bit different because the servo horn is not in the middle of the servo. This means that the servo housing is pointing out in the front of the hex and pointing inwards at the back of the hex.
The timer stuff will take care of the synchronisation between the BAP and SSC. There is no need to change that.
I hope this helps.
Xan
ofcourse i looked over the code. I know how these things work. I tried changing some parts but it keeps giving me this same output. Xan gave me this code so i assumed it would work…
What is wrong with it?
Are you sure about that Xan? I believe it takes a bit longer time to send the SSC commands for 27 servos than it takes for sending commands for “only” 18 servos.
Correct me if I’m wrong but I think this line must be changed:
;Wait for previous commands to be completed while walking
pause (PrevSSCTime - CycleTime - 45) MIN 1
The 45mS value should be increased a bit.
Works for me…and yes , good eye…Sometimes it’s the simplest solution for the biggest problem.
Hi! Thanks to Zenta and Xan.
OK, that’s nice: i’ll open a thread about the Atrax project with pictures. I don’t know at all if this new bot will be able to work yet! 
The femurs are 7.4 cm and what about its total weight? 3.1 kg, ouch!
My first intention in fact, was to begin the changes with the 1.3 version of Xan’s code because I used it already with my Phoenix, … and I’m a bit (but just a little bit) less afraid with studying Xan’s code!
But the 2.0 version seems really crazy. Hum, why not!
So, if we get the accurate timing with 45 mS for 18 servos, 45/18 = 2.5 ms
By this way could I assess this Time as follows: 2.5 * 27 servos = 67 ms ?
Ok i got it to work and the output is 0 0 0
of course when i move my throttles it changes but when in default mode it stays 0 0 0
So no what should do?
@macspider:
don’t be afraid to look into the new code… It stayed pretty much the same…
EDIT! I just thought of the same problem i had before… It might have something to do with the offsets of the ssc-32 not being read. can’t remember what it was though.
Totally right Zenta! I overlooked that part. I’ve been bumping in to that part a couple of times already. I’ve got a better idea how to solve that for once and for all. Why not send the new positions, get the cycle time and pause. Then only confirm the positions by sending a . This always takes the same time. I’ll see if I can get this part done.
LOL, it’s not as simple as this. Each of the servos got 6 (#0P500) to 8 (#10P2500) bytes to send the pin numbers vary from servo to servo but they are the same for every cycle. The position can change from 3 to 4 bytes in every cycle. So we are using an average. And at the end of the command is a footer that contains the time (T200) and commit (). Most of the time this footer contains 4 bytes. But then again, the time can vary as well.
Hopes this makes any sense.
Xan
You didn’t really look in to detail did you? 
Make sure the offsets are enabled in the general register of the SSC. Check out the SSC manual for more information.
Xan
So just to make clear, i need to adjust the ofsets in lynxterm or in sequencer?
I used to do it in lynxterm but found something similair in seq.
LOL I knew that was coming!
Adjust the offsets using LynxTerm. I don’t think SEQ adjusts the offsets in the SSC-32 registers.