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: 5447

Comment by Tilman Baumann on January 9, 2013 at 4:46am

That is pretty cool. I always wanted to use CAN, but always thought the official standards are too convoluted. But that looks pretty nice actually.

I hope I one day find time to integrate that into Paparazzi...

About the 310 ($136) Right aileron position message and the ones alike, do you think I could use those to drive servos? They seem to be more intended to be actual state information rather than commands. I suppose in doubt, just do it. :)

Comment by Pavel Kirienko on January 9, 2013 at 5:32am

Thank you for the feedback, I'd be really glad to see this integrated into UAV systems.

About the 310: it is not intended to be used as drive directive indeed, but rather as feedback. To actually drive servos, consider the messages from the section 5.2 Flight control data, like 401 ($191) "Roll control position" for instance.

Comment by Tilman Baumann on January 9, 2013 at 5:35am

Thanks. I see I will have to read the whole document. :)

Comment by Cliff-E on January 9, 2013 at 3:01pm

Very nice indeed. We use CANOpen/Elmo on a lot of things here, just not anything that flies :(  yet... Though not considering a lot of my coworkers are moving to Ethercat.

I assume this still follows the limitation of 127 device ids per CAN bus and a 1Mbps bus rate limit?

Comment by Pavel Kirienko on January 9, 2013 at 3:23pm

Maximum number of Node IDs for CANaerospace is 254 (127 is for CANOpen), but of course physical limitations are stricter, and they are depend on physical layer. For the high-speed CAN you hardly can use more than 110 nodes.

Data rate depends on physical layer too, and 1Mbit/s is the maximum possible for any of them, yes.

Comment by Tilman Baumann on January 9, 2013 at 4:48pm

As far as I understand the number of addressable nodes is not necessarily the limit of members on the bus. As long as you don't have a 1:1 conversation with them you can have as many devices listen to your message.

In the context of CANaerospace that might be highly non-conformal, but most can devices usually allow you to filter on the full message header. CAN extended message specifies 29it identifiers.

But really, 254 or 127 is astronomical in the context of a small UAV. So whatever. :) Next step is Ethernet...

The short message length of CAN totally sucks though. But of course that is to achieve the low latency.

Comment by Pavel Kirienko on January 9, 2013 at 5:56pm

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.

Comment by Chris Card on January 9, 2013 at 8:39pm

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 .

Comment by Andrew Dunlop on January 9, 2013 at 9:51pm

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

Comment by Tilman Baumann on January 10, 2013 at 3:38am

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.

Comment

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

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service