Open source CANaerospace library for UAV

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. :)

Views: 5487

Comment by Pavel Kirienko on January 10, 2013 at 5:28am

Sorry for the late reply guys.

The specified connectors are quite large + heavy.

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.

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?

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.

If one device on the CANaerospace buss goes fails and goes mental, could it hijack the data buss?

As Andrew said again, no. There is also protection against so called "babbling idiots".

Comment by Pavel Kirienko on January 10, 2013 at 6:28am

Quick fix: I didn't want to say that the redundancy support is main feature; rather it is just important feature. :)

Comment by Andrew Dunlop on January 10, 2013 at 7:12am

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.

Comment by Pavel Kirienko on January 10, 2013 at 7:32am

It is hard to disagree. But remember that single-CAN microcontroller has poor compatibility with the bus redundancy concept.

Comment by Uwe G. on June 17, 2014 at 5:43am

Could please someone explain me why ATMEL MCU's and CANaerospace is not a best idea?

Comment by Pavel Kirienko on June 17, 2014 at 9:51am

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.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service