Good day everyone,
A modern drone or flying robot tends to have quite a number of different hardware units onboard - Autopilot, Gimbal, GPS, ESC, OSD, PDB, RC just to name a few. As there is no common method to interconnect that variety of devices, and for sure each hardware unit tends to implement its very own interface, obvious difficulties arise:
- Implementing support for new peripherals is hard (e.g. consider PX4Flow driver for APM; 3DR GPS; MinimOSD).
- Autopilots need to accommodate variety of physical interfaces for different peripherals - this imposes some penalties on the device size, cost and weight (e.g. Pixhawk and its so called "connector farm").
- MOST of currently used interfaces are simply not designed to be reliable nor scalable, thus moving towards more reliable systems while sticking to the current onboard communication methods is absolutely impossible (e.g. RC PWM - pet peeve of mine, absolutely worst case; or ubiquitous UART).
Properly designed standard for hardware interconnection in UAV systems may encourage different manufacturers to produce compatible hardware and software, this is why I consider it important to offer such a standard for community. Previously I took some steps trying to rectify the current state of affairs with the hardware compatibility: first, I implemented the CANaerospace protocol support in portable C library - libcanaerospace: http://diydrones.com/profiles/blogs/open-source-canaerospace-library-for-uav (BTW this article covers the CAN bus features in general, those who are unfamiliar with CAN may be interested to read); second, with cooperation with Lorenz Meier, there was proposed a convention for connector compatibility: http://www.diydrones.com/profiles/blogs/can-bus-conventions-for-small-uav.
However, CANaerospace is apparently not a silver bullet, here's why:
- CANaerospace has more than 50% of payload overhead which makes it unfit for high speed data streams that are so common for UAV (especially for light machines where the controlled system requires high update rates and low latency).
- CANaerospace does not provide an easy way to pass multiple values in one bunch, which is also very common task in the UAV field.
- CANaerospace does not provide adequate means for some extremely common higher-level tasks, such as node configuration handling, firmware update, time synchronization, etc.
Thus, there seem to be a need for some protocol that could be used as a backbone network on UAV and flying robots, and that could address the issues listed above. So meet the UAVCAN protocol specification draft: https://docs.google.com/document/d/1IgOZ2proS0Bwx3_nc8u7CM81ldHcxWzlgMVjNfW5Has/pub
UAVCAN core design goals:
- Provide a suitable protocol standard for UAV hardware manufacturers.
- Support redundant physical interfaces and redundant nodes for highly reliable systems.
- Address the issues inherent to CANaerospace, as listed above.
- Make it easy to implement and easy to use in deeply embedded systems with limited computational capabilities (i.e. ensure small memory footprint, low computational complexity).
- Explicitly define support for some common tasks (node configuration handling, firmware update, time synchronization, etc).
All of this is described in-depth in the RFC linked above. I'd like to ask the community for comments on this standard, especially regarding the standard data type definitions (see the corresponding chapter), the "std/equipment/" part. It is important to make sure that the standard types are extensive enough to cover most possible use cases for the majority of UAV applications. Also I'd like to make sure that the RFC language is comprehensive enough so that other engineers can get at least general idea of how to implement it, and absolutely clear understanding of how to use it.
As a closing remark I'd like to add that the situation with UAV hardware is changing: the next revision of Pixhawk is going to get the full support for UAVCAN, as well as PX4ESC is; also there are some other compatible hardware to be announced pretty soon.
Best regards,
Pavel Kirienko.
P.S. This is a cross-post from drones-discuss: https://groups.google.com/forum/#!topic/drones-discuss/DMjfnaWViUw; please leave your comments there.
Comments
Pavel,
whatever.
Ralph,
CANopen is nice, but it has some drawbacks when used in a general UAV application:
Some comments based on recent developement experience with CAN for aircraft,
CANaerospace should really be viewed the translation and enhancement of ARINC-429 (Boeing 757, 767, 747 or Airbus A320,330,340) to the CAN bus. Thus the low message efficiency, very similar to "429". ARINC-825 is the effort to take CANaerospace and make it into an ARINC standard for broad general avionics application. Thus I believe it is not the right thing for amateur UAV application. The reality is also that unless your customer is Airbus nobody fully implements ARINC825.
If you want take ideas from a standard, dig into CANopen. CANopen is used in a lot of applications, there are many open tools available and our experience is that you can get away with implementing only a subset (fixed configurations) and yet still have an efficient and compliant message traffic. It also provides a standard/reference for the things mentioned above, Master/Slave, Sync, Netwoek discovery, ...
CANopen is also simple enough for people to get started quickly and not try to reinvent the wheel.
Cheers
Alexander:
Yes of course I was considering ARINC-825 but its specification is quite expensive, which is a deal breaker.
Daniel:
Yes, I was trying to avoid centralization in any form to retain simplicity and flexibility. For instance: you're assuming that an autopilot could perform as master in a centralized network, which is true for many use cases; however, if the system has a higher-level computer, should the master functions be delegated to it instead of the autopilot? What if there are two redundant autopilots, i.e. two redundant masters?
As for network discovery - there are several mechanisms to do that:
1. Node description string. Assuming that an application needs to find a specific device in the network, e.g. Pixhawk, it can query each node using the service std.protocol.GetNodeInfo, response of which contains short node description string, e.g. "pixhawk".
2. Data type based discovery. ESC will certainly subscribe to the type std.equipment.esc.ThrustCommand and publish std.equipment.esc.Status. So query each node using the services std.protocol.GetDataTypeInfo to find all available ESCs.
3. Just wait while the interesting node publishes some particular message. E.g. since any ESC should publish std.equipment.esc.Status periodically, it will be possible to just wait for this message and then look which Node ID it came from.
Regarding ID assignment: yes, this should be done during initial system configuration; shouldn't be an issue though. I don't see reliable ways of assigning IDs automatically in a decentralized system.
It looks good to me, certainly better than CANAerospace for our purposes IMHO. You are trying to be quite complete with specification and even try to cover connectors, pinouts etc., which is good, but still there is a thing I'am missing. Do you think about some kind of mechanism for CAN nodes enumeration and Node ID assignment? I have some quick ideas, which includes usage of some kind of long (multiple bytes) unique and permanent ID for each node and ability of each node to report some basic info about itself (Hey, I'am ESC, i'am sonar and so on) when addressed(somehow) just by this UID and also ability to assign itself some Node ID(1-127) upon request. I'm not happy with this idea because it requires some central authority, which is typically present in UAVs(autopilot control board), but it breaks your completely decentralized concept. Any other ideas?
Have you considered Arinc-825?
Euan, yes, connectors will be defined in the standard as well. Currently you can see the chapter dedicated to the hardware interconnection (the last one), but the exact connector types are not specified yet. Most likely it will be Molex CLIK-Mate, 4 circuits.
Good luck with this!
-
1
-
2
of 2 Next