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/1L9HXnlS7FqYGCrBM9hExpfpJZ99gKUB...

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!

Views: 2822


Developer
Comment by Lorenz Meier on September 4, 2013 at 9:16am

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


Developer
Comment by Randy on September 4, 2013 at 10:29pm

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.

Comment by James Cotton on September 5, 2013 at 7:06am
I used CAN with Sparky to control a brushless gimbal controller and track a location http://vimeo.com/67528638

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.
Comment by Pavel Kirienko on September 5, 2013 at 2:25pm

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.

Comment by Pavel Kirienko on September 5, 2013 at 2:35pm

James:

If anyone wants to help define a message for gimbals though I'd be happy to try it out.

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.

Comment by Pavel Kirienko on September 5, 2013 at 3:50pm

Randy,

I hope we will have an ESC that can communicate with the flight controller using a CAN bus.

PX4 team is working exactly on this.

Comment by James Cotton on September 5, 2013 at 6:27pm

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.

Comment by Pavel Kirienko on September 6, 2013 at 1:43pm

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.

Nope, the protocol is not defined yet AFAIK.

Comment by Don LeRoi on September 6, 2013 at 1:58pm

microdrones uses a CAN bus for their ESCs.

Comment by Cliff-E on September 6, 2013 at 8:04pm

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.

Comment

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

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service