inav
inav copied to clipboard
iNavFlight
iNav 1.7.3 FW maintains a turn even after sticks are released in Angle mode
Hey guys, I may have a possible problem on an iNav build, and would appreciate some info on the matter, as I did not get any answers in RCGroups, so decided to post here as well.
I recently flew a 3.5kg V-tail plane with an Omnibus F3 Pro on it, running latest iNav at the time I setup the board, it was 1.7.3. Did the V-tail mix from Painless360 and only had to reverse one aileron to make everything work and stabilize in the correct directions.
Had to switch off the pitch2thr mix as it was constantly nosing down the plane and trying to plant it in the ground, so if I may suggest something to the devs - make it so that this mix is switched off when a non-flying wing type of plane is selected, as it could cause all sorts of issues! Nearly crashed a few times because of it!
Anyway, having sorted a lot of the programming I got to relax and fly the plane for a bit to test it out, and noticed a weird behavior in Angle mode! My trims on the radio are 0'ed out, and I have adjusted the servo mid positions on the Servos tab in the GUI to allow level flight in passthru mode. When in Angle mode the plane flies straight and true if I don't touch anything, or if I make small changes in the course! However, when I do a long 180 degree turn using ailerons and rudder, and then let go of the sticks, the plane doesn't return to level, but keeps turning in that same direction, and I actually have to push the rudder and aileron sticks in the other direction a good deal and stay like this for a few seconds, and then when I let go of the sticks it would get to level again!
Any chance this is normal Angle mode behavior, which I somehow doubt, or is there something wrong somewhere in the code, or possibly with my plane?
Any insight into this would be much appreciated! Thanks in advance.
I also have such issue on all my planes. Would be great to know how to fix it.
This is a known issue and currently there's no way to fix it (I am working on it though).
@fiam yes. During a balanced turn acceleration vector is ~ equal to Gravity but is not pointing downwards which confuses the firmware into thinking that "banked is actually "level".
I don't get this, is that only on planes with a rudder ? I never noticed such behaviour but I only have flying wings with iNav. If it's also affecting planes with only elevons, I'm worried about the pilot (me) if I never noticed this, because I fly in angle mode a lot.
I don't get this, is that only on planes with a rudder ?
No, I have been experiencing this on my first and second flying wing with inav. I fly ACRO most of the time so I don't really care about ANGLE mode but it is annoying to have the plane drifting in ALTHOLD after doing a constant turn.
It depends on the setup and flying style actually. It's most evident if the turn is slow and long and the plane sinks a bit during the turn. I notice it on some setups and don't notice on others. If you accelerometer calibration is off it may also make things worse (or better). It's really complicated that's the main reason it's tricky to fix.
You can make the effect less severe by lowering imu_dcm_kp quite a bit. But bear in mind that it will also make the firmware take longer to recover from the effect.
I'd rather wait for a proper fix than mess with params I don't understand! :)
Is it know if this behaviour also occurs in RTH or the other auto modes?
I find this one puzzling, I've never noticed this horizon drift issue, I fly iNav on a large flying wing in angle mode, most of the time, maybe like 90%. I only switch to acro mode for few stunts and landings. I also have iNav on a small wing, mostly flown in acro mode, so it's unlikely I would notice an angle issue on this aircraft, but for sure she comes back in RTH mode really well. Next time I fly the large wing I'll make tests, what is worrying me is not the issue itself, but the fact that I never noticed it :) If it happen on this plane.
It's most evident if the turn is slow and long and the plane sinks a bit during the turn.
In such a condition the resulting absolute g-force can quite possibly be equal to standard gravity for the sensor itself while not pointing towards ground but towards the bottom of the banked plane.
This most likely results in a similar ACC sensor reading as in leveled flight. But there should be a difference in GYRO reading. In leveled flight, all gyro axes should read more or less zero deg/s while in a turn one or more gyro axes should read non-zero values. This fact might be helpful to rule out false interpretation of leveled state.
@Dronek actually this might work if we have a pitot sensor. Knowing airspeed and angular rates it would be fairly easy to calculate and cancel out the centrifugal acceleration. I need to give it a thought.
The ArduPlane firmware for certain does not suffer from this issue, and I have quite a few planes equipped with that, and none have a pitot tube! Since you calibrate the ACC once so it knows what is level, isn't it easier just to have that calibration stored as a constant, and to have it revert to that the moment you let go of the sticks?
isn't it easier just to have that calibration stored as a constant, and to have it revert to that the moment you let go of the sticks?
This could work in angle mode but autonomous modes would be still affected unless you substitute "let go of the sticks" by something else. In acro mode letting go of the sticks doesn't necessarily mean leveled flight, so there would be no mechanism to revert a slanted AHI back to normal unless doing a constant turn in the opposite direction (as it works now).
It's a good idea to compare with arduplane. I still have a gut feeling that "early" versions of iNav (like 1.4) didn't exhibit this issue but I could be wrong.
I was looking at this with original multiwii which had similar issues. I'm guessing the code is significantly different now but I had some degree of success. I was using change in MAG heading over time to create a value that varied the trust of gyro data vs acc data and length of validity of acc data. It didn't stop the drift when in turn as I had no compensation, but recovery was improved. I didn't appreciate at that time how much current was affecting the mag sensor. And I had significant variation from sensors being impacted by vibration. Some appeared really bad - the vibrations were increasing the perceived gravitational force in the turn. Lost interest as migrated to mainly fly acro but it's always bugged me. Mainly because OSD horizon accuracy stands out.
Agree - worth having a look at what other Open Source projects do.
Just to add... I've noticed this behaviour in pitch also. At some point I would let go of the stick and the plane would nose dive a bit, then I would compensate with the stick to keep it level, and all of a sudden it would start pitching up, and when I let go of the stick, it would be flying level again! Certainly need to leave enough battery for a few approaches on landings, as this is quite difficult with a plane that is pitching down and you need to compensate it, and I do like to land in the Angle mode, the plane I have this on lands super smooth in it! :)
@ArxangelRC you are getting it a bit wrong. Accelerometer measures acceleration not levelness. Acceleration is composed of gravity (which is constant and indicates level) and motion acceleration (speeding up, turning etc). Acceleration from motion can't be easily calculated.
APM is using GPS to attempt to compensate for this acceleration from motion. #1481 is an attempt to do something similar, but it's not working yet.
I really hope you fix it guys! ArduPlane has it solved and the planes are a dream to fly in FBWA mode! :)
I would have thought that the straight and level values would be a fixed reference, from pre flight calibration, as with non gps based stabilisers. No update of it in flight means no type of flight situation can alter that base value and therefore straight and level would always be that. Not professing anything here, just wondering why the S&L would be floating over any time period. Arxangel, one question, during the turn, does the AHI suddenly show level, during bank? I sometimes fly into clouds and in mountainous terrain so I must believe the AHI at all times during those IFR situations, I can see some bad outcomes otherwise.
Agree, I also encounter this issue almost every flight now. Now I know why the plane has always had this "slightly drunk" behavior. Never quite flying level after letting go of the sticks. Sometimes it's quite violent and needs full counter stick for a few seconds. When it's bad you can clearly see the artificial horizon crossing the real horizon by 20-45 degrees.
Wow, I might just stick with Vectors and Pitlab. Thanks for the update.
Sent on the go with Vodafone -------- Original message --------From: compuatic [email protected] Date: 22/11/17 4:37 am (GMT+10:00) To: iNavFlight/inav [email protected] Cc: Alasdairx [email protected], Comment [email protected] Subject: Re: [iNavFlight/inav] iNav 1.7.3 FW maintains a turn even after sticks are released in Angle mode (#2459) Agree, I also encounter this issue almost every flight now. Now I know why the plane has always had this "slightly drunk" behavior. Never quite flying level after letting go of the sticks. Sometimes it's quite violent and needs full counter stick for a few seconds. When it's bad you can clearly see the artificial horizon crossing the real horizon by 20-45 degrees.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/iNavFlight/inav","title":"iNavFlight/inav","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/iNavFlight/inav"}},"updates":{"snippets":[{"icon":"PERSON","message":"@compuatic in #2459: Agree, I also encounter this issue almost every flight now. Now I know why the plane has always had this "slightly drunk" behavior. Never quite flying level after letting go of the sticks. Sometimes it's quite violent and needs full counter stick for a few seconds. When it's bad you can clearly see the artificial horizon crossing the real horizon by 20-45 degrees."}],"action":{"name":"View Issue","url":"https://github.com/iNavFlight/inav/issues/2459#issuecomment-346103571"}}}
It would be interesting to see what RTH would do with the corrupted S&L value.. which bad data does it adhere to?
Is there a solution to this old horizon drift problem in sight? Sometimes it's almost impossible to fly in Horizon Mode... :-( 17.04.18: With Inav 1.7.3 (POSHOLD always + ALTHOLD)
Sometimes in addition to the drift ALTHOLD works very badly. Otherwise, ALTHOLD usually works better. 18.04.18 same model updated firmware: With Inav 1.9.0 (POSHOLD always + ALTHOLD)
Make sure you don't touch trims or sticks during heading hold, any value outside 1500ms will disable it.
On 24 Apr. 2018 1:46 am, "Dirk" [email protected] wrote:
Is there a solution to this old horizon drift problem in sight? Sometimes it's almost impossible to fly in Horizon Mode... :-( 17.04.18: With Inav 1.7.3 https://youtu.be/Zg_YElIAMsM (POSHOLD always + ALTHOLD)
Sometimes in addition to the drift ALTHOLD works very badly. Otherwise, ALTHOLD usually works better. 18.04.18 same model updated firmware: With Inav 1.9.0 https://youtu.be/fpWqB5Lpu_M (POSHOLD always + ALTHOLD)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/2459#issuecomment-383623270, or mute the thread https://github.com/notifications/unsubscribe-auth/AgMI6nmfIlEVHOr2yzT0NOQ-j3OBpaZXks5trfdUgaJpZM4QSSHg .
I'm pretty sure that this issue was almost unnoticeable in 1.6.1 version. Now I moved to 1.9 and I feel very uncomfortable with this issue. Now thinking about returning to 1.6.1
Hello, I guess it´s not just the artificial horizon that is affected. I guess it´s all axis. I think the artificial horizon is just where you can see it obviously first. When going nose down for more than a few seconds, the plane also tends to go to the ground, after the sticks are released to level flight. And vice versa. You can notice that behaviour in Horizon flightmode. I guess it´s always happening when the board wants to level the plane but "does not know" where level is. It seems always the latest flying position changes the zero position. After some time of counteracting manually in the opposite direction, it slowly drifts back. I don´t use ANGLE, I have this in Horizon mode.
I'm puzzled by the horizon drift issue. I looked at the INAV source code and it seems to me that the error is accumulating at the level of the wind estimate calculation functionality. I have a plane on Matek F411 controller. I constantly observe the deviation of the horizon - the problem of horizon drift. I want to help solve the problem. I am a software developer. To quickly dive into the subject area I need a developer who has experience with INAV source code, its debugging, testing. Together we are more likely to solve the problem. Who can I work with?
