I am having problems getting correct readings from the PiicoDev VL53L1X Distance Sensor. I would like to ignore the values that the sensor returns when it is out of range.
I am using it with the Raspberry Pi Pico and MicroPython.
I have looked at the PiicoDev libary for the sensor and this document and it seems as though the PiicoDev library supports thresholds and detection modes. As far as I can work out, using these functions would allow me to only get values when it is within accurate range (4m).
Any help as to how I would enable the thresholds and detection modes would be greatly appreciated.
Hi @Jaden130809 - the PiicoDev VL53L1X module only supports basic ranging functions (for now ). The linked document is for the VL53L1X C/C++ API which has a lot more functionality that we haven’t ported to MicroPython.
If you’re up for a bit of reverse engineering, I believe this is the official page where you can download the C/C++ libraries for the VL53L1X. And here’s Pololu’s version for Arduino. If you do end up porting any functionality to MicroPython, consider creating a pull request on the repo!
For now, if you’re just after a quick fix, does it make sense to just ignore values that fall outside a given range?
eg.
Thanks for your response. I will have a look at those links.
The problem with the code you suggested is once the sensor is out of range it starts returning values that are likely to be within the limits (less than 15 or greater than 3000). Hope this makes sense.
I actually tried to modify the VL53L1X module by uncommenting the if, elseif, and else statements for the range status and added in return status into each statement.
The results were great. When it was in range it returned OK and when it was out of range it returned SignalFail.
Will keep experimenting and try to modify my code. Can’t wait till its completely ported to MicroPython.
You’re right @Jaden130809, the functionality is in there. I must have had a brainfart. Glad you dug into the module
Maybe it makes sense to set the status as a property of the class, and access that with a ‘getter’ function. So code to check validation might look like:
d = sensor.read()
if sensor.rangeIsValid() == True:
# do something with the range
else:
print('Data is out of range')
In any case, I’ll open an issue on our repo and earmark it to work on - this functionality is too useful to ignore. Thanks
Hey @Stephen202603, I’ve just pushed an (experimental) updated that exposes the .status attribute.
Available by downloading PiicoDev_VL53L1X.py (right-click, save-as).
It appears to work well for ranges beyond the max-range. Minimum range still gets reported as OK through. You can include the status in the example script as follows.
from PiicoDev_VL53L1X import PiicoDev_VL53L1X
from time import sleep
distSensor = PiicoDev_VL53L1X()
while True:
dist = distSensor.read() # read the distance in millimetres
print(str(dist) + " mm " + distSensor.status) # convert the number to a string and print
sleep(0.1)
This update hasn’t been made available for Raspberry Pi through the Thonny package manager yet. That’s ok though you can still download the source file into your working directory if you’re working on a Raspberry Pi. It’ll get pushed out as usual on the next package update ie. when we release a new PiicoDev device or make an important patch.
@Jaden130809 hi… I’ve been working on adding in missing functionality to the VL53L1X MicroPython driver recently, with considereable improvement in accuracy/consistency… and only just found this thread.
I would be interested in seeing what you developed… are you still working on it, or at least interested in taking this further?
@Michael Sorry… should have included you in my last post. You said in 2023 you had (I think) uploaded a version that exposed the status… I don’t see it on the link given.
Yes, I see that Jane, but other aspects of what Jaden mentioned (eg threshholds) seemed missing, but on closer reading, maybe he was simply using the status attribute, not detection threshholds at all.
I am working my way through the many methods provided in other drivers… I have many of them now working, but might put this aside for 2-3 days while I return to my main task… reporting on the accuracy/consistency impact of the Timing Budget. And maybe now including the narrower focus/FoV provided by changing the ROI. This might be useful in my project, albeit the device is now working just fine with the default ROI.
Might be useful for other scenarios.. but proper testing of this will mean going off on a tangent rather more than I want to do at this momemt… I might return to it after current priorities are addressed!
Hi @Jane , still no response from @Jaden130809 , maybe he has moved on… whatever.
I have added the ROI functions to my enhanced VL53L1X driver… it does improve performance a little, but by far the biggest win is altering the timing budget. Hugely better results.
I have I think taken this as far as I can, for now. Leraned a few lessons about how to get best results, which really should be included as something in the README.md or whatever… without it, things may not work as well as hoped.
@Michael I’ll look at doing a pull request on the repo as suggested.. I am not very experienced with git PR’s… I use git in VS Code for my own tracking, but have not really engaged in collaborating with other users. I’ll give it a crack and shout if I need help!
Wouldn’t it be easier for others to just grab it from the Core github repo? I am NOT really expert with github… I did the pull request, Core staff (or others ?) should be able to grab my mods from here, I think…possibly after my pull request is reviewed/accepted (?) Best ask someone like @Michael who probably knows github processes better than me It might need some minor tweaks before being release to the public…
I am trying to clean up some things that should not really be exposed… but not making any changes of substance. Just housekeeping stuff.
Cheers, T.
EDIT: if the github thing gets too hard… sure, I can just upload… let me know.
Unfinished business really is writing some documentation about the extra methods… this is kinda important - it’s not obvious from the methods themselves, but in practise I found certain tricks… that make things work as intended. Mostly things like adding sleeps here and ther. Which, I guess could/should actually be hardwired into the methods, to be sure.
When I have some time I might do that… and while I’m at it, perhaps add some extra notes in the README.md. I guess that’s the best way to manage this ???
Adding to the documentation would be a huge time saver for us converting the PR, sharing those examples and verification scripts would be amazing (if they arent already in the GitHub).
No worries if you dont want to update the README, we completely understand if you want to power on with your project!
). The linked document is for the VL53L1X C/C++ API which has a lot more functionality that we haven’t ported to MicroPython.
