UAVCAN - CAN bus for UAV

[Pavel Kirienko]

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.

[Gary McCray]

Hi Pavel,

Clearly CAN is one of our most important (and currently totally underutilized) resources for future development and especially for distributed intelligent systems.

It seems to me that what you have defined looks equally suitable for non-flying autonomous or semi-autonomous vehicles or robots and appears to be a "universal" solution.

Would (could) this be a universal, open solution that did not require individual licensing for each node or application?

What else would need (or be appropriate) to add in order to use it as a universal solution?

Just some of my considerations, it looks like you have done excellent work on this and I am still hoping for previously promised PX4 - CAN I/O board to show up.

Best Regards,

Gary McCray

[Pavel Kirienko]

Hi Gary,

> It seems to me that what you have defined looks equally suitable for non-flying autonomous or semi-autonomous vehicles or robots and appears to be a "universal" solution.

Yes, it can be considered universal.
What makes it UAV-oriented is essentially the set of standard data types - you can see that the defined types generally address the typical use cases for flying robots.
One can define their own set of messages and use UAVCAN for non-UAV applications.
In fact, the reference implementation I am currently working on (in C++03 and Python) is going to allow to completely disregard the standard types in favor of the application-specific requirements.

> Would (could) this be a universal, open solution that did not require individual licensing for each node or application?

You bet, it will be 100% free for everyone; the reference implementation is going to be released under MIT or BSD license (not sure yet).

Pavel.

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/DMjfnaWViUw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Roberto Navoni]

Hi Pavel
we are available to integrate it in Nuttx Enviroment and test on
VRBrain . It support the bus and we are working in progess also on
some device that support that bus.
What's your idea about it ?
We are working to develop a hardware simulator of GPS using a VRBRain
4.5 without GPS interfaced with a VRBRain 4.5 with GPS and implement a
can connection ... we are working on DJI can protocol ... but we can
also evaluate to use Aerospace Can BUS.
Best
Roberto

2014/1/23 Pavel Kirienko <pavel.k...@gmail.com>:

> You received this message because you are subscribed to the Google Groups
> "drones-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Pavel Kirienko]

Hi Roberto,

> we are available to integrate it in Nuttx Enviroment and test on VRBrain.

That's good, then stay tuned for the updates - when the UAVCAN implementation will be available for testing, I'll let you know.
AFAIK NuttX has pretty simplistic CAN driver that lacks some necessary features (e.g. it seems that there's no way to detect when an outgoing CAN frame leaves the TX buffer, which is necessary to properly support TX timeouts), but it must be doable anyway.

> but we can also evaluate to use Aerospace Can BUS.

Make no mistake, CANaerospace != UAVCAN. You should evaluate the latter. :)

Pavel.

[Nathan DuCray]

Very glad to see someone working on this Pavel, I am constantly frustrated by the state of the market around this area. These non-standard dedicated cables and connectors and their tiny little wires carrying critical signals for thousands of dollars of aircraft. I see this small autopilot revolution as a possible future path for personal transportation but this will never happen until the communication infrastructure of this system is evolved and standardized. Good luck!

[Daniel Strnad]

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'm ESC, i'm 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?

[Karoly Molnar]

Pavel, this is a really impressive work. Still, I am just wondering, why are you developing a new standard while ARINC-825 is a good fit for this need?

[Pavel Kirienko]

Karoly,
ARINC-825 is not free, its specification is quite expensive. It's not a fit at all.

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

Pavel.

[independ...@gmail.com]

Hi Pavel,

Great work! Is there anyone else assisting you with this endeavor?

I have some questions:

- Has the target audience for utilizing the UAVCAN bus as well as supporting peripherals/nodes been identified? Implementation of such would come with a not insignificant cost (in money terms). The "big guys" and their subcontractors already have solutions which are industry supported. For the individual market, which is where i am guessing the target audience may be(?), I find that individuals willingly/knowingly trade off robustness all in the interest of saving a buck. Are there any ideas on how to ensure this appeals to the broadest possible target audience and thus ensure its success?

- What is the target size UAV this bus is intended for? Implementation of this within the UAV will come at the expense of cost/power/weight/area. As such I would presume there is a minimum size UAV at which point the expense of cost/power/weight negates the benefits of UAVCAN bus.

- It appears for the interconnect (connectors/headers/cabling) unshielded is being favored over shielded. Is there a reason why? I would presume that lesser robustness is being favored over increased cost/weight/area?

- Every node will require a processing entity of some form to at the least bridge UAVCAN bus with the node's primary function(s). For a node, is the processing entity and functionality thereafter to be electrically isolated from the UAVCAN bus?

- How will minimum distance between UAVCAN bus nodes be handled? Depending upon what the answer to the first question above, it could be something which requires a solution other than node to node wire/cable length. Such a solution would of course come at the expense of cost/weight/area.

- Why is the power 5v nominal as opposed to +12v-36v nominal? A 5v nominal source of power when distributed and depending upon current pull may not be sufficient to supply 5v circuitry at a node. Worse yet is when it occasionally goes out of spec, it will cause intermittent brownouts and partial/full system reset/reboot.

- I presume that this bus is intended for command/control within the UAV? Due to limited bandwidth it is not intended for UAV payload traffic (eg. payload sensor collection, video, etc)?

[Kevin Hester]

Hi guys,

