Proposed Changes to UAVCAN's High-Level Architecture

[Scott Dixon]

I'd like to propose some changes to the high-level architecture for UAVCAN to make it more modular and allow for different types of UAVs to utilize it. The modifications will introduce the following new concepts:

• Specification Levels – Pre-defined integration points to define and promote more modularity in UAVCAN implementations.
• Profiles and Standard Profiles – Sets of pre-defined messages/data-types specific to various types of Unmanned Autonomous Vehicles.
• aero - Existing non-protocol data-types would live in this set.
• marine/sub-marine – data-types for autonomous boats or submarines.
• space – data-types for satellites and other space-craft.
• hyper-space - For Faster-Than-Light autonomous vehicles (this is a joke ;-)
• ground - For autonomous rovers, cars, or other land-based vehicles.
• Core Data types – Profile-agnostic data types supporting standard functions. This provides the basis for generalized use of UAVCAN where all data-types are custom types.

Level 1

Integrating with UAVCAN at this level allows for resource constrained and/or simplistic systems to utilize UAVCAN's transport layer directly possibly to port an existing data serialization layer to CAN.

Level 2

Integrating with UAVCAN at this level allows for full use of the UAVCAN specification but with all custom data-types for vehicles that have different requirements that are not met by the pre-defined data profiles.

Profiles

• Profiles need not be completely defined in v1.0 of the standard. Instead we would start with just the aero profile containing the existing, non-core, types and develop other profiles as-needed.
  
• Profiles are also not meant to be anything more then a collection of data-types provided for organizational clarity. There is no hierarchy and types can exist in multiple profiles. 
  
• An implementation may combine profiles (e.g. amphibious vehicles would use ground+marine).
  

[Pavel Kirienko]

Thanks, Scott!

The general idea of "profiles" (which are really domain-specific namespaces - let's call them that instead for extra clarity) makes sense, I think.

However, I am against the idea of Level 1 because it seems to add fragmentation with no apparent benefit for the ecosystem. Unless I misunderstand your proposition, one who needs to tunnel third-party protocols over the CAN bus may just as easily use ISO-TP or the standard UAVCAN data types designed specifically for the tunneling purposes: https://github.com/UAVCAN/dsdl/tree/master/uavcan/tunnel

The presentation layer of UAVCAN does not add any noticeable overhead. Somebody built a Libcanard-based UAVCAN node on a 32K 8-bit AVR MCU (there was a discussion in the Libcanard repo), so given that and the previous point there doesn't seem to be a real need for Level 1.

I suggest we push back on domain-specific namespaces until the DSDL versioning system is in place (thanks Kjetil) and UAVCAN v1.0 is out (should be soon).

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/510f09ca-30d6-4c51-8128-71616ad714a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kjetil Kjeka]

I'm all for splitting up the dsdl definitions into domains. If i understand your proposal correctly it will also formalize the notion of  "core" data types like "NodeStatus" that is directly tied up to the uavcan specification and cannot be changed without breaking the protocol. This sounds like a great idea.

I'm currently helping a group at the university evaluate uavcan for a ground vehicle. They're primarily after the firmware upgrade features (I've actually started looking into kocherga), but if they're happy with the protocol they might adapt more of it. There is nothing really wrong with how it's currently laid out, but the ability to not opt-out "aero" definitions and use "ground" instead would make the protocol feel more streamlined thought-through for ground vehicles. Even if the only difference would be that the definitions existsted in a different namespace.

When it comes to the layer 1 seperation i don't see much use. I've implemented basic support for uavcan on an atmega64m1 (8bit AVR) which is one of the weakest MCUs that comes with a can controller i know of. Since only the `NodeStatus` message is required to support uavcan i don't see resource constrained devices as much of a reason to do so. The protocol and reference implementations are open sourced so if you still want to piggyback on the uavcan (de)framer this should not be too much work. On the other hand it would not be too much problem to implement in uavcan.rs so I'm not really against it, I just fail to see the advantages. Do you have a concrete case for wanting this, or just making things more general?

Anyway, I suggest we look at this after the DSDL versioning is in place (which is hopefully very soon) but before the release. I think it would help quick adoption of the new version if everything is sorted out and announced at the same time. I think most people would prefer to fix dsdl versioning, namespacing and protocol version at the same time instead of having to change things up three times.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/CAD6GmdA8Lm7zTc9VXMA4HGfkmj4TmpOXWuap1uJQ8_oFpwQ6ZQ%40mail.gmail.com.

[Scott Dixon]

Perhaps I should work on two proposals then. The idea of domain-specific namespaces seems uncontroversial. I can add a github issue to formalize just this part of the proposal. Once we have this defined in the specification individual projects like the gui_tool can add features to help users work with the domains. We'd also need to spend some time building at least one other domain (probably ground?) to prove out the reference implementations. It'd be great if we could find a project that would use the definitions so they can be field tested.

My "level 1" idea is perhaps a bit more nuanced. I'm thinking about integrations of UAVCAN that don't involve dsdl at all and am actually more interested in higher-level integrations than lower-level. Specifically I'm interested in how UAVCAN could integrate with other frameworks like ROS which have their own data serialization standards. If we provided requirements for this type of integration it would drive changes in implementations that could allow different serialization technologies to be swapped in.