Open ecmnet opened 3 years ago
Yes, of course :D
Do you have anything else on that particular bus? Does the manual start ever fail?
I would try setting _retries = 3
in the constructor. https://github.com/PX4/PX4-Autopilot/blob/1ec8ce58c7e544e96cbda711d85c7f3b21731b9b/src/drivers/distance_sensor/lightware_laser_i2c/lightware_laser_i2c.cpp#L141
Starting manually always works - currently I send the console command via the companion. Never had issues with that approach.
Starting manually always works - currently I send the console command via the companion. Never had issues with that approach.
I'm wondering if all the other random I2C probing during startup is causing problems. It's one of the reasons I'd really like the startup of these optional external peripherals to be configured explicitly.
Can you see if the retries help? https://github.com/PX4/PX4-Autopilot/pull/17311
The other thing we can do (that requires slightly more rework) is to add an option that lets the driver start and continue running even if it hasn't been found yet. https://github.com/PX4/PX4-Autopilot/pull/15758
Unfortunately, https://github.com/PX4/PX4-Autopilot/pull/17311 does not solve the issue. Might be related to the HW, as RM3100 is on the same bus and is initialised properly.
Unfortunately, #17311 does not solve the issue. Might be related to the HW, as RM3100 is on the same bus and is initialised properly.
Thanks for testing.
Does it make any difference if you disable all the external i2c probing? SENS_EXT_I2C_PRB 0
https://github.com/PX4/PX4-Autopilot/blob/588883f6636863c7dfa7278be8eae4d7db330db4/ROMFS/px4fmu_common/init.d/rc.sensors#L112-L147
No difference, if SENS_EXT_I2C_PRB
is set to 0.
Does it make a difference if there's nothing else physically on the same bus?
We might need someone with one of these units to step through the code during init to understand what's happening.
I have tried that already of course, no difference.
Could it be power up timing? Does it take a bit longer for the Lightware to actually start?
If I had one of these to debug the next thing I'd try is looping (+ small sleep) in the probe.
We should implement the keep running (-k
) option for all of these devices that are explicitly user enabled.
I verified that hypothesis using px4_usleep(200000);
in the probe method of lightware_laser_i2c.cpp
without success - so I doubt that it is purely a power-up-timing issue.
Sleeping 200 ms is not really long. Can you re-test 2 seconds and then start to reduce?
PX4FLOW has similar problem #17358
I have a similar issue as mentioned here:
https://discuss.px4.io/t/lightware-lidar-wont-let-the-gps-boot/22334
I was wondering if there is any workaround for it or if any data is needed from me to help debugging this?!
Currently the companion starts the driver using NSH commands:
I'm seeing this issue on 1.13.2 as well on Flight Core V2
I'm seeing this issue on 1.13.2 as well on Flight Core V2
I am facing the same problem with CUAV X7 FC, the FC did not detect LW20/C. It works fine if it is used with Cube orange FC, so weird.
Noticed issue on 1.13.2 FlightCore V2, 1.12.2 FlightCore V2, and 1.13.3 PixHawk4
It appears that the lightware lidar SF11/C does not get detected on any of these boards and attempting to start it shows an error that it is not detected on bus.
The only way I'm able to get it to be detected is manually plug into I2C after the device is already on.
Super weird. Not only that, but if the lightware lidar is already powered on via microusb, it still does not matter, and I run into the same problem.
Since I've noticed this on both the FlightCore V2 and Pixhawk4, it appears to be a bug in PX4. It might explain the problems people are running into here.
Lightware Laser (Sf10a) does not start with boot sequence on Pixhawk4 (FmuV5). Starting it later via console works without issues:
Tested releases:1.11.x, 1.12-beta1 and 1.12-beta2
No issues with external RM3100 magnetometer.