Position Hold and Navigation issue

[giacomo892]

Hi. I've already wrote about this issue in the forum and no, unluckly, I do not have a blackbox log but a video. I'm posting here just because a better analysis could maybe fix the issue and cause i've found a previous similar issue that is now declared as closed. (#431)

First of all. Setup.

1.6.1 NAZE. F450 QUADX. UBLOX M8N,HMC5883,BMP280,MPU6050.

And the conf diff:

feature GPS
feature TELEMETRY
feature PWM_OUTPUT_ENABLE
serial 0 17 57600 38400 57600 115200
serial 1 2 57600 38400 0 115200
aux 0 1 0 950 2050
aux 1 1 1 950 2050
aux 2 3 0 1600 2025
aux 3 3 1 1600 2025
aux 4 9 1 1600 2025
aux 5 8 3 1650 2050
aux 6 19 2 1850 2050
set acc_hardware = MPU6050
set acczero_x = 164
set acczero_y = 16
set acczero_z = -12
set accgain_x = 4071
set accgain_y = 4082
set accgain_z = 4012
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 mag_hold_rate_limit = 45
set baro_hardware = BMP280
set rx_min_usec = 989
set rx_max_usec = 2100
set failsafe_procedure = RTH
set vbat_scale = 50
set nav_max_speed = 700
set nav_max_climb_rate = 400
set nav_manual_speed = 500
set nav_manual_climb_rate = 300
set nav_mc_hover_thr = 1575
profile 1

set mc_p_pitch = 79
set mc_d_pitch = 45
set mc_p_roll = 79
set mc_d_roll = 45
set mc_p_yaw = 80
set mc_i_yaw = 40
set max_angle_inclination_rll = 350
set max_angle_inclination_pit = 350
set rate_accel_limit_roll_pitch = 4000
set rate_accel_limit_yaw = 1800
set roll_rate = 35
set pitch_rate = 35

Basically I had some other times when the quad was in position hold and magically started to drift away (fast!) like @xdigyx reported in #431 "Today I had a situation when at pos hold mode my hexacopter rapidly started to fly away. "

So maybe the fact that this time happened during a mission (and at the final stage = position hold) urged me to post this issue since there maybe something left from that issue.

I've checked for I2C errors and GPS errors after landing and they were at zero, so I assume all the sensors were working.

More, I did another flight without rebooting the FC also in position hold, even fully yawing the multi to check for mag issues, and it held correctly without toilet bowling. (an issue I never had before to be clear)

Here is the video on what happened https://www.youtube.com/watch?v=_kv2N9qdhfc

I've annotated the video , please check it using desktop version of youtube.

[giacomo892]

It's strange cause it always performed well (beside position issue) I didn't expect a motor to shutdown in flight at this point. And ground tests seems all ok.

Regarding the hardware it is Maple Mini (STM32F103RBT6) on custom board with MPU6050,BMP280,HMC5883+M8N. No different from any NAZE targets.

[Redshifft]

Time to test PH now then ;) - If it works you have to put your old fw on and retest.

[giacomo892]

The everyday luck. I went to a safe field to fly and test and some rain started to drop. Well! (?!?!?!?!). I didn't care as soon it didn't started properly raining. I did a 12 minutes position hold (I only sightly moved 2-3 times) and IT WORKS. No flyaways.

Tomorrow if the weather allows I'll try again to check everything working.

I'have filmed the position hold https://www.youtube.com/watch?v=6OgGtwdDGvI .

OFC Luck in the luck the SD CARD failed and the recording stopped after 8 minutes.

There was a nice breeze with some gusts and the machine nicely sensed the wind and adapted the roll in a very smooth way to stay in place. (I really like constant wind fighting 🥇 )

If you take a look at the video you can say how nice the pos hold is, maybe altitude hold need to be worked a bit, maybe increasing a bit the baro authority.

PS. If you can please try my 1.6.1 version with glitch detection enabled. Before the crash I had, I saw it kicking it at least one time. The quad drifted a bit with the wind before stopping again. PS2: Minute 6.40 AS350 Squirell passing on the quad Minute 8 Heli ambulance (I-PAAA) landing

[giacomo892]

Hi. Finally a nice day. A bit windy but ok for our testing purpose.

I've done some several flights in position hold mode, the longest leg was 16 minutes of continuous holding. The quad acted VERY VERY well (beside small issue on mantain correct height but we are on INAV 1.3 things may be improved a lot thanks to our master @digitalentity 🥇 ).

The quad only one tried tried to "escape" giving a small pitch bump but immediately stopped after doing like a 15cm run. Maybe it was only a strong wind gust or turbolence. Beside that INAV 1.3 position hold is solid.

Tried some RTH with different batteries, all perfect like you can see: https://youtu.be/-DxdmndwYYA

Tried to yaw the quadcopter while in Position Hold.

Held the position perfectly: https://youtu.be/aol7n2OttZU ( @digitalentity is that bit of swerving normal ? )

Two more bonus videos:

Wind Gust fight: https://youtu.be/bh4JgEnZMXk (Nice, what do you think?) Closeup and Landing: https://youtu.be/l85ErVJ4ARk