Alas I haven't been following this thread (and won't really be able to until late next week).  However, I've written a fair amount of CAN stuff for some commercial projects (electric vehicles and large scale sensor networks).  I think CAN could be great for our family of platforms if the following aspects are considered:

• Think very carefully before signing on to any 'big' frameworks.  Both of the projects I worked on eventually decided to just use bare CAN - just pick a good mapping for the 11/29 bit IDs and size payloads so that most messages can fit in the 8 byte payload.   Use this for almost all traffic.
  
• Standardize an optional 'streaming' protocol on top of CANbus that can be used for firmware update or other applications that really need such an abstraction.
• Consider the cost of transceivers when selecting MCUs to talk on the canbus.  We had great success with the lpc11 family for all of our 'dumber' CAN slaves for the following reasons:
• They are really cheap (for many applications a low end lpc with a few analog channels and built in can transceiver was cheaper than even a dumb i2c adc) (for a 50Mhz cortex m0)
• Built in bootloader in mask rom provides sw update over can
• Tiny so they can be placed almost anywhere 
• Truly single chip

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Pavel Kirienko]

Hi,

Great work! Is there anyone else assisting you with this endeavor?

Yes, this have been done with the cooperation of PX4 dev team members.

 

- Has the target audience for utilizing the UAVCAN bus as well as supporting peripherals/nodes been identified? Implementation of such would come with a not insignificant cost (in money terms). The "big guys" and their subcontractors already have solutions which are industry supported. For the individual market, which is where i am guessing the target audience may be(?), I find that individuals willingly/knowingly trade off robustness all in the interest of saving a buck. Are there any ideas on how to ensure this appeals to the broadest possible target audience and thus ensure its success?

Yes, UAVCAN is intended primarily for higher-end machines, where the reliability and endurance are critical - e.g. filming, aerial imagery/surveillance, delivery - such applications where UAV are often equipped with expensive hardware or the cost of failure is significant. Nathan DuCray nailed it pretty well in the post above.

There is little point for UAVCAN in entering the low-grade UAV/toy market, as it would be hard to compete with simpler/cheaper products (think of Phantom or something wii-based), and there is no much need for high reliability in that segment anyway. However, though CAN bus hardware tends to be somewhat more expensive when compared to simpler interfaces (UART, I2C), there is no striking difference in BOM costs and weight. Pixhawk could actually have been *reduced* in weight, size and cost if some interfaces were removed in favor of UAVCAN (RC PWM, I2C, UART).

- What is the target size UAV this bus is intended for? Implementation of this within the UAV will come at the expense of cost/power/weight/area. As such I would presume there is a minimum size UAV at which point the expense of cost/power/weight negates the benefits of UAVCAN bus.

Though your statement about the trade-off between cost/power/weight/area and reliability is pretty valid, it is not always true - see above. I don't think it is correct to think of some threshold in UAV size beyond which UAVCAN is no longer feasible - rather it is matter of the application requirements.

- It appears for the interconnect (connectors/headers/cabling) unshielded is being favored over shielded. Is there a reason why? I would presume that lesser robustness is being favored over increased cost/weight/area?

No, specification does not prefer unshielded over shielded, nor vice versa. It is hard to cover all use cases with one connector, so the chapter "Physical connector definition" can be extended in the future.

- Every node will require a processing entity of some form to at the least bridge UAVCAN bus with the node's primary function(s). For a node, is the processing entity and functionality thereafter to be electrically isolated from the UAVCAN bus?

That is entirely implementation defined.

 

- How will minimum distance between UAVCAN bus nodes be handled? Depending upon what the answer to the first question above, it could be something which requires a solution other than node to node wire/cable length. Such a solution would of course come at the expense of cost/weight/area.

Minimum distance is not an issue as long as either condition is satisfied:

- overall bus length is much shorter than a wave can travel in one bit period (maximum bus length for 1 Mbps CAN is 40 meters);

- nodes are evenly distributed.

Both can be easily met even for very large vehicle, so there is no such issue as minimum inter-node space.

In case if you're interested in the detailed explanation, I can refer you to these sources:

- http://www.ti.com/lit/an/slyt325/slyt325.pdf (Message priority inversion on a CAN bus)

- http://www.ti.com/lit/an/slla279a/slla279a.pdf (Critical spacing of CAN bus connections)

- Why is the power 5v nominal as opposed to +12v-36v nominal? A 5v nominal source of power when distributed and depending upon current pull may not be sufficient to supply 5v circuitry at a node. Worse yet is when it occasionally goes out of spec, it will cause intermittent brownouts and partial/full system reset/reboot.

1. Typically, +5 VDC or lower voltage is sufficient for low-power nodes (Autopilot, IMU, OSD, receiver, telemetry, GPS, whatever).

2. High drain nodes must not be powered from the CAN bus connectors since it will impose EMI interference with other nodes powered from the same branch.

3. Having one (or few redundant) 5 V DC-DC converter is more efficient than place a low-power converter on each node separately.

4. Low-voltage sensor nodes are relieved from having noisy DC-DC converters, as they can be efficiently powered from +5 VDC via an LDO.

5. Having independent DC-DC converter on each node imposes higher weight and cost.

- I presume that this bus is intended for command/control within the UAV? Due to limited bandwidth it is not intended for UAV payload traffic (eg. payload sensor collection, video, etc)?

Yes, UAVCAN is designed for low latency, low data rate communications.

