Good day everyone.
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
Why CANaerospace
The time of randomly mixed I2C, PPM and UARTs should be over.
1. Reliability
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.
Supported hardware
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.
UAV-specific features
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.
Conclusion
Feel free to publish feature requests or whatever on the project page, and good luck with your work. :)
Comments
Uwe, from the technical standpoint there is nothing wrong in AVR + CAN(aerospace). However, CAN-enabled AVR MCUs are more expensive than some other MCUs of comparable performance (e.g. NXP LPC11xxx, especially NXP LPC11Cxx with built-in CAN driver, or STM32F10x series, etc). Also there is no option for 2x CAN per chip (unless you're using external CAN controllers) which may be desirable for some applications.
Could please someone explain me why ATMEL MCU's and CANaerospace is not a best idea?
It is hard to disagree. But remember that single-CAN microcontroller has poor compatibility with the bus redundancy concept.
I would like to add that CAN implemented on an AVR is not too bad - I've implemented two different CAN protocols on an AVR and it was fine (neither was CANaerospace unfortunately). The only caveat is that you absolutely must choose an AVR that has CAN hardware, and you must use a precision frequency source (i.e. a crystal). Rolling your own software CAN implementation is a recipe for disaster.
Quick fix: I didn't want to say that the redundancy support is main feature; rather it is just important feature. :)
Sorry for the late reply guys.
Yes, suggested connectors are hardly applicable for small UAVs, I totally agree. However, I can't see why can't we use something else. I personally like MicroFit (or CP35) rather than LEMO or picoblades, because MicroFit is compact and looks reliable since it has the latch.
As Andrew said, we should use T-connectors. Also, keep in mind that the main feature of reliable buses in general and CANaerospace in particular is support for redundant media.
As Andrew said again, no. There is also protection against so called "babbling idiots".
I was going to use picoblade connectors for CAN. I like them for internal stuff.
Alternatively the good old RJ11 telephone plug is pretty nice for external quick release connectors.
Re connectors: I agree that smaller connectors are highly desirable for small aircraft. CAN architecture means that systems are vulnerable to connector failure - even a single connector failure will take out the bus, or part thereof - so I don't think this is the place to skimp on quality. Ideally a prefabricated T-piece would be the best solution, but the last time I looked these were prohibitively large. The alternative is to put a pair of connectors on every device. Little LEMOs would certainly be reliable, but no doubt there are other contenders that may be suitable or possibly even better.
Re a single CAN device going mental: My understanding of CAN is that a single device cannot hijack the bus, even if it goes nuts. This is one of CAN's great virtues - fault confinement. Unlike I2C...
This is quite interesting. I followed the links to the protocol & the specifications..
I've only skimmed through the documents, so far, but some thoughts / questions come to mind.
The specified connectors are quite large + heavy.
Just how small, physically, could this type of system be if each device (sensor or actuator) had two buss connections. Even the smaller D-Sub 9-pin connector with, back-shell, has many times the volume of the GPS modules we use.
What sort of smaller+lighter "standardized" connectors might one use? (LEMOs?)
The connection topology is sort of like a daisy-chain,physically. If less robust connectors are used to save on weight & space, is there a chance that a faulty connector could short out one buss?
If one device on the CANaerospace buss goes fails and goes mental, could it hijack the data buss?
The various sensors offerings such as GPS, airspeed, volts/current, sonar are constantly evolving.
For DIY practicality some sort CANaerospace adapter needs to be incorporated or connected to each of these devices.... serial=>CANaerospace, analog=>CANaerospace, as I would imagine that the currently available off the shelf sensors that implement CANaerospace are big, heavy, and pricey. :(
Future versions of these sensors from 3DR or Sparkfun could have CANaerospace controllers, but in the nearer future we'd have to cobble these together.
I hope this doesn't seem all negative, it's food for thought & I'm just trying to visualize how all this would come together in terms of the kind of aircraft that are used here for amateur UAV .
Yes, you're absolutely right about IDs, I mentioned exactly the number of Node IDs, not physical nodes.
About extended identifiers: they are actually used for Redundancy Channel IDs, take a look at the chapter 7 of specification.
-
1
-
2
of 2 Next