Hi
Im looking for some custom electronic in my plane.
I still hesitate between tcp/ip and a can bus for network communication between many devices (including barebone and linux)
After some seaching for a standard communication protocol I can upon uavcan and it seems ideal.
I already selected a couple of stm32 mcu (all with can functionality)
I did read the guide and im not sure to understand well all those services and messages definition (will I have them in the STM32?)
Am I correct to think UAVCAN is suitable for my project?
Thanks all
Broadly speaking, our goal is to make UAVCAN the technology of choice for any real-time intravehicular computing system, but as with any technology, there will always be edge cases where it just wouldn’t work. Not being aware of the specifics of your application it is hard to give you a definitive answer, but at least you’ve come to the right place to talk about it.
One reason why your application might not benefit from UAVCAN is that you mentioned TCP/IP in your OP post. Generally, TCP is the wrong choice of protocol for a real-time application or for a highly deterministic network, which implies that your application may have requirements that UAVCAN is not built for. Maybe you could elaborate a bit on your requirements, and we would see then whether the use of UAVCAN is advisable.
I would like you to note that there is no “Controller Area Network” in “UAVCAN”. The protocol is designed to be compatible with different underlying transports, where CAN is one of the available options. Although at this very moment the support for other transports is experimental, it is there nevertheless, so with necessary precautions one can commit to using, say, UAVCAN/UDP (since you mentioned IP) today and possibly influence the development of this transport as it matures together with the application leveraging it. This is how UAVCAN v1 came to be, anyway.
Data type definitions are the key part of the protocol, and the capabilities built around them make UAVCAN what it is. Using UAVCAN pretty much means using that, so the answer is yes. Generally, it boils down to the following:
Define the logic of your intravehicular system in terms of isolated services that interact using well-defined interfaces described in the DSDL language. The chapter “Interface Design Guidelines” that you referred to is exactly about this.
Automatically (or manually) generate code from these DSDL definitions using Nunavut.
Write your (embedded) application using the generated code and a library like Libcanard or maybe a third-party one like Canadensis or libuavesp.
Iterate as necessary until the business requirements are satisfied.
The description may seem vague, but that is sort of on purpose: the Guide is focused on the abstract matters, leaving the specifics to the implementation docs, such as PyUAVCAN or Libcanard. The best way to get started is to pick the language you are more familiar with, and read the documentation for the corresponding library. While following along, you should see most of your practical questions answered; even if not, we are here to help on this forum.
Hi
Thanks for the answer.
Currently my goal is to develop some custom avionic for a real experimental aircraft (currently a flying vans rv-7a, my father is building a sonex model A, and I might one day build a cozy mkvi). At this moment Im rebuilding a trim controller (I have done one in the past but im adding communication) but many module in an aircraft ECB, flap, AHRS and so on maybe even custom EFIS.
I did work a few year in electronic design so I know mostly on that side
Im not an expert software engineer but I know how to program microcontroller (never work with stm32 before mostly done 8bit, freescale/nxp, stm8, pic) and windows/linux. So I know C pretty well, im pretty confident with C++, I can work with python (still have to learn to use it effectively)
So you confirm my choice of going with can over tcp. Now I have to lean that DSDL language (where do I start?)
so im looking to use libcanard for stm32 right?
After a long road and some sleep I have some question to add.
From what I understand node doesn’t have address but message does. Lets say I have a new device called trim controller which has a 16bit output called position and 2 bool as input, I can define that in dsdl and program it to periodically send its pos data.
how do I know the bandwith usage im using sending a data and how to know the network load?
If I add another trim controller (since I could have many) how a device reading the pos know from which one the value is comming?
That’s not what I am saying, it was rather the opposite. Your trim controller is likely part of a real-time system interfaced over a network with predictable temporal properties where a highly stateful protocol like TCP is unlikely to be beneficial. If you are defining the interface yourself, which I understood is the case, then it certainly doesn’t make sense.
Correct. But observe that UAVCAN strongly advocates in favor of higher-level interfaces. Do not send some 16-bit values; send the information that they represent. For example, instead of a raw 16-bit ADC reading, communicate the quantity that it relates to; say, it is some angle, which is represented in radians, so in your case the 16-bit value becomes, say, a 32-bit floating point. The guide speaks about this at length.
When you define a message type, you add something like @extent 1024 * 8 at the end. The number is the maximum possible size of a serialized message (1024 bytes in this example). You multiply the maximum size by frequency by the number of publishers, you get the network load. Divide that by the maximum throughput of your transport, you get network utilization. While working on the DS-015 standard, we put together a spreadsheet for assessing the feasibility of our design for Classic CAN networks; you may find it useful:
You can easily adapt the spreadsheet for your transport.
You mentioned that messages have “addresses”, right? You were very close. These things are called not “addresses” but “subjects”, or actually “subject-IDs”. Your first trim controller would take a subject-ID, say, 6000, and the other one would be 6001. You choose the numbers arbitrarily but every component of your vehicular network needs to be configured correctly such that it is aware of which subject-IDs to use for which data.
