SSC-32 and BB issue

Hello,
I have a quadruped robot with an SSC, BotBoarduino, and PS2 controller.
I uploaded my configured Pheonix code - the “QuadC_PS2_SSC32” Arduino file - to the robot using Arduino and it said that everything compiled and uploaded fine.

When I started up my robot and got everything connected, I pressed some buttons on the Lynxmotion controller and the robot started beeping when I pressed certain buttons. However, the robot did not move and the SSC’s green light did not flash when I was pressing the buttons.
Is there a certain procedure that I need to follow to get the robot moving (setting a certain mode using the controller, etc)? Or do I need to do anything to the code?

My Baud rate in both the code and on the SSC-32 is 115200 and I am using the 12/13 pins for the Tx and Rx.

Additionally, how am I able to debug the system? When I was going through the code, I noticed that there was a lot of debug serial outputs, but I do not know how to read these outputs.

Below are images of my setup for your reference.



Please let me know if you see any issues with my system and if you know how to get this system working.

Thanks,
Christopher

I have continued working on my quadruped over the past few hours with some luck. I tried to change the baud rate to 38400 in my code and on my robot, which didn’t work; I decided to keep my system like this, however. I then readjusted some of the wires (Tx --> Rx, etc), which seems to have corrected some of the issues with BB to SSC communication because the green light now flashes on the SSC. However, the Servos do not seem to move even though they are receiving power.

I decided to attach my code as a ZIP file so that you can briefly skim it and determine if there are any issues with it. I also attached a video that better demonstrates the issue I am experiencing and my setup.

Again, please let me know if you have any ideas or suggestions regarding my setup. I have gotten a bit frustrated and any help would be greatly appreciated.

Thanks,
Christopher

libraries.zip (1000 KB)

Hi Christopher,

< 1st post >

We assume you are using the code example found here.

Typically pressing start to activate the robot and then the other controls can be used to cause motion.

The default code uses 38400 since the BotBoarduino is using a SoftwareSerial port (over pins 12/13) to send data to the SSC-32. We strongly recommend to stick to that baud rate since the SoftwareSerial interface is limited in maximum baud rate because it is software-driven and therefore CPU bound. Since the CPU of this microcontroller is also doing many other tasks (PS2 reading, IK calculations, etc.), it most likely will not be able to produce proper communication above 57600. We suspect 38400 is used by default because it is more stable. Please note that a baud rate higher than what is required to keep the motors updated in real-time is not useful (and in fact may cause communications errors for various reasons, as may be the case here).

If you look in the config file, you’ll notice the debug interface is defined as Serial, which is the hardware serial port of the BotBoarduino (available through pins 0/1 and the USB port). Therefore, you can access the debug interface through there. Typically the baud rate used on this one is 57600.

< 2nd post >

Please check the comment above concerning baud rate. At this point, it may be simpler to download a fresh copy of the libraries and source/config code and set your SSC-32 jumpers to 38400 baud rate and try again.

Sincerely,

Thank you very much for your prompt reply.

I attempted to redownload and upload a fresh copy of the library. I also set my SSC’s baud rate to 38400. However, I ran into the exact same issue. When I move the joystick forward, the SSC’s green light flashes as if it is receiving a command but the Servos do not move in response.

Is it something with my wiring or jumpers?

Thanks again,
Christopher

This would need more investigation. Do you have another Arduino-compatible board available to do a quick serial data test (or, alternatively/even better, a logic analyzer)?

At first glance they do not seem wrong, but some clear picture of their current state would help.
Generally speaking, you should have the following settings:
> BotBoarduino

]Power = EXT/:m]
]VS = VL/:m]
]All GPIO ports set to 5V/:m]
> SSC-32

]Baud set to 38400/:m]
]Both VS1=VS2 in place/:m]
]No VS=VL if you have a separate source for VL (greatly recommended to prevent brownouts. The SSC-32U has a fix for this, but the SSC-32 is very vulnerable to brownouts)./:m]

Sincerely,

Hello,
Yes, I do have access to some Arduino boards.

As requested, here are some images of my current system.




