I have assembled an AH3 R hexapod and I am having trouble getting the BotBoarduino to communicate with the SSC-32. I have been able successfully to calibrate all 18 servos using the SSC-32 Servo Sequencer program. I am also able to control the servos using the Lynx SSC-32 Terminal program. I wrote a simple Arduino program to have the BotBoarduino control the servos, and here I am having no luck. Here is the program:
It runs OK but the SSC-32 doesn’t respond. I am confident I have the connection between the BotBoarduino and SSC-32 OK. I took a nice picture of it but can’t figure out how to insert it here!
Does anyone have a suggestion for where something might be wrong?
You code seems good, so I would suspect that there’s a communication problem between the two devices.
I see from your code that you’re BotBoarduino is set to use a baud rate of 9600. Have you changed the jumpers on your SSC-32 to match? See item 9 in the SSC-32 manual. If the headers are correct (first one removed, second still present), then I would suspect it’s a wiring problem and your picture would help.
To upload the picture, you can use the Upload Attachment area (below the message body area) to upload a picture as an attachment. You can also use the “Add the file” button afterwards to include the file in a specific position in your response.
Also my guess is that you want the Time parameter to the SSC-32 and not the Speed parameter.
That is the " S", maybe should be " T"
To add a picture go to the Full editor and click on the upload attachment tab, In there browse to your picture and upload it. You can then click on insert inline…
Thank you for your help. Attached is a picture of my boards showing how the BotBoarduino is connected to the SSC-32. I suspect a baud incompatibility too; I’ll look into that after Christmas.
I’ve made the baud rate 115200 in both the program and the SSC-32. When I run the program the servo does not move. My procedure is first to turn on the servo power and second to turn on the logic power. The voltages are 6.6V for the servo power and 7.37V for the logic. The physical setup is the same as I showed in the picture earlier. I modified the program slightly, not enough to effect the SSC-32. I’ve attached a screen shot showing the program and the monitor output.
Sorry, I did not notice it earlier with your picture you posted of the two boards. The wires you have connecting the BotBoarduino (BBD) to the SSC-32 is going to the IO pins 12/13 on the BBD. The hardware Serial port on an Arduino like BBD is to IO pins 0/1. So two options here:
Move wiring to hardware serial port. There is a 3 pin connector on the board for this: #10 on diagram lynxmotion.com/images/html/build185.htm
Plus side it has hardware support and can run at 115200(maybe). Downside is you usually have to remove the cable when you want to download new program to BBD and it uses your serial output which is nice for debug…
You use a SoftwareSerial connection. There is information about this library up on Arduino (arduino.cc/en/Reference/SoftwareSerial). My Phoenix port to the Arduino uses this with the BBD. I have code that defines it like:
SoftwareSerial SSCSerial(cSSC_IN, cSSC_OUT); // where I have the pins defined in a config file:
then you need to do a begin:
SSCSerial.begin(cSSC_BAUD); // Again baud defined in a config file, normally use 38400
Then your writes go to this object and not Serial object.
SSCSerial.print("#");
As I tried to mention, the tutorial was written the way that mine was wired… I prefer that way as to leave the serial port available for debug… So then you need to go to my option 2) above.
Note if you look at the tutorial you mentioned at picture #3, you will notice that the BAUD jumpers have the first jumper installed, the second one removed. This configures the board for 38400. However before you do this, I would suggest that you update the firmware in the SSC-32 to the latest version that ends with EGP (extended GP) as only these versions support binary mode, which the Phoenix software by default is configured for… Different subject, several threads on this.
[code]#include <SoftwareSerial.h> #define cSSC_OUT 12 //Output pin for (SSC32 RX) on BotBoard (Yellow) #define cSSC_IN 13 //Input pin for (SSC32 TX) on BotBoard (Blue) #define cSSC_BAUD 38400 //SSC32 BAUD rate
SoftwareSerial SSCSerial(cSSC_IN, cSSC_OUT); // where I have the pins defined in a config file:
void setup() {
SSCSerial.begin(cSSC_BAUD );
}
void move_servo(int servo, int angle, int time) {
SSCSerial.print("#");
SSCSerial.print(servo);
SSCSerial.print(" P");
SSCSerial.print(angle);
SSCSerial.print(" T");
SSCSerial.println(time);
}
Hi, I have similar problem. It looks like mine SSC32 is not communicating with BotBoarduino. I did steps from this tutorial lynxmotion.com/images/html/build99f.htm so it should work but it doesn’t. According to sounds it looks like BotBoarduino is accepting commands from PS2 controller so I think I uploaded the software correctly, I also tried to switch wiring to hardware serial port, but nothing. Jumpers are exactly like on pictures. The only differences from the tutorial is that I skipped the calibration for now because I couldn’t connect the SSC32 to communicate with computer properly. I tried COM, USB-COM adapter, on three different computers, but everytime I run the Hexapod Calibration software, it founds nothing. If I run SSC32-Sequencer-Utility than it found it but after 5 seconds there appear a message that I should repower the board. I set jumpers according to setting the baud it the software but nothing. I also have two SSC32 boards and both do the same.
But at least to communication with BotBoarduino should work without it so I suppose that there is another problem. Software should be 2.01XE like in the tutorial. So for now I don’t know to get it working. I have different servos but they should be compatible. They are Towardpro MG996R.
Does anyone have any idea where could be the problem? Or should I change something in the arduino code from the tutorial?
Thanks
Pictures would help. Also, what are you using to power the VL of the SSC-32? Maybe the battery isn’t good anymore? Also, did you remove the VL=VS1 jumper so that the servo battery isn’t fighting with the logic battery?
Are you running the Phoenix software? When you hit the Start button on the PS2, can you see if the red led on the SSC-32 is flashing? If it is, it is probably one of the following:
a) Power - My number one thing to check. Is the Servo power turned on? Do you have a fresh change on this battery? can you measure the voltage that is at the terminal…
b) Wrong baud rate. Program is probably configured for 38400, so should have the first baud rate jumper on and the second off.
c) The Phoenix code is configured for binary mode and the SSC-32 firmware that you have on your robot does not have a version of firmware that supports this installed. By default this is turned on as when we did this, the default firmware that was going to be installed on new boards was going to change, but I don’t think this ever happened.
Two ways to resolve:
rebuild Phoenix code with binary mode turned off. Open up Arduino project, go to the file Hex_Cfg.h and comment out the line: #define cSSC_BINARYMODE 1 // Define if your SSC-32 card supports binary mode.
like:
//#define cSSC_BINARYMODE 1 // Define if your SSC-32 card supports binary mode.
Now rebuild and download program and see if that helps.
Probably Lynxmotion should do this on their Github version.
Thanks, I was too depending on the tutorial. I found out that I have to connect tx/rx with jumpers and then the SSC32 was able to communicate with pc, so I tried to flash the latest firmware 2.07EGP and it is working now.
But I have different problem now. It is working, but not walking as it should. When I pull the left joystick on PS2 controller up than it starts walking to back instead of front. And if I put it left or right than it behave strange, it doesn’t strafe, also the right joystick should rotate it but it is also unable to rotate.
I am thinking now that I may misunderstand the assembly instructions and swapped horizontal and knee outputs on SSC32. After recharging battery I will try to swap them. And just a thought, as I wrote, I have Towardpro MG996R servos, isn’t also possible that they have reversed direction?
edit: So the horizontal, vertical and knee was switched. I just imagined it wrong. Now, after correcting the positions, it walks and it should.
edit2: If anyone would like to see the current status, I uploaded a short video on google+
I followed your suggestions in your last post, updating the SSC-32 firmware and commenting out the line 60, #define cSSC_BINARYMODE 1 // Define if your SSC-32 card supports binary mode.
Compiling gives the error message “‘ServoMoveTime’ was not declared in this scope” in Line 269 of phoenix_driver_ssc32.cpp. It compiles OK for me with the line not commented out.
I have switched successfully to SoftwareSerial as you suggested. The little SoftwareSerial test program you suggested also worked OK.
Is there something else I need to modify in the code besides the commented-out Line 60?
Ted
@tedkurtz, If you successfully up the firmware of the SSC-32, you do not need to comment line 60 anymore. You should be able to leave it as-is, compile and upload.
Compiled and uploaded the software OK and it is now working. Nothing like kwong showed in his video, which is fantastic, but responding to PS2 buttons. Thank you for your help.
I should mention, that my later versions of the Phoenix code base for the Botboarduino is up on my own github account. In particular the project: github.com/KurtE/Arduino_Phoenix_Parts
Note: The layout of this project is a bit different as I have a separate arduino library for each part (main, servo driver, Input Controller). This allows me to have many different configurations that are all sharing the same code bases and try to keep them in sync… There is a readme up on that project that talks more about this.
One of the things I have found in the past is when you first setup a robot and it is not walking correct (and I have not screwed up the code ), is that maybe I have the wrong servo plugged in to one or more servo pins… Also I found that I don’t like taking the time to use some external program to setup the servo zero points. So the version I have up on github has the ability to compile in some simple servo offset adjusting code, that you can get to by having the Botboarduino USB connected to the PC. I have a simple terminal monitor, that if you bring up the terminal monitor at baud rate 38400. If you enter an empty command (just hit enter), it should show you a list of commands. One such command is the Servo offset Mode, which enters a mode. In this mode you can use keyboard commands to walk through the different servos and use the + and - keys to change the offset of a servo and at the end you can decide if you wish to save these changes. Note: some of this code may also be in the Lynxmotion version of the code. However one thing I added later in my version, is when you tell it to go to the next servo (* key), it will print out the pin name, plus the pin number. Also when you choose a servo, it will wiggle it. So when you walk through the servos, you can watch to see if the servo it thinks should be manipulated is the one that wiggles… I have found this useful in the past to find things, like the wrong servo moving, or one not moving at all…
I got my robot running well. I did indeed have two servos not connected properly. Now it walks nicely in various directions.
I do have a question about calibrating my servos using the SSC-32 Servo Sequencer Utility program. I clicked on CALIBRATE and adjusted all the servos so that everything was aligned nicely. Then, disconnecting the robot from my computer, the settings seemed to drift. The servo positions don’t seem to always be the same when I power up the robot. I had expected that the settings were stored in either the Initial Pulse Width registers or the Initial Pulse Offset registers of the SSC-32, and that the settings would remain constant and be used to position the servos when the power came on. Is that the way things are supposed to work? Perhaps my calibration procedure is wrong. (I’m drifting off topic.)
