cancel
Showing results for 
Search instead for 
Did you mean: 

How to implement the VL53L3CX on a Raspberry PI3

AGree.4
Associate

My goal is to implement the VL53L3CX TOF sensor on a Quanser Qdrone as a sensor for height control.

As an inbetween I am trying to get the VL53L3CX working with my Raspberry PI3 first to better understand how the sensor and API work. So far I have not been able to find any premade PI3 libraries for communicating with the VL53L3CX. I believe this means that I have to use either the en.VL53L3CX_LinuxDriver_v1.0.5 or the EN.EN.bare_driver_VL53L3CX_v1.2.4.

I have the sensor wired to the raspberry pi and using i2cdetect -y 1 I can see the sensor at address 0x29. From what I have read on other threads, the sensor does not send a stream of distance but instead sends a histogram of distance that needs to be decoded by the API/driver. This means that I will have to implement one of the drivers, right?

What is the difference between the two drivers? Is there an advantage to one over the other or are they roughly equivalent?

I am very new to Linux and am not sure how to install the drivers. Could you help me or provide me with documentation on how to install and use either of the drivers?

Thanks,

Anthony

7 REPLIES 7
John E KVAM
ST Employee

The linux driver - dispite it's name - is NOT a very good way for you to implement the sensor. That is a kernel driver and unless you have a lot of experience I'd stay away from it. It's main use is if you don't want to give access to the I2C bus to user-level code. (This makes sense in a cell phone, but not for a normal developer.)

In your RPi, you can feel free to write directly to the I2C bus - it works fine.

Take the STSW-IMG015

VL53L3CX API (Application Programming Interface)

This is almost everything you need. It even has example code.

But what it does NOT have is an interface between the sensor's code and the I2C.

This code was not written for any particular processor, so they left this interface empty.

There is a platform.c file that contains the functions you need - but it's empty.

You have to populate it.

Couple of ways to do this.

You can take the file I wrote for the VL53L1 and modifiy it. (It's included below.)

Or you can search GitHub for RPi and VL53L3 - I'll bet someone else has done it for you.

You might actually start with GitHub and see if there is already an example.

I'm betting there is one. If there is, it would be a good place to start.


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
mongezik19
Associate II

Hi Agree.4, I know this is an old thread but did you find a solution to this problem. I'm also looking to use the VL53L3CX on a Raspberry Pi. I've been struggling with setting it up with the correct driver. 

If you are new to Linux, use the Take the STSW-IMG015

It's using the I2C driver to talk to the sensor. 

The other driver is a bit of Kernel code. This writes to the sensor by making call to the Kernel which validates that you are only accessing the VL53, and then it's the OS that communicates with the sensor. The user never has access to the hardware itself. We wrote this code for platforms (like cellphones) that allow users to download programs. Imagine if a Cellphone app could get hold of the hardware directly? Not very secure. 

But as a beginner - or someone who does not want the hassle of writing Kernel the STSW-IMG015 is what you want. 


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
mongezik19
Associate II

Thanks for the reply sir. I did try to compile the bare driver using the platform.c file and I'm getting some errors about missing header files, namely the ranging_sensor_comms.h, and ranging_sensor_comms.h. 

The way we deliver software is that we include everything you need up to the point where you start writing to the hardware. That hardware access is in platform.c and platform.h. 

Those two files we leave up to you as we do not know which processor (or OS) you are using. 

Using that you can re-write the platform.(ch) so it works for any processor.

But I think you did something wrong. There is an example directory in that code. 

C:\..\STSW-IMG015\VL53L3CX_BareDriver_1.2.10\CubeIDE_Example\Src\

Go there, take the whole thing, and try to build it. 

In the example code there is a driver written for linux. We tested it on an RPi - so it should be close.

- john


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.

Thanks again sir. I managed to compile the driver, but now not sure how to use it. Forgive me for asking what may seem straightforward but i've never used STM32CubeIDE I'm just used to just installing existing python dependencies for modules on the RPi. In any case, please see image below of the project structure after compilation of that example project. Thanks.Screenshot 2024-09-05 at 05.57.31.png

This will be the blind leading the blind. I'm really experienced with CubeIDE, but not on a RPi. 

Let's back up a bit. The STM32CubeIDE is based on the Linux Eclipse IDE. We pre-loaded it to talk to the STM32 debug processor on our boards. 

But if you have the Eclipse IDE running on your RPi, I see no reason it should not work. 

What happens when you hit the green '>' icon? 

It's just to the right of the 'debug' icon that looks like a bug. 

It's a good IDE, but it's written in python, so it's not really fast. But you don't need fast. 

Hit the debug, the screen will change to a debug view. You get a 'skip-over' icon, that will run the next line and skip one down. The 'jump Into' will enter a function. With only these two, you can follow the code. 

Dwell over the status return and look for anything non-zero. 

See how far you get. 

The output in my system goes to a serial port, so I'm expecting your will too. You just have to figure out where that serial port writes too. 

Have fun. 

- john


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.