Andy Piper
09c48d855f
terrain_srtm_alt is the terrain height above the EKF origin, positive up: AP_AHRS::writeTerrainAMSL() converts the AMSL height AP_Terrain supplies with alt_amsl_m - origin.alt, and the core stores it verbatim. pd is the vehicle's position.z, positive down. Height above ground is therefore (-pd) minus the terrain height, not the terrain height minus pd. The neighbouring terrainState expression is right because terrainState is itself a D coordinate, built as position.z + rngOnGnd, so the two branches of one variable were being differenced in opposite conventions. Where the AHRS and core origins coincide the old error is 2 x terrain_srtm_alt, so it is smallest where the origin sits at field elevation and grows with relief - and it moves the wrong way, reading high over ground that is above the origin. AP_AHRS subtracts the one public origin and hands the same figure to every core, which then differences it against its own position.z, so where a core's own origin altitude has moved - ekfGpsRefHgt drift, or lanes aligning against different receivers under EK3_AFFINITY - the corrected form still carries that difference. The trace here is complete only for the default EK3_OGN_HGT_MASK. A terrain height that disagrees with the datum still collapses the scale height to the on-ground range through the MAX, exactly as it does today. The old expression could go negative too - over ground that sits further below the origin than the vehicle sits above it - so this is pre-existing, and the sign fix moves which geometry triggers it rather than closing it. Falling back to terrainState there is the obvious repair and it does not work: the enclosing condition has already declared that state stale. Measured in SITL off the Kalaupapa cliffs, holding 60 m above an origin the ground falls to 160 m below, so the true height above ground reaches 220 m. GPS navigates, so flow is not fused into velocity and both builds fly the same trajectory; only the scale height differs. Across the traverse the logged flow innovation consistency ratio saturates its 255 ceiling - at least 2.55, so flow at that geometry is rejected outright - against a peak of 0 with this change. The raw innovation is deliberately not quoted: XKF5 logs it as an int16 scaled by 1000, and the old expression drives it past the wrap point, so the logged figure there is an aliased value rather than the real one.
ArduPilot Project
ArduPilot is the most advanced, full-featured, and reliable open source autopilot software available. It has been under development since 2010 by a diverse team of professional engineers, computer scientists, and community contributors. Our autopilot software is capable of controlling almost any vehicle system imaginable, from conventional airplanes, quad planes, multi-rotors, and helicopters to rovers, boats, balance bots, and even submarines. It is continually being expanded to provide support for new emerging vehicle types.
The ArduPilot project is made up of
User Support & Discussion Forums
-
Support Forum: https://discuss.ardupilot.org/
-
Community Site: https://ardupilot.org
Developer Information
-
Github repository: https://github.com/ArduPilot/ardupilot
-
Main developer wiki: https://ardupilot.org/dev/
-
Developer discussion: https://discuss.ardupilot.org
-
Developer chat: https://discord.com/channels/ardupilot
Top Contributors
- Flight code contributors
- Wiki contributors
- Most active support forum users
- Partners who contribute financially
How To Get Involved
-
The ArduPilot project is open source and we encourage participation and code contributions: guidelines for contributors to the ardupilot codebase
-
We have an active group of Beta Testers to help us improve our code: release procedures
-
Desired Enhancements and Bugs can be posted to the issues list.
-
Help other users with log analysis in the support forums
-
Improve the wiki and chat with other wiki editors on Discord #documentation
-
Contact the developers on one of the communication channels
License
The ArduPilot project is licensed under the GNU General Public License, version 3.
Maintainers
ArduPilot is comprised of several parts, vehicles and boards. The list below contains the people that regularly contribute to the project and are responsible for reviewing patches on their specific area.
- Andrew Tridgell:
- Vehicle: Plane, AntennaTracker
- Board: Pixhawk, Pixhawk2, PixRacer
- Francisco Ferreira:
- Bug Master
- Grant Morphett:
- Vehicle: Rover
- Willian Galvani:
- Vehicle: Sub
- Board: Navigator
- Michael du Breuil:
- Subsystem: Batteries
- Subsystem: GPS
- Subsystem: Scripting
- Peter Barker:
- Subsystem: DataFlash, Tools
- Randy Mackay:
- Vehicle: Copter, Rover, AntennaTracker
- Siddharth Purohit:
- Subsystem: CAN, Compass
- Board: Cube*
- Tom Pittenger:
- Vehicle: Plane
- Bill Geyer:
- Vehicle: TradHeli
- Emile Castelnuovo:
- Board: VRBrain
- Georgii Staroselskii:
- Board: NavIO
- Gustavo José de Sousa:
- Subsystem: Build system
- Julien Beraud:
- Board: Bebop & Bebop 2
- Leonard Hall:
- Subsystem: Copter attitude control and navigation
- Matt Lawrence:
- Vehicle: 3DR Solo & Solo based vehicles
- Matthias Badaire:
- Subsystem: FRSky
- Mirko Denecke:
- Board: BBBmini, BeagleBone Blue, PocketPilot
- Paul Riseborough:
- Subsystem: AP_NavEKF2
- Subsystem: AP_NavEKF3
- Víctor Mayoral Vilches:
- Board: PXF, Erle-Brain 2, PXFmini
- Amilcar Lucas:
- Subsystem: Marvelmind
- Samuel Tabor:
- Subsystem: Soaring/Gliding
- Henry Wurzburg:
- Subsystem: OSD
- Site: Wiki
- Peter Hall:
- Vehicle: Tailsitters
- Vehicle: Sailboat
- Subsystem: Scripting
- Andy Piper:
- Subsystem: Crossfire
- Subsystem: ESC
- Subsystem: OSD
- Subsystem: SmartAudio
- Alessandro Apostoli:
- Subsystem: Telemetry
- Subsystem: OSD
- Rishabh Singh:
- Subsystem: Avoidance/Proximity
- David Bussenschutt:
- Subsystem: ESP32,AP_HAL_ESP32
- Charles Villard:
- Subsystem: ESP32,AP_HAL_ESP32