What FC and Firmware releases have you tried ?
I have tested them on Pixhawk - PixRacer - BeagleBone Blue
Pleas read my blog, you cannot connect more than one VL52 on a bus because the adressing is volatile
i used 2 auav x2 and a pixracer. on auav it was the only single device on the i2c bus. no use. i asked randy if it is possible to add a startup message to ardupilot to print addresses on all discovered devices on the i2c bus - i have no clue what to do next with it, as i do not see what may be failing.
on all your tests, did you power those lidars from the 5v on the same uart or from an external 5v BEC?
The VL53L0X can be powered from the FC 5 Volts no problem.
I assumed you used up to date firmware (this range finder has been added around 3.5.4, with some fixes on 3.6.rc2)
yes, all is done properly. like i already stated, i am testing this on the 3.6 rc6.
odd. it definitely sees this lidar - as i get ‘bad lidar health’ message only if this lidar is in fact connected to the i2c bus. it is same if it is after compass or without compass. if signal wires are removed or altered, or unit is removed - ‘bad lidar health’ message does not come, it is only shown if lidar is in fact connected.
could you pls post all your rngfnd params you used on this lidar? i assume nothing else is needed at all in any other param sections for it?
i tried to alter address ‘41’ into some wrong one, i think, 27 - and i still see ‘bad lidar health’ message after that, with lidar connected. i can only suspect some kind of a bug to set or use correct address 41? no clue.
Actually, the only difference is the adress that I leave to 0 because its the defaulted value
i altered address to 0 - same thing, ‘bad lidar health’. is there any way at all to extract any debug info from arducopter on this thing? any console port to connect, anything at all?
generally you connect to serial 5 , that is the console port, or you can use mission planner to connect to console as well
@ppoirier, the connection diagram on our VL53L0X wiki page looks correct right?
@Paul_Atkin1, a few ideas:
- I guess you’ve triple checked the wiring? I often try to swap the data and clock pins around 'cuz that’s a common one to get backwards.
- you’re using a pixhawk flight controller? I think I saw you said you were using AUAV2.1 board.
- providing a log file would be good I think. That will at least provide the parameters so we can see if anything obvious is incorrect.
Apologies if you’ve already done some of these things.
@rmackay9 yes it is correct, the RNGFND_ADDR is irrelevant because it is for the LightWare I2C sensor to allow for multiple sensors on different addresses.
Please note that the second part of the text of RNGFND_ADDR on mission planner might be confusing ‘‘A value of 0 disables the sensor’’ that is not the case with the VL053 and all other sensors.
Hi Randy,
if there is a screw up on my part - i cannot find it. 
wiring is fine as i used same exact wiring on arduino test. i just soldered pins to another VL53 lidar - i have several of them, it acts the same - on the i2c chain it only generates ‘bad lidar health’ response.
address 41 or 0 (or anything, actually) given in options seems to be irrelevant - i still see same bad lidar message when it is properly connected to i2c bus.
if it connected wrong, with mixed wires for clock/signal or no power - ‘bad lidar’ message is not generated.
i am not sure what log to provide or what options to set as i tried to capture pre-arm log but saw absolutely nothing in it for i2c bus.
i also do not agree with you about printing out i2c devices in the message - it is pretty much same thing as to print out GPS ROM version - it helps to see that GPS is actually communicating. it would be nice to see same for i2c devices - it would help troubleshooting a lot, i think, as right now it seems to be just a black box.
here is a link to a last log, if it may help.
https://drive.google.com/file/d/1ImchD775IZsOcWC--bjkQgYHnLvYaOCs/view?usp=sharing
so, i see in the beginning of the sample code for lidar in the sketch they set serial port speed. i tried to play with it and i see that serial monitor is only capable to show correct output if speed in monitor params matches speed set in the sketch.
how is all that done in the ardupilot code? as sensor is definitely alive, but if it is unable to read it, the easiest explanation would be a port speed mismatch, i would think.
#include “Adafruit_VL53L0X.h”
Adafruit_VL53L0X lox = Adafruit_VL53L0X();
void setup() {
Serial.begin(921600);
// wait until serial port opens for native USB devices
while (! Serial) {
delay(1);
}
Serial.println(“Adafruit VL53L0X test”);
if (!lox.begin()) {
Serial.println(F(“Failed to boot VL53L0X”));
while(1);
}
// power
Serial.println(F(“VL53L0X API Simple Ranging example\n\n”));
}
also, in the header of other sketch i see this statement, quoted below.
are those ‘different ranging profiles’ or other settings permanent - kept after power off, and may affect compatibility, or is sensor erased into ‘default’ state after each power off cycle?
/* This example shows how to get single-shot range
measurements from the VL53L0X. The sensor can optionally be
configured with different ranging profiles, as described in
the VL53L0X API user manual, to get better performance for
a certain application. This code is based on the four
"SingleRanging" examples in the VL53L0X API.
The range readings are in units of mm. */
ok. i finally figured out how to see this and now i see WHAT happens - Randy, could you pls review and may be say WHY it happens?
it first says it is not an ‘owner’ of 0x2909, and then says ‘Failed to get SPAD info’. it looks like something more of less definitive?
not very extensive googling points to this:
and this block below.
So, who is the “bus.semaphore.check_owner()” and why it hates this lidar?
bool I2CDevice::transfer(const uint8_t *send, uint32_t send_len,
uint8_t *recv, uint32_t recv_len)
{
if (!bus.semaphore.check_owner()) {
hal.console->printf(“I2C: not owner of 0x%x\n”, (unsigned)get_bus_id());
return false;
}
bus.dma_handle->lock();Hi Randy - i did not realize i did not respond to you with my update, pls review when you`ll have time. The issue seems to be with the “bus.semaphore.check_owner()” call, it looks like.
What IS your RNGFND_ORIENT=
Why would it make any difference? It was supposed to be looking down, log should have value. just checked - it is ‘25’, to look down.
@tridge has found and fixed a semaphore issue with the VL53L0x driver. This will be included in the next release candidate and I strongly suspect this will resolve the issue that @Paul_Atkin1 has been seeing. The error message reported was too odd to be a user configuration issue but it definitely fits with a semaphore issue.
Thanks @Paul_Atkin1 for your reports and patience!
1 Like
hi, i tested new fix and confirm it works now as expected, kudos to Andrew.
1 Like