[WIP]: ST VL53L1X ToF driver

[dagar]

This PR introduces a new driver for the ST VL53L1X long distance ranging Time-of-Flight sensor. https://www.st.com/en/imaging-and-photonics-solutions/vl53l1x.html

What's a little unusual here is that I used ST's VL53L1X API (https://www.st.com/content/st_com/en/products/embedded-software/proximity-sensors-software/stsw-img007.html) rather than directly talking to the sensor. This wasn't my first choice, and I initially implemented it from scratch, but it was massive with a fairly complex initialization routine (that failed sporadically) and still only implemented a fraction of what ST provided. For reference here's the Arduino library provided by Pololu for this device - https://github.com/pololu/vl53l1x-arduino. There are over 1000 registers.

The ST library is BSD 3-clause.

[davids5]

@dagar - it will be a while until I can look a this.

[TSC21]

I should get some units in the next 2 weeks, so maybe I can test it.

[davids5]

There is a lot of unknown code in this driver.

I did a quick pass looking for {while|for} I stopped looking when I got to
-VL53L1_wait_for_range_completion
-- VL53L1_poll_for_range_completion
---VL53L1_WaitValueMaskEx

VL53L1_Error VL53L1_WaitValueMaskEx(
	VL53L1_Dev_t *pdev,
	uint32_t      timeout_ms,
	uint16_t      index,
	uint8_t       value,
	uint8_t       mask,
	uint32_t      poll_delay_ms)
{
	VL53L1_Error status  = VL53L1_ERROR_NONE;
	return status;
}

I think the only options are: testing it, and use code coverage and profiling to verify it is not going to hang the system or rely on bad code, like above.

[davids5]

Title block?

[dagar]

Standby, ST has a slightly less enormous "ultra lite" driver (ULD) for this thing I'm looking at.

[TSC21]

Standby, ST has a slightly less enormous "ultra lite" driver (ULD) for this thing I'm looking at.

@dagar is this still feasible before a release? Or should we aim to a further patch release?

[zbynekwinkler]

How can I help with this?

On a related note - any thoughts on connecting multiple VL53L1X sensors to Pixhawk 4? The I2C address of the sensor can be changed but AFAIK the change does not survive the reset. The suggested way is to either connect the reset pin of the sensor to mcu and start the sensors one by one or use some kind of I2C switch to separate them from each other. I am thinking about using PCF8574 to drive the reset pins. Would approach like this be welcomed as a PR?

[zbynekwinkler]

I am thinking about using PCF8574 to drive the reset pins. Would approach like this be welcomed as a PR?

I believe that is the solution used in bitcraze multiranger deck: bitcraze/crazyflie-firmware@bbf485a and also in https://github.com/ipmgroup/RangeFinder_9xVL53LXX_hardware

[davids5]

@zwn

If adding an IC; Why not use something like http://www.ti.com/product/PCA9548A

These downstream channels can be used to resolve I2C slave address conflicts.
For example, if eight identical digital temperature sensors are needed in the 
application, one sensor can be connected at each channel: 0-7.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[copterspace]

Today I have tried to build https://github.com/dagar/PX4-Firmware/tree/pr-vl53l1x and setup my test Pixracer + vl53l1x sensor with it.
Driver does not start up automatically, but it starts OK manually.
But although I see the driver reports it works OK:

I stil can not see any Distance sensor measures in Widgets-Analyse in QGC:

How can I obtain Distance Sensor uorb messages from this driver, to test it in flight?

[dagar]

@copterspace I've been using this driver in private for various things, but it never merged in PX4/Firmware because the enormous ST driver seemed questionable. I can take another look at bringing it in using the smaller version of the ST driver before the next PX4/Firmware stable release.

[copterspace]

@dagar yes, please consider include the driver for vl53l1x to the PX4/Firmware release.
I currently use https://github.com/okalachev/vl53l1x_ros with this sensor, it works OK, does not seem much bigger then any other i2c device driver.
vl53l1x rangefinder is also supported in latest Arducopter, it works OK.
But I'd like to use it with PX4 flight stack, connected directly to FC, not via onboard computer+mavros.
I can help with any hardware tests of vl53l1x + Pixracer

[dagar]

Accidentally overwrote the branch with a new PR cleaning up the pr-vl53l0x. I'll open a new PR for the vl53l1x.

[koby08]

@dagar Have you got a chance to open such a PR? Worth to mention just for the sake of continuity in this thread.. Thanks :)