BasicMicro

I'm trying to do dead reckoning on a differential drive robot using encoders, and I get a little bit of slip because the RoboClaw takes a while to read one encoder, and then the other. In my capture below, you will see that it takes 3.05 milliseconds just to respond to the command to read; the interval between reading one and reading the other is over 5 milliseconds (even though I'm running at the highest baud rate and am turning around to read the next very quickly.)

If there were a command to read both encoder positions at the same time, that would be a lot more accurate. Is there such a command that I'm missing in the docs?



Channel 1, RoboClaw Cmd, is sending the command. Channel 2, RoboClaw Rsp, is the RoboClaw responding. The timing between the two green markers is shown in the "T2 - T1" calculation in the upper-right of the Logic window.

This is using a RoboClaw 2x30A, serial control at 38400 bps.

There is not currently a command to read both encoders at once. Ill see if I can add one in the next firmware release.

With the current system it takes 2 * (1ms + (10*6/38400) = 5.125ms to read both encoders. With a command that could read both at once it would take 1ms + (10 * 10bytes *1/38400) = 3.6ms. So faster but not massively so.

Note the 1ms delay added is on purpose so slower processors without hardware uarts can get ready to read the data.

Its also possible you could use the distance commands(or position commands) to handle the motion inside the Roboclaw, however the PID routines are updated 300 times a second. So you are still at an average delay of 1.66ms(eg any command will start from 0ms to 3.33ms before the next PID cycle).

Post some more info about your project and I may be able to help you out or make other suggestions.

So faster but not massively so.

Thanks!

I'm not so worried about the total time it takes to read the command, as I am about the skew between read samples, because if the wheels run at the same speed, but are sampled at different times, I will get skew between the wheel encoders, which my sensor fusion will translate into a slight rotation of the chassis.

The reading is actually asynchronous in the higher-level code that does sensor fusion, short-term planning, and tells the RoboClaw what to do. That update loop is actually multiple overlapping loops running at frequencies between 1000 Hz (IMU integration,) 100 Hz (the roboclaw poll and control loop,) 30 Hz (vision detection) and 10 Hz (GPS and magnetometer.) This is for a navigating/pathfinding rover robot.

As long as I can avoid the skew, that'd be great!

OK. i got it now. I will see if I can add a new command that will let you read both values at once.

That would be super. Thanks for looking into it!

has this new command been added and if so what is the command # and usage?

also you mentioned one can use the distances commands instead - which commands are you referring too?

thanks,
Jack

Its hasn't yet but Ill see if we can fit it in. The manual is being updated and we are finishing updates to all teh libraries and examples. Im current working on a java library and possibly a LabView driver as well. Im expecting the new release with manuals and updated libraries/examples to be done in the next day or two.

I see command 78 (GET ENCODERS) in the sample code, but it's not in the documentation I just downloaded.
I assume that it simply returns the M1 and M2 raw encoder values? If so, that's perfect

Correct. It returns two long values(8 bytes plus the CRC16).

I have a 2x15A roboclaw running 4.1.6. It does not respond to command 78.
Is 4.1.6 the newest version? Any hints?