I can’t register on the Orion robotics forums, so I’m asking here (as I bought the controllers through Pololu.)
I have a couple of 2x5A RoboClaw controllers, each driving two Pololu 37D 50:1 12V gear motors, using the quadrature encoders. I’m using version 3.1.5 of the firmware, and version 4 (?) of the hardware.
I use a simple Linux program to read and write the serial bus of these controllers, also using a diode-based buffer board to make both boards able to fan-in to the single controller, as they are not set up for sharing a TX line like some other serial controllers.
After running for a while, it seems these controllers go crazy on the serial bus. The symptom is that the controller will respond to a command like it has been doing, but then just spews random-ish bytes on the bus. At some point, my controlling code then sees that it gets a checksum error, and exits the process, which then restarts (which re-opens the serial driver) but the board will just keep doing this for a long while.
Also note that there are two boards on this bus (0x80 and 0x81,) so it may be something that only happens in this configuration, and it’s some fight between the boards, although I make sure to wait for the response from one board before polling the other board, and they are not supposed to talk on the bus of their own accord.
I have captured some Saleae Logic screen shots from this problem, which may perhaps help.
There is some small chance that this is a Linux USB serial driver bug (God knows I’ve lived through such things before) or perhaps even a USB serial adapter bug (Prolific PL2303 controller; not FTDI) but I’d like to know if anyone has seen a similar problem with the RoboClaw to see if I can isolate the problem this week-end, without having to wait for alternate hardware in the mail.
Here’s a good-looking command being sent (the second row) and responded to. Note that the 0x18 byte (the sixth byte) is the response checksum, and the bus should go quiet after that (it has done so in response to the same command for > 95 seconds before this,) but it doesn’t.
Here’s how that command follows:
You can see that the bus even ends up with a framing error (flatline of the serial line) after which it goes to a bunch of zeros, and then some more random-ish data:
For reference, here is a higher-level overview of the communications. The quiescence and successively slower sends on the second row is my driver detecting checksum error and restarting with a linear time backoff. The RoboClaws seem to keep writing onto the bus no matter whether commands are written or not. Also, this is taken from the OR-ed bus, so I know it’s the claws doing the writing (not the serial driver,) but I don’t know which of the two it is.
