INAV 1.7/1.7.1 code testing,reports and bugs mainly for @DigitalEntity

[giacomo892]

Hi all and @digitalentity I'm opening this mainly to post some blackbox logs , testing PR and report some issues.

First of all I've flown development 1.7.1 since 876a98e (11 May) patched ( in order to test my PRs and one from DE ) with:

1. BMP280 I2C data sanity check #1654 (BMP 280 I2C sanity)
2. Enabled IIR internal filter for BMP280 #1600 (BMP280 Internal IIR)
3. Fix MSP blocking when flooded with MSP requests #1593 (MSP flood fix)
4. GPS glitch detection ON with a radius of 10m. Just to avoid hugely incorrect GPS glitches like the one i've reported in Position Hold and Navigation issue  #1402 at the end.

With this configuration:

feature SOFTSERIAL
feature GPS
feature TELEMETRY
feature BLACKBOX
feature PWM_OUTPUT_ENABLE
serial 0 128 115200 38400 57600 250000
serial 1 2 57600 115200 0 115200
serial 30 17 9600 38400 9600 115200
aux 0 1 0 950 2050
aux 1 1 1 950 2050
aux 2 20 0 1600 2050
aux 3 4 0 1600 2050
aux 4 3 0 1600 2025
aux 5 9 1 1600 2025
aux 6 8 3 1700 2050
aux 7 19 2 1850 2050
aux 8 26 0 1750 2100
set gyro_hardware_lpf = 98HZ
set gyro_lpf_hz = 42
set acc_hardware = MPU6050
set acczero_x = 159
set acczero_y = 19
set acczero_z = -33
set accgain_x = 4070
set accgain_y = 4080
set accgain_z = 4013
set align_mag = CW270FLIP
set mag_hardware = HMC5883
set mag_declination = 230
set magzero_x = 55
set magzero_y = -133
set magzero_z = -33
set baro_hardware = BMP280
set rx_min_usec = 989
set rx_max_usec = 2100
set blackbox_rate_denom = 16
set motor_pwm_rate = 1000
set motor_pwm_protocol = ONESHOT125
set failsafe_throttle = 1500
set failsafe_procedure = RTH
set align_board_roll = 2
set align_board_pitch = -6
set vbat_scale = 50
set gps_sbas_mode = EGNOS
set alt_hold_deadband = 60
set inav_reset_altitude = EACH_ARM
set nav_use_midthr_for_althold = ON
set nav_user_control_mode = CRUISE
set nav_auto_speed = 800
set nav_auto_climb_rate = 350
set nav_manual_speed = 1000
set nav_manual_climb_rate = 400
set nav_mc_hover_thr = 1510
profile 1

set mc_p_pitch = 64
set mc_d_pitch = 45
set mc_p_roll = 64
set mc_d_roll = 45
set mc_p_yaw = 90
set mc_i_yaw = 35
set mc_p_level = 21
set max_angle_inclination_rll = 320
set max_angle_inclination_pit = 320
set dterm_lpf_hz = 20
set rate_accel_limit_roll_pitch = 800
set rate_accel_limit_yaw = 800
set heading_hold_rate_limit = 30
set nav_mc_vel_z_i = 55
set rc_expo = 60
set rc_yaw_expo = 30
set roll_rate = 33
set pitch_rate = 33

Ok. Regarding BMP280 PR 1 and 2 :

First session of flight ran with IIR filter put at 8 and median filter to ON:

LOG00283.TXT

Second session of flight with IIR filter put at 8 but media filter to OFF:

LOG00284.TXT

I think that the performance is great even without the median filter, so the internal IIR filter is a nice feature to have since it may remove some more noise from not well isolated BMP280.

I think mine is pretty well foamed btw.

3)MSP flood fix is working very well. I don't find any issue with that and it is very useful since I use 9600baud for my MSP link.

Before passing on bugs just some reports.

