The framing logic of high-overhead transports like UDP is a little different from CAN; they use simpler and more robust transfer reassembly policies which are hard to generalize in a manner compatible with CAN, so I doubt that the idea of building a robust multi-transport implementation for embedded systems is feasible. My PyUAVCAN rewrite is multi-transport capable, but then again it’s ~20k LoC large and it’s not yet quite finished.
I think I should put together a brief post sometime soon to shed some light onto PyUAVCAN and implementations of alternative transports.
The UAVCAN team is currently working on a Survey with the goal to understand what type of adopting vendors are already in the ecosystem, we are hopefully going to capture feedback on v0, v1, and the migration path.
Question areas that the call attendees think we should implement:
CAN bootloader, and Security around that bootloader
Migration guide
Do you already have a v0 enabled product
Are you familiar with UAVCAN v1.0?
NXP presented their BMS design
NXP presented their UAVCAN conversion board
NXP is working on a Development Board reference design, that will be sold very low costs, this is a perfect entry point for devs into our project.
Ramón; I think we should Identify and list UAVCAN hardware that is already out there.
Project funding
The UAVCAN team has identified a developer that can assist in the integration of v1 with PX4 and project Yukon, the team will create a value proposition document and present to vendors.
The goal is to get funding to bring those projects to the finish line.
What’s the ask, how much money, what’s the benefit, what they are going to do
Pavel: Had a prominent discussion with the APM team on v1 adoption. They are ready for us to let them know when we are ready for them to implement.
Scott: Just writing unit-tests for C++ structure generation in Nunavut. Will have PR this week and then move on to generating (de)serialization logic in Nunavut. These types and (de)serializers are provided to libuavcan where I will consume in that project’s media layer.
Ramon: UAVCAN v1 Sponsorship Value Prop doc ETA Friday. Survey will be scheduled on the next Dronecode newsletter.
Survey (updated)
Core team covered the main topics, needs one last pass from @mrpollo. This is scheduled to appear on the latest Dronecode newsletter first week of December.
V1 Project Funding
Core team met over the weekend and defined the value-prop for supporting vendors, we are waiting for @mrpollo to give form to document.
Nunavut refactor to support .ini style configuration
Finishing serialization logic for CPP
C++ requirements for libuavcan are not set in stone but the following can be assumed at this point:
requires C++11
has minimal requirements from the standard library including:
standard integer types
type_traits, static_assert, and various compile-time utilities to support templates and TMP
std::unique_ptr (which does not require an allocator) but mostly this will be used internally for RAII patterns.
std::vector but don’t panic: we will provide allocators for this and any other STL construct we use that needs an allocator. These allocators will have O(1) complexity and will use statically (i.e. compile-time) allocated memory pools, however, the allocators will also be optional so you will be able to fall back to a heap-based allocator if you want. That said, so far we only plan on using std::vector with allocators.
RTTI will not be used. Since dynamic_casts will not be allowed within libuavcan compiling with this enabled should have no effect on its internal correctness.
exceptions will be optional (i.e. we will provide exception-safe logic but will also allow compiling with -fno-exceptions with no loss of functionality or correctness).
v1 will be header-only so you will not have to worry about the ABI.