I can affirm that Position Hold in 1.3 is solid and in >1.5 is not working correctly or it has flyaway issues at least on NAZE target.

I can tell only about 1.5 since it is the version I started used INAV.

[Redshifft]

@giacomo892 :D Don't get ahead of yourself, 1.3 has the same bug as 1.6 (for F1) What you were flying was My modified and cut down 1.3 ;) Our leader is still recovering and when up to full strength will be able to work out the cause of the "glitch" after a few mumbles of F1's should be in the trash bin :D lol

[digitalentity]

Hi guys! I'm back among the living! @Redshifft what did you strip down in your 1.3?

[giacomo892]

@Redshifft LOL. I tried my best, even with a full video reportage LOL Hope you have enjoyed it :)

So I've flown an highly experimental version LOL Nice LOL

@digitalentity I red about your illness. Glad that now you are ready to rock again.

[WaspFPV]

@giacomo892 Glad I found this thread. I have similar issues with my Naze on 1.6.1. It holds position just fine for a couple minutes, but if I move or engage RTH it starts flying away. Compass is calibrated, GPS module is UBLOX LEA-6H, and I usually get 6-9 satellites.

[giacomo892]

@andre92 Try this firmware on your NAZE and report if position hold works. Pay attention to setup it properly with the calibrations all in place and fly safe.

What machine are you flying? 10 incher?

minimal_inav_1.3.0_NAZE.hex.zip

[WaspFPV]

@giacomo892 Thanks, I have it set up now and I'll fly it asap. One more thing I noticed with 1.6.1 is the configurator would hang after leaving CLI on Naze. I thought nothing of it then, but it doesn't hang with 1.3. And yes, I'm flying a 10 incher, the one in my profile pic. (except it runs a Naze32 now instead of an Arduino)

[digitalentity]

If somebody will provide blackbox logs of the issue it would be much easier to troubleshoot.

[Redshifft]

My finest fw is going viral :D

@digitalentity, @stronnag compiled it, knowing me I would have said strip out everything you can..Lol Blheli passthrough was added + Frsky telemetry, I will try and find the post in the forums

[stronnag]

I remember building it, stripped down, do it may not even have black box built in. The perfect Schrödinger's cat chasing a heisenbug.

[digitalentity]

The thing is that I'm unable to reproduce the bug on ANY of my machines - varying from CC3D to AnyFC_F4

[stronnag]

Likewise I tend to fly a number of different machines and boards, frequently. Unfortunately, we are not looking at a 'standard' hardware platform here, so the lack of logs is even more acute.

[Redshifft]

Found it, https://www.rcgroups.com/forums/showthread.php?2495732-Cleanflight-iNav-%28navigation-rewrite%29-project/page646 It would not have had BB for sure. :D can't help it if you guys can not reproduce the the fault, but it does not mean it's not there. You have to think it's a resource / load issue, you lot would know better than me which modules are making processor calls etc.

[WaspFPV]

Is there any possibility that this issue is specific to Naze target and only on newer iNav versions? Naze has to support more drivers than most other boards so it could be a memory issue.

[Redshifft]

It seems to be just an F1 issues for some

[giacomo892]

@andre92 the CLI hang is a known configurator bug. There is already an issue open. @stronnag Beside my custom hardware, the others seems like they are flying standard configurations(CC3D,FLIP32,...). Am I wrong?

Could even be something related the the compiler? Maybe @stronnag know which one he used to compile the stripped version of 1.3.

And, why the blackbox feature would cause problems if it is compiled but not used?

[stronnag]

Compiler was gcc 6.2 Blackbox was removed to free up space for frsky telemetry. I've tested FLIP32 on more recent versions without problems. I can do so again, possibly this week.

[digitalentity]

@stronnag thanks! I don't have any flying NAZEs at the moment - might indeed be board specific. I hate Schrödinger's bugs.

[giacomo892]

So, just to recap, we have now a "randomly" stripped down INAV 1.3 firmware which is bug free. Nice situation to start the bug search. I thought that the "modified" 1.3 had some fixes in it.

[stronnag]

The only changes, afaik in a 1.4 pre-release build was to remove some standard features and add in some non-standard. No other code changes. Just a placebo.

[giacomo892]

Maybe I should try building 1.6.1 with the same feature set and try to fly it.

It should have:

1. No Blackbox
2. FrSky telemetry (should be already enabled, which I do not use)
3. BlHeli Passtrough (I cannot find the 1Wire #define to enable it, can you point it out please)
4. Only MPU6050,BPM280 and HMC5883 selected,
5. Disabled SPI

Correct me if the feature set should be different.

[Redshifft]

What's all this random and placebo stuff ? :D

[stronnag]

I can check the features later.

[WaspFPV]

@giacomo892 main/src/target/Naze/target.h, near end of file: //#define USE_SERIAL_4WAY_BLHELI_INTERFACE By the way, do you really need it? I just save my config dump and switch to Betaflight.

[giacomo892]

andre92 Thanks. I use it sometimes to check ESCs but I want to include it just to have the most similar firmware to the modified 1.3 Betaflight is intended for racers and it wont provide any GPS features which are being discussed here. And please fly the custom INAV 1.3 first and report if RTH and POS HOLD works

[giacomo892]

I've compiled the firmware as I said earlier.

I've used gcc-arm-none-eabi-6_2-2016q4 :

arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]

