Publish dual antenna attitude in "track" field of gpsfix message

[andreaeusebi]

Hi all,
We are using Septentrio receivers in dual antenna setup (we use both SB ProDirect and SBi3 Pro+).
We are used to subscribe to /gpsfix topic to get position, velocity and vehicle heading information.
In the configuration file I've set "multi_antenna" to true.
When the vehicle is in motion track is correctly published on the /gpsfix topic, however when the vehicle is standstill track seems to be no more available and the value is set to something like "-200000000000" (I think it is the default value to inform the user that the data is not available).
However, in the "/atteuler" topic the "heading" field is always available (both when the vehicle is in motion and when stanstill). I think that it would be more logic to always supply "track" in /gpfix too since that data is de facto available.
I'm not totally sure if track and heading are retrieved in the same way internally (from what I've seen, track is computed using Course Over Ground, while heading exploiting the presence of the 2 antennas); however I think that heading/track should always be published in the gpsfix topic since the receiver has that information at any time when running in dual antenna setup.
Please let me know what do you think.

[thomasemter]

Hi there,

I must admit that I am not very familiar with the GPSFix message and this was implemented before I joined driver development. Looking at the code for GNSS, track is indeed calculated from course over ground which in my eyes makes sense as it is not under the section # Device orientation (units in degrees) and track is interpreted as direction of travel which must not coincide with the heading, e.g. for a UAV flying sideways.
I am not sure if it would make sense to fill track with heading as you would lose information on the direction of travel and would not have any information in case of a single antenna receiver. I wonder why there is no heading field in the GPSFix message but instead there is a so-called dip angle?

[andreaeusebi]

Hi @thomasemter ,
thank you for your answer.

I agree with your intuition about the difference between COG and heading (I'm used to work with ground vehicles, for which this difference is much less evident than for aerial platforms). So probably it is okay to leave "track" field as COG.
However it remains opened the question about heading data. At the moment this information isn't provided in the "gpsfix" topic. I also noticed the presence of the "dip" field, I am not super familiar with geodetic/magnetic terminology, so I'm not going to formulate a specific proposal; however, do you think that that "dip" angle can be intended to be the heading of the system? If so, I think you could fill that field with the heading data reported in the "atteuler" topic.

Please let me know what you think about this.
Greetings.

[thomasemter]

We had a discussion and do not think that dip is intended to be the heading of the system. Nevertheless, we came to the conclusion that it is the best option to divert it from its intended meaning an populate it with the heading angle and err_dip with its uncertainty respectively. In this way, we don't lose the direction of motion and dip is somewhat ambiguous anyway. You may test it if you like: ROS 1 or ROS 2

Thank you for your feedback and suggestions.

[andreaeusebi]

Hi @thomasemter,
sorry for my late reply.
I'm very happy that you decided to integrate heading data inside the "/gpsfix" topic. I'm going to adapt my code to this new feature (I will be now able to subscribe to a single topic and get all data that I need :) ).
I've noticed that the changes that you committed on your forked repo have been merged on the branch "dev" of the original driver repo (link to the pull request here): so it should be enough that I switch my local original repo to the "dev" branch to get this new feature, am I right?
Thanks again for your kind support.

[thomasemter]

Hi @andreaeusebi ,

you are welcome :-)
Correct, the changes have been merged to the dev branch.