Thanks again for your help,
Christopher

Hello,
I attempted to do a serial data test, but I got some strange results.

Here is what I did:

  1. Connected the Tx pin on the BB to the Rx pin on my Arduino Uno, the Rx pin on the BB to the Tx pin on the Arduino Uno, and both GNDs
  2. Plugged my Uno into my computer and uploaded the SoftwareSerialExample to it
  3. I then opened up the Serial Monitor, turned on my BB, and moves my PS2 remote
  4. This is what came out of the Serial Monitor:

Here are some images of my setup:



Please let me know if I am doing something wrong.

Thanks,
Christopher

Hi,

That is pretty much the test I was going to recommend. It should be noted that the default baud rate for the SoftwareSerial on the BotBoarduino will be 38400, not 57600. Hopefully you’ve modified the SoftwareSerial example to use that baud rate in its .begin() calls. If that is not the case, this should explain the unreadable output.

Lets us know how that goes!

Hello,
I realized that after I posted that and adjusted it. However, I was unsure as to if I needed to change both Baud rates in the code to 38400 (for both mySerial and Serial). I tried it in both configurations (57600, 38400 and 38400, 38400), but both did not yield results. I got the “Goodnight Moon!” message, but nothing else.

Is there something wrong with my setup?

Christopher

This is my code:
[left][code][/LEFT][LEFT] /*[/LEFT]
Software serial multple serial test

Receives from the hardware serial, sends to software serial.
Receives from software serial, sends to hardware serial.

The circuit:

  • RX is digital pin 10 (connect to TX of other device)
  • TX is digital pin 11 (connect to RX of other device)

Note:
Not all pins on the Mega and Mega 2560 support change interrupts,
so only the following can be used for RX:
10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69

Not all pins on the Leonardo and Micro support change interrupts,
so only the following can be used for RX:
8, 9, 10, 11, 14 (MISO), 15 (SCK), 16 (MOSI).

created back in the mists of time
modified 25 May 2012
by Tom Igoe
based on Mikal Hart’s example

This example code is in the public domain.

*/

#include <SoftwareSerial.h>

SoftwareSerial mySerial(0, 1); // RX, TX

void setup() {
// Open serial communications and wait for port to open:
Serial.begin(38400);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}

Serial.println(“Goodnight moon!”);

// set the data rate for the SoftwareSerial port
mySerial.begin(38400);
mySerial.println(“Hello, world?”);
}

void loop() { // run over and over
if (mySerial.available()) {
Serial.write(mySerial.read());
}
if (Serial.available()) {
mySerial.write(Serial.read());
}
}
[LEFT][/code][/left]

The debug serial interface is typically defined in the “Hex_Cfg.h” file as DBGSerial.