Pavel.

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/DMjfnaWViUw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Pavel Kirienko]

Hi Kevin,

Thanks for the comments, that LPC11 may be interesting.

Both of the projects I worked on eventually decided to just use bare CAN - just pick a good mapping for the 11/29 bit IDs and size payloads so that most messages can fit in the 8 byte payload.

True, if you read the RFC you'll find that UAVCAN is just a simple transport for serialized message structures. There is no complicated communication patterns like in CANopen/DeviceNet.

Some higher-level concepts defined by UAVCAN are generally sort of conventions based on that basic communication layer.

Standardize an optional 'streaming' protocol on top of CANbus that can be used for firmware update or other applications that really need such an abstraction.

It can be done if a need arises (e.g. 11-bit identifiers are not used at all), though it is difficult to imagine an application that would require that sort of streaming. For instance, the firmware update approach is already defined in the specification.

Pavel.

[Meier Lorenz]

Hi Kevin,

The LPC11 family was actually where we started off and it would be still the preferred chip, however, it is only really low-cost if you need minimal RAM or flash (which is true for many CAN nodes, but was not what we found for the things we’re currently working on). If anyone would be willing to join the efforts on the LPC11 that would be awesome (please get in touch, I want to do a small dev node for a year now!), for the sake of getting the job done we’ll probably resort for the current iteration to slightly more flash and RAM and the STM32 family.

Cheers,
Lorenz

------------------------------------------------------
Lorenz Meier
Computer Vision and Geometry Group
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

Am 25.01.2014 um 23:50 schrieb Kevin Hester <kev...@geeksville.com<mailto:kev...@geeksville.com>>:

Hi guys,

Alas I haven't been following this thread (and won't really be able to until late next week). However, I've written a fair amount of CAN stuff for some commercial projects (electric vehicles and large scale sensor networks). I think CAN could be great for our family of platforms if the following aspects are considered:

* Think very carefully before signing on to any 'big' frameworks. Both of the projects I worked on eventually decided to just use bare CAN - just pick a good mapping for the 11/29 bit IDs and size payloads so that most messages can fit in the 8 byte payload. Use this for almost all traffic.
* Standardize an optional 'streaming' protocol on top of CANbus that can be used for firmware update or other applications that really need such an abstraction.
* Consider the cost of transceivers when selecting MCUs to talk on the canbus. We had great success with the lpc11 family<http://www.nxp.com/products/microcontrollers/cortex_m0_m0/series/LPC11C00.html> for all of our 'dumber' CAN slaves for the following reasons:
* They are really cheap (for many applications a low end lpc with a few analog channels and built in can transceiver was cheaper than even a dumb i2c adc) (for a 50Mhz cortex m0)
* Built in bootloader in mask rom provides sw update over can
* Tiny so they can be placed almost anywhere
* Truly single chip

On Sat, Jan 25, 2014 at 10:00 AM, <independ...@gmail.com<mailto:independ...@gmail.com>> wrote:
Hi Pavel,

Great work! Is there anyone else assisting you with this endeavor?

I have some questions:

- Has the target audience for utilizing the UAVCAN bus as well as supporting peripherals/nodes been identified? Implementation of such would come with a not insignificant cost (in money terms). The "big guys" and their subcontractors already have solutions which are industry supported. For the individual market, which is where i am guessing the target audience may be(?), I find that individuals willingly/knowingly trade off robustness all in the interest of saving a buck. Are there any ideas on how to ensure this appeals to the broadest possible target audience and thus ensure its success?

- What is the target size UAV this bus is intended for? Implementation of this within the UAV will come at the expense of cost/power/weight/area. As such I would presume there is a minimum size UAV at which point the expense of cost/power/weight negates the benefits of UAVCAN bus.

- It appears for the interconnect (connectors/headers/cabling) unshielded is being favored over shielded. Is there a reason why? I would presume that lesser robustness is being favored over increased cost/weight/area?

- Every node will require a processing entity of some form to at the least bridge UAVCAN bus with the node's primary function(s). For a node, is the processing entity and functionality thereafter to be electrically isolated from the UAVCAN bus?

- How will minimum distance between UAVCAN bus nodes be handled? Depending upon what the answer to the first question above, it could be something which requires a solution other than node to node wire/cable length. Such a solution would of course come at the expense of cost/weight/area.

- Why is the power 5v nominal as opposed to +12v-36v nominal? A 5v nominal source of power when distributed and depending upon current pull may not be sufficient to supply 5v circuitry at a node. Worse yet is when it occasionally goes out of spec, it will cause intermittent brownouts and partial/full system reset/reboot.

- I presume that this bus is intended for command/control within the UAV? Due to limited bandwidth it is not intended for UAV payload traffic (eg. payload sensor collection, video, etc)?



--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[Jed Dennler]

Hi Pavel,

I absolutely have to agree with you on the obsolete method of PWM and serial UART communication.  I really would like to see UAVCAN become a viable standard with hardware such as ESCs, IMUs, GPS units, ETC.

I did read the UAVCAN RFC and have just had a quick point:  PLEASE do not use "fuses" on power supplies or recommend them for protection.  The power supplies should either automatically pull back voltage to prevent over-current damage and inputs to devices should have the appropriate resistors to limit current.  Blowing a fuse in mid air really sucks, and as far as aircraft go it would be better just to let the equipment keep trying to go until catastrophic component failure.  If a ground vehicle wants to use a fuse, the incoming power to devices can be fused but not at the hardware level.

