iNavFlight
Problem with horizon drift.
My friend use iNav 1.7.1 in a 3.5M glider. When he make a circles in thermals he get a huge drift in angles.
Situation is always the same. When he hold roll for a long time IMU roll angle calculation have gets huge drift and think that it is leveled....
The best if you see that movie: OSD time: 23:00 - 24:08 - circles with roll stick 24:09 - 24:39 - circles without roll input, IMU "think" that plane is leveled 24:40 - roll stick in opposite side and big horizon error
https://www.youtube.com/watch?v=e3H8lEJbgv4
Like you see on the video this is without motor so it is not because of motor noisy... The same situation is for pitch, sometimes he hold Pitch down a little when make a circles and when release model stayed pitch up.
Is there any parameters to tune to avoid this situation ? Filters, ACC weight in calculations ?
Sensor is MPU6000 over SPI.
Any suggestions?
From description it's radio drift or FC sensor drift or I term pumping up - With a little imagination you could test this on the bench quite easily, also test it in passthrough
I flew between trees in acro mode and pass and everything was fine :) This is not a drift radio signal
I recently (after version 1.7) had this issue myself. I partially fixed it by doing a new accelerometer calibration as explained in the wiki. I verified in the CLI that the relevant parameters changed by a noticeable margin, and a second calibration confirmed them with a good approximation. I say partially because I keep on experiencing some drift that I didn't notice before, but given that the issue (and the firmware upgrade) arised after a crash I'm not sure if it's due to software or hardware issues.
Did your friend experience a crash previous to the issue? Does anyone know if a MEMS accelerometer can change its characteristics (but keep working) following a moderate shock?
We certainly have issues with accelerometers on our boards. Their characteristics change with temperature and we don't compensate for it. I've also seen accelerometers killed by moderate crashes.
In my case, it is not drifting due to temperature. I never had this model of any accident that could affect my work ACC Shortcut of my settings: set acc_hardware = MPU6000 set acc_lpf_hz = 15 set acczero_x = 114 set acczero_y = 23 set acczero_z = -286 set accgain_x = 4063 set accgain_y = 4082 set accgain_z = 4062
@wiesiekkr Ok, this might be something https://github.com/iNavFlight/inav/pull/1481 is going to fix. It was not tested yet, so caution is advised.
Promised log file: https://drive.google.com/file/d/0B3GW08HpYYLJek1qTnJrUk52Tm8/view?usp=sharing
@oleost @wiesiekkr looks like the problem that is unsolvable without additional external reference (like GPS). In a proper balanced turn accelerometer reads 1G, but in a wrong direction. Basically, plane indeed thinks it's flying level, while it's in a balanced turn.
I'm going to further develop and test #1481 once I get home
Situation is always the same. When he hold roll for a long time IMU roll angle calculation have gets huge drift and think that it is leveled....
I can confirm this drift on my wing as well. It's enough to do a constant roll turn for a few seconds to get a slanted AHI in the OSD in leveled flight. Turning the other direction for a few seconds gets AHI back to level. Meanwhile I calibrated the ACC several times with quite similar results in terms of values.
Also, I don't remember having this issue with 1.6.x versions on identical hardware.
Will try to reproduce this behavior in a bench test.
I'm moving this issue to 1.9. The problem related to OSD updates is fixed, the problem with making longish banked turns remains, but it will have to wait a bit.
Hello, something going on in the topic? When I flying a glider it is really very annoying :( Below is a movie from the flight. INAV 2.2.0
BR Wiesiek
http://youtu.be/nRl5xqnDpMQ
Edit in attachment my diff file drewniak 2.2.0 .txt
Btw. Wiesiekkr recalibrated ACC, and still have a problem. It is quite danger because when you got failsafe when IMU goes creazy you have big chance to see your plain will make something not expectect...
I have the same issue as @wiesiekkr has, and it is very annoying too. My horizon drifts in pitch axis after 2 or more circles.
Hello, Horizon Drift Fixed - probably :) I did only two flights, but everything looks promising. I entered the suggested value in cli : imu_acc_ignore_rate = 10 Below I'm sending you a link to the movie
https://www.youtube.com/watch?v=xfZFMtaLGnA&feature=youtu.be
BR Wiesiek
Thanks for sharing your experience! This was not a "fix", rather a "workaround", but at least it's something that works.
I'll close this issue now.
The first thing you should do before trying to tune the IMU ACC ignore parameters is to make sure your build is as good as you can get physically and electrically. If you are finding it impossible to fly, you likely have excessive vibrations or noise.
- Make sure there are no removable vibrations. For example imbalanced propellers, damaged motors etc. if the airframe has bad vibrations and you can fix them. You may need to soft-mount the flight controller. This article has some good ideas for soft mounting flight controllers, if you need to; this article has some good ideas https://ardupilot.org/copter/docs/common-vibration-damping.html
- Make sure there is no erroneous electrical noise. For example, if you can see noise in your video feed, that does not just effect the video. That can effect other components too, like the accelerometer. Clean the power with capacitors on the hardware that is causing the noise, the ESC for example. LC filters on the video equipment only hides the noise from them, not fixes it for everything else. In fact, decent VTxs with good filtering may even mask this issue too.
Once the system is clean. The ignore rates can be tuned.
To be honest though. I don't know why this issue was closed. Horizon drift still exists, and the band aid of the imu acc ignore parameters can only go so far. It ok to say that this problem does not have a simple solution. It is complex. But we should say it's fixed, when it isn't.
I have been trying to overcome this problem for more than six months, but nothing is working. For example, on the Atomrc Dolphin plane, I managed to pick up a propeller group in such a way that this is the best thing I've had in the last ten years. There are no vibrations, with a cruise current of 3-6 A, the plane flies almost soundlessly. Even my friend noted it, which turned out very well. Even flying slowly without sudden maneuvers, the horizon is floating away. I'm disappointed that I can't fly planes right now because of INAV issues. Does everyone really like it?
It's certainly unpredictable how this happens. I have an AR flying wing that struggled to RTH some time back, roll had drifted 40 degrees so it couldn't turn back toward home without hitting what it thought was level when in fact it was still rolled away from the turn to home. Eventually the drift reduced enough to allow it to snake its way back. This was flying with a lighter battery pack than the one it has now which seemed to caused bad pitch "nodding" even though the CG seemed OK, probably also a poor PID tune didn't help. At times you could see the horizon drift up in sync with each nod when it was at its worst, I guess due to the G each nod induced.
After changing the battery pack to something heavier and improving the tune the nodding pretty much disappeared and using ACC ignore reduced the drift to the point it isn't really a problem any more. I flew the same wing last night in fact and it detected landing within a few seconds which. given the way the landing detector works, means there was little drift. If there is drift the landing detector takes 10+ seconds to trigger because FC roll and pitch continue to change as the drift resets once the plane is stationary on the ground, making the detector think the plane is still flying.
I get the impression people have given up trying to fix the drift issue. Is this because of fundamental issues with INAV's IMU design or simply because nobody is smart enough to work out how to fix it ? Ardupilot doesn't seem to have the same issue (or certainly it's nowhere near as bad) so given it's generally using the same hardware there must be a firmware solution surely ?
I started using INAV from the first release. There were no problems with the horizon at the beginning, until a certain moment (release). I don't remember exactly, but somewhere in the second branch, a similar problem with horizon drift began, which was surprisingly quickly fixed. And starting from version 2.6, everything was broken again. People, let 's fix this misunderstanding! After all, this problem pushes the community away from the project. A meme has already appeared on how to quickly get rid of the INAV horizon drift in five minutes, go to Ardupilot. After all, this is a fundamental function. Because of the drift, I have already crashed two planes, when the RTH is triggered!
I understand that everyone doesn't care about this problem? Is it really necessary to switch to the wretched Ardupilot...
I don't think people doesn't care ... I think it's more the thing that nobody has a good idea to solve it in the current constellation/development! I can't do it ... but I assume you can't neither!
It would be wonderful if somebody took care about it and moves this issue out of the way FOR GOOD! ... And if it is as @breadoven assumes, that the design of INAV not offers any easy solution, then there must be a redesign. That happens all the time (here) although it's more the smaller things. But perhaps its time to rethink the old patterns ...
Anybody up for this task? That would need somebody like Konstantin back then, who said: "I think I can do this!" ...
Well, since no one can solve this problem, I understand that they don't want to. I have a plan: roll back to the release of five years ago where everything worked, cut out all the wrappers and focus on the fundamental functions of INAV on which it was based. If this is not done, then INAV is dead.
@a6j I really don't think either if those things are true. Rolling back 5 years of work is really not going to happen. I'm sure that one of the first things to have happened when this issue was first discussed is that the difference between a "working" version and 1.7 would have been investigated. So rolling back is not the answer.
Also, if after 5 years of having this issue, it will not kill iNav. It does need to be solved, but it is complex, and you are being melodramatic. If your plane is unflyable, as you have previously stated. I'm betting that there are excessive vibrations and electrical noise in the build. That is how large drifts occur. Smaller drifts from slow, constant turning etc, can be tuned out with the imu acc ignore parameters.
I think @breadoven hit the nail on the head with "because nobody is smart enough to work out how to fix it". And that is not saying that people working on iNav aren't very smart. It says more to the complexity of the equations involved, understanding of flight dynamics, fusion, and how iNav currently is coded.
Dude, are you inattentively reading my messages or my English is really bad? In previous messages, I emphasized and specifically pointed out that the plane does not have vibrations at all! I understand that all developers are looking for an excuse for their mistakes. You confirm once again that INAV is dead. I can program, but in other languages in which INAV is built.
You need to understand quaternion theory and all that nice IMU stuff and then program it. But understanding the quaternion stuff in itself probably requires more time and effort than most people are prepared to give up for free.
And isn't the big problem with Ardupilot related to the fact it simply won't fit on many boards due to its size, even after it's been split up into different craft types.
... dead? ... nah ... not at all! @MrD-RC did pretty much hit it !
Yet, if INAV doesn't suit your needs anymore then Ardu is surely not a bad choice.
The problem here will remain until somebody will have a solution and the knowledge + time - thats how open source works, I guess!
But stating INAV to have died is a strange idea !
Five years! Five years! And no result! Yes, INAV is dead in absentia, if nothing changes.