PLS HELP! ArduCopter V3.6.0-rc7: two sonars, none works (glitches, extreme values)

[Webillo]

Hi.

Hexacopter with ArduCopter V3.6.0-rc7 on Pixhawk v2: two sonars, none working for weeks. Same problems as in:
Copter V3.6.0-rc6 two sonars (Maxbotix I2C, Benewake TFMini): glitch
which had no answer.

It flies very well if both sonars are disabled, in PosHold, AltHold and Auto. If any sonar is enabled there are constant sudden altitude changes and EKF error changes, and even it starts going up without limit towards the moon with the selenites in some modes.

The sonars are:
-Maxbotix I2C (ultrasonic).
-TFMini serial (infrared).
Being of different technology, I understand that they can coexist without interfering. Anyhow, I did a few tests with only one sonar connected, and nothing changed.

It has also two GPS’s installed. Briefly:
-SERIAL0: USB.
-SERIAL1: telemetry.
-SERIAL2: GPS2.
-SERIAL3: GPS1.
-SERIAL5: TFMini.

After many unsuccessful sonar tests, since any sonar can need a big current when triggered, and after observing some ripple on the +5V Pixhawk supplies logs, I decided to supply both sonars directly from the Pixhawk servo pins, which are directly connected to the +5V converter on the Pixhawk power supply (a typical one with two XT60 connectors, shunt and 5V converter between them), building special cables.

Four tests follow, one at home (almost successful) and three unsuccessful ones at the field. Sonar altitudes correspond to RFND.Dist1 and RFND.Dist2 in the logs, which are compared with BARO.Alt.

1. I tested at home (indoors, no GPS’s lock), flying the hexacopter lifting it around 1.5m:
   Copter_20180812_75_home.bin

These are baro and sonars altitude logs:

Both sonars follow baro altitude, but Maxbotix I2C sonar has a negative glitch.

2. At the field I first tested with both sonars, lifting the hexacopter around 8m:
   Copter_20180812_76_2sonars_8m.bin

Maxbotix I2C follows baro only 2m, and then goes to 8m with glitches:

TFMini reports going up to 800m:

The voltages seem perfect:

This appears in the log:
ERR, 744795297, 24, 1
close to
MSG, 744795528, EKF primary changed:1
which I can’t interpret.

3. Next I repeated previous test done at home, lifting the hexacopter around 1.5m:
   Copter_20180812_77_2sonars_2m.bin

As on previous test, Maxbotix I2C follows baro only 2m, and then goes to 8m with glitches:

and TFMini reports going up to 655m:

So doing the same than at home (up 1.5m), outdoor results are very different.

4. Next test was disabling and disconnecting the TFMini sonar, lifting the hexacopter around 8m:
   Copter_20180812_78_1sonarI2C_8m_I2Cbaro.bin

Again, Maxbotix I2C follows baro only 2m, and then goes to 8m with glitches:

Conclusions:
-Unusable sonars with extreme values, being worse on the TFMini.
-Both sonars were tested with an Arduino; no known malfunction, and the two cannot be bad. The TFMini was recently purchased (firmware upgrade is mentioned elsewhere, but both sonars fail).
-Same test (up 1.5m) gives different results at home than at the field.
-It happens as if there is an instability somewhere, but I understand RFND.Dist1 and RFND.Dist2 as measurements.

What can I have misconfigured, or be doing wrong?

These sonar installations are documented at:
Maxbotic I2C Sonar Rangefinder
Benewake TFmini lidar

On Copter Complete Parameter List:
Serial rangefinder protocol: 9 (SERIAL5_PROTOCOL 9).
Rangefinder type 2 MaxbotixI2C (RNGFND_TYPE 2).
Rangefinder type 20 BenewakeTFmini (RNGFND2_TYPE 20).

This is an example of a perfect flight in Stabilize, AltHold, PosHold and Auto modes with both sonars disabled:
Copter_20180812_79_sonarsdisabled-perfect.bin

[rmackay9]

Hi Webillo,

So as you say, both sonar are not working well at all.

There’s actually no good reason to have two downward facing sonar/lidar. Copter will only use the first one in any case. I think it would be good to get rid of the Maxbotix one and just use the Benewake Lidar. I would try a test where you lift the vehicle up and down and then we check the distance reported by the lidar either in the ground station’s Flight Data >> Status tab or in the dataflash logs.

[Webillo]

One would think that being there separate parameters RNGFND_xxx and RNGFND2_xxx, with equal orientations, the program would average them, choose the best or reject that one with bad measurements (as above), as seems it happens with two GPS’s (parameter GPS_AUTO_SWITCH), as long as they can coexist, which I think they can if the sonars have different technologies. Having both prepared makes easy at the field enable one, the other, both or none.

I am not still fully confident on sonars behaviour on copter software, although the one I like most is the TFmini (delicate and with confusing documentation). I have seen good behaviour on one flight and giving constant height on an immediate one.

Brief test with only TFmini, lifting the drone by hand:

better than above. Will it repeat?

This 4K video (identical mission on Rover and Copter) might show the need for a working sonar:

The copter waypoints are alternatively at 3.5m and 4.5, high enough because of the low barometer/GPS’s altitude measurements precision. ROI=podium.

These are barometer/GPS’s altitude measurements on the Rover, which should be constant since it runs over a perfectly horizontal surface:

(GPS2 seems going crazy)

So if the drone is 50 or 100 meters high, baro/GPS altitude uncertainities might not be important, but they are if on a low altitude mission as above. It seems a miracle that the drone has maintained altitude on above video, given the logs on baro/GPS’s altitudes.

[Webillo]

This is a flight with a Benewake TFmini as only sonar, not fully successful (ArduCopter V3.6.0-rc7):

Two circles, with waypoints alternatively at 4.5m and 5.5m, although flight height resulted lower. In the log appears a 2m offset between BARO.Alt and RFND.Dist1. Real flight height moreless was the rangefinder measured one, as can be seen in the video.

Log:
Copter_20180916_56_circle2.bin

2m offset between BARO.Alt and RFND.Dist1:

Strangely, Baro.Alt starts at 2m. Shouldn’t it start at 0 when arming?

CTUN:

-Again, 2m offset between CTUN.BAlt and CTUN.SAlt.
-Although CTUN.Alt follows closely CTUN.DAlt, their values are between 8 and 9m (even higher than CTUN.Balt). Mission waypoints are 4.5 and 5.5m high alternatively.
-CTUN.DSalt values stop when mission starts.
-No idea what is CTUN.TAlt: its values are 0.

Questions:
-Why BARO.Alt starts at 2m, if it should be reset when arming?
-Why 2m offset between BARO.Alt and RFND.Dist1? RFND.Dist1 seems height observed in video, but is far from waypoint altitudes (alternatively 4.5 and 5.5m).
-Why CTUN.Alt and CTUN.DAlt values between 8 and 9m, if waypoint heights are 4.5 or 5.5m?
-Is CTUN.DSalt of any use? What is CTUN.Talt?