You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The MAVRos global position plugin supports a channel called global_position/compass_hdg.
In the docs, it calls this Compass heading in degrees. and populates the heading into a std_msgs/msg/Float64
This is not a compass heading. This is the vehicle's AHRS heading.
Just reading the docs, I would expect the heading from the primary compass, in either true heading or magnetic heading.
This plugin publishes neither.
I believe this is misleading, and either the implementation should change, or the docs should change.
In the event the vehicle's EKF diverges but the compass sensor still works, now the ROS algorithm you thought was using compass sensor heading is actually using a diverged state estimate from what the sensor is reporting. This interface also does not populate the uncertainty of the value, so if the EKF variances are high there is no way to know whether to trust this value. Overall, I am not sure why this message exists.
The text was updated successfully, but these errors were encountered:
The MAVRos global position plugin supports a channel called
global_position/compass_hdg
.In the docs, it calls this
Compass heading in degrees.
and populates the heading into astd_msgs/msg/Float64
It populated the data from GLOBAL_POSITION_INT.hdg.
This is not a compass heading. This is the vehicle's AHRS heading.
Just reading the docs, I would expect the heading from the primary compass, in either true heading or magnetic heading.
This plugin publishes neither.
I believe this is misleading, and either the implementation should change, or the docs should change.
In the event the vehicle's EKF diverges but the compass sensor still works, now the ROS algorithm you thought was using compass sensor heading is actually using a diverged state estimate from what the sensor is reporting. This interface also does not populate the uncertainty of the value, so if the EKF variances are high there is no way to know whether to trust this value. Overall, I am not sure why this message exists.
The text was updated successfully, but these errors were encountered: