Target_track_message

[TomasTwardzik]

Motivation:
This is a new message providing data from onboard detection systems on boats, that are considered to be valid objects, static or otherwise.

Structurally it follows the fields defined in TTM message of NMEA0183.

PR introduces new:

ENUMs:

• BEARING_TYPE - defined by NMEA0183
• COURSE_TYPE -defined by NMEA0183
• TARGET_TRACK_STATUS - defined by NMEA0183
• TARGET_TRACK_ACQUISITION_TYPE -defined by NMEA0183

MESSAGE:

• TARGET_TRACK - this is a individual hit of a detection system transfered from vehicle to GCS. GCS side may want to accumulate these hit to show them for the user. A staleout logic should be applied to hide old data.

FIXES:

• spelling

[KonradRudin]

Hey, can you give a bit more background why this specific message is needed, what is the intended use case?
Since this message is very closely related to the TARGET_ABSOLUT and TARGET_RELATIVE messages defined in the development.xml with additional CAS (collision avoidance system) data including time and distance to CPA. Would it be enough to just specify the additional CAS data in a separate message? There is even the COLLISION message, where you could simply add and src type

[KonradRudin]

Two things:

1. Why do you need to define here the course type again, as the option can mostly be the same as for the BEARING_TYPE. Can we just do one definition and call it i.e. NAVIGATION_ANGLE_TYPE?
2. As course in aviation you define the intended angle to your destination you want to reach. A such it is mostly defined in magnetic or true north reference. relative makes less sense there as this changes on the environmental conditions (wind). Also the relative course is less obvious when you talk about the targets course (is it relative to your own heading or the targets heading?)

[TomasTwardzik]

1. I agree, I will reward the BEARING_TYPE and COURSE_TYPE into one aggregated ENUM type. I will work that in.
2. The nomenclature is quite loaded between "course", "true course", "bearing" and "bearing to", yes and it perhaps slightly differs between maritime and aviation. This MAVLink has the naming scheme coming from the source protocol. "Course" is not the angle to destination with respect to North, but course over ground of the target target with respect to North, which accompanied by target speed defines target's planar motion.
   I think the point why there are the other options are based on what is available to the system producing TargetTrack NMEA0183 message. If you have no position, magnetometer compass measurement, you fallback to RELATIVE measurement type.

Also the relative course is less obvious when you talk about the targets course (is it relative to your own heading or the targets heading?)

I have same issue with the ambiguity, however the specs for NMEA0183 are not particularly verbose on the topic. I would want to put this out on water and capture data from the TTM provider to fully understand how it does things.

[TomasTwardzik]

This is fundamentally a translation of a Target Track message coming from NMEA0183 definition spec. It basically is a translation from Raw radar energy returns to "hey this might be something that is an object of interest".

Thank you for the suggestion of these messages, quite frankly I did not look for them. I will look into the use of those and see if they fit the bill and report back on my findings.

[TomasTwardzik]

Reviewing this, I agree that the contents strongly resembles TARGET_RELATIVE, however, this is one of the main data points for USV operators when looking for potential threats. From that perspective, I feel like presenting them the data in one individual message, would be beneficial.
Is this a substantial reason to introduce the message, or would you lean towards rewrite with TARGET_RELATIVE + CAS data? Because that alone creates new message type, but now you dont get all data at once.