AlecHub
commented
2 years ago Great work Eeshwar!!! The driver knows the sampling frequency of the hardware for any given sampling parameters. Driver should return the cached value when no new sample is available.
The current behaviour of the VL53L0X driver is to wait in a while loop until the RESULT_INTERRUPT_STATUS is non-zero. This can make sense from the user's perspective, always gathering new data, but in practice the 33ms timing budget and the fact that the SYSTEM_INTERRUPT_CLEAR register is written to means that every distance read from the user results in an up to 33ms delay.
I got around this using a cached distance value that is updated whenever new data is available to read from the sensor. We know that new data is available only after the timing budget expires, and we know the timing budget, so we can use a timer to guarantee no pointless reads. If data is available, it reads it, clears the interrupt, then resets the timer, otherwise it just returns the cache.
I tried to minimally change the existing code, just modifying the readRangeContinuousMillimeters() method. The implementation I wrote is here: https://github.com/Eeshwar-Krishnan/Photon-RC/blob/NeutrinoDev/Hardware/src/main/java/com/qualcomm/hardware/stmicroelectronics/VL53L0X.java
As a note: This behaviour is what is seen in the REV Color Distance Sensor V3. Either that paradigm should be changed to block until new data is received, or the paradigm here should be changed to cache. I think the second is preferable personally.
The implementation also has a secondary feature which takes advantage of the VL53L0X's timing budget system. This allows for increasing the timing budget of the sensor in order to increase accuracy, which is something that may be desirable for using the sensor for ranging. I included three presets, HIGH_SPEED (33ms timing budget, the default as far as I can tell), BALANCED (75ms delay), HIGH_ACCURACY (150 ms delay). These three values were experimentally derived based on the standard deviations of the sensor under different timing budgets, although further testing may be needed to refine these values to better ones. This system is secondary and less immediately important to implement, because more testing is probably needed to refine these values instead of the current ones. However, I can confirm that the different timing budgets can have a very large impact on the sensor accuracy, particularly as the sensor gets further away from its target (see the attached chart for the three different modes I currently have).
Exposing the method to set the timing budget to the user, or providing preset timing budget profiles for use by teams may be a useful feature to prevent filtering from the user in order to use the data with higher accuracy at longer ranges.