Will you please show the wiring that provides the VS to the SSC-32.
I doubt its the wiring because the servos work fine when I adjest them in lynx term, but if you insist ill take a picture as soon as I come home.
Many of your problem descriptions point directly to power issues. Moving a single servo with Lynxterm is completely different from commanding all servos at once. Is this battery new or old? Fully charged? The wires going to the battery look too small to me, but it is very difficult to see them in the SSC-32 picture.
Ok … this is quiet odd, i fully charged the battery yesterday and used it for like 30 mins max so i didn’t think it will go dry so early, i plugged in the on-board battery checker and it reads 2 red leds … so i double checked with the multi-meter and the voltage reads 0.8V. to be honest im not sure how the battery got depleted this fast. ill recharge it again and hope this solves it.
I want to thank everyone for the troubleshooting and sorry for the headache i gave you guys.
Awesome… 
I have found in my 30 years of experience in electronics, code rarely has any effect on a system with a dead battery.
Blunt but to the point. Lol
Yes my first thoughts are to change power supply.
This is clearly stated in the SSC-32 manual.
Firmware Upgrade.
Updating the firmware is an easy straight forward task, but can only be done at 115.2k baud. Unlike simple VER or servo move commands, updating the firmware requires fast bi-directional serial communications. If you are experiencing problems with this please check over the serial port troubleshooting guide to ensure your serial port and or USB to serial drivers are optimized.
I think I’m getting grumpy in my old age. 
hmm, still didn’t work. The battery is charged to the max, I thought it might be too much load on the board so i decided to disconnect 2 legs and operate on the other 2 but still no movement. Here is the connection im using:
Note: This is the same connection i was using when i only had the BB2 and i was able to do push ups with it. To the left is the cable i connect to the battery checker for fast measuring the battery. The bottom black&red wires are directly from the battery . the top black&red are connected to the VS of the SSC with a switch.
Incase there are errors they should be displayed in the terminal when i connect to the chip from the IDE at 9600 baud rate right ?, well if thats the case then nothing seems wrong in terms of coding or connections, i still cant see whats going on wrong…
If it were me, I would start off debugging some of this stuff, one piece at a time… For example is your Connection working for the SSC-32…
So I would write a real dumb program, that did something like:
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 i115200 ;SSC32 BAUD rate 115200 require the Studio version 2.0.0.7 or later
leg var byte
pos var word
main:
gosub AllLegs1500
DoNothing:
goto DoNothing
AllLegs1500:
for leg = 0 to 31
serout cSSC_OUT, cSSC_BAUD, "#", dec leg, "P1500", 13]
next
returnNote: Typed in on the fly so may be bugs and the like. If all of the servos snap to 1500, you know that a lot of your hardware hookups are working… In that case I would try adding another function, like wiggle each servo. something like:
WiggleLeg[leg]:
serout S_OUT, i9600, "Wiggle Servo: ", dec leg, 13]
for pos = 1500 to 1800 step 50
serout cSSC_OUT, cSSC_BAUD, "#", dec leg, "P", dec pos, "T250", 13]
pause 250
next
for pos = 1800 to 1200 step -50
serout cSSC_OUT, cSSC_BAUD, "#", dec leg, "P", dec pos, "T250", 13]
pause 250
next
serout cSSC_OUT, cSSC_BAUD, "#", dec leg, "P1500T250", 13]
returnThen in the main loop before the Do nothing loop add something like:
for leg = 0 to 31
gosub WiggleLeg[leg]
next…
If this works you know that individual legs are hooked up. Also I added a serout to S_OUT at 9600, so it should tell you which servo number is being moved. Sometimes I use this to help find out some servos are not hooked up to the right pin…
If the first test did not work, I would check my wiring, and make sure for example that one or more servo wires are hooked up upside down… If still no luck, I would unplug most if not all of them and try again with just a few servos to see if it works… If not? If so add more. I have had a few problems in the past for example where maybe a servo fried or maybe the wire get caught in brackets and shorted… Found it this way…
Hope this helps
Kurt
Thanks Kurt, i tested all the codes, everything worked just fine as it suppose to. all legs moved so i guess the connections are ok.
Ill reprogram the robot with phoenix code again and see what happens, 1 question though:
In the phoenix code, there are 3 separate files (in 1 project), do i need to program the entire project into the chip or curtain files ?
so far I’ve been programming the whole project since they all seem to be related.
Edit: i tried the code at 115.2k baud rare but that didn’t work aswell
You need to load the project as a whole or for sure it won’t work! That is you MUST open the .PRJ file, not one of the .BAS files.
It might be some place in your posts, but which project did you download? Changes? If so maybe post it up, to look at…
I downloaded the code from lynxmotion.com/images/html/proj102.htm, and made the changes from lynxmotion.net/viewtopic.php?f=8&t=5523. Then i made a few changes to fit my robot:
Phoenix_cfg:
Changed the baud rate to 115.2k, body dimensions and starting position.
[code];--------------------------------------------------------------------
;[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 i115200 ;SSC32 BAUD rate
;--------------------------------------------------------------------
;[BODY DIMENSIONS]
cCoxaLength con 37 ;Length of the Coxa [mm]
cFemurLength con 90 ;Length of the Femur [mm]
cTibiaLength con 79 ;Lenght of the Tibia [mm]
cRRCoxaAngle1 con -450 ;Default Coxa setup angle, decimals = 1
cRMCoxaAngle1 con 0 ;Default Coxa setup angle, decimals = 1
cRFCoxaAngle1 con 450 ;Default Coxa setup angle, decimals = 1
cLRCoxaAngle1 con -450 ;Default Coxa setup angle, decimals = 1
cLMCoxaAngle1 con 0 ;Default Coxa setup angle, decimals = 1
cLFCoxaAngle1 con 450 ;Default Coxa setup angle, decimals = 1
cRROffsetX con -89 ;Distance X from center of the body to the Right Rear coxa
cRROffsetZ con 89 ;Distance Z from center of the body to the Right Rear coxa
cRMOffsetX con -63 ;Distance X from center of the body to the Right Middle coxa
cRMOffsetZ con 0 ;Distance Z from center of the body to the Right Middle coxa
cRFOffsetX con -89 ;Distance X from center of the body to the Right Front coxa
cRFOffsetZ con -89 ;Distance Z from center of the body to the Right Front coxa
cLROffsetX con 89 ;Distance X from center of the body to the Left Rear coxa
cLROffsetZ con 89 ;Distance Z from center of the body to the Left Rear coxa
cLMOffsetX con 63 ;Distance X from center of the body to the Left Middle coxa
cLMOffsetZ con 0 ;Distance Z from center of the body to the Left Middle coxa
cLFOffsetX con 89 ;Distance X from center of the body to the Left Front coxa
cLFOffsetZ con -89 ;Distance Z from center of the body to the Left Front coxa
;--------------------------------------------------------------------
;[START POSITIONS FEET]
cRRInitPosX con 117 ;Start positions of the Right Rear leg
cRRInitPosY con 79
cRRInitPosZ con 117
cRMInitPosX con 105 ;Start positions of the Right Middle leg
cRMInitPosY con 25
cRMInitPosZ con 0
cRFInitPosX con 117 ;Start positions of the Right Front leg
cRFInitPosY con 79
cRFInitPosZ con -117
cLRInitPosX con 117 ;Start positions of the Left Rear leg
cLRInitPosY con 79
cLRInitPosZ con 117
cLMInitPosX con 105 ;Start positions of the Left Middle leg
cLMInitPosY con 25
cLMInitPosZ con 0
cLFInitPosX con 117 ;Start positions of the Left Front leg
cLFInitPosY con 79
cLFInitPosZ con -117
;--------------------------------------------------------------------[/code]
At the Phoenix_v20 :
I changed the ripple gait to a simple 4 legged gait.
[code]IF (GaitType = 0) THEN ;Ripple Gait 6 steps
GaitLegNr(cLR) = 1
GaitLegNr(cRF) = 2
GaitLegNr(cRR) = 3
GaitLegNr(cLF) = 4
NrLiftedPos = 1
HalfLiftHeigth = 0
TLDivFactor = 2
StepsInGait = 4
NomGaitSpeed = 100
ENDIF [/code]
If it were me, I would try a different set of Phoenix code to see if that works better. Like maybe the version 2.1 stuff. Not sure if it is up on the main website? But you can try getting it from thread: viewtopic.php?f=8&t=7658
Otherwise if it were me, I would hook up my logic analyzer to the IO pin going to the SSC-32 to see what if anything is being sent to it. Without one of those, I would probably start playing other games, like set or clear or toggle Leds on the board at different places in the code to see if the code is being executed. Since I think you are using the PS2 on standard IO pins (12-15), where the Leds are by default. One trick I learned from Xan, was to use a servo jumper wire and jumper from other IO pins like 4-6(connect one side up to these) and connect the other end up to the top (outer) side of where the PS2 jumpers were. This allows you to use these IO pins for the Leds and buttons… I would then toggle one lets say in the PS2 Control_input function and another one in the Servo output functions…
Kurt
Hmm, i downloaded the code, powered the robot but the speaker keeps playing a note repeatedly.Im not sure what that means but I’ll check around and see if i did something wrong.
If it continues to play a sound, it usually implies that it is not happy with the PS2 controller and hanging in the PS2 Init code…
Or could be the program is resetting…
Kurt
Precise 
, it seems i pulled the PS2 cable out when i opened the robot, i just plugged it in well and now its working 
.The gait sequences looks fine but i don’t think i did the configuration and body dimensions right. The legs aren’t in their places properly. ill go over the cfg file again and fix whats wrong.
I want to thank everyone who participated in this long and painful troubleshooting x).
Great! , I’ve finished the configuration and the gait looks so nice . But one thing left to do, My robot has 4DoF, it has a 4th servo at each leg that is closer to the center, its job is to flip the legs upside down whenever i want it to. The problem is, these servos are not included in the gaiting sequence so they’re always off.
What i want to do is send a serout command to the SSC to keep those servos at curtain degree all the time and through all the gaits. The problem is that i don’t know the exact syntax for sending a servo command to the SSC. I dug through the code to see how its done but its quite complicated there, i also checked the user manual for examples but couldn’t find any. could someone provide an example please ?
The Syntax is in the manual: lynxmotion.com/images/html/b … htm#srvmov
In that document There is also a link to the manual for the binary command format: lynxmotion.com/images/html/build177.htm
Once you tell the SSC-32 you wish for a servo to go to a specific place, it will stay there until you tell it to go someplace else. (Assuming that you don’t run out of battery or the servos are not overloaded… 
)
So for example if you wish for all of those servos assuming that at at servos (3, 7, 11, …) to go to their center place, you can do a simple output like:
serout cSSC_OUT, cSSC_BAUD, "#3P1500#7P1500#11P1500", 13] Note: this is all hard coded and it will actually be undone the first time you tell the robot to stop, as the function FreeServos will tell all servos on the SSC-32 to free themselves…
A cleaner approach would be to add them in to the Phoenix Servo Driver code… If you are using the 2.1 code that would probably be in the file
phoenix_driver_ssc32.bas in the function UpdateServoDriver. In there you can see some optional code for a 4th DOF for legs. However this code relies on things setup in the config file for having the Tar’s length for each leg… But assuming you are using the same servo numbers as we defined for the 4DOF, you could make simple code like the part in the #ifdef c4DOF of that function. that for some fixed angle, like 1500 again…
serout cSSC_OUT, cSSC_BAUD, [0x80+cTarsPin(LegIndex) ,1500 >> 8, 1500 & 256]Or you could try to simply define this within the current 4DOF code and see what happens… Otherwise if these servos are not directly inline and actually create another DOF, than the IK will probably need some work…
Kurt