inav
inav copied to clipboard
iNavFlight
New DCM AHRS
well... I've been working on it for at least 2 or 3 months, with the help of some friends like: @Jetrell, @b14ckyy and @MrD-RC. The intention is just to end the Drift of the current AHRS. So far, almost 90% of this is functional, but we still have some issues that need to be resolved, I'll list them below. This PR is being difficult for both parties, both for the developer, and also for those who will merge this in the future (if the problems are fixed, of course)....
-
[ ] 1 ~ There is a small drift in the AHRS, when we leave a maneuver in fixed-wing aircraft, but the GPS compensation manages to mitigate a good part of the drift (This may be related to the
change_limitvariable on line 938, since I spent days trying to fix this, but I couldn't). -
[ ] 2 ~ When the GPS is deactivated, the Drift increases even more (because the centrifugal force correction function stops working, see line 821 to 836).
If this short list of problems is solved, we will have a good AHRS in iNav... I can mention some benefits:
1 - The circles in Pos-Hold mode on fixed-wing aircraft were perfect... So far I can't believe what I saw... Overall, this AHRS improved the performance of the INS.
2 - If we are flying with Compass, a "consistency" check will always be checking if it is useful to use in flight, if not, the system automatically switches to the use of GPS (This has already been proposed in the past here in iNav, but it didn't go any further, because I don't think anyone put this in lines of code).
3 - Delayed acceleration vector to compensate for low GPS refresh rate.
4 - Gyro coning correction (https://scholarsmine.mst.edu/cgi/viewcontent.cgi?article=8915&context=masters_theses).
5 - During a launch acceleration, and reduce the Roll and Pitch gain by 50% to reduce the impact of GPS lag on takeoff attitude when using a catapult.
6 - We only have 3 configuration parameters for this AHRS... kP Acc, kP Mag and GPS Gain.
Anyone interested in helping me with this, please fork my branch,study the entire algorithm, not just the lines I mentioned above, it is necessary to understand how everything else works, so that no incorrect conclusion occurs... HITL mode using XPlane11 also helped a lot with the development of this!
About the Pos-Hold mode (Loiter or Circle, call it what you want)...
With iNav current AHRS:
With the New AHRS:
Myself and a few more pilots have flight tested a few builds of this new AHRS and with the last one we had fantastic results. I did tests in the HITL Simulation that turned out to be extremely accurate in representing real world scenarios. The Circle images are from a Waypoint mission I creatred to test and compare the stability of the AHI first in the HITL Simulation and then in the real world.
Here is the HITL Test of this mission, with some 25kph simulated wind from the west to east with 5.0 + latest mitigations and this 6.0 dev build: https://youtu.be/P3jcryn04Zw
Here is the exact same mission at the same location as in the Flight Simulator but as a real flight. This time I had very strong widns of 35kph with gusts up to 55kph from the north west. I used my AR Wing Pro for this test so it was a bit unfair as this is an extremely clean build that has barely any drift at all witht he current mitigations. Therefore not really representative for the average build. But it still shows how much better the INS and Navigation work witht he new AHRS. Here we also see one of the remaining issues. Everytime the plane turns downwind and accellerates rapidly relative to the ground, the AHI drifts downward with the new AHRS. The same happens later when I fly aerobatics, especially after loopings with strong accelleration during the dive, or in rolls when there are small but rapid directional changes. https://www.youtube.com/watch?v=5HlYgSKkSi0
Here are some more real world flights that show how reliable the new AHRS system works. Even with some drifting after aggressive maneuvers, it recovers very fast and makes any navigation mode very reliable. It would be good to get the Aerobatic drifts still fixed though.
https://youtu.be/3Rmt2MjHVd4 https://youtu.be/q3VlbGnlaNI
All these tests are wit the same Build.
That is bloody amazing @JulioCesarMatias I do have a question: was this tested on Multirotors too?
The only thing we have to do in this new AHRS is just make the centrifugal force correction part using GPS work correctly and, and the omega_sum part of the Integral term which is the drift estimation, I believe the problem is in the scale defined in the change_limit variable
I just want to give an update on this. Darren Lines, bonafidepirate, 3 other pilots of the community and myself, we have now cumulative around 20-25 flight hours with the last commit of this test build. Multiple planes like AR900, AR Pro, Esky Eagle, Dart 250G, AtomRC Seal 1.5m (with some vibration problems that ran Ardupilot before), AR 600, Nano Drak and a Harrier S1100. where tested with many different FCs. Not even counting the 10 hours of flight time in the simulator testing missions and behavior with different sensor setups.
No one reported any problem with it!
The 2 points that @JulioCesarMatias lists, fixing the AHI up/down drift after agressive pitch inputs and fixing the accelleration estimation with no GPS (maybe both the same fix at the end?) are the only things that should be corrected before a potential release. Just to satisfy all the aerobatic pilots out there who might complain because just for aerobatics the old AHRS with mitigations was more solid.
########################
Maybe a temporary fix could be to bring back the ignore_rate mitigations, just with much higher threshold values than before, to freeze the accellerometer during very aggressive maneuvers (Especially for non-GPS setups this might be a option). the accelleration compensation can do the rest for everything alse as it does that already perfect. What do you guys think?
I just want to give an update on this.
Darren Lines, bonafidepirate, 3 other pilots of the community and myself, we have now cumulative around 20-25 flight hours with the last commit of this test build. Multiple planes like AR900, AR Pro, Esky Eagle, Dart 250G, AtomRC Seal 1.5m (with some vibration problems that ran Ardupilot before), AR 600, Nano Drak and a Harrier S1100. where tested with many different FCs. Not even counting the 10 hours of flight time in the simulator testing missions and behavior with different sensor setups.
No one reported any problem with it!
The 2 points that @JulioCesarMatias lists, fixing the AHI up/down drift after agressive pitch inputs and fixing the accelleration estimation with no GPS (maybe both the same fix at the end?) are the only things that should be corrected before a potential release. Just to satisfy all the aerobatic pilots out there who might complain because just for aerobatics the old AHRS with mitigations was more solid.
########################
Maybe a temporary fix could be to bring back the ignore_rate mitigations, just with much higher threshold values than before, to freeze the accellerometer during very aggressive maneuvers (Especially for non-GPS setups this might be a option). the accelleration compensation can do the rest for everything alse as it does that already perfect. What do you guys think?
Not! I will not add old iNav parts here!
I just want to give an update on this.
Darren Lines, bonafidepirate, 3 other pilots of the community and myself, we have now cumulative around 20-25 flight hours with the last commit of this test build. Multiple planes like AR900, AR Pro, Esky Eagle, Dart 250G, AtomRC Seal 1.5m (with some vibration problems that ran Ardupilot before), AR 600, Nano Drak and a Harrier S1100. where tested with many different FCs. Not even counting the 10 hours of flight time in the simulator testing missions and behavior with different sensor setups.
No one reported any problem with it!
The 2 points that @JulioCesarMatias lists, fixing the AHI up/down drift after agressive pitch inputs and fixing the accelleration estimation with no GPS (maybe both the same fix at the end?) are the only things that should be corrected before a potential release. Just to satisfy all the aerobatic pilots out there who might complain because just for aerobatics the old AHRS with mitigations was more solid.
########################
Maybe a temporary fix could be to bring back the ignore_rate mitigations, just with much higher threshold values than before, to freeze the accellerometer during very aggressive maneuvers (Especially for non-GPS setups this might be a option). the accelleration compensation can do the rest for everything alse as it does that already perfect. What do you guys think?
And the two corrections you mentioned, they are not the same!
I just want to give an update on this. Darren Lines, bonafidepirate, 3 other pilots of the community and myself, we have now cumulative around 20-25 flight hours with the last commit of this test build. Multiple planes like AR900, AR Pro, Esky Eagle, Dart 250G, AtomRC Seal 1.5m (with some vibration problems that ran Ardupilot before), AR 600, Nano Drak and a Harrier S1100. where tested with many different FCs. Not even counting the 10 hours of flight time in the simulator testing missions and behavior with different sensor setups.
No one reported any problem with it!
Awesome work on this PR including all the testing that is been done. @b14ckyy Will you also thoroughly test PR #8403 to see which comes out as best?
to see which comes out as best
This is not a competition! "to see which comes out as best". From my point of view, this new AHRS has a lot of improvements that the old one doesn't have.
What's the point of making the centrifugal correction using the GPS work, if when you don't have a GPS, the Drift will still be there?? Tell me?
to see which comes out as best
This is not a competition! "to see which comes out as best". From my point of view, this new AHRS has a lot of improvements that the old one doesn't have.
No one is competing, it was just a coincidence that both PR's were open at the same time (although I don't want to open this one now)... Both are totally different.
What's the point of making the centrifugal correction using the GPS work, if when you don't have a GPS, the Drift will still be there?? Tell me?
the other PR uses still the ignore_rate mitigations if no GPS is available. If course it is not a perfect solution but doable.
Anyway. I see no reason why you should not have opened this PR. We know that some last things are to fix and you need some help. Without the PR no one would be able to help. Let's wait till @digitalentity has time to look at it. #####################
One more update in case this helps solving issues. Marcin did another test flight with the seal today. Drift was only there if excessive or continuous Z-Accelleration is applied like a spiral climb in cruise mode or during autotune on Pitch.
But one more thing that is more noticeable on his plane is the heading randomly doing correction jumps. Check the numerical heading at the following times: 1:31 - 2:53 - 4:42 (maybe more but i did not frame by frame chat the whole flight.
It is not really noticeable in Angle mode of course but in nav modes this can cause sudden course changes. Keith also saw it on one mission flight when a waypoint was not properly approached and then a sudden course correction appeared and I saw the same in my 5.1 comparison flight here when approaching WP4
I have not taken it serously before but in this flight it was more obvious to see the connection.
Here is the full video of Marcins flight: https://youtu.be/ZOygg6xUMrE
Hey, great stuff we have here!
I would still suggest to have ignore_rate in place for no-GPS aircrafts. It's not perfect, but it does the job to some extent. Obviously, the code should also be tested on copters.
I would still suggest to have
ignore_ratein place for no-GPS aircrafts.
I don't agree with that!
Let's try it first in the current state. I am maybe able to do a real no-gps flight tomorrow after work (late shift today so it might be too dark when I arrive at the field). If not then on the weekend.
for GPS enabled flights on wings in my opinion the remaining possible drift on certain maneuvers is not even a showstopper. The only big issue I see with gps assisted flights is the heading currently. that sometimes is off by too much. Looking closer over recent flight tests (also my own) show that this can be an issue for WP missions as well as RTH. I have seen heading jumps of 30° but also up to 70° while flying a straight line in cruise mode. Also can be seen here in this WP mission when the plane tries to fly from WP4 to WP5 but starts completely off course.
I'll have a look at my past flights and upload logs if needed.
I would still suggest to have
ignore_ratein place for no-GPS aircrafts.I don't agree with that!
Why not, just because it's old code?
What I see from the flight footage is that your code works really well.
Only issue is when you do acrobatic flight.
ignore_rate with a high value might be a good solution for now to get the PR merged.
After that, polish it to perfection and remove the ignore_rate when done.
You might consider it temporarily...
instead of you thinking about using the old AHRS parts, I recommend you to take a paper and pencil and help me correct the current AHRS math! If I didn't add the functions "ignore_rate" and "ignore_sloope" it's because I know that this new AHRS works without these functions! And merge this to fix this in the future? No, that doesn't make sense, it's totally wrong.
Guys let's calm down a little bit. I agree with Julio, that if the AHRS can work without ignore rate (even on quads and with no GPS present) then we should avoid to bring it back in. If the AHRS is fully functional as it is on Ardupilot and Aerobatic pilots are not satisfied enough at the end, THEN we can think about this as a edge case option just for these pilots as it worked well for this kind of flying.
The only problem that I see at the end is, that the ignore rate workaround is depending on very clean setups and high gyro precision and that can cause new issues for these.
But as long as GPS is available and we have the speed and heading working, there is no point in adding back the ignore rates.
btw @0crap it is not just acrobatic flying causing still drift. When I do autotune and pitch up and down in waves I would not consider this acrobatic and here is the biggest impact visible with the most amount of drift. Also when it is very windy and the plane turns from upwind into downwind, this sudden accelleration causes a noticeable down drift of the AHI for a moment. This happens in navigation modes and can't be fixed with ignore_rate. Adn these are currently the major issues (for fixed wings) that have to be fixed for GPS available flights. Soem more stuff on quads needs to be done as well.
... . When I do autotune and pitch up and down in waves I would not consider this acrobatic and here is the biggest impact visible with the most amount of drift. ...
True, seen that on your vid. Weird indeed. Thx for explaining.
Also, overcoming the remaining issues by the easier path of ignore_slope, won't help to overcome the Multi-rotor braking runaway issue in Poshold.
This has been a considerable problem for years. And freaks you out if you're not expecting it.
This temporary runaway occurs if a quad experiences specific G forces acting on the accelerometer as it slows, and begins to tilt back in the braking phase... Hopefully, being able to mitigate this X axis conflicting data while braking, should help alleviate this problem.
well... sorry for the earlier message! But, I think we should pay attention to the function that is activated through the variable "should_correct_centrifugal", and also give a review on the fusion of the NED (3D) speed of the GPS in the AHRS.
just a quick test flight today with the Dart 250g. It flew very bad becasue I had messed up the first launch and the Hatch cover flew off and broke off the tabs. So I had to fly with an open fuselage xD This time no GPS and no Compass. Just plain Gyro, acc and baro available.
https://www.youtube.com/watch?v=9In1nxRDOjQ
https://drive.google.com/file/d/0B9rLLz1XQKmaZTlQdV81QjNoZTA/view?resourcekey=0-tMmw1tSCJzcthOHDaPqdyA
no solutions here! Let's pay attention to >> https://github.com/iNavFlight/inav/pull/8403