I think there also should be a way to "schedule" communications to only update at the rate that the data is needed.  For and ESC, simply streaming the motor frequency output at 400Hz without any required device ack would be reasonable, and then have a feedback for the current used by the motors/Battery Voltage/etc. that the autopilot needs really only should update at about 10Hz.

While some networks such as J1939 are true peer to peer, for higher speed industrial networks use a master/slave relationship with a token (similar to ODVA's DeviceNet Protocol) to speed up the network.  Once the Autopilot is armed it would be good to have a fixed amount of time on a 400Hz clock to update the ESC's first on a multicopter, then pull data out of the GPS if data is ready (most GPS units only run @ 10Hz anyway), then get any feedback from the ESC's for current/temp/voltage before the next scheduled 400Hz update scans.  Unless there is truly data coming that is random in nature, I think it would be best to have a scheduled network for the critical data, and then let the non-critical data fill in the empty space between the scheduled updates.

That's all the time I have for now.  I'll keep following the idea and comment when I can.
Jed

On Thursday, January 23, 2014 10:39:32 AM UTC-8, Pavel Kirienko wrote:

[Kevin Hester]

Hi Lorenz,

I totally agree on where the 'sweet spot' is for that family.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Karoly Molnar]

Hi Lorenz,

I have built a number of sensor nodes around lpc11 for UAVs. I have a battery sensor that went thru the third hw iteration and has working software, this could be readily used. Its CAN stack is configurable, and could be adjusted with minimal effort for any signal based network protocol. I also have an airspeed sensor in progress and a servo controller that is still immature (1st hw iteration). I would be glad to work with you to get these the part of other UAV projects.

Regards
Karoly

[Karoly Molnar]

Pavel, its good that you mentioned the priority inversion. Please observe that the "num remaining frames" field in your CAN ID definition will immediately cause internal priority inversion, when multiple frames are pending for transmission.

Other observations: for clarity, it would be really beneficial if you would separate parts of the specification to multiple documents, so the individual parts could be elaborated in details. For example,
* i see that the transport layer and download protocol still needs details about the error handling, timeouts, bandwith utilization and other high level protocol details on confirmation of a successful download. Not to mention security measures to avoid initiating software download while the vehicle is in air.
* the phyical connection, altough good if standardized, would limit the usage of the protocol significantly. It would be better if it could be moved to a separate document, as a recommendation. Perhaps it could be extended later to allow other connector choices.
* i do not find anything how you would set up the payload part, a drawing would be helpful. From which direction do you count the 0th byte of the payload?
* what about the size of the frames and packing multiple signals to frames? As you know the CAN is the most efficient if you exploit all 8 bytes data. Do you want to apply any limitation here?
* i think that the chapter " higher level concepts" is unnecessary
* I see your motivation to save bandwith with moving control information to the ID field. However this has some drawbacks. On one side, it is very difficult to monitor/test/debug such system, because the ID is changing during the communication. Also this makes the precise calculation of the network latencies difficult or impossible, depending on the actual implementation.
* the services are not elaborated in details, i guess you would work more on this part?

Regards
Karoly

[Pavel Kirienko]

Hi Jed,

I did read the UAVCAN RFC and have just had a quick point:  PLEASE do not use "fuses" on power supplies or recommend them for protection.  The power supplies should either automatically pull back voltage to prevent over-current damage and inputs to devices should have the appropriate resistors to limit current.

Generally, UAVCAN has nothing to do with hardware implementation specifics aside from connectors, their pinouts and CAN layer. That "e.g. fuse" part was added just to clarify the intention.

Blowing a fuse in mid air really sucks, and as far as aircraft go it would be better just to let the equipment keep trying to go until catastrophic component failure.

Depends. Obviously, mission critical nodes (e.g. IMU) and auxiliary nodes (e.g. gimbal controller) might need different approaches to ensure bus protection against short circuits, this is why I don't want to go into details much. I just wanted to emphasis that possibility of power failure on a given node must be accounted properly so that it won't bring down the power on the bus entirely.

I think there also should be a way to "schedule" communications to only update at the rate that the data is needed.  For and ESC, simply streaming the motor frequency output at 400Hz without any required device ack would be reasonable, and then have a feedback for the current used by the motors/Battery Voltage/etc. that the autopilot needs really only should update at about 10Hz. 

