For VL53L5CX: what does "ResultsData->distance_mm[ZoneNum]" exactly mean?

[DWang.7]

For VL53L5CX: what does "ResultsData->distance_mm[ZoneNum]" exactly mean? Is it the distance of the object in the zone from the sensor in a straight line or is it the distance of the vertical plane in which the object is located from the sensor, when I place the sensor directly against a wall, the distance shown is greater in the middle zone and less in the surrounding zones? How to convert the straight line distance from the sensor to the object in the zone?

[DWang.7]

Another question is how the 64 measurement zones are distributed, are they distributed by angle?

[John E KVAM]

We tried to make it very easy for you. If you point the sensor at a wall exactly perpendicular and at 1 meter, all the zones will report that 1 meter. Doing the radial to perpendicular conversion is done on the chip.

In the 64 zone configuration, you will get an 8x8 grid, with each zone comprising a touch over 5 degrees of area in both directions.

[DWang.7]

Thanks for the reply! This means the 64 zones are distributed by angle, the shape of each zone is not a square as shown on the datasheet but a circle, a projection of a cone. The area of each zone is not exactly the same, right? Because for me, I try to transform the distance in each zone to a xyz coordinates. The Z value is correct (Distance between orgin and zone plane), but I always got too big x and y value. I used the same transform matrix which you have posted in one reply. Thanks.

[John E KVAM]

I sure goofed that explanation up.

I think you are giving us way too much credit. The light goes out in a flash - here is a diffractive element that projects a pyramid of light. If you could see it, you would see a square of light on a perpendicular wall. When the photons return, they go through a lens so we can determine the approximate direction from which they came.

The photons hit our SPAD array (Single Photon Avalanche Diode) and are binned into 64 different histograms. One could imagine 64 smaller SPAD arrays, with one for each zone.

From these 64 histograms, 64 distances are calculated.

We then translate that 'radial' measure to a perpendicular one. So that if you are looking at a perpendicular wall, all the distances should be the same (considering tolerances.)

Consider the following code:

#include <stdio.h>
#include "vl53l5cx_plugin_plane_algo.h"
#include "math.h"
 
 
const double VL53L5_Zone_Pitch8x8[64] = {
62.85,	66.50,	69.40,	71.08,	71.08,	69.40,	66.50,	62.85,
66.50,	70.81,	75.05,	77.50,	77.50,	75.05,	70.81,	66.50,
69.40,	75.05,	78.15,	81.76,	81.76,	78.15,	75.05,	69.40,
71.08,	77.50,	81.76,	86.00,	86.00,	81.76,	77.50,	71.08,
71.08,	77.50,	81.76,	86.00,	86.00,	81.76,	77.50,	71.08,
69.40,	75.05,	78.15,	81.76,	81.76,	78.15,	75.05,	69.40,
66.50,	70.81,	75.05,	77.50,	77.50,	75.05,	70.81,	66.50,
62.85,	66.50,	69.40,	71.08,	71.08,	69.40,	66.50,	62.85
};
 
 
const double VL53L5_Zone_Yaw8x8[64] = {
135.00, 125.40, 113.20, 98.13,  81.87, 66.80, 54.60, 45.00,
144.60, 135.00, 120.96, 101.31, 78.69, 59.04, 45.00, 35.40,
156.80, 149.04, 135.00, 108.45, 71.55, 45.00, 30.96, 23.20,
171.87, 168.69, 161.55, 135.00, 45.00, 18.45, 11.31,  8.13,
188.13, 191.31, 198.45, 225.00, 315.00, 341.55, 348.69, 351.87,
203.20, 210.96, 225.00, 251.55, 288.45, 315.00, 329.04, 336.80,
203.20, 225.00, 239.04, 258.69, 281.31, 300.96, 315.00, 324.60,
225.00, 234.60, 246.80, 261.87, 278.13, 293.20, 305.40, 315.00
};
 
double SinOfPitch[64], CosOfPitch[64], SinOfYaw[64], CosOfYaw[64];
 
uint8_t ComputeSinCosTables(void)
{
	uint8_t ZoneNum;
	for (ZoneNum = 0; ZoneNum < 64; ZoneNum++)
	{
		SinOfPitch[ZoneNum] = sin((VL53L5_Zone_Pitch8x8[ZoneNum])*Pi/180);
		CosOfPitch[ZoneNum] = cos((VL53L5_Zone_Pitch8x8[ZoneNum])*Pi/180);
		SinOfYaw[ZoneNum] = sin(VL53L5_Zone_Yaw8x8[ZoneNum]*Pi/180);
		CosOfYaw[ZoneNum] = cos(VL53L5_Zone_Yaw8x8[ZoneNum]*Pi/180);
	}
 
	return 0;
}
 
