AP_ExternalAHRS: Add Advanced Navigation Driver Support #30057
+3,013
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit includes support for the Advanced Navigation devices using the [Advanced Navigation Packet Protocol](https://docs.advancednavigation.com/certus/ANPP/Advanced%20Nav igation%20Packet.htm). It replaces the earlier version of the driver which has now become stale (see [here](ArduPilot#23267)). The driver has had some major rework, fixing many critical bugs and refactoring for better readability. Core functionality of the driver remains the same and includes a SITL for development and testing purposes. The driver has been validated through numerous Certus Evo GNSS aided flights on an Aurelia X8 Standard copter. The feature also includes serveral modifications outside of the AP_ExternalAHRS library. These include: - The addition of yaw to AP_ExternalAHRS::gps_data_message_t message, allowing for dual antenna GNSS yaw to be passed from the ExternalAHRS library - The completion of the get_variance method to the AP_AHRS_External backend. Without this, the mandatory_gps_checks will always fail within the ArduCopter pre-arm checks.
This commit includes the following fixes: - Invalid index for packet request identifiers - Moved logging name convention from `ANx` to `ADx` due to conflicts with newly added logs - Added a `has_compass` method for handling devices that do not have magnetometers (i.e. Boreas series)
pbassett1996
changed the title
tridge
requested changes
May 14, 2025
| Location loc; | ||
| get_location(loc); | ||
|
|
||
| // @LoggerMessage: ANG |
| "QffffLLfffff", | ||
| AP_HAL::micros64(), | ||
| this->velocity_ned[0], this->velocity_ned[1], this->velocity_ned[2], | ||
| this->has_yaw() ? degrees(this->heading): 0.0f, |
There was a problem hiding this comment.
maybe NaN better when no yaw?
There was a problem hiding this comment.
also, is it yaw or heading? (ie. is it ground course or where the nose is pointing?) if it is yaw then call it yaw in the message
|
|
||
| https://docs.advancednavigation.com/certus/ANPP/PacketTimerPeriodPackets.htm | ||
| */ | ||
| struct PACKED AN_PacketTimerPeriod |
There was a problem hiding this comment.
this is naturally packed, I suspect the compiler will do better without PACKED
| if(pkt.has_yaw) | ||
| { | ||
| state.have_gps_yaw = true; | ||
| state.gps_yaw = pkt.yaw; |
There was a problem hiding this comment.
is this a yaw or a heading?
| uint16_t filter_status; | ||
| uint32_t unix_time_seconds; | ||
| uint32_t microseconds; | ||
| double llh[3]; // rad,rad,m |
| if ((AP_HAL::millis() - _last_pkt_ms) > AN_TIMEOUT) | ||
| { | ||
| static char buf[50]; | ||
| hal.util->snprintf(buf, 30, "AdNav: No Connection (last packet %8ums ago)", (unsigned int)(AP_HAL::millis() - _last_pkt_ms)); |
There was a problem hiding this comment.
this is not what get_name() is for, it should just be "AdNav"
| { | ||
| if (!send_airspeed_aiding()) | ||
| { | ||
| GCS_SEND_TEXT(MAV_SEVERITY_WARNING, "ExternalAHRS: Unable to send airspeed aiding."); |
There was a problem hiding this comment.
please review all GCS_SEND_TEXT() calls - this and several others could flood the telemetry link. eg. if airspeed went unhealthy then it would flood the link, possibly making control of the vehicle impossible
| { | ||
| const auto *acknowledge = reinterpret_cast<const AN_Acknowledge *>(&packet.payload); | ||
|
|
||
| GCS_SEND_TEXT(MAV_SEVERITY_INFO, |
|
|
||
| last_raw_gnss_packet.copy(&packet); | ||
|
|
||
| auto *raw_gnss = reinterpret_cast<AN_RawGnss *>(&packet.payload); |
There was a problem hiding this comment.
why the heavy use of casts instead of the more usual union structure?
| */ | ||
| struct PACKED AN_RequestPacket | ||
| { | ||
| AN_PacketId packet_id[(AN_PacketPayload::AN_MAXIMUM_PACKET_SIZE) / sizeof(uint8_t)]; |
There was a problem hiding this comment.
sizeof(uint8_t) just makes the code harder to read
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request includes support for the Advanced Navigation devices using the Advanced Navigation Packet
Protocol. It replaces the earlier version of the driver which has now become stale (see here).
The driver has had some major rework, fixing many critical bugs and refactoring for better readability. Core functionality of the driver remains the same and includes a SITL for development and testing purposes. The driver has been validated through numerous Certus Evo GNSS aided flights on an Aurelia X8 Standard copter.
The feature also includes several modifications outside of the AP_ExternalAHRS library. These include:
If desired, the additional modifications can be moved to a separate pull request.