Why were the application specific datatypes removed in UAVCAN v1?

While the application specific message definitions were removed from the core specification v1 does not prohibit or even disown the concept of application specific messages. The messages in v0 were designed with px4 systems in mind and we are more than willing to work with that community to define a regulated, public set of datatypes that could be similar to the v0 definitions (if that is the outcome of the design process).

When starting the design of v1 we found that most of the v0 application functions sowed confusion in industries evaluating UAVCAN for use in non px4 systems. V1 clarifies that the core specification is complete and comprehensive without any predefined application functions while also building a process for communities, vendors, and private firms to define standard “profiles” that allow for interoperability and efficiency.


What is the process for defining application specific datatypes in UAVCAN v1?

We don’t yet have a lot of what is in our heads written down for how this process will work. This is because we’ve been building the new spec from the ground up and are just now getting to that part of the stack. We’re also resource constrained and have been moving our efforts into completing v1 versions of the reference implementations as we complete the v1 version of the core specification.

So…stay tuned. Details will follow.

1 Like

Should I use V0 or V1 at this time?

At this time we are in that most unenviable state for any technology where we’ve invested a significant amount of time in the design and are excited by what we’ve come up with but just aren’t quite there yet with the implementation. The simple reality is, if you must get something working within the next few months, v0 is your only option. If you can wait and work with us to get past this transitional time you will benefit from the lessons we’ve learned while implementing and deploying v0 and will avoid the pain of a future transition to v1.

We have been pushing people to use V1 with the hope that they will not just use it but will get actively involved in defining it for their specific systems. While there are no application specific types yet, the core v1 specification is far enough along that it should be safe to implement something against it.

I should also add that v1 comes out of a positive experience with v0. V0 is not fatally flawed in any manner and has proven to be useful in real systems but is, ultimately, a prototype we used to learn and improve. Had it been a disastrous experiment we would have yanked it wholesale from github. As it is we are willing to support it but, being an all volunteer open-source community, we very much want to devote our limited resources to completing and promoting v1.