Slow Communication Speed

Questions about using encoders with the Roboclaw product line
kp_ctr
Posts: 2
Joined: Thu Jul 26, 2018 7:51 am

Slow Communication Speed

Postby kp_ctr » Thu Jul 26, 2018 7:54 am

I have 7 roboclaw 2x15a amplifiers. I plan to control a robot with 14 motors in real time. I am having trouble with communication speed.

I have boiled the system down to it’s simplest example, communicating with one roboclaw in order to debug communication speed.

I have the roboclaw connected to the computer using packetserial mode and a USB cable, and am sending one writeVelocities command and one readEncoders command. The fastest I can get this loop to run is 2ms. Is it possible to get it to run faster? I need it to run on the order of <0.5ms to control all the motors. I am programming in visual studio c++. I have also confirmed these speeds using the python examples on a linux computer.


for (int i=0; i<numIterations; ++i ) {
for (int j=0; j<numMotors; j++){
ROBOCLAW.SpeedM1M2(0x80, 0,0 );
uint32_t enc1, enc2;
ROBOCLAW.ReadEncoders(0x80, enc1, enc2);
}
}

I cannot determine if the slow communication speed is my implementation or a limitation of the device. What is the expected communication frequency for this device? The documentation talks about communication speed of about 1mb/s over USB.

TL/DR: How do I get communication running at the 1 mb/s noted in the documentation in order to get real-time control working?

Thanks!

User avatar
Basicmicro Support
Posts: 1003
Joined: Thu Feb 26, 2015 9:45 pm

Re: Slow Communication Speed

Postby Basicmicro Support » Thu Jul 26, 2018 9:53 am

There is enough overhead and delays between send/receive that your average communications rate will be around 200kb/s over usb. A single packet(USB packet) will get 1mb/s(or more) but there is an inherant 1ms delay between send and receive over USB(eg the minimum latency is 1ms). So 2ms is about what I would expect for the loop period of your example(two commands, two acks, two send/receive transitions so 2 * 1ms latency).

However that will be the case for each USB connected roboclaw(eg adding a roboclaw wont slow down the system itself). You would need to run each Roboclaw in its own thread though so you are not blocking waiting for an ack from one Roboclaw, delaying talking with another Roboclaw.

What is your application that you need more than a 500hz update rate?

Note that other than Current/Voltage limiting the Roboclaw updates its command buffer 300 times a second so sending commands faster than that will not execute them faster. Some will simply be overwritten before they execute if you send more than one command to a motor in that 1/300s window.

Also sending commands even at the command buffer rate will have almost no effect on the motor. Motors are slow to respond. A motor has an electrical time constant which indicates how quickly current will change in the motor widings. This is usually in the 10s to 100s of milliseconds range(3* motor inductance/motor resistance is the time it takes current to rise to 63.2% in the motor windings from a dead stall, it is slow when backemf is taken into account). The mechanical time constant(how quickly the motor can reach 63.2% of its rated speed under no-load) which indicates how quickly the motor will responde to the electrical changes is usually many times longer(this is dicated by inertia of the motor spindle.

Some modern high performance servo controllers may reach as high as 1khz(or possibly higher). Our MCP line runs its control loop at 625hz. But in general unless you have a very special motor(eg a low inertia servo motor) going that high has no advantage if the motor just filters it out.

kp_ctr
Posts: 2
Joined: Thu Jul 26, 2018 7:51 am

Re: Slow Communication Speed

Postby kp_ctr » Thu Jul 26, 2018 10:59 am

Thanks for this detailed and very helpful reply.

I noticed this morning while clocking the individual functions that a 1ms delay appears when switching from a writing to reading command. (FYI for the next reader, I have 1.5 ms for the SpeedM1M2 function, 0.3 ms for the ReadEncodersM1M2 function, and 2.9 ms when I run one after the other in the same loop).

My application is robotics research on a 14 DOF manipulator. I do not in fact need 500 Hz update, ~250 should be fine.

Great insight on the motor time constants. It had not occurred to me that I would be entering a refresh rate that was smaller than the time constant. This reaffirms that there is no need for the 500 Hz update rate.

I will go implement multiple roboclaws on separate threads to verify your suggestion.

Thanks again!

User avatar
Basicmicro Support
Posts: 1003
Joined: Thu Feb 26, 2015 9:45 pm

Re: Slow Communication Speed

Postby Basicmicro Support » Fri Jul 27, 2018 9:42 am

Yes, that is the 1ms latency. USB is a polling interface so the PC has to ask the device for new data(when it wants to read data). Standard USB polls at 1ms(or longer) rates(we set the latency to 1ms which is the minimum allowed).

If you use our libraries(arduino or python or C#) evey command has an acknowledgement or a read back value so every command will have the 1ms latency added to it plus its own inherant latency.

Sending multiple command packets without reading the ack immediately and only reading the ack bytes after sending all the commands you want to process should speed things up some. This complicates error handling but would elliminate 1 or more of the latency delays inherant to virtual comports over USB. Obviously this would require writing your own packets since our libraries are all setup to wait for acknowledgment or return data but in extreme cases this would be my recommendation.


Return to “Velocity and Position Control”

Who is online

Users browsing this forum: No registered users and 1 guest

cron