1. Heading Lock is working great as MAG was in 1.6.1. I don't really find any issues and I leave it enabled the whole flights. (Heading-hold issues on 1.7.0 and 1.7.1 #1644 someone reports troubles but I don't see them)

2. Turn Assistant still works ok and helps a lot with my fat F450

Now bugs, unfortunately.

1. Battery type and voltage is not reported correctly on BlackBox. I have a 3S battery and the logs are reporting a much more cells one. INAV explorer and MWP @stronnag are affected.

2. Most of the times I uploaded even a simple mission with all WP's very close the quad my quad was not armable anymore. The navigation was blocked. Only fix is to reboot the machine.
   Even deleting the WP's from flash didn't work.
   All sensors were reporting healthy status and GPS had many sats as you can see from other logs.
   I do not have logs on this since logs are not working while on ground.

3. This is the critical one. RTH sometime doesn't work if the quad is under 10m. It arrives like at 9.4-9.5m and it holds there forever @digitalentity .
   I never never had this issue with 1.6.1.
   You can see it from LOG00284.TXT second flight at circa 1:10
   This maybe has something to do with the margins (Improve climb-out logic for RTH. Different margin for airplane and copter #1568) that have being modified sometime ago. I think the quad should start moving home when it reaches 1 meter less the designated return altitude to avoid any infinite holdings.
   This is not good in case of failsafe. For the moment I suggest anyone that fly far away from the pilot to stay above your RTH altitude in order for the quad to return home directly without having to climb.
   I've more logs of this but need to search occurences.

4. As you can see from the logs nav_auto_speed is still enforced instead of nav_manual_speed when using PH cruise. The quad should reach 10m/s (nav_manual_speed) but from the log it remain stuck at 8m/s which is mine nav_auto_speed.

Sorry for the long post, hoping to have a done an helpful work.

[stronnag]

Some questions:

Which FC? Your 'custom' FC ?

I have never seen bbox VBAT behaving badly on a commercially available FC (flip32, SPRF3, SPEVO, Omnibus); however all these use vbat scales at or near to default; although bb records the correct scale, maybe there is a scaling issue?

If you look at the logs, the tools (mwp, BBox explorer) are just showing the reported data; they are not 'affected' -- just reporting what the log holds.

What does the CLI or configurator report?

For WP, can you please define 'very close to the quad' in terms of metres. I would like to test this. Is 'very close' within the waypoint radius?

In LOG0284, I see two attempts at RTH, the first one is at a range of 32m, alt c. 6m. For some reason it does not return before you bail out. The second, at range of 21m and c. 8-9m altitude appears to succeed. https://vimeo.com/217318402

I could post dozens of logs of RTH succeeding on 1.7.* with BP280 at altitudes well below RTH altitude on SPRF3, SPEVO and OMNIBUS FCs (which doesn't help you in the slightest). Can't say I've ever seen RTH with a delay of more than c. 15s (prior to 1.7), and 1.7 is way better than previous iterations at quickly reaching RTH altitude for me (all my iNav machines are BMP280).

Finally, have you considered a pwm rate of 2000, nav and 1000 loop time on F1 is at best optimistic. It would be at least interesting to see if that gets better results.

[giacomo892]

Yes my custom NAZE. As usual STM32F103C8T6 (nothing different from flip32) and MPU6050+HMC5883+BMP280. Nothing new under the sun :)

Voltage was correctly anounced by EZ-GUI and with the same settings it worked on 1.6.1 (se my older logs), configurator reports correct voltage :) And I've quoted you because you are the telemetry guy :) kudos!

I initially tough that WP1 was too far, but that was not the case. So I tried various geometries with 3 WPs. Very close = maybe 10 meters from the quad. So yes it might happened that I was inside the wp radius but that is not the issue. Trust me, I tried many combinations and had only one success in arming the quad after uploading the mission.

For the RTH: (Thanks for your video! :) )

I've seen like a 10% failure rate if I stay under 10m with 1.7. Never happened before, seriously.