While some networks such as J1939 are true peer to peer, for higher speed industrial networks use a master/slave relationship with a token (similar to ODVA's DeviceNet Protocol) to speed up the network.  Once the Autopilot is armed it would be good to have a fixed amount of time on a 400Hz clock to update the ESC's first on a multicopter, then pull data out of the GPS if data is ready (most GPS units only run @ 10Hz anyway), then get any feedback from the ESC's for current/temp/voltage before the next scheduled 400Hz update scans.  Unless there is truly data coming that is random in nature, I think it would be best to have a scheduled network for the critical data, and then let the non-critical data fill in the empty space between the scheduled updates.

UAVCAN is intentionally made democratic (peer-to-peer), since centralized networks tend to have a single point of failure. Thus, the communications in UAVCAN are naturally asynchronous - each node decides independently when to transmit the data. I refer you to the concept of Time Triggered Bus Scheduling (used, for instance, in CANaerospace and ARINC 825) for further explanation.

Karoly,

Pavel, its good that you mentioned the priority inversion. Please observe that the "num remaining frames" field in your CAN ID definition will immediately cause internal priority inversion, when multiple frames are pending for transmission.

Exactly, as intended.

Priority of an UAVCAN transfer is defined by, in that order:

- Data Type ID (lower wins)

- Transfer type (service wins over message)

- Num remaining frames (see below)

- Node ID (lower wins)

The objective here is to ensure that once node A began transmission of a data of type Z, it won't be interrupted by transmission of the same data type from other nodes, even with lower Node ID.

This renders the following properties:

- At any moment the bus sustains no more than one ongoing transfer of a given data type (there are few exceptions though), thus the nodes that are interested to receive this data can make reliable assumptions on how much buffer space must be allocated. Since we're dealing with deeply embedded systems, that sort of determinism is helpful.

- Interval between transmission start and transmission end is minimized, thus message delivery time is minimized as well, because a transfer won't be preempted by other transfers of the same or lower priority.

The keynote here is that data priority is generally defined by Data Type ID rather than by transmitting Node ID. The latter kicks in into arbitration only if multiple nodes attempt to transmit the data of the same type and the same length concurrently.

Other observations: for clarity, it would be really beneficial if you would separate parts of the specification to multiple documents, so the individual parts could be elaborated in details.

Accepted.

Thanks, I was going to split the specification later, yes. Currently it is just RFC.

* i see that the transport layer and download protocol still needs details about the error handling, timeouts, bandwith utilization and other high level protocol details on confirmation of a successful download. Not to mention security measures to avoid initiating software download while the vehicle is in air.

Accepted.

Though the part regarding the firmware update safety was sort of mentioned.

 

* the phyical connection, altough good if standardized, would limit the usage of the protocol significantly. It would be better if it could be moved to a separate document, as a recommendation. Perhaps it could be extended later to allow other connector choices.

Accepted.

I'll need to clarify that it is not *required* to follow the proposed interconnection conventions, but *recommended*.

As for extension, yes, few posts earlier I said that this part is inevitably going to be extended later.

 

* i do not find anything how you would set up the payload part, a drawing would be helpful.

Accepted.

From which direction do you count the 0th byte of the payload?

From lower memory address.

* what about the size of the frames and packing multiple signals to frames? As you know the CAN is the most efficient if you exploit all 8 bytes data. Do you want to apply any limitation here?

UAVCAN operates with serialized compound data structures, where each structure can be of arbitrary complexity and even contain nested structures. So in this regard, UAVCAN pretty much supports such signal packing (see the last answer).

However, it is impossible to pack multiple data structures into one CAN frame. If such need arises, the application designer should consider the possibility if defining their own data type for that particular task.

 

* I see your motivation to save bandwith with moving control information to the ID field. However this has some drawbacks. On one side, it is very difficult to monitor/test/debug such system, because the ID is changing during the communication. Also this makes the precise calculation of the network latencies difficult or impossible, depending on the actual implementation.

On part of the network latencies, please refer to the explanation of the arbitration process above.

As for ID field: yes, bandwidth efficiency is the most important feature of UAVCAN. Typical light UAV requires high bandwidth data streams - it is easy to use up all available bandwidth since CAN 2.0A @ 1 Mbps has maximum throughput as low as 8000 messages per second; thus payload overhead is one of the primary concerns.

I'm not sure I can easily agree that UAVCAN network is going to be very difficult to test/debug/monitor; it just would require a toolset that is capable of proper tracking of UAVCAN data exchange patterns. Stay tuned for that part.

Pavel.

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/DMjfnaWViUw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Karoly Molnar]

Hi Pavel,

In regards priority inversion. It is really an evil issue and should be avoided to make the network scheduling predictable.
Still a simple measure could help you here. If you just use a counter starting from 0 instead of the the "num of remaining frames" then at least you would see that the first and the second CAN message would not be sent swapped. If you have a field for "num of remaining frames" then consider this:
1. You have a message that consists of 20 bytes and would fit in 3 frames. Practically, these 20 bytes could be a single C structure in your presentation, hence available in the same time. So you can simply execute three consecutive tx requests and let the CAN controller or an underlying sw layer mark it as "pending for transmission". Num of remaining would be then 2 for the first part of the data, 1 for the middle and 0 for the last. However, the CAN frame with "num of remaining" = 0 will be transmitted first, if you observe the priority of the frames properly. And the "num of remainging" = 2 would be the last (lower number is higher prio on CAN). If the messages are sent with some gaps between them, then they would be sent with the order of 0 - 1 - 2. This requires a more complex protocol then to build the structure on the receiver side if the CAN frames can arrive in arbitrary order. It would be better if you use the field as "frame sequence number" instead of "num of remaining frames" then the order of the messages would be always the same.

I do not follow on your statement that priority inversion is "intentional". Could you please elaborate.

/Karoly

[Pavel Kirienko]

Hi Karoly,

I admit I overlooked the priority inversion in TX buffer while trying to optimize the bus arbitration. I see the problem clearly, thanks for the feedback.

I introduced a minor change in frame format so that priority inversion during transmission is no longer an issue, and added few clarifications.

Please take a look: https://docs.google.com/document/d/1_38WbdeUzauL02ZeEGKgEAj7A6CPD0RuPzbhfm3kuok/pub#h.1nv0doru4579

