no, since im running the code on a quad i have defined the pins differently. im pointing out that pin0 was acting up in the way i explained. i just thought it was strange. i see now that you also have servos connected to pin0 and there for i realize it cannot be something in the code and could maybe be my SSC. i do remember a while back i had problems with pin0 but i put it down to code. there is no problem now as iv moved the servo pin.
Jonny,
So what was the outcome? I notice that in your Axis 4D0F V2.0.1 code, you’re assigning pins 1-4 for LR leg. Bad P0?
I also notice that the RR corner of the SSC-32 is pins 0-3. Do you flip the board over or something?
I’m wiring up my 'Quad. I suppose I could wire like my hexapod, RR is 0-3. Phoenix build 139
lynxmotion.com/images/assembly/phoenix/phoen14.jpg
give the Phoenix R/C servo wiring.
Oops, 6v battery is dead. I measured it open circuit, before starting work on the 'bot this PM, and the first time I powered up one leg, the voltage dropped to just over 2v. Charging.
Alan KM6VV
yes i think my P0 is damaged or something thats why i change it to another pin. and yes my SSC is flipped over with the DB9 pointing forward. but its up to you what pins you use.
Yeah, I know about the pins. CFG file sets up all that. Just curious…
Alan KM6VV
I’m seeing strange P0 activity as well. Went to P8, but I’d like to know why. I searched the files for uses of P8 to no avail.
What did you find?
Alan KM6VV
Hi,
Jim and James asked me to make the 4 DOF T-Hex code available for PS2 controller.
I found it a bit plundering to use my existing XBee code, therefore I found it easier to start over by using a plain Phoenix V20 code (thanks Xan!)
I’ve mentioned the modifications I’ve done to the V20 code in the comment field:
;New in the T-Hex code version:
; - 4 DOF IK
; - Support both normal and binary command mode, the mode can be changed in the .cfg file
; - Support use of Code Offsets and use of the SSC-32 Offset registry, what offset to use can also be changed in the .cfg file
; - Modified gait method support of 5 lifted positions, added two types of Triple tripod
; - Modified and improved sync section
I included the Servodriver code Xan posted in this thread.
From the .cfg file:
UseCodeOffsets con 1 ;Comment this line if you are using the internal SSC32 registry offsets
BinaryMode con 1 ;Comment this line if you don't want to use the SSC32 binary mode
If you choose to calibrate the servos using the internal SSC-32 register offsets you’ll need to calibrate the servos like I mentioned in this post. Further down in the .cfg file you’ll see these lines:
;[Joint offsets]
;First calibrate the servos in the 0 deg position using the SSC-32 reg offsets, then:
cFemurHornOffset con 150 ;Snap out the horn one click upward
cTarsHornOffset con 150 ;Snap out the horn one click inward
These constants are used in the LegIK sub for compensating the snapped servo horn:
...
;IKFemurAngle
FemurAngle1(LegIKLegNr) = -(IKA14 + IKA24) * 180 / 3141 + 900 + cFemurHornOffset
...
;Tars angle
TarsAngle1(LegIKLegNr) = (TarsToGroundAngle1 + FemurAngle1(LegIKLegNr) - TibiaAngle1(LegIKLegNr)) +cTarsHornOffset
...
Jim just confirmed me that James has tested this working OK.
BTW: Recommend using the latest Studio version (2.0.0.7) to make the high speed baudrate to work. Thanks to Kurt and Nathan! 
T_Hex_4DOF_PhoenixV20_PS2.zip (18.4 KB)
EDIT: I did only make some minor changes in the PS2 controller file. The maximum TravelLength values might need some additional tuning.
Sounds great!
I May try to integrate some more of this into my code… For example this won’t compile for a Bap40 or Arc32… (Uses TimerW which is not supported on those chips…) Not sure if I will do like I did before and use TimerZ0 instead or convert to TimerA and TimerB1 like I did later…
Kurt
Note: I have the code modified on my machine for Bap40/Arc32. It builds for either Bap28 or for Bap40/Arc32 through the compiler defined constants (#ifdef BASICATOMPRO28). I have not tested it yet. Let me know if anyone wants it and I will upload…
Hi Zenta and anyone else who may be interested…
I don’t know why, but sometimes I end up doing pointless diversions 
I would like to play with one of these T-Hex soon, and I know that they are probably going to do a 3dof as well as a 4dof version of this. Made me wonder if maybe someone may want to do a hybrid version with some of both, like maybe the front and rear legs with 4dof and the middle with 3… So I wondered how hard it would be to change the code. The first thing it brought to mind was I would need to change the servo driver code to not output the Tars servo if the leg does not have one… It also made me think believe that you would probably have different lengths of joints for the different legs… So I updated the code to have bytetables for the lengths… I hacked up the code, such that if you define PERLEGCONFIG it changed the code… It compiles both ways now, but I have not tested it as I don’t have the hardware…
Now back to my normal diversions.
Kurt
T_Hex_Per_Leg_config.zip (19.2 KB)
Hi Kurt,
I’ve just looked at the code you’ve posted. I really like a universal base code that support the two BAP’s and especially the possibility for different 3/4 DOF and leg dimensions. A smart way to select between 3/4 DOF!
Just want to remind people to define the BASICATOMPRO28 const if they are using BAP28, maybe that should be defined as default in the .cfg file?
An even more universal code should support (or include) the XBee DIY remote too?
Anyway, thanks for the code Kurt! Awesome. 8)
Thanks, just having some fun!
FYI - the current versions of studio automatically define a constant for you depending on which platform you are compiling for. Things like:
BASICATOMPRO28
BASICATOMPROARC32
BASICATOM28
BASICNANO18…
Makes it much easier to write code for multiple platforms!
Note: on the code I uploaded. I did not do all of the changes needed if you are not running the SSC-32 in Binary mode. I also thought of changing the Non-per leg stuff to also conditionally compile depending on if cTarsLength is defined or not. If it is not defined, you could conditionally compile out the Tars code and change where the two variables TarsOffsetY, TarsOffsetXZ are defined as variables and instead define them as constants of value 0 which the compiler would more or less compile out… That way you could have one code base that handles 3dof 4dof and a mix…
Just a thought.
Kurt
I shamed myself into finishing the changes I mentioned in the previous post
So I think I have the code setup to handle:
All the legs the same both 4dof on all legs, 3dof on all leg.
Per leg config: can be all 3dof, 4dof, a combination of both…
Also I think the code is also in for both SSC binary mode and non-binary mode. Also in for code offset mode or not…
Again warning: I have not run any of this code so…
Kurt
T_Hex_Per_Leg_config.zip (19.4 KB)
Thats awesome Kurt! The code looks very good.
Thanks for the info about the automatically BAP type definition in the Studio, very convenient.
Like I mentioned before, would it be hard to also include the DIY XBee code as an option in this or does that just make it messy?
It should be a piece of cake to use the Xbee with this, likewise my hacked up RC version I did awhile ago… The code I put up recently for the ARC32 code compiles with or without SSC-32 and for BAP28, so it should lift straight on over…
Kurt
Quick update on the XBee stuff. It will take a little more work right now as this code base is based on V2.0 code base and the stuff in the other thread is based on V2.1 code. So there are variables like:
BodyRotY that in the other code base is now BodyRotY1…
I can do the conversion if anyone is interested… I may start off going the other direction and porting the 4 DOF / 3 DOF code back to the other base…
Kurt
Oh, I see… Ah, this explained why I was a little puzzled when altering the max/min body rotation values in the control file and comparing with my XBee code… 
I totally forgot the increased resolution on the body rotation part. Like i said I started all over using a plain V2.0 code. I’m not sure if it matter for the PS2 users though. If you ever find time to fix it, it would be nice though.
Hi Zenta (and others),
I hope you are having a great holiday season and are pretty busy with the new child!
I have played around with the code some and have it building with PS2 or XBEE… I did not put in the code to allow both as on a BAP28 you run out of code space…
While merging some of this code in, I found I needed to merge some more of the 2.1 stuff into the main program file… Also a few minor additions to the .CFG file…
Some of this revolved around making sure that we don’t receive any interrupts while we are doing a serout to the SSC-32. This was not as necessary when we were outputting at a lower baud rate and we only received timer interrupts, which are pretty quick, but were really shown to be a problem when we were receiving interrupts from HSERIAL which I am using in the XBEE code.
So I added in the calls to ControlAllowInput, which if defined uses the RTS line to the xbee to turn off the receiving of characters while we are outputing… Also calls to enable/disable the timer interrupt.
The project as I put in the zip file has both PS2/DIY stuff in the same project. You can compile for either by defining USEPS2 or USEXBEE in the config file… Can easily remove one or the other from project if not used… Likewise I did some minor editing like changing the hard coded P9 for sound to a configurable value as if running on Arc32 or Bap40 may not be on P9…
Again I have not tried running any of this code!!! If you get a chance, it would be great if you could try out the PS2 part again and see if any of it works. You will need to
T_Hex_Per_Leg_config.zip (34.9 KB)
Awesome Kurt!
Now I really need to switch over to API mode on all my robots…
I assume your latest XBee DIY remote code are posted in your thread, so I guess I’ve to jump in and try it one time. 
Whats the CHexInitY experiment in the .cfg?
And would you mind telling me a little about this part in the DIY control file:
; Used for updating leg positions depending on height
XZLength1 var sword
FemurAngle1H var sword
TibiaAngle1H var sword
I think I’ll update the bodyrot to sword too one time.
At the moment I’m on Christmas vacation so I’m not able to test the code, but I sure will when I get time for it.
Btw, We are doing fine with the baby. He do cry sometimes during the night so its less sleep for my wife and I’m pretty occupied with the two other boys. Pretty busy…
Yep - all of my stuff runs in API mode. I think it does give me better reliability and less overhead.
Most all of the changes you mentioned are part of some experimental code I was playing with. I was/am having problems with the contact switches making contact and think that having the legs be more perpendicular to the ground. So I have code that when you press the 9 key on the DIY it recomputed a set of leg positions depending on how high up the body is. Look in the code at "elseif iNumButton = 9 " (about line 552) to see where I am trying that out.
Glad things are going well with the baby.
Got to go.
Kurt
I take it “API mode” is a mode of the XBEE?
Merry Christmas!
Alan KM6VV
