2021-07-16 06:33 PM
Hi ST team and community !
I'm here because i have some troubles on the VL53L1X.
I use the following library available on GitHub : openmv/vl53l1x.py at master · openmv/openmv · GitHub.
I deployed several VL53L1Xs around the mobile robot, hoping to get the distance information of other robots with the help of vision. However, in practical tests, it is found that when VL53L1X on one robot is used to obtain the distance of another robot, The VL53L1X on the other robot will produce very large interference to the measured value. The following is my experimental data, the abscissa is the number of measurements, the ordinate is the distance .It can be seen from the figure that the interference between the sensors is very large, and the measured data cannot be used at all. After subsequent experiments, it is found that when using the drive library, the sensor has been working, that is, the launch tube has been emitting laser light, which affects the measurement of other sensors. Therefore, I hope to control the start and stop of the sensor through software and increase its ranging time interval, but on the OpenMV platform I can only manipulate the registers to control the sensor, and the description and operation methods of the registers are not given in the data sheet. .
Finally, I want to know if there are other ways to avoid the interference between the two sensors, or how to control the working transition of the sensors by operating the registers, so that they can work staggered.
2021-07-19 07:34 AM
Doesn't look like your plot got attached.
In our experiments we were rather supprised to see that the sensors (In autonoumous mode - like th VL53L1X) do not interfere with each other very much.
But someone on this forum, said they DID interfere, in that he got A BAD range one out of 5 or 10 ranges when he had the sensors face each other at a distance of about 5cm.
We fully expected to see a lot of interference, but apparently the PLL on each sensor is just enough different that each sensor sees the other sensor as ambient light.
But the sensor can only handle so much ambient light - that's why it doesn't work very well in bright sunlight.
We suspect that when the sensors get too close, and point directly at each other, it's the ambient.
Could you check the amount of ambient you are seeing when you get the bad readings.
And if you could add a graphic showing the relitive positions of the sensors when you are getting your bad data, I might be able to shead more light on the subject. (Sorry, it's a bit of 'light' humor.)