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.
--
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.
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?
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.
--
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.
Great work! Is there anyone else assisting you with this endeavor?
- 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 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.
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.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
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
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
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.
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.
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.
* 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 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.
--
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.
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.
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.
Using multi frame messages during vehicle operation has always caused communication issues in the vehicles in my experience.
Splitting data into several independent transmissions would require the application layer to reassemble them into one consistent object before processing anyway.
- 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)
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
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.
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
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.