cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple VL53L1X sensors and FOV interfernce

CBila.1
Associate II

Hi, I am working on a project which multiple VL53L1X sensors will be placed on multiple robots and they will work in the same arena. As a result, FOV of different VL53L1X sensors will intersect and I am curious whether or not behaviour under these circumstances is observed before. In my tests random errors occur and I could not find a distinctive feature for this interference in order to filter those readings. Do you have any suggestions about this issue ?

3 REPLIES 3
John E KVAM
ST Employee

if you use the longer TimingBudgets, the sensors don't interfere, but if you go really fast then they might.

But I have a different thought about your errors.

Each range consists of two ranges with different timings. This eliminates something called "radar aliasing" - or "wrap around".

If the range given from both sub-ranges are the same, you get a status 0. But if you get different ranges, you will see an 'error'. This error is really a warning - wrap-around. If you know the different ranges were due to the robot's motion, then you can discount the error and use the range. In this case, both the sub-ranges were valid when the data was collected.


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

First of all thank you for answer it is really helpful.

"​if you use the longer TimingBudgets, the sensors don't interfere, but if you go really fast then they might. "

Actually I think it is better for me to sensors interfere and catch that specific error since by doing so I can identify that object as a kin robot.

Then, I can give a timing offset between measurements of different robots and also get the distance (without inteference between sensor readings) to that kin robot and that would be great.

So, I did listen to you and decreased the timing budget, now range status became wrap around.

But from time to time I also get out of bounds range status as well.

If I can be sure that these errors are generated "only" when a kin robot is seen and not in other circumstances I think it would be possible for me to mark the detected object as a kin robot.

Now the question in my mind what should be the minimum time (can it be smaller than timing budget ?) offset between two robots in order to not get a wrap around or out of bounds error and get the distance to the kin robot as well.

John E KVAM
ST Employee

In order to detect a problem called "radar aliasing" we actually do two different mini-ranges for each range. If the ranges agree, fine. But if they disagree, we declare a 'wrap around' error. But the error can also be caused by fast motion. The answer disagree because they were actually different. If you know your robot was moving accept the range even if it has a 'wrap' error. You know what cause the error and you are free to believe the answer.

  • john

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'