You may want to have a look there and make sure it is active (there are a few #undef for it, so look carefully).

As for the init of the debug interface, this is typically done in the “Phoenix_Code.h”. In the case of the quad libraries, it seems the default baud is 38400 (and not 57600, like in the 3 DoF examples).
Here is an example of what it looks like:

#ifdef DBGSerial DBGSerial.begin(38400); #endif

You can also see more details concerning the debug in the TerminalMonitor() function.

Sincerely,

Sébastien,
I have been trying to set up this system for a few hours now and it still doesn’t seem to be working as expected.I took a video demonstrating what is occurring, it can be found at this link: drive.google.com/file/d/1EaIpUn1saOOjA3Opcxo0AoTxb8Y6JdyU/view?usp=sharing.As you can see, I get the Goodnight moon message signaling that the computer and Arduino board are connected. The D4, 3, and 6 also seem to be in sync with the L light on my Arduino. However, no message is received.
I ensured that the DBGSerial is active, but just in case, I attached my “Hex_Cfg.h” file below.Hex_Cfg.h (11.2 KB)
Thanks again,
Christopher

Update:
I found a commented out region in the Hex Config file, so I fixed it and retried.
This is what I am getting now: drive.google.com/open?id=1kFDVc … vFIwBKpbud.

Hey,

Did not catch this at first, but you should probably remove the mySerial.println("Hello, world?"); since the interface from the BotBoarduino does not expect some communication; it may cause an issue of some kind.

Also, typical data coming from a BotBoarduino running the Phoenix code should look like this. Therefore, the output you received seems partially good and then garbled later on. You’ll need to look into that (may be related to the point above, too).

Sincerely,

As requested, I eliminated the Hello World.

Output still is garbled; please suggest a next step.

Update:
I seemed to have gotten a partially correct output from the BotBoardunio.
When I start up the Serial monitor before pressing start on my controller, Servo numbers, positions, and time are clearly printed out. However, when you press start on the controller, the serial interface becomes are garbled. Below are some images of what is occurring.



Do you know why that may be occurring?

It would seem the output either is shifted (a few bits) or at the wrong baud rate after you press start (activate the robot).

Have you noticed what happens to the output if you press start a second type, deactivating the robot? Does it stay garbled or change back?

As a quick test to reduce the number of potential issues, please try the code found here. Very important :: do not change anything else!
The goal here is only to figure out if this code produces the proper output on your current setup, since it has been tested many times (as recently as last week!) and is certain to work (i.e.: produce proper outputs after pressing start / moving the joysticks).

Let us know how that goes.

Sincerely,

After pressing start a second time, the output returns to normal.

The new software was loaded to the robot. After starting up the robot and turning on the controller, the green light goes solid. However, no chime is played after pressing start. It connected to the BotBoarduino board, but it seems as if the BB is not properly interpreting the output from the PS2. Finally, to ensure that it wasn’t an issue with the PS2, the original code was rerun and the PS2 properly connected to the BB and beeped after pressing the start button.

Hi,

That would most certainly indicate a software issue in the quadruped code. Please note that this code was developed by the community ~2012 as an example and was a “WiP” at the time (and still is, since it was not significantly updated). Since the quad platform and code example are nowhere near as popular as the hexapods, it is quite possible some things in that software setup are wrong and need fixing. At the very least, this is a strong indication that your BotBoarduino is working properly.

Similarly, most likely a software issue concerning reading the PS2 adapter.

It should be noted that these code example were provided as-is by Lynxmotion originally. Since their inception they have not been maintained for the most part and it is quite possible that anyone using them had to fix a few things here and there (but unfortunately did not contribute their findings back to the repo).

At this time, the best solution would probably be to take both examples and compare them and their libraries and see what differences there are between them. It seems very possible that different parts of each were updated independently/improperly and thus fixes in one were not posted to the other by the previous maintainers.

Sincerely,

The Robot Shop recommended the PS2 and the Botbordino setup. The system is not working. The firmware might have bugs or the hardware might be defective. The Robot Shop regarded the PS2 and Phoenix firmware to be a reliable system. The next step should be determining whether there is a hardware or firmware issue. Hardware issues were found in the past. Please recommend a procedure. There is a deadline for the system to be working and this is a large program.

OK, so we tried it out (the quad code from the GitHub) on our own BotBoarduino. We did the following:
Changed the pins from 10/11 to 12/13 for the serial interface.
Swapped DAT/ATT from 6/8.
It seems the pins used in the quad code and the 3DoF hexapod code are different. That would most likely explain why you did not see any response from your PS2 controller with the 3 DoF code.

Before we pressed START, we had proper all #?P0" outputs.
Once we pressed START to activate the robot, we also got proper output out of the BotBoarduino.

This minded me of something else I noticed on your pictures: you previously had the output from the BotBoarduino (12/13) connected to pins 0/1 on that extra Arduino.
If using the default SoftwareSerial example from the Arduino libraries, you should have those connected to pins 10/11, not 0/1. That maybe be causing some of the issues with the garbled test output.
Also, make sure to change both baud rate to 38400 in that example. They are by default set to 57600 and 4800.

Please check all the info above and test again and see what you get out of the BotBoarduino.

Since in your pictures you are using pins 12/13 on the BotBoarduino for the software serial output (usually connect to the SSC-32/SSC-32U), it means you did modify at least a bit the config file from the repo. Did you make any other modifications?

Sincerely,