I’d like to use a ST VL53K1X as a rangefinder for obstacle avoidance.
There is a parameter sens_en_vl53L1x (enable/disable)
I’m trying to find out how to use parameters for the I2C Bus and device address.
The VL53L1X has a default I2C address - but I may use something different.
And the CubePilot Cube carrier boards have their I2C port labeled as (I2C 2) - that I presume means it’s a port for the I2C number-2 bus. The Holybro flight controllers only label their ports as “I2C” - so I don’t know what bus they represent.
I’ve done some research and have more information now.
Thank you for your inquiry @nitru - I am planning on using those sensors for obstacle avoidance.
I’ve learned that the drivers for each type of supported rangefinder handles the sensor identification - the bus and address in the case of I2C sensors.
So for example, when I connect my I2C Lightware LW20/C, and enable the driver for it - PX4 “discovers” it.
It’s interesting to note that when you query rangefinders in Qgroundcontrol MavLink Console, it will show multiple rangefinders when they are connected. For example, when I have a HolyBro H-Flow and a Lightware LW20/C connected - doing a “listener distance_sensor” in the Qgroundcontrol MavLink Console - both devices are reported - along with some of their capabilities.
However, doing “I2CDETECT” in MavLink Console shows neither device.
I’ve tested this both on a Pixhawk 6C and a Cube Orange. This is interesting because the Cube Orange’s I2C connector is for Bus 2. I think the Pixhawk 6C connector for I2C is for Bus 1.
So with two rangefinders detected - one for optical flow - how do I configure the other rangefinder to be used as an obstacle detection device?
When both are connected, the “distance sensor” report in Qgroundcontrol MavLink Detector only shows the rangefinder data from the H-Flow optical flow’s rangefinder.
Forr i2cdetect, you must specify your i2c bus. Many devices use bus 1 (the default one when none is specified), as the internal one. use i2cdetect -b 2
and so forth to see the other buses. Pixhawk 6c, i know uses the bus 2 for one of the i2c ports, Cube orange i do not know.
Use this command, once plugged in and once without the sensor to figure out on what bus the sensor is, and then start the device with the correct bus.
About the configuration for obstacle avoidance, I unfortunately cannot help you.
I’ve tried specifying different I2C busses with the i2cdetect command - it didn’t have any effect for me. Maybe I wasn’t using the parameters correctly.
I’ve been thinking about why maybe the Cube only exposes bus 2 - and perhaps the Pixhawk does as well. By reserving bus 1 for the device internals, there’s no chance for an added device to conflict with the flight controller’s function. So I’m guessing that I2C bus 2 is the only one exposed on a flight controller’s carrier board - by design. If so - that’s a good design choice.
So if the user added I2C devices are all on bus 2, then all PX4 has to do is scan the bus for devices, and then check to see if there’s a device driver installed to support that device.
With ArduPilot, the individual bus and address can be set with parameters. With PX4, the device driver seems to be responsible for sorting that out. And as not all device drivers are the same - there can be variations.
I tried to get a Matek I2C-INA-BM current detector to work with PX4 - and failed. This type of digital current detector is what’s on the Pixhawk 6C - presumably bus 1. It could never find the device I added.
Maybe this is an area that receives little attention from the DEV’s. But it would sure be nice if it was at least better documented, so users could know the capabilities - and how to use them.
