Page 1 of 1

How fast can a Roboclaw process commands?

Posted: Tue Mar 12, 2019 3:39 am
by ChrisA
How fast can a Roboclaw process commands in serial packet mode over USB? I'm sure that must be a limit.

Why do I ask? I'm using ROS and the "roboclaw_node" base controller node. This roboclaw_node, on it's own reads both encoders 10 times per seconds and also reads out all the diagnostic data (voltages and temperatures) at 10 Hz. This is about 60 reads per second

Then I add on top of this my own software that causes the cmd_vel_callback() method to be called which then calls "setspeedM1M2 about 20 times per second. So a basics ROS controlled Roboclaw is running at about 80 commands per second continuously for hopefully hours.

Is this reasonable?

Next question is if there is a "best" rate" for updating the velocity PID via the speedM1M2() method? My use case is driving a simple robot mobile base along a curve defined by an arbitrary polynomial. On paper it is more accurate if I chop the path into tiny segments but that means I change the velocity of each wheel 20 times per second. Is that going to work?

Re: How fast can a Roboclaw process commands?

Posted: Tue Mar 12, 2019 1:09 pm
by Basicmicro Support
This is reasonable. See Motion Studio running. It is effectively constantly reading all the status information and allowing motion commands to be sent at all times. The time it takes to send the commands are the majority of the time used. The actual command processing time is in microseconds while communications are in milliseconds. For USB communications you can assume an effective baudrate of around 250khz when calculating time. That will provide a significant amount of margin in your calculations(actualy through put is closer to 500kbs last time I tested it).

I dont know how much the ROS overhead will slow this all down though.

There is no best value for updating the speed of the motor. Obviously you want to update it as often as possible to get the smoothest curves. I would look at potentially using the buffered commands to produce motion curves with speed/distance commands. You can send upto 32 speed with distance command to produce your motion. Then you can go off and do other things while those commands are processed.

Programmatically changing the speed 20 times a second isnt a problem. The problems can arise when the motors are incapable of making those changes. You will need to experiment to determien if your motors mechanical time constant is fast enough for the requested motion. Also if your Velocity PID is not tuned well enough this can cause motion problems as well.

Re: How fast can a Roboclaw process commands?

Posted: Tue Mar 12, 2019 2:17 pm
by ChrisA
Just as an aside, we can't send a long sequence of comands into a robot. The problem is that wheels slip and the wind vlows and the ground is not flat so we must continously measure where the robot is relative to the desired location and correct it. So we use IMU, GPA and cameras to track location with Kalman filters. And then what if a moving obstacle waks in front? we need to adjust the path in real-time s we can never load motiona commands in advance. Updating at 5 Hz to 25 Hz is required.

OK, back on topic...

THe following test program hangs my roboclaw if "sleeptime" is set to small. It will run for hours if the value is larger than 0.01 The failure messages print out very often and then it dies if you make the "sleep time zero".

Yes the windows based motion studio works well. Does it depend on" I'm guessing not.

I would be interested to hear what others find as the minimum working value of "sleeptime"

Code: Select all

#!/usr/bin/env python
import signal
import time
import random
import roboclaw_driver.roboclaw_driver as roboclaw

__author__ = ""

baud_rate = 115200
sleeptime = 0.01    # 100 Hz works well, no issues

dev_name  = "/dev/serial/by-id/usb-03eb_USB_Roboclaw_2x15A-if00"
address = 128

def sigint_handler(signum, frame):
    roboclaw.SpeedM1M2(address, 0, 0)
    print "Exit"

signal.signal(signal.SIGINT, sigint_handler)

def open_robo():
    roboclaw.Open(dev_name, baud_rate)

def read_encoders():
    status1 = status2 = enc1 = enc2 = crc1 = crc2 = 0

    status1, enc1, crc1 = roboclaw.ReadEncM1(address)
    status2, enc2, crc2 = roboclaw.ReadEncM1(address)
    if status1 == 0 or status2 == 2 :
        print ">>>>>  ReadEnc FAILED  <<<<<"
        print "ReadEnc OK"

def write_motor_speeds(speed):
    ret = roboclaw.SpeedM1M2(address, speed, speed)
    if ret == 0 :
        print ">>>>>  SpeedM1M2 FAILED  <<<<<"
        print "SpeedM1M2 OK"

if __name__ == "__main__":
    print "starting test"

    while True:

        for i in range(50):
            speed = random.randrange(200, 800, 25) # force the PID to make a calculation


Re: How fast can a Roboclaw process commands?

Posted: Wed Mar 13, 2019 10:20 am
by Basicmicro Support
I noticed this line: import roboclaw_driver.roboclaw_driver as roboclaw

At a minimum you have renamed the Rooboclaw python library or you may be using something completely custom with similar function names.

Please email with this program and the modified library. I'll look at it to see if something in the modifications is causing your problem.

Re: How fast can a Roboclaw process commands?

Posted: Thu Mar 14, 2019 2:03 am
by ChrisA
It is the normal python driver but I've been placing every every attempt to communicate with the serial port in a try ... except block. Mostly comm failures are ok because the control loop will just cycles and we try again on a few milliseconds. With try-except we don't crash the program, we just log the problem and keep gong.

One thing you might want is the try-except around "open". Now I can start the software and later plug in the Roboclaw

I will use "real serial" and then re-test and then send you what I have. Your explanation of USB serial is making me switch to TTL serial. Thanks

I need to get or make a 3.3 volt to 5 volt level converter as the Raspberry Pi runs on 3.3Volts.

Re: How fast can a Roboclaw process commands?

Posted: Thu Mar 14, 2019 10:05 am
by Basicmicro Support
You should set a 10ms timeout on any serial write, if you are using a try except on any commands. The Roboclaw will timeout and clear any garbage left in the packet receive buffer so you can start a new clean packet. This is how the write commands are already setup in the library though unless you modified them.