inav_1.6.1_NAZE_minimal.hex.zip

The firmware size went from default 127676 bytes to 118400 bytes.

Here are target and common modified and commented files.

target.h.zip common.h.zip

I'm unable to fly till the next weekend. So if someone can try this before me it will be awesome.

[Redshifft]

Did you do as you said ? "No Blackbox FrSky telemetry (should be already enabled, which I do not use) BlHeli Passtrough (I cannot find the 1Wire #define to enable it, can you point it out please) Only MPU6050,BPM280 and HMC5883 selected, Disabled SPI" I would have asked everything that I did not need driver wise be pulled, don't forget UBLOX for the GPS.

[giacomo892]

@Redshifft I've attached common.h and target.h if you want to check. UBLOX is enabled too since it is already enabled in the official build.

[Redshifft]

LOL, I did what's all this Mac stuff :)

[giacomo892]

Holy cow. Compression Utility leaves some files inside zip :) Ignore them

[stronnag]

I flew F1 (FLIP32) 1.6.3 on my half rebuilt 420mm quad. Somewhat unsatisfactory as it was completely untuned (just copied a CLI dump from a 250 onto it), and due to the rebuild, the mag was closer to the power than I'd like.

Regardless it works (for me). After about 12 minutes of entirely OK POSHOLD (no flyaways, no crashes), bit bouncy due to the lack of tune, but in the same place POSHOLD, I went to do something less tedious.

[giacomo892]

HI all. Just to keep you posted about what going on.

I'm building a DIY serial openlog blackbox so I can connect it to the official 1.6.1 and let you all see what is going on.

I hope it will work ok and so I will finally post some logs here. Even if I don't get a flyaway we should see strange things happening when in POS HOLD.

I just miss a level converter between SD and Arduino and I should ready to go.

On sunday there will be rain here, so I hope I'll have time to set it up for saturday.

Beside that, anyone has flown the stripped 1.6.1?

@stronnag I'm glad you don't have the issue but trust me, it's somewhere hiding there.

EDIT: Perfect! My soldering iron broke down. I hope I can find a new one today.

[giacomo892]

Yay! I've flown with the blackbox! i've setted 1/32 logging ratio and using cleanflight explorer I still have some corruption? Do I have to use cleanflight explorer?

Or maybe the SD CARD is not fast enough. I'm using 250000 as baudrate so that should not be a problem.

I had no flyaway today and all worked really well.

Can you take a look in the logs and say me if they are ok or not?

Thanks

[stronnag]

I replayed the logs in mwp, looks normal (just like I'd expect for iNav on a supported FC); at least for the amount of time I'm prepared to watch a replay of PH. So what's all this fuss about?

btw. You do know the two LOG files are identical?

btw, btw: You should use the iNav Explorer (or mwp for pretty geospatial display)

[giacomo892]

Ok. Blackbox explorer show weird data. Do you think this rate is ok for debugging navigation or I higher it a bit?

[stronnag]

Rate is OK for general navigation debug, if you can identify a specific problem, then a higher rate would help.

[giacomo892]

Are they 100% identical? If so it could be an issue with upload

If the log is ok I double the rate. It should not be a problem.

[stronnag]

100% the same.

I didn't look at the whole log, but random bits looked ok in INav Explorer

[giacomo892]

Really strange since the file size are different. How can they be identical?

[stronnag]

Seems I can download the same file under two names. Strange indeed.

[stronnag]

btw: https://github.com/iNavFlight/blackbox-log-viewer

We need to update some links ...

[giacomo892]

Sorry for "spamming " the issue . I've tried the INAV explorer manually loading the app in chrome and it works. Is there any possibility that the app will be published in the app store?

Btw. Yesterday​ I did almost 25 minutes of GPS holding including moving in GPS cruise. No flyaways.

Now that I have a blackbox ( I've configured it to log 1/2) and it just drops some loops every now and then I'm ready to chase the bug more than ever. It's rather strange since before installing the blackbox the issue was always present :(

[giacomo892]

I recorded a GPS glitch on blackbox on the 5th flight.

You can notice the position jumps many meters far away from the quadcopter after it took off and other many succesful flights in the past weeks.

While the quad was still glitching and GPS position was converging to the right position I enabled GPS HOLD and visually it felt very unsure on holding position but without any weird accelerations and fly aways.

After some seconds I disabled the HOLD and renabled it again without any flyaways.

After landing I tried another flights and they worked well as you can see.

LOG00275.TXT

Now imagine what can happen if the position jumps while the GPS HOLD is on.

Can you get some useful info from the log to prevent this?

EDIT: It glitched also on the first part of the 6th flight but the position quickly converged to the correct one and the it flew well.

Viewing this log can be nice to see: 1)position hold logic while position is wrong (converging to the correct point) 2)simulate with real data what the position hold controller would have done if it was enabled during the glitch 3)check if glitch detection would have helped.

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[stale[bot]]

Automatically closing as inactive.