farhang
November 26, 2024, 5:18pm
1
PX4 Sync / Q&A: Nov 27, 2024Dronecode Calendar
Announcements
Release Discussion
Q&A
New Podcast Release:
1- Backports for Unicore GPS from @JulianOes .
2- ci: update actions and images by mrpollo · Pull Request #24039 · PX4/PX4-Autopilot · GitHub
@bresch would be good to have SIH fixed and maintainted@dagar as long as it is on CI, means it exists. It is recommended to move all SITL tests from Gazebo Classic (which is current) to new Gazebo.
1- @slgrobotics How important is to support RPi for PX4 builds?@dagar By default such support could be included.
2- @Rowan_Dempster Mag heading in 1.14 is not aligning to the real heading when setting EKF2_MAG_TYPE to Auto.
@dagar highly recommended to use v1.15 and on for mag since there had been major useful changes to how MAG Heading is fused.
1- boards: emlid_navio - support 64-bit OS on Raspberry Pi 4,5 by slgrobotics · Pull Request #24006 · PX4/PX4-Autopilot · GitHub
2- crsf_rc: add bind command by benjinne · Pull Request #23294 · PX4/PX4-Autopilot · GitHub
3- common.xml: EGM96 is geoid not ellipsoid by hamishwillee · Pull Request #2168 · mavlink/mavlink · GitHub
4- [Sponsored by ARK] Bidirectional DShot by dakejahl · Pull Request #23863 · PX4/PX4-Autopilot · GitHub
PX4:main ← PX4:pr-ekf2_gpos_rework
opened 01:56PM - 25 Oct 24 UTC
<!--
Thank you for your contribution!
Get early feedback through
- Dronec… ode Discord: https://discord.gg/dronecode
- PX4 Discuss: http://discuss.px4.io/
- opening a draft pr and sharing the link
-->
### Solved Problem
The current EKF evolves in a fixed local NED tangent-plane frame with an origin set at boot. This works well for short and moderate distances but degrades when flying over long distances (>100km) as the tangent frame gets significantly further from the ellipsoid surface.
### Solution
Mechanize the navigation equations using a local-navigation-frame which is NED-oriented and with its origin attached at the CG of the vehicle. The position state now defines the global position of the drone (geodetic Latitude-Longitude-Altitude) and the local position is constructed by projecting the global position using an arbitrary origin (initialized at boot or manually by the user).
The error-state is defined in a fixed local-navigation-frame to ignore all the -really small- pseudo-forces due to the frame rotation. This allows us to keep the covariance prediction really simple and unchanged from the previous local tangent frame approximation. The position uncertainty is also defined in the local NED which makes it more intuitive than latitude/longitude errors.
Note that the global position state is not directly included in the state vector from the derivation as lat/lon require double precision. The global position is stored in a new class `LatLonAlt` which contains operators to combine ellipsoidal position and Cartesian position errors (to compute position innovations and apply corrections).
When no latitude/longitude/altitude is available, the EKF assumes to be started at 0/0/0. This avoids having to handle multiple conditions everywhere in the code and the incorrect radii of curvatures is insignificant when navigating close to the starting location. It is then still possible to manually set the current position of the drone to automatically initialize the EKF at the correct location and continue dead-reckoning from there.
The position of the output predictor is considered as an error relative to the main (delayed-time EKF) and thus integrates the velocity and position directly on the Cartesian local-navigation-frame (origin at the LLA of the delayed-time EKF).
### Changelog Entry
For release notes:
```
TBD
New parameter: -
Documentation: -
```
### Alternatives
-
### Test coverage
-
### Context
-
