Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AP_DDS: Add support for NavSatFix publishing from AP #23277

Closed
Ryanf55 opened this issue Mar 22, 2023 · 4 comments
Closed

AP_DDS: Add support for NavSatFix publishing from AP #23277

Ryanf55 opened this issue Mar 22, 2023 · 4 comments

Comments

@Ryanf55
Copy link
Collaborator

Ryanf55 commented Mar 22, 2023

As part of the MVP API for DDS, one commonly used message is NavSatFix.

It is the lat-lon-altitude version of position in WGS-84 coordinate system, which is commonly used to publish GPS data (before fusion).

It can be consumed by visualization tools like Foxglove to show the vehicle on a map.

The publish rate should match the fix rate of the GPS sensor, and the timestamp should match the timestamp from the GPS receiver, not when it's published by DDS. This may require changes in the GPS code to add a callback. Be careful about adding circular dependencies in the code between AP_DDS and AP_GPS.

Tridge: In AP_GPS, look at last_update_time (uint32 ms). If timestamp is different, publish and update. Poll at 1Khz. It may be 5Hz, it may be at 10Hz. Timestamp comparison is cheap.

  • Complication: Some GPS produce data, but perhaps yaw may not be update (moving baseline RTK), which may be at a different timestamp. This can be ignored because we don't send yaw in NavSatFix.
  • Complication: Last message time vs last update time. Last message time whether for GPS device is still talking, last update time is last complete frame of state. Want the state update from last_fix_time_ms

Test this in SIM_GPS_* to test

  1. Losing lock, but still has signal (SIM_GPS_FAIL)
  2. GPS cable breaks (SIM_GPS_TYPE to different type)

GPS can set num_instances

Original intent of NavSatFix can be found here: https://wiki.ros.org/sensor_msgs/Reviews/2010-05-31%20GPS%20Proposal_API_Review?highlight=%28PackageReviewCategory%29

@Ryanf55
Copy link
Collaborator Author

Ryanf55 commented Apr 4, 2023

I'm hoping some additional fields can be added in time for ROS2 Iron.
See the request here: ros2/common_interfaces#219

If the changes are accepted, this means ArduPilot will have to figure out how to support multiple ROS 2 versions.

@russkel
Copy link
Contributor

russkel commented Apr 7, 2023

I always viewed NavSatFix as rawish sensor data more than an actual position output.
Similar to the way for orientation we use a Pose message with a Quaternion field, and not, say, a MagneticField (https://docs.ros2.org/foxy/api/sensor_msgs/msg/MagneticField.html) message.

As it's appropriate here, I'll mention the option of using the geographic_msgs GeoPoseStamped (https://github.com/ros-geographic-info/geographic_info/blob/ros2/geographic_msgs/msg/GeoPoseStamped.msg) type.

@Ryanf55 Ryanf55 changed the title AP_DDS: Add support for NavSatFix AP_DDS: Add support for NavSatFix publishing from AP Apr 13, 2023
@Ryanf55
Copy link
Collaborator Author

Ryanf55 commented Apr 18, 2023

publish GPS data (before fusion)

Yep, as mentioned in the issue publish GPS data (before fusion). It's the raw data from the first GPS. If you want data from AHRS, we can use GeoPoseStamped. Thanks!

@Ryanf55
Copy link
Collaborator Author

Ryanf55 commented May 5, 2023

Completed by #23533

@Ryanf55 Ryanf55 closed this as completed May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

2 participants