Thanks for these infos!
I saw that Xan put this value at 50 ms in the 1.3 version of his code. And this value is decreased to 45 now.
I think for starting to work with the gaits now.
Thanks
Hi McSpider,
Yepp, the value is a bit of calculating and a bit of feeling and fine tuning. LOL
Pushing the joystick further forward will not only change the size of the steps but also the speed. Besides this variable speed there is also a ‘Nominal Gait Speed’ This is the nominal time between the different steps in the gait. The lower the number, the faster the gait. More steps in the gait will make the gait more… let’s say solid. But it also decrease the speed. So a gait with a lot of steps will have a low NomGaitSpeed. If the number of steps is low the legs will travel a big distance between one step and the next. So it’s better to make it a bit slower. Just play around with them to see what they do.
The SSCTime is the final update time that will be send to the servos. So if this value contains 200, all servos will travel from A to B within exactly 200ms thanks to the SSC. There is no need in changing any of this.
InputTimeDelay is used to vary the speed when the joystick is pushed further (and the left slider on the DIY remote)
SpeedControl is used to change the speed using the D-pad on the PS2 remote.
I hope this helps.
Xan
OK, Thanks a lot Xan. That’ll help me.
hi Xan.
well I’m recovering OK so i thought i may as well do somethings while I’m off work.
I finally uploaded your v.20 into my MSR-H01 hexapod.
great work. it was really cool to see it on your phoenix in your vid but it was even better to see it for myself.
loving the single leg control by the way.
much more faster. 
one question. in 1.3 we had BodyYshift. what has this been replaced with?
the reason im asking is iv also added my pan/tilt head to the code using this:
pan sub =
[code]
HeadPanAngle=0
IF (ABS(BodyRotY)>cTravelDeadZone | ABS(BodyRotY)>cTravelDeadZone | ABS(TravelRotationY*2)>cTravelDeadZone) THEN
;Calculate direction Z and X
HeadPanAngle = SQR((BodyRotY * BodyRotY) + BodyYshift * BodyYshift)
;Add sign depending on the direction of X
HeadPanAngle = HeadPanAngle * (BodyRotY/ABS(BodyRotY))
ENDIF
;Calculate body angle depending on rotation
IF ABS(TravelRotationY2)>cTravelDeadZone & ABS(TravelRotationY3) > ABS(HeadPanAngle) THEN
HeadPanAngle = -TravelRotationY3 ; Rotation max = 166 to get max range of 90 deg.
ENDIF[/code]
also how do a add the head to the single leg control mode so that i can select the head to move in the same way the legs to in this mode.
Again great work.
Apart from “autonomy”, I’m not sure how this code could be improved on.
EDIT. just realised bodyYshift is still here. some reason my code didnt see it. 
As far as I can see its still there, in the phoenix_control_PS2.bas file.
Edit: Oh, I didn’t catch your edit… 
The reason is probably that you are trying to call this variable from the main .bas file, where its not defined yet. Maybe moving the code to the control file would help?
hi zenta,
yep… no points for me there!
thanks mate.
?
regarding the GP-player…
im not updating my firmware due to it having to disassemble to get to it!
so can i delete everything in the code related to [GP] or are there parts i will need to leave?
loving the code,
J
From what I remember from chatting with Xan, he checks for the proper firmware version before any GP commands are implemented. So no changes to the code are necessary.
yes this is true. the code does check the firmware version before any GP commands are used. but seeing that i wont be using these commands, would it be ok to remove them? and is it safe to.
Obviously Xan is the one to answer this.
but I don’t see any reason why it should negatively cause problems with or without the GPPlayer code. At a minimum you could always start off with simply doing something like: #ifdef USEGPPLAYER… #endif around the sections of code associated with the player.
Just search for everywhere in the code that uses the variable GPEnable. This will be in the main phoenix code as well as in the control (PS2, …) source file
Kurt
thanks. well about 30mins ago i went thought it anyway commenting out anything GP and all is OK…
it seems there are no strings attached between this sequencer parts and the main function of the code.
im going to be looking into finding or modifying a RS-232 connection “m/f” with a short SATA or IDE cable and have one end constantly connected to the botboard and at the other end im going to fix it to my chassis with the pins facing out 'on the top of the hexapod. so instead of moving legs, wires etc to plug in, i can just connect it from the top. 8)
Hi guys,
I swore that I answered yesterday but I think I just hit the “preview†button instead of the “submit†button. 
There ain’t nothing wrong with your memory Jim
The BAP code checks the SSC version. It enables the GP player if the version number ends with “GPâ€. Depending on this it will enable or disable the GP player. There is (almost) no time loss with this because there is a single “if†check in the main loop.
The GP player is a stand alone sub-function in the code that can be easy removed. The only reason for removing I could think, of would be to clear memory space. But offcourse you’re free to do it. 
Xan
The only other reason I can think of, is he wants to use that button on the PS2 remote (or whichever input method he uses) for something else… 
Kurt
Indeed, i didn’t think of that one.
xan
i can help you there… there isn’t really a reason for doing this.
i think its mainly due to the fact that im still learning programming so every bit of info helps i guess.
the code is fantastic and all credit to you xan. i do plan on writing my own code in the future.
thanks for your help guys.
Ah, the reason is: Enjoying youself and gadering some new programming skills!
How could could I miss that! What about you Kurt?
Hi Xan and guys
Marvellous: All seem finally work quite well for the Atrax (octopod) … with the 1.3 version of Xan’s code.
The gaits are so cool but the bot walks a bit too slow; I enjoy the V2.0!! We can observe the difference between the scorpion gait (4231 seq) and the Tarantula one (4132 seq) patterns. That’s so nice! Thanks Xan for your great work! I’ll present it to you asap in a new Projects topic with pictures…
But what a pity that the V2.0 code version doesn’t work yet at all with this Atrax!!What could go so wrong?
Note at first: after each Basic Micro Studio IDE installation (several trials), I had to restart the PC (Compaq NC6000 with XP pro) manually before the first use.
Hi McSpider,
If the code can’t be build it will give you some compiling errors. Can you tell me what they say?
I’m still using the old IDE (8.0.1.7). I know that Zenta uses 2.0 in combination with the Studio with success. I can’t say what version he used though.
I do know that there are some issues with the serin command in the new studio. It is possible that the GP will not work while using the Studio.
The beeping sound looks like the controller isn’t connected correctly. Are you able to turn the bot on and off by pressing the start button? Are you sure you’ve got the correct PS2 file loaded to your project setup? You should also double check if the pin layout is correctly configured in the config file.
I hope this helps.
Xan
Hi Xan
Thanks for your quick answer.
When using BMStudio 10015, the compiler cannot start the compilation at all. For all bas programs, I observed the same behaviour.
The bot beeps with the V2.0 and I cannot turn it on neither by pressing the start button. But the remote works perfectly with the 1.3 version. I tried to program your original V2.0 for the Phoenix (without changes for Atrax) too. The behaviour is always the same: nada.
You’re still using the IDE (8.0.1.7)? Wow: I remember it didn’t work with the 1.3V and the 8.0.1.8 was recomended. OK, I’ll try the 8.0.1.7 one. But the prj file doesn’t appear in the working zone on the left.
I’ll give some feedback. Thanks