Hi everyone!
As the developer of the open source CANaerospace library that (I hope) is gaining attention (as well as CAN does), I'd like to propose this RFC that defines the community standard for CAN interoperability:
https://docs.google.com/document/d/1L9HXnlS7FqYGCrBM9hExpfpJZ99gKUBtNMMypMZKSvw/pub
The set of rules defined by this document shall be easy to follow for the majority of CAN-enabled UAV hardware.
Please join the discussion and leave your comments in the MAVLink group: https://groups.google.com/forum/#!topic/mavlink/dHDkRd1vT3k
Thanks!
Comments
We are considering to use CANaerospace.
CANopen seems to be rather centralized and over-complicated. Besides, CANopen has no built-in support for redundant nodes and interfaces.
Are you looking at a vanilla CAN implementation [just the wire protocol] or following specs like DS201/301?
I have a library that runs DS301 calls (PT and PVT modes) as well as DS401 calls (we run Elmo drives here), though I've found the 401 calls are vendor specific, CiA allows it, so it totally create havoc if you write a generalized library and want to run different hardware though they all speak CAN.
microdrones uses a CAN bus for their ESCs.
Nope, the protocol is not defined yet AFAIK.
Randy,
PX4 team is working exactly on this.
James:
Gimbal control should be somewhat straightforward.
Say we normalize 360 degrees into 16 bits (0..65535), then pack Roll, Pitch, Yaw into one 6-bytes message using the layout proposed above.
It is just a thought, I may miss something important here.
James,
Regarding layering UAVTalk over CAN: it is very possible to use CANaerospace to transport the raw serial interface, and in fact I was thinking about this use case. This approach is easy way to migrate some serial-based protocols to CAN.
Look, the typical CANaerospace message consists of the following fields:
a. Message ID - encoded in CAN Identifier A (11 bit)
b. Redundancy Channel ID - encoded in some least significant bits of CAN Identifier B (18 bit total)
The following fields are allocated inside the CAN frame payload, one byte each:
c. Transmitting Node ID
d. Data Type
e. Service Code
f. Message Code
Then follows payload up to 4 bytes.
Watch closely now:
1. Field B has one byte to spare, provided that one does not use more than 31 redundant units per function (I doubt anybody ever will).
2. Field E is needed only for CANaerospace Node Service Protocols - which is not the case so it's free.
Hence we have up to 6 bytes of payload per CANaerospace message, with one minor drawback: the Redundancy Channel ID is now polluted with a payload byte, so this extra byte must be masked out. I think this is not a big deal to accept such an extension.
Now let's add new Parameter ID Distribution Mode (it's like a namespace, see the specs chapter 4.1 and 5), call it SERIAL_OVER_CAN. Then add some Message IDs: one for single-byte-payload frame, one for two-byte-payload and so on up to six bytes per frame.
Voila, we just extended the CANaerospace so it can carry serial data with relatively low overhead (6 bytes per CAN frame) and still doesn't distort the standard much.
I hope we will have an ESC that can communicate with the flight controller using a CAN bus. I've got some initial questions from an ESC manufacturer asking what protocol they should support and I recommended CAN.
+1. This is an initiative in the right direction and we've been following closely Pavel's work. Both PX4 generations (FMU+IO and Pixhawk) have in-built hardware support for CAN, and we're already tinkering on peripherals for those ports - its time to put this bus to some real work, and a good start is to settle how to connect it.