There is open-source library implementing the CANaerospace protocol, targeted for microcontrollers and Linux. It is compact and easy to use in embedded systems with few amount of memory and limited processing power (such as most drone autopilots).
It is released under MIT license, so there is no problem if you want to link and distribute it along with your closed-source project.
The repository is here: https://bitbucket.org/pavel_kirienko/canaerospace
Examples, of course, also provided: https://bitbucket.org/pavel_kirienko/canaerospace_embedded_examples
The time of randomly mixed I2C, PPM and UARTs should be over.
The first reason is reliability.
CANaerospace allows the use of redundant CAN buses as well as redundant units. I.e. you can connect each device to the two CAN buses simultaneously, and if one bus fails other will keep going (so there is no single point of failure). In case of unit redundancy you can use two identical mission-critical devices, and if one device fails you'll simply switch to another and save the world.
Note that this library supports CAN bus redundancy in fully transparent way, i.e. your application simply will not care about how many buses are currently in use, and how many of them are dead.
To know a bit more about unit redundancy you can read the corresponding chapter in the CANaerospace specification.
2. Common standard
The second reason is the ability to come to the common standard to get a better interoperability between devices from different vendors. Consider the great ESC32 project (I'm not affiliated) - it has nice CAN interface, but lacks any software to work with it. Consider the discussions on OpenPilot forum for instance, where people are looking for a way to build a reliable bus for their system.
Yes, CAN bus will be a bit more expensive than usual interfaces, but it's worth it in most cases.
Currently just two platforms are supported out of the box, they are Linux (with SocketCAN) and STM32 (with embedded dual CAN controller). Since STM32 is so wildly popular in UAV systems, support for it does worth a lot I believe. If there is a demand I'm feeling ready to provide even AVR/Arduino support, despite the fact that using CAN on AVR is not a best idea I've had.
Anyway, if you lack support for your very own hardware, it is not a difficult task to write your own driver for it. Just refer to the examples.
If there are guys who are familiar with CANaerospace, they may be aware that standard NOD identifier distribution lacks support for some messages which may be extremely useful in UAV applications, such as:
- Camera control messages
- Messages to transfer the covariance data from IMU
- Messages for magnetometer readings
- Whatever else
Thus, I'm going to extend the standard ID distribution with these messages, to make this protocol more UAV-friendly. Feature requests are highly welcome.
Feel free to publish feature requests or whatever on the project page, and good luck with your work. :)