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.
That sounds reasonable for serial, although shuffling bits like that (as opposed to them being a contiguous block) doesn't sound ideal for performance. Still I can't imagine the performance hit is really relevant, just slightly inelegant code. And 6 versus 8 bytes per message is fair enough to conform to a protocol if it became more widely used.
Regarding gimbal control, probably some bits might be needed to indicate if this was a rate signal (deg/s) versus absolute (deg). I can't think of much else. Could those be encoded as different message IDs (consistent with what you were saying above) to have 8 message IDs for all the permutations?
Regarding ESCs - what is the message format for that? Have you defined messages for configuration and getting data back from the ESC? The serial would be a nice thing to implement a bootloader over CAN too.
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.
It worked pretty well. The approach that works well for Tau Labs is to packetize addressable serial communications via the CAN bus. Then we can layer UAVTalk messages on that, and fairly easily replace the link with a serial one too. In this case I just pass the CameraDesired object - which basically defines the higher level protocol.
The nice thing about this approach is it easily generalizes to new things (e.g. ESC control which is something i've been wanting to add to our ESCs) with basically no code.
The down side of this approach is
1) not moving towards a standard for other systems
2) less efficient since the message ID is used as an address and then you only have 8 bytes for data, which means a standard UAVTalk packet for a small message is still a few bytes
If anyone wants to help define a message for gimbals though I'd be happy to try it out.
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
-
2
of 2 Next