Following the instructions I get …
pi@Test-pi:~ $ sudo pip install vl53l1x
Collecting vl53l1x
Could not find a version that satisfies the requirement vl53l1x (from versions: )
No matching distribution found for vl53l1x
the pip for smbus2 worked a treat … any ideas ?
Python version is 2.7.13
You should see:
pi@raspberrypi:~ $ sudo pip install vl53l1x
Collecting vl53l1x
Downloading https://files.pythonhosted.org/packages/5f/7b/c4ff0368c866a94e92225dce025a2ab4d0d3a6d426ac3c6e7592c129afd2/VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl (128kB)
100% |████████████████████████████████| 133kB 1.2MB/s
Installing collected packages: vl53l1x
Successfully installed vl53l1x-0.0.2
Probably some pip/networking error, I wouldn’t be surprised. If all else fails you can grab the .whl from https://files.pythonhosted.org/packages/5f/7b/c4ff0368c866a94e92225dce025a2ab4d0d3a6d426ac3c6e7592c129afd2/VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl and install it manually with:
sudo pip install VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl
the download worked ok …
pi@Test-pi:~ $ ls Downloads/
VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl
but …
pi@Test-pi:~/Downloads $ sudo pip install VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl
VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl is not a supported wheel on this platform.
tried with -v option …
pi@Test-pi:~/Downloads $ sudo pip -v install VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl
Converted retries value: Retry(total=5, connect=None, read=None, redirect=None) -> Retry(total=Retry(total=5, connect=None, read=None, redirect=None), connect=None, read=None, redirect=None)
Converted retries value: Retry(total=5, connect=None, read=None, redirect=None) -> Retry(total=Retry(total=5, connect=None, read=None, redirect=None), connect=None, read=None, redirect=None)
VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl is not a supported wheel on this platform.
Exception information:
Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/pip/basecommand.py”, line 215, in main
status = self.run(options, args)
File “/usr/lib/python2.7/dist-packages/pip/commands/install.py”, line 330, in run
wheel_cache
File “/usr/lib/python2.7/dist-packages/pip/basecommand.py”, line 276, in populate_requirement_set
wheel_cache=wheel_cache
File “/usr/lib/python2.7/dist-packages/pip/req/req_set.py”, line 245, in add_requirement
wheel.filename
InstallationError: VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl is not a supported wheel on this platform.
p.s. I’m on a pi Zero
D’oh classic Pi Zero/Python wheel architecture problems- try renaming “armv7l” to “armhf”. I’ll have to figure out how to build wheels that default to “armhf” so the Pi Zero isn’t excluded. Even though they are built on an armv7l platform, they’re still armhf.
Still not there I’m afraid …
pi@Test-pi:~/Downloads $ mv VL53L1X-0.0.2-cp27-cp27mu-linux_armv7l.whl VL53L1X-0.0.2-cp27-cp27mu-linux_armhf.whl
sudo pip -v install VL53L1X-0.0.2-cp27-cp27mu-linux_armhf.whl
Converted retries value: Retry(total=5, connect=None, read=None, redirect=None) -> Retry(total=Retry(total=5, connect=None, read=None, redirect=None), connect=None, read=None, redirect=None)
Converted retries value: Retry(total=5, connect=None, read=None, redirect=None) -> Retry(total=Retry(total=5, connect=None, read=None, redirect=None), connect=None, read=None, redirect=None)
VL53L1X-0.0.2-cp27-cp27mu-linux_armhf.whl is not a supported wheel on this platform.
Exception information:
Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/pip/basecommand.py”, line 215, in main
status = self.run(options, args)
File “/usr/lib/python2.7/dist-packages/pip/commands/install.py”, line 330, in run
wheel_cache
File “/usr/lib/python2.7/dist-packages/pip/basecommand.py”, line 276, in populate_requirement_set
wheel_cache=wheel_cache
File “/usr/lib/python2.7/dist-packages/pip/req/req_set.py”, line 245, in add_requirement
wheel.filename
InstallationError: VL53L1X-0.0.2-cp27-cp27mu-linux_armhf.whl is not a supported wheel on this platform.
I had the same problem with a pizero. I solved it by preparing the card on a Pi3 and then used that card with no problems in the pizero. Of course iyou need to have a Pi3 as well …
On my original question I found the solution was to use pip3 to install the library using
sudo pip3 instrall vl53l1x
Then navigate to the folder /usr/local/lib/python3.5/dist-packages and create an alias to the file vl53l1x_python.cpython-35m-arm-linux-gnueabihf.so naming it vl53l1x_python.so
The entire procedure is
sudo pip3 install vl53l1x
cd /usr/local/lib/python3.5/dist-packages
sudo ln -s vl53l1x_python.cpython-35m-arm-linux-gnueabihf.so vl53l_python.so
you also need:
sudo pip3 install smbus2
You can then successfully use the sensor with python3
you can try python3 graph.py
of course it would be nice to have the package fixed so that this hack becomes unnecessary.
Thanks for that rbnman, unfortunately no Pi3 available at present ( they’re all built in to devices running 24/7 ( web server etc ) :-(
As of version 0.0.2 the sudo ln -s stage should be unnecessary as I’ve made the library smarter about finding its own .so file.
My bad, it should be “armv6l” (I’ve just fired up a zero to compile and upload it) not “armhf”.
I’ve uploaded a Python27 and Python34 build so far, working on 35. I’m pretty sure these are identical to the armv7l- I seem to remember the standard procedure was to just rename the arch part and upload them.
Edit: ^ TLDR: sudo pip install vl53l1x should just work for Python2 on a Zero now.
I installed v 0.0.2 and it installs ok now with pip3. However, I’m not sure if anyting else has changed, becuase I now get a jitter in the output.
previously if I held my hand in front of the sensor and got a low reading and then quickly removed my hand it reverted to 800 (I was using the graph example without the graph drawing but with the clamp at 800 still in place.
Now if I remove my hand when it was giving a reading of say 5 then it reverts to 800, but seems to remember the 5 reading and put in random outputs of 5 mixed in with the 800s
I have two micro sd cards and the same hardware in each case. One card has 0.0.1 the other 0.0.2 installed.
In fact I’m sending the readings via OSC to Sonic Pi, but stripping out this code incase it affects things still gives this jitter result in 0.0.2
I doubt the jitter was introduced in 0.0.2- but stranger things have happened! None of the underlying code changed, just the mechanism in Python to locate the right file.
That said, I can’t think of any reason off the top of my head why you would see this effect- but there are definitely plenty of potential reasons. My best bet would be environmental though- if your ambient light level has changed since you last tested it.
That now works a treat
Thanks
I now worked on just one SD card.
I uninstalled version 0.0.2 and then used sudo pip3 install vl53l1x==0.0.1
I had of course to add the ln -s again. It worked fine with no jigtter.
I uninstalled version 0.0.1 and reinstall version 0.0.2 Nothing else changed but the jitter is back again. It swaps between 800 and the previous recorded low reading, not so much with a jitter but regularly. When I revert back it is OK, so there is definitely some interaction.
SE EDIT BELOW
(However, I modified my script so that it didn’t flush the stdout buffer each time and print the value on one line, replacing it with a standard print command and then it behaved as expected, listing the values one beneath the other. It is odd, as I don;t see why the actual value of distance_in_mm should be affected, (which is sent via OSC to sonic pi), but it certainly was being.
So I’ll leave this as a quirk, as I am happy I can live with it.)
EDIT no its back again. I’ll just use version 0.0.1 for my project. That does what I want.
Welp, colour me baffled! I’ll have to try and set up a test between the two versions when I get some time. No doubt I’ll find it impossible to replicate, as is typical of these quirks!