Both roboclaws sudenly stop

General discussion of using Roboclaw motor controllers
Post Reply
felix
Posts: 19
Joined: Thu Dec 03, 2020 8:08 am
Both roboclaws sudenly stop

Post by felix »

Hi,
I have some strange problem.
We are using 2 robots, each with 4 motors (one per wheel). We use 2 pieces of 2x60A roboclaws per robot (one for the front wheels, one for the back wheels). Those are communicating with a Linux computer (Jetson Xavier AGX developer kit), over the same serial output on the GPIO.

From time to time both roboclaw stop for a fraction of a second (ie all 4 motors stop at the same moment).
Do you have any idea where it might come from?


Some (maybe) useful infos:
- the motors are rather big (rated 24V 250W, in practice it can be more than the announced 10A)
- it happens at all speeds we tried (from very slow to a speed of over 1m/s for the robot)
- it also happens when the wheels are not attached to the motors (so nearly no load condition)
- we use the E-stop function. There is a 1k or 4.7k resistor to pull up the E-stop. We use an electro-mechanical relay to connect the E-top pin to ground when we press one of the emergency buttons.
- batteries are 7S Lipos (max voltage 29.6V, min = 20V at rest). There are voltages drops when aksing huge currents (for example when turning on the spot), however I would be surprised if that's the problem, because the cut-off voltage of the roboclaws is very low (12V), and the problem happens even at low speeds without wheels.
- on the second robot (the new one), the problem appears to be far more frequent : I would say about 3 times per minute on the new, against 0.5 - 1 time per minute for the first one.
- the delay between to cut-off of the wheels is tottaly unpredictable : it ranges (on the new robot) from a few second to 1-2 minutes

Do you have any ideas where it might come from?
Thanks a lot in advance

Best
Felix
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Both roboclaws sudenly stop

Post by Basicmicro Support »

All of them stopping at the same time seems to be pointing to an E-Stop problem. Disable the E-Stop inputs on all the Roboclaws and see if the problem goes away. If it does you have narrowed down the cause. If it doesn't, then the next step would be to look at your coding on the Jetson.

You will need to narrow this down to something more reasonable before I can be of much more help.
felix
Posts: 19
Joined: Thu Dec 03, 2020 8:08 am
Re: Both roboclaws sudenly stop

Post by felix »

Hi,

Thanks a lot!

So finally it happend to be a combination of problems :
- I had a serial timeout of 0.5s on the roboclaws (I can't really increase that for security reasons)
- the CPU was somewhat overloaded
- the ROS node doing the communication with the roboclaw sometimes executed the message callbacks but not the main thread (doing the roboclaw communication). It seems it gives higher priority to the callbacks than to the main thread.


Increasing the serial timeout to 1.5s solves the problem, but is too dangerous (we can't have a robot with >100kg when loaded moving without any control for 1.5 seconds at full speed (>1m/s))

Reducing the CPU load helps a lot, but so far it hasn't solved the problem completely.


Do you have by any chance a C or C++ implementation of the roboclaw communication (adapted for computers running linux/ubuntu)? It would make things much easier to integrate "properly" with ROS (the C++ version of ROS allows precise control of when the message callbacks are handled, while the Python version hides this aspect and just execute callbacks in a separate thread (that seems to have higher priority than the main one)).

Another thing that would be useful to mitigate things, would be if in case of serial timeout the robot could stop with a specified deceleration instead of instantaneously (which might lead the robot to fall over if on a negative slope).

Thanks a lot in advance
Best regards
Felix
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Both roboclaws sudenly stop

Post by Basicmicro Support »

We don't have a specific linux implementation in C/C++ mainly because there is no standard serial port class(python has pyserial atleast). However I usually recommend to people to use the arduino C++ implementation. The arduino library was written so the only arduino specific dependency was the serial port class.

You can create a wrapper around your own serial port class and use the arduino library without modification. See the hardwareserial.h for the arduino serial port class here: https://github.com/arduino/ArduinoCore- ... reSerial.h

Or you could modify our arduino library and replace any calls to the arduino serial port with your own specific libraries calls. There are only a few places that would need to be modified.
felix
Posts: 19
Joined: Thu Dec 03, 2020 8:08 am
Re: Both roboclaws sudenly stop

Post by felix »

Hi,

I reduced the python ros node to the strict minimum (just a main loop checking if the node is not asked to shut down, and a delay to keep a 10Hz rate), and I still had issues (the program got stuck for quite exactly 1 second each time).
So I suppose there must be somewhere a mutex or an I/O command with a timeout of 1s (either in the roboclaw library, the pyserial library or in the linux intself (maybe Jetson specific).

So in the end, I renounced to dig in even deeper and switched to a 3rd party C library for linux, which has quite limited functionalities (but contains the few I need) : it completely solved the problem.

Still, I think it might be interesting for you to add C or C++ support, because they are quite popular languages in robotics. If my predecessor (who used more python) hadn't decided to by the roboclaws, I think I wouldn't have tried them given the lack of C++ support. If it is indeed rather simple to add C++ support, then I think it would be well spent time.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Both roboclaws sudenly stop

Post by Basicmicro Support »

Roboclaw has a 10ms timeout on replies and retries is set to 3 times by default. There is no location in the Roboclaw library that would delay for as long as 1 second. That actually sounds like something someone would add to try debugging a problem.

Post Reply