There are two major approaches: some basic functionality can be interfaced using the SI or primitive types (defined in the namespaces uavcan.si and uavcan.primitive). For example, one could command an array of ESC by publishing uavcan.primitive.array.Natural8, or one ESC by publishing, for example, uavcan.si.angular_velocity.Scalar. An ESC can report its status to the bus by either publishing separate SI messages, like uavcan.si.electric_current.Scalar, uavcan.si.angular_velocity.Scalar, etc, or by publishing a vendor-specific status message (or both, for extra compatibility).
A GNSS receiver node is unlikely to benefit from SI or primitive types due to the complex nature of the output; hence, it makes sense to use a vendor-specific message (possibly based on the legacy uavcan.equipment.gnss.Fix2), optionally providing some very minimal degree of service via SI/primitive types.
There currently are none of the vendor-specific messages you are inquiring about, but I intend to publish a GNSS fix message as a starting point and a reference for future contributions once we’ve finished with the v1.0 spec draft. As explained earlier, this message will not be included in the uavcan namespace; rather, it will likely be located under a different namespace named after a company (zubax), but the MIT license will permit its unconstrained reuse in third-party applications, obviously. The idea is that other vendors will be contributing their data types in a similar fashion under the MIT license. It obviously is also possible to define private data types for internal use; the details are explained in the specification draft.
You can find the draft here: http://new.uavcan.org/specification (this is a temporary location while we’re working on the new website); chapter 2 and section 5.2.6 should be of particular interest here.
Hope this helps!
