Observations on Locator

Finally have all my C++ for the API working so turning to testing how the RVR works.

I laid out a 1 meter distance on a tile floor and tested the accuracy of the locator data. The test was a loop reading the locator Y value streaming at 30 msec. It started with a reset of the locator and stopped when Y > 1.0. The error over a number of tests was generally less than 0.05. I also ran it in reverse from the ending position until Y < 0.0 with similar results.

These tests were done with both raw and heading versions of the API. Note that setting the heading speed to 0 didn’t stop the RVR but allowed it to roll forward a distance. How far depended on the speed. Using a raw drive of (0, 0) caused a full stop.

I set speeds based on percentage (0-100) not the 0-255. I find it easier to think of speed that way.

When speed was less than 15% the locator was way off. The loop stopped when Y > 1.0 but it actually was around 0.75m (eye ball estimate).

An adjustment I need to make is gradual acceleration and deceleration of speed. Going from 0 to 100% or 100% to 0 not only looks bad but slowing at the end should allow more accurate movement.

1 Like

Hope to hear more of your progress. I went straight to implementing my command logic and will be worrying about accuracy afterward.

Generally I would say I see roughly a 5 cm error as well, but I have not made an effort to keep track of it besides doing a few 1 meter tests for you just now. Concur with the use of raw motors 0,0 for full stops. Mines rolling like yours did so I’ll have to make that change too. All that said, looking at Locator data, RVR is accurate its my code that needs work.

I want to add easing / gradual acceleration as well, it just isn’t a priority but I’m glad to see someone else wants it too. Excited to see what you write.

1 Like

I was playing with that the other day and noticed that the unit did run on after setting the speed to 0. Will have to try the stop function and see if that makes a difference.

I was able to get it to stop on the spot using a PI controller to quickly accelerate and then decelerate as it approached the target distance. I just used java script programming.

var Kp = 0.15;
var Ki = 0.0009;
var Kd = 0;

async function pID(position, destination) {
    err = destination - position;
    totalErr = totalErr + err;
    hint = Kp * err + Ki * totalErr + Kd * (err - prevErr);
    prevErr = err;


1 Like

Ah, good find @rmerriam, I’ve recently made some modifications to the locator that theoretically improved accuracy, so I’ll have to conduct some low-speed tests to make sure your observed issue is fixed. It would fit with the bug I found in the code. These locator improvements will be in our next firmware release, probably late Q1.

In my testing, errors of +/-5% are about as good as you can get on hard floors without some kind of external environmental measurement, since the treads make a bumpy interface with the ground as you drive, and the bend radius of the tread directly underneath the wheels is payload dependent. Driving on carpet or other squishy surfaces will cause additional errors, as the treads sink into the surface slightly and reduce the effective wheel radius. RVR has no native way of detecting this, so that’s where something like SLAM or an external beacon system would come in handy for projects that require high precision over long distances.

1 Like