I’m running a Control Zero for a flight controller along with an LW20 facing down, and a TFmini+ facing forward. I’ve had this combo work in the past on 3.6 with a cube.
Currently I’m getting a Bad Lidar Health message. I disabled the TFmini (set up as RNGFND2) to see if that would help, but it didn’t make any difference. What I did notice is that when I pass my hand in front of the TFmini the sonar range changes (incorrect values from 1 meter to 100+ meters) even with the RNGFND type set to 0.
Any idea what is going on? Is anyone else successfully running this combo of rangefinders?
1 Like
Probably best to provide an onboard log but I guess you’re saying that just having the TFMini powered up and connected to the flight controller is causing interference issues with the downward facing LW20?
I’ve never used this combination but I guess the source of the problem could be:
- light from the TFMini bouncing back and affecting the LW20 (even though they’re apparently pointing in different directions)
- both lidar are connected to the same I2C port and some interference is somehow travelling back along the I2C line or perhaps they have conflicting I2C addresses (unlikely)
- some kind of EMI transmitted through the air from the TFMini to the LW20
I suppose some tests could be run to figure out which of these it is (assuming this is the complete list of possibilities) including connecting the TFmini to another I2C port or even a separate autopilot. Perhaps try putting something in front of the TFmini so that light from it can’t possible escape and affect the LW20.
1 Like
Both of the lidar are using serial.
I got the LW20 working by setting serial1 that the TFmini is connected to 0. When I set that serial input to rangefinder, I get the bad lidar health message.
I’m 99% sure that it isn’t light bouncing between the sensors. I can completely cover the Lw20 and I still get values changing for sonarrange and rangefinder1 when I pass my hand in front of the Tfmini.
I guess my question is how does AP know which rangefinder is which? I understand that you set the serial protocol to 9 for rangefinder, and then you set your rngfnd_type to whatever is plugged in. How does AP know that the TFmini is plugged into serial1 as rngfnd2 and that the LW20 is plugged into serial2 as rngfnd1?
1 Like
@pkocmoud and I figured out the issue. Whatever you want to be rngfnd1 has to be a serial port before whatever rngfnd2 is plugged into. To fix my problem I had to put the LW20 downward facing on serial1 and the TFmini front facing on serial2.
1 Like
@rmackay9 @tridge I plan to open an issue. But to summarize this appears to be caused by the order in which the enabled rangerfinder drivers detect UART sensors by checked the ports in numerical order. We may need to have a way to specify not just rangefinder type but also the expected port number it is connected to.
When we matched the serial port order to the order in AP_RangeFinder.cpp where the range finders are initialized, it worked out correctly.
2 Likes
Glad that this is sorted out.
Perhaps it’s more of a documentation issue though. As you say, the first RFNDx_TYPE which uses a serial port will use the first serial port with SERIALx_PROTOCOL = 9 (rangefinder). The 2nd RNGFNDx_TYPE that uses serial will use the 2nd serial port with SERIALx_PROTOCOL = 9.
Adding another RNGFNDx_ parameter may not make things simpler because it would be redundant and simply add another parameter that the user needs to set and thus possible set incorrectly.
2 Likes
I think making the documentation more clear regarding this is enough of a fix for me.
1 Like