Rest of the document is left unchanged.

Thanks,

Pavel.

[Karoly Molnar]

Hi Ppavel,

Now you are OK from priority perspective. Do not forget to add to the spec that the underlying driver shall also consider priority inversion free transmission (e.g. the libopencm3 drivers are not supporting this at the moment, altough I plan to suggest some changes there).

On the other hand, I still see some possibilities to improve some parts of your the concept. Consider the following scenario: You have a node, say, the IMU, that wants to publish a large number of data: coordinates in floats, Perhaps raw sensor data, quality data, GPS location, pressuure and temperature information, perhaps speed, etc. It is a theoretical example, I might have made a mistake by listing what you expect from an IMU. Anyhow, lots of data, could be in the range of 60-100 bytes. What do you do with this then? In your concept, you encapsulate this in one big data structure (if I am correct, please confirm) and publish it in a sequence of frames. Then consider an other simple node, that would like to know the temperature (e.g. the sensor that detects wing icing). Might be a very simple sensor with very limited RAM and processing capability. What can we do? In your concept, the icing sensor should subscribe the to receive the complete data structure from the IMU in order to receive the single byte or 16bit data about the temperature. This will be a blunt waste of RAM, especially if there are multiple sources of fractional informations that other nodes would require. Another drawback is that perhaps the icing node is just too slow to catch up with the data stream from IMU that, for other reasons, supposed to push out its information at very high rate. So my proposal would be to revert to a leaner solution. You should save the multiframem transmission for the software download only, while for normal communication you may just break down the complex data structures to basic signals and publish them in single frames. Still you can packk multiple related data in one CAN frame, but you shall construct the signal database in a way that would not require the multiple frame transmission in normal communication.
Another issue with using the multiple frame transmission as the basic comm layer is that, as I indicated before, right now your transport layer has no proper timeout annd flow control and bandwith control mechanisms. If you add these, it would then most likely be complex enough in terms of software and protocol overhehad, that you would loose the majority of the benefit of the theoretically high throughput.
The third issue is, that the more complex the data structure is, the most likely you would need to reprogram all other nodes that would require only a few bytes from the large data stream.
So my proposal is to keep the 8 bytes CAN frame as the basic communication unit usue the trannsport layer only for rare, very special purposes, like software download, textual error messages (assuming a diagnostic onboard display for ground testing, for example) etc.

Regards
Karoly

[Pavel Kirienko]

Hi Karoly,

I disagree. One of the primary goals was to remove the CAN restriction of 8 bytes per transmission, because there are many cases when 8 bytes isn't enough. Splitting data into several independent transmissions would require the application layer to reassemble them into one consistent object before processing anyway.

On the other hand, you don't have to pack everything into one message, thus your example is exaggerated. If you avoid packing unrelated things into the same message, you'll be OK in terms of the RAM/processing time overhead, and free of the compatibility issues described in the last paragraph.

Pavel.

[Jaime Machuca]

Hi, I would like to pitch in to this discussion, a little bit about my background before. I am an electronics engineer with 10 years of experience in embedded software programming and program management on the automotive industry. I have worked with all of the major OEMs on design and development of instrument clusters. CAN is used extensively by all the modules in the vehicles and it works very well. I have however never seen a use of CAN like the one being proposed here. This seems to be a very non standard use of the CAN system and while it may work, I am not sure if its the best use. 

I am concerned about the use of the identifiers and the processing toll it will take on the nodes. This use of identifiers will effectively disable any hardware assistance in filtering the CAN messages. Most MCUs that support CAN and have dedicated hardware for CAN transmission have hardware filters where you calculate a bit mask to allow the passing of only the messages you are interested in. This helps a lot in the processing time because this si done with out using CPU time. With the way you propose using the identifiers each node will have to receive and process all messages on the bus and determine if its of interest or not, because the identifiers for a particular data of interest may change over time depending on node ID, number of frames remaining, etc...

To me it seems you are overcomplicating and trying to resolve things that are already working on CAN. The basic idea of the CAN spec, is that the IDs are predefined in a system design. These IDs are assigned depending on the priority of the data contained on the message. Multi-frame messages are never used for critical data, in fact most OEMs only use multi frame messages for diagnostics messages or boot loader transfers so that the bus is not overloaded with these transfers. Using multi frame messages during vehicle operation has always caused communication issues in the vehicles in my experience. The CAN messages also always contains the same data, for example CAN-ID Message 100 might have the following structure:

(Disclaimer: This is just an example, I know these data types maybe longer or shorter)

Byte 0    Latitude Hi

Byte 1    Latitude Lo

Byte 2    Longitude Hi

Byte 3    Longitude Lo

Byte 4   Altitude

Byte 5   Sat count

Byte 6   Other GPS flags

Byte 7   HDOP

I would propose that we create a rule for choosing CAN-ID messages. For example GPS messages should take from 200-2FF, Attitude message from 100-1FF, and so on taking into account the priority of the data to be transmitted. 

That we keep a CAN message database that contains all the messages and the structure for each message. The type of message, wether its cyclic (and its period), or sporadic, etc.

That we try to use only single frame messages and if there are structure that don’t fit, that we split them into several messages. This way every node can receive only the data they want. 

That we setup some kind of network status ring where we have the current state of each node and that can be used as a method for determining node failures and to save power in the future by shutting down the bus when its not in use, and allowing the modules to go to sleep when not needed.

