How to compensate for asymmetric sensor array response?

[FPayn.1]

I have an array of three VL53L0X sensors, mounted at -20, 0 and +20 degrees with respect to each other. The idea is to use the differential between the distances measured by the three sensors to determine the orientation of my autonomous wall-following robot with respect to a nearby wall. I compute a 'steering value' by dividing the difference between the two outside sensor measurements by the center sensor measurement, i.e. (R-L)/C. This value should be zero when the array is oriented parallel to the target wall.

I have performed a number of automated and manual rotary scans with this array offset about 20 cm from a target 'wall', and I have noticed a consistent asymmetry in the array measurements, as shown in the attached Excel plot. The left sensor measurement data is unusable beyond about -30 deg relative to the parallel orientation, but the right sensor provides good data out to almost +60 deg. In addition, the orientation for which the steering value goes through zero is skewed to the right about 6-12 degrees from where the array is physically parallel to the target wall. For all the gory details, including a number of scan plots and videos of scan operations, please see my 'Paynters Palace' blog post

The sensors do not have glass coverings, but I have visually verified they are free of any obstructions.

So, how to address these issues? I guess I could compensate for the steering value offset in software, but I'm unsure how well that would work, and that would still not address the asymmetric performance issue. I have not calibrated the sensors because I quite frankly get lost every time I try to work through the API documentation.

Any thoughts or suggestions would be appreciated.

Regards,

Frank

[John E KVAM]

I’m hoping John, the ST Micro guy, can shed some light (pun intended) on this.

(I put this in just to prove I read your blog - very impressive.)

I'll give it a shot.

I'm guessing it's the offset calibration.

You said the procedure in the manual confused you - and I agree it's not well written.

So let me try:

During the re-flow process the geometry of the chip changes ever so slightly. But we are talking picoseconds per mm here, so it doesn't take much to mess it up.

So you can either calibrate it yourself or use the function in the code.

Calibration:

Range at a known distance (14cm is what we use) maybe a few dozen times with a sensor that has been warmed up. I think we waste 50 measurements, then take 50 more.

Average the 50 measurements and compare them to your known distance. This delta is your offset for that sensor.

Now you could apply that offset after every measurement, or you could send that offset to the sensor on boot-up and the sensor will apply that offset for you.

Offset's are good forever, so if you can save them in your MCU somewhere, you can apply them whenever you boot.

To try this out, find the offset for each sensor. Then apply that offset to your already collected spread-sheet data.

Does it fix your issue?

Offsets can be as much as +/- 2cm. So they have an effect.

If you write your own calibration, keep in mind that we tried to do the calibration in the factory, so there is already an offset value in the register. Zero this before you do your own calibration.

• john

[FPayn.1]

John,
Thanks for the suggestion about calibration. I set up my 'wall' target at approximately 200 mm, and rotated my sensor array manually until each sensor was directly facing the wall. Then I carefully measured the exact physical distance and used the difference to compensate the measurements from an earlier -50 to +50 automatic scan. As shown in the plot, the compensation made almost no difference to the result.
[image: 200610 VL53L0X Comp vs unComp -50 to +50.jpg]
Regards,
Frank

[FPayn.1]

Thinking a bit more about this, I don't see how any amount of constant offset applied to the sensors change the shape of the distance vs angle curve, as it would be applied to every point equally. I suppose it might move the y-intercept point of the steering curve horizontally one way or the other, but not the overall curve shape.

Just my $0.02 😉

Frank