Peter: Hamish was asking we switch to EGM96 in our Global altitude. Thomas: UBlox does an approximation of EGM96.
We don’t know exactly how it works. Ryan: We could do it onboard, but it wouldn’t fit in our FC, because of the conversion tables size. Andrew: What we could do in common is to have ellipsoid height instead. R: Our Terrain data is EGM96, this would be a conflict. Most likely. A: The database might actually not use the same datum across the globe. T: Some drivers report a mix of altitudes. Trible GSOF reports WGS84 as AMSL height. R: The conversion tables could live in an SD and use up 120M of space and 6k of flash. A: No, that’s not acceptable.
Could we try to do the conversions analytically? E.g. Ellipsoid to EGM96?
R: It’s not possible, it’s not a closed form solution. T: No it is, but the tables are still big. Not as big though. A: Okay, so we could have a separate terrain DB with ellipsoid heights, which the GCSs should support fetching.
These are one-off costs.
And perhaps add a new frame in the mission definition.
T: We could annotate this capability in the capabilities bit. A: This would incur a lot of work in multiple systems. - Aside: The use-case of predownloading the terrain data complicates the ability to switch between frames after the fact.
Hosting a duplicate terrain database would cost a few more $100/year.
In sum, changing the MAVLink reference document to report EGM96 would likely be a lie.
R: Could we still theoretically support two datums? MAVLink-wide? A: We could use the compatibility bits, we still have some spare. But it’s still tricky. R: The issue is still present, when we try to link up different autopilots, with different datums, across a MAVLink network. A: The shortest path to compatibility would be for ArduPilot to use ellipsoid (and have a local conversion of the terrain database), and make sure your other systems can use this information. T: On our side we could even support some sort of MAV_CMD to do the switching. And a capability bit to let the GCS know. A: Re. this PR, if it went through, it would make us non-compliant. R: Then we’d better write a note somewhere that the returned altitude is undefined and for the user to verify. P: It would be nice if someone made a plan to get us through a clean transition from here to the desired capabilities. George: I know that at least one long-standing mapping user would prefer having a WGS84 datum. A: Ryan, can you do a test if your GPSs agree on the Ellipsoid height at least? Within 10cm or so. Don’t care about absolute height.
UTC0741
R: This is SITL-only, an attempt to add thermals for slope-soaring. Using the terrain data, using it to scale the wind. A: The home gradient calculation isn’t necessary for this application.
Add guards for this feature.
Consider if this can be enabled for SIH.
The overall idea is great!
R: Would it be OK to use external libraries in SITL to acquire an accurate/advanced thermal simulation capability? P: Sure, it’s not much different to how we use JSBSim. A: It could even be a MAVProxy module that feeds it back to the simulation.
Even a Lua script could try to do that. And even use it in a real vehicle if it’s useful!
In principle stock SITL should should only need the dev env install to run. But for non-stock runs, 3rd party options are welcome.
UTC0754
A: How come relaxing the pitch limits for TECS didn’t fix this? G: TECS is working in FlightStage::Takeoff during that time and in speedweight=2. We would need to switch to FlightStage::Normal. A: We could gradually transition from FlightStage::Takeoff to FlightStage::Normal by the end of the climb.
There’s an integer wrap bug issue.
How about we stop the scale-back, based on some climb rate (e.g. 1m/s?)
Alternatively we could just end the takeoff and continue with the flight.
G: I actually like that and prefer it. A: Make a note on the wiki.
Taper off works in 4.4.
G: Yeah, I think it’s 4.5 where it was broken.
UTC0819
A: Add an autotest with a large, one-off home alt change. And see if it behaves nicely.
Merged!
UTC0835
P: Let’s wait until Andy replies to the review comments.