That multi frame messages are used for diagnostics and boot loader operations only. And that a general diagnostic specification is used by all, maybe KWP2000 or UDS diagnostics.

All this will give the protocol and communication bus better stability and testability since we can also define tests a parameters to check. For example we can test that all cyclic messages are being transmitted within their specified period. We can use existing tools for debugging, testing a defining the databases. 

Anyway, this are my thoughts. Also please not that I am not just criticizing your work, I am also volunteering to work on this in the future. I just moved from the automotive industry and have now setup my own company that will be dedicated to the design of UAVs, and one of our goals is to become an active participant and contributor to these open projects. And I think this is a very good entry point for me. I still have a way to on understanding the current state of software and installing the toolsets and getting up and running. But hopefully I will get this done soon.

- Jaime 

You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Pavel Kirienko]

Hi Jaime,

Thanks for the feedback.

This seems to be a very non standard use of the CAN system and while it may work, I am not sure if its the best use.

I am concerned about the use of the identifiers and the processing toll it will take on the nodes. 

Using ID field to encode auxiliary information, like in case of UAVCAN, is very common. I refer you to, for example, ARINC 825 (page 10-10), VSCP, NMEA 2000 (page 11) - these protocols interpret ID field as complex bit structure rather than as integral numerical value.

This use of identifiers will effectively disable any hardware assistance in filtering the CAN messages.

This is not true.

CAN standard specifies mask registers for the hardware acceptance filters (chapter 4) that allow the filter to exclude some ID bits from matching. From my experience, most CAN controllers implement acceptance filters with mask registers, e.g. AVR built-in CAN controller, STM32 built-in bxCAN, Microchip MCP2515 - this list is far from being complete.

In case of UAVCAN, mask registers would allow to effectively ignore values of all bits of the CAN ID except two fields: Data Type ID and Transfer Type - thus the filtering still can be done in hardware. Once again, this is not uncommon to use mask filters and CAN ID like that, see the list of the protocols above.

Using multi frame messages during vehicle operation has always caused communication issues in the vehicles in my experience.

I'd repeat myself from the post above:

Splitting data into several independent transmissions would require the application layer to reassemble them into one consistent object before processing anyway.

If your protocol does not decompose and reassemble the data automatically, it does not mean that the application is free from multi-frame transactions. The only difference is that the application can not rely anymore on the protocol's features of data reassembly and integrity checking. Typical tasks in robotics/UAV require nodes to exchange larger data structures than can fit into single CAN frame. Think of your GPS fix example, IMU sample, estimated 3D velocities, etc - in virtually all cases you can't just use one value from these examples apart from the rest of the structure. OTOH UAVCAN still doesn't prevent you from sending primitive messages (one message = one signal) efficiently, since all 8 bytes are available for the payload.

Don't get me wrong though - I am not encouraging to merge any data that can be published by a node into few large data structures, I perfectly understand that it will cause obvious difficulties (already discussed earlier). If you consider the standard data types defined in the RFC you'll find that most of them fit into just one, two or three CAN frames, with very few exceptions.

Pavel.

[Jaime Machuca]

I am reading through the documentation you sent for the other protocols. Very interesting stuff. I'll have to digest it over the weekend. =).

You are right you can set the mask to only look at the bits of interest. And you are right all the MCUs I know implement these filters in that way.

What would be the case where you need to send a message with data longer than 8 bytes? you could send for example the set of GPS Data and IMU values over several individual messages instead of one large structure. And any node interested could take that data from each of the messages and reassemble it. The problem I see is that maybe the values sent over the CAN bus may not be synchronized in this case. Is this the reason for sending large structures? 

I will read through your document more in depth over the weekend and I'll get back to you on Monday.

Jaime 

[Karoly Molnar]

Hi Pavel,

As I understand, your main goal is
1 to enable a lightweight transfer of larger set of data.
2 in a way that still allows lightweight transfer of smaller data
3 in a format that does not require extra cpu processing for data packing/unpacking on the transmitter or receiver side.

1: I still miss the proper transport layer protocol from your specification. You should address flow control at least. You extra challenge is to address flow control in a way that still allows broadcast, which is not that simple. But even for point to point, the receiver node shall be able to indicate that it is ready to receiive the larger data block, or that it isi able to receive but only with a limited data rate. The latter is especially important for the Flash download. There are MCUs with Flash memory that are not able to erase/program the Flash at the rate that would come from a 1Mbps fully loaded CAN bus. The Renesas MCUs were famous of their slow Flash programming, at least they were, a few years ago. If you do not apply flow control on the data then you need to apply requirememnts on the receiving nodes as:
- they must be able to receive the complete data structure in one step
- they must be able to read the CAN frames sequence without frame loss. This is about 100us per frames, so all receiving nodes in the system shall be able to process the data with this speed while performing ist main function, or multiple slots or HW receive FIFO shall be used.
- they must be able to process the received data as fast as it arrives (see Flash programming)