I was used to get a steady climb to 10m and immediately gaining speed to home. Seems to be somehow broken somewhere now. Maybe temperatures? It was quite hot today (27 degrees) but it was already hot (25) on easter and I flew a lot without issues in that period with 1.6.1 .

I am not getting your latest sentence. I'm using 2000us of looptime with 1KHz PWM with Oneshot 125 in order to reduce the ESC delay. This in conjunction with 98Hz gyro to again gain 1ms in gyro readings.

I think F1 can't perform that much well under 2000us :)

[stronnag]

If the voltage is correctly reported in the configurator and ezgui then it looks like a scaling bug in storing to blackbox; the values in the video are those directly from the log --- and factoring 50/110 would give sane 3S numbers.

I will try some sub-10m WPs tomorrow. I will be shocked if they fail --- I'm prepared to be shocked.

It's not that I don't believe you; having flown 113 iNav flights in the last 30 days (i.e. 1.7.0 or its dev predecessors) , all involving RTH (I'm too lazy to land manually), more than 50% being also WP missions, all using BMP280, I never see anything like you report and can't reproduce such issues.

[giacomo892]

Thanks for you believing in me :) if you have a naze target I'm happy to share my current firmware hex so you can try it.

[stronnag]

I tried (hard) to reproduce a couple of these:

• I created a mission, the first three points were respectively 11m, 10m and 7m from home. The machines (tested on two craft) had no problems arming with these missions loaded. Now that I've left a physical home marker in the field (and I know the position to within 0.1m) I can retry with closer distances if necessary.

• I performed multiple RTHs from altitudes between 2m and 4m. In all cases the machines reached RTH altitude (17 and 22m) quickly and efficiently and returned home.

I somewhat doubt these are generic bugs. Logs / videos available on request. In the attached image, for referenc, the range rings are at 20m intervals.

[giacomo892]

I'll try again this week on the bench and on weekend if the weather allow.

In the meanwhile:

Here there is a mission I was able to execute after many trials with blocked navigation. You can see it on the fourth flight.

LOG00286.TXT

I've also noted that reported altitude on blackbox is way lower 10m (default RTH altitude) when the quad returns home while on the phone I was almost sure it was reporting 9.4-10 meters.

Moreover I've found this #1581 but the fact is that I was getting 100% RTH success with 1.3 1.5 and 1.6 at any altitudes.

I don't think my hardware configuration has nothing to do with the bugs I am reporting. It's just a standard NAZE simply not condensed in a single tiny board but sightly bigger :)

I've also edited the OP with one more bug. (nav_auto_speed is still enforced instead of nav_manual_speed)

[stronnag]

I tried to reproduce these 'bugs' on a F1 FC. I built the crapiest frakenquad I could with the worst hardware to which I have access:

• Flip32 acro
• GY652 (HMC5983/BMP180)
• Neo 6M
• PPM RX
• Softserial MSP/LTM

Flies / performs beautifully; RTH, PH, WP. RTH from 1m altitude (to an RTH altitude of 17m), arming with the nearest WP at 3m. All just perfect.

Great tribute to iNav to work so well on such marginal hardware. Logs, cli diff

These are not bugs IMHO. Even the HMC5983 works perfectly (take that RCG 'fake news').

And the firmware is be7f49e (the commit in the log is a local commit for modified target files)

[giacomo892]

@stronnag Thanks for testing.

Impossibility to ARM due to not safe navigation is due my personal try of using GPS GLITCH DETECTION.
See giacomo892@034fb59 and giacomo892@794004d

Running latest 1.7.1 (as 19 may) this is no more and issue. (it's just my "own" code problem)

Regarding bug 1 (bb battery voltage) it still displayed wrongly but still don't know why, since it was used to be correctly saved and displayed until 1.6.1

Bug 3 is still investigated by digitalentity.

Bug 4 has being fixed and I've tested it this morning. I was able to reach 10m/s with CRUISE @digitalentity

[digitalentity]

I believe this issue is irrelevant now. Closing