This is the params exported from the Flight Controller…
Scratch that one. Tower has an issue exporting params sometimes. I’ll export from QGroundControl and upload it.
QGroundControl has some extra fields in the params file, but it still should be readable by any text editor. And interestingly it identifies the vehicle type as a multi-rotor instead of a heli frame in the comments header: https://drive.google.com/open?id=0B5oLpNzxih4tbWhBbEY3VmxxTzA
Paul, I read thru the review on that PR. And it was merged into master (3.6-dev). But did it actually get into 3.5 backports? I checked out the 3.5 branch and I don’t see in there for 3.5.3.
OK, my mistake. I saw the Copter 3.5.3 release commit in master and assumed that was the same as AC3.5.3 release. It isn’t. The AC3.5.3 release is in a separate branch and does not contain https://github.com/ArduPilot/ardupilot/pull/6288.
The log data is consistent with an EKF origin that is slowly changing through flight to be consistent with the GPS. The EKF height is tracking the baro correctly and the local vertical position is tracking the control system demand. Both are trending down in height, but the average GPS height remains constant through the mission.
Thanks for taking a look, Paul. At least it’s been addressed and just a matter of getting the fix into the mainstream release.
At first I thought it wasn’t using the baro. But I did notice the baro tracking the vertical position (DAlt) and that’s what raised an alarm that it was an EKF issue related to the height at arming. And that height remaining consistent with the GPS while the control system went down. That’s why the heli was actually at ~1.5 meters at the final waypoint - the control system (DAlt) said it should be there. What I didn’t know was why. Now, after reading the PR thru I have a better understanding of it.
Yes, the EKF uses local NED coordinates internally and publishes a local position and an WGS-84 origin taken from GPS. The navigation code converts that information back to global coordinates. The EKF2 in 3.5.3 is slowly adjusting the published height of it’s origin to be consistent with the GPS and while that may give the most accurate WGS-84 estimate output, it is incompatible with how the data is being used by the control loops.
If a relative height to takeoff location is required, then the origin height at takeoff should be used throughout flight when converting from EKF to nav coordinates.
This issue was debated at length and in the end https://github.com/ArduPilot/ardupilot/pull/6288 was added to give flexibility in dealing with Baro vs GPs drift in a way that met the requirements of the different applications.
For example for long duration missions , Baro drift can be a bigger problem than GPS drift.
This is a crazy parallel, but I mentioned this issue to an avid aviation buff and he said it sounds like the same symptoms the Airbus 380s had on auto pilot. Gradually lost altitude over 200 miles or something like that.
I found that totally bizarre.
Full size aircraft are a little different in that respect in that they all use barometric pressure with the altimeter set to 29.92 above FL180. And it is an encoding altimeter connected to the transponder to report altitude to ATC. Altitude hunting is usually the result of not having the gain set properly on the autopilot’s altitude hold function. Some variation is normal as long as IFR separation minimums are maintained. If they aren’t ATC is on the radio telling the pilots they’re a thousand low or whatever, and can they please break off their card game long enough to get the airplane back to cruising altitude.
I don’t know that I did any solving, just tested Paul’s EKF updates. For others that test it you’ll find a new param, EK2_OGN_HGT_MASK. It’s set to zero by default in my custom builds linked above. I don’t know what the default will be in the production releases for copter. But set to zero it uses the baro for the height origin. And it works really good. Flew two long (~40 minutes each) flights this afternoon with the custom build and it worked flawless. You can still get some baro drift but the worst I had today was 2 meters, which I consider perfectly acceptable, considering the length of my flights today. Even certified aircraft altimeters, set to the current barometric pressure reading at the airport aren’t normally closer than 10-15 feet.
Sure hope all the EKF updates make it into 3.5.4 because there was more than just this one in the updates included in the PR
Yes. it does, unfortunately. Paul’s updates are only in master, and not in 3.5. The only 3.5 firmware, at present, that has these updates in it is our helicopter-specific firmware.
I have flown those updates ~27 hours of flight time in the 3.5.3 build, flying Section survey’s at 60mph, and never had the problem re-occur. I don’t know why they never made it into 3.5.4. @rmackay9 might be able to answer that.
Just to clarify how things get into a release, one of the developers needs to put the item into the “Copter 3.x Backports” project. https://github.com/ArduPilot/ardupilot/projects/4. In particular there are two columns on the left called “PRs” and “Commits”. So under those column headers is where the commit or PR should be added.
So for example, there’s a “3.5.4” column there and I included all the items that people told me they wanted released. There are just too many changes going into master for me to keep track of them all. So if a developer thinks something is important, they’ve got to put it in the list.
Yeah, that’s kind of what I figured the deal is. We learned that as we were watching what was going into Copter-3.5 and our PR’s to master weren’t in there. We sort of had to hussle a bit and get those PR’s backported and in, or they wouldn’t be included in the next point release