uint8_t ConvertDist2XYZCoords8x8(
		VL53L5CX_ResultsData *p_ResultsData,
		XYZ_Coord_t *p_XYZ_ZoneCoordinates)
{
	uint8_t ZoneNum;
	double Hyp;
	for (ZoneNum = 0; ZoneNum < 64; ZoneNum++)
	{
		if ((p_ResultsData->nb_target_detected[ZoneNum] > 0)
				&& (p_ResultsData->distance_mm[ZoneNum] > 0)
				&& ((p_ResultsData->target_status[ZoneNum] == 5)
						|| (p_ResultsData->target_status[ZoneNum] == 6)
						|| (p_ResultsData->target_status[ZoneNum] == 12)
						|| (p_ResultsData->target_status[ZoneNum] == 9)) )
		{
			Hyp = p_ResultsData->distance_mm[ZoneNum]/SinOfPitch[ZoneNum];
			p_XYZ_ZoneCoordinates->Xpos[ZoneNum] =
					CosOfYaw[ZoneNum]*CosOfPitch[ZoneNum]*Hyp;
			p_XYZ_ZoneCoordinates->Ypos[ZoneNum] =
					SinOfYaw[ZoneNum]*CosOfPitch[ZoneNum]*Hyp;
			p_XYZ_ZoneCoordinates->Zpos[ZoneNum] =
					p_ResultsData->distance_mm[ZoneNum];
		}
		else
		{
			p_XYZ_ZoneCoordinates->Xpos[ZoneNum] = 0;
			p_XYZ_ZoneCoordinates->Ypos[ZoneNum] = 0;
			p_XYZ_ZoneCoordinates->Zpos[ZoneNum] = 0;
		}
	}
	return 0;
}

This is the code we use. I'm not absolutely sure I understand it, but give that a try. See if the results it gives works for you.

[DWang.7]

Thanks! It helped me a lot. I just happened to have a very strange problem. When an object(blue plastic box) is 1m in front of the sensor, should only cover 20% of the sensor FOV, which means, about 20% of 64 Zones should indicate this box. But when I tested with the Sensor, about 95% of Zones output the same distance, which is exactly the distance between the box and sensor. Could you please help me to figure it out? Thanks.

[John E KVAM]

It's always a bit tricky knowing how deep to dive.

But let me start by asking you, "Did you check the RangeStatus?" I'm guessing no.

So here is what is happening.

Light from your target is entering our lens and most of it goes through and does what it is supposed to.

But some actually is trapped in the lens, bounces around and pops out in the wrong place.

It's the same effect you see in your glasses sometimes. Call it 'glare' or maybe 'blur".

Generally this tiny bit of light is not an issue, but our photon detectors are REALLY sensitive.

So we dutifully report it.

But the signal is so tiny, and at the same distance as a nice, bright object, that we can pretty safely declare it as Status 12 .

So if you are trying to get every last photon, you can except a status 12 as a real target, but if you are trying to find the edge of an object, reject the ranges with status 12. Only accept status 5, 6 or 9 as valid.

There is a section in the user manual - 4.4 Results interpretation. That should help.

And we cleverly hide the user manual in the:

STSW-IMG023 Ultra Lite Driver (ULD) for VL53L5CX multi-zone sensor.

(And you should ALWAY check the RangeStatus. The sensor has a habit of leaving junk return values in the output and only updating the RangeStatus.)

If you are using the GUI, there should be a button to only report the Valid statuses.

• john

• john

[DWang.7]

thank you very much and have a nice weekend.

[PGibs.1]

@John E KVAM​  Is there an error in the Yaw LUT with a repeated angle "203.20" in the first column?

const double VL53L5_Zone_Yaw8x8[64] = {
 --- omitted 5 rows ---
203.20, 210.96, 225.00, 251.55, 288.45, 315.00, 329.04, 336.80,
203.20, 225.00, 239.04, 258.69, 281.31, 300.96, 315.00, 324.60,
225.00, 234.60, 246.80, 261.87, 278.13, 293.20, 305.40, 315.00
};

Based on the symmetry, I believe that should be 225-(324.6-315) = 215.40, like this:

const double VL53L5_Zone_Yaw8x8[64] = {
 --- omitted 5 rows ---
203.20, 210.96, 225.00, 251.55, 288.45, 315.00, 329.04, 336.80,
215.40, 225.00, 239.04, 258.69, 281.31, 300.96, 315.00, 324.60,
225.00, 234.60, 246.80, 261.87, 278.13, 293.20, 305.40, 315.00
};