3: Your claim that one large data structure is better because it does not require packing/unpackking is true only if both the sender and the receiver node is a 32 bits LlittleEndinan node, with the very same packing rules enforced by their C compilers. If one of the nodes is a 16bits node or has BigEndian byte order then there would be challenges with data misalignment and endianness. I would say, as long as you are thinking in the scope of ARM Cortex M CPUs it is OK, but apparently this is just a part of the MCU universe. For example, Freescale is strong in cheap 16bits S12x and PowerPCs while TI has a BigEndian CortexR4F family of MCUs. Both Freescale and TI is extremely strong in high reliabile transpoprtation industries (automotive and commercial UAVs). This is unfortunately not true for the STM32 nodes that are often used in small hobby UAVs.
The incompatible data structures of different MCUs would immmediately require interpretation, shifting, endianness conversion of the data in concern. So your claim that large data strcutures are beneficial over smaller signals is limited. In case of having standard types of 1bit/8bit/16bit/32bit/float/double for signal types you can still group them in the definition file and enforce the signal group consistency in software. I do not mention other type of signals, like 2 bits or 12bits signals etc, which are also common in CAN transnportation systems and typically well supported. These would be challenging to support in your system in general and especially in a mixed MCU environment.

I believe that you will be able to find a good compromise between point 1 and 2, I am not very concerned on this (or just apply the system restrictions on the hardware that I wrote above). However, correct me if I am wrong, point 3 would be rather restrictive and eliminates the the advantages of the "large data structure" solution.

Rregards
Karoly

[Pavel Kirienko]

Hi Karoly,

1. I don't think flow control is needed nor applicable, here's why:

- Anyway receiving nodes will not be able to process frames as they arrive, because all frames of a transfer must be received first before the encoded data structure can be deserialized and checked for integrity. Thus, reception throughput is not limited by the application response time.

- For CAN 2.0B frame time is 145 microseconds - this is maximum possible IRQ latency that has to be met, provided that the controller lacks HW FIFO (few do). For many real-time applications this requirement shouldn't be hard to satisfy, not to mention that nearly all CAN transceivers implement FIFO buffer in hardware, which further relieves requirements to IRQ latency.

- As for your comments on Flash download - this is not a relevant issue. First, as I said above, data structures are not processed until the transfer received completely - thus Flash programming process belongs to higher level of abstraction than transfer reception. Second, Flash programming process is entirely slave-driven, i.e. node that is being updated requests new data as needed.

What the specification lacks is timing requirements for file transfer operations, i.e. minimum interval between subsequent read requests to prevent bus congestion. Initially I was assuming that this parameter should be application-defined, but maybe I need to add some sort of recommended defaults.

As for requirements:

- they must be able to receive the complete data structure in one step 

Yes. This requirement should not be hard to meet since maximum data structure size is known statically and never exceeds 256 bytes. 

- they must be able to read the CAN frames sequence without frame loss. This is about 100us per frames, so all receiving nodes in the system shall be able to process the data with this speed while performing ist main function, or multiple slots or HW receive FIFO shall be used.

Yes. By the way, I don't know any CAN controllers that don't have at least 2x HW RX FIFO.

- they must be able to process the received data as fast as it arrives (see Flash programming)

Not the case, see above.

3. Yes Karoly, I am well aware of binary compatibility issues, this is why I don't suggest to exchange plain C structures. Instead, UAVCAN relies on automatically generated serialization/deserialization code generated from message description file. Byte order is defined as well (though this chapter is not perfectly finished yet).

Your claim that one large data structure is better because it does not require packing/unpackking is true only if both the sender and the receiver node is a 32 bits

This was not packing/unpacking that I was concerned about, but decomposition over multiple CAN frames and related synchronization issues - if there were no compound message transfer, application would have to handle decomposition/reassembly on its own. It is true that some extra processing power for serialization/deserialization is needed in any case.

I do not mention other type of signals, like 2 bits or 12bits signals etc, which are also common in CAN transnportation systems and typically well supported. These would be challenging to support in your system in general and especially in a mixed MCU environment.

https://docs.google.com/document/d/1_38WbdeUzauL02ZeEGKgEAj7A6CPD0RuPzbhfm3kuok/pub#h.vt9makyqm85p 

In fact, the ROS reference I put in the beginning of the document was intended as hint on what the basic approach to the message serialization is like. Probably I need to clarify this as well.

By the way, it never occurred to me to mention (though it is obvious in some way) that packed data structures can be more efficient in terms of throughput (thus latency) than a set of independent messages. For instance, take GNSS fix message definition:

Timestamp timestamp
int32 lon_1e7
int32 lat_1e7
int24 alt_1e2
float16 track_deg
float16 speed
float16 climb
float16[<=9] position_covariance
float16[<=9] velocity_covariance

Provided that we have 48-bit timestamp and diagonal covariances, the packed message size is (48 + 32 + 32 + 24 + 16 + 16 + 16 + 4 {this is array length} + 2 * 3 + 2* 3) (second array length can be omitted) --> 200 bit --> 25 bytes --> 4 CAN frames.

I don't see how the same efficiency can be achieved with independent messages, not to mention issues of synchronization already mentioned above.

Jaime,

What would be the case where you need to send a message with data longer than 8 bytes?

Generally it is complex sensor data (like GNSS, IMU, battery info), packed actuator commands (e.g. for large group of servos or more than 4 ESC), or higher level structures (like estimated velocity/position with uncertainty).

Please consider the standard data type definitions.

you could send for example the set of GPS Data and IMU values over several individual messages instead of one large structure.

Yes, this is exactly the case. As I said earlier, there are not so many big data structures.

Speaking of this example - there is no point in merging GPS and IMU since most likely these measurements will be produced by different nodes.

Pavel.