MAVLink, CAN and CANaerospace

[crashmatt]

Pete drew my attention to the possibility of the MAVlink community
choosing to write CANaerospace translation.

I have some interest in CAN since my UDB connects to the servos and
radio via CAN.
My interest is transporting control demand, flight surface and
aircraft IMU data between processors and dataloggers.

Some observations on the CANaerospace specification:

1. Its good that there is a specification out there. We dont like re-
inventing things.

2. CAN aerospace is based on standard length CAN identifiers.
It has to use some of the 8 byte message data payload to use as
message identifiers. This halves the data bandwidth.

3. Most processors support CAN2.0B which can use extended
identifiers. This extends the identifier length from 11bits to
29bits.
The extra identifier length leaves more space for the data payload
making it more efficient.

4. There are data types missing from the CANaerospace specification.
The most obvious for our UAV application is camera position.
Also missing is numerous control surface positions and a few flight
controls.

However, the identifiers that are there are quite thorough. There is
even an identifier for "Landing gear #n brake
pad thickness".

My first impression:
I was hopeful that this would be a good solution. I am now doubtful.
The message packing is pretty inefficient. We could do better.
If we really wish to send MAVlink over CAN, it may be best to break
the data packets into 8 byte chunks, send and re-assemble them at the
other side.
The existing UDB CAN protocol drivers already do this with long data
frames.

Hope some of this makes sense.

Regards Matt

[Mariano I. Lizarraga]

Hello Matt,
We too have some interest in having Mavlink over CAN. This is something that we are planning on tackling over the summer, or maybe before that for several things.

I do agree that using one (or more) of the payload bytes as an "extended" identifier is rather inefficient but by moving to an extended frame Mavlink/CAN converter would not be CANAerospace compliant, what advantages do you think are lost by not being "compliant"?.

--
Mariano

[crashmatt]

Mariano,
I posted a response to your question but I can not see it. Do you see
a new posting?
Matt

[qgroundcontrol]

Can you repost please? It also didn't end up in any Google Groups
filter, so your message never reached here.

Since you already read the documentation - can you maybe propose a
mapping between CAN device/bus IDs and component IDs?

We're also interested in getting MAVLink on CAN, so it might make
sense to discuss now the different approaches openly. Soon enough
several projects will want to implement it.

[malife]

Hello Matt.

 I did receive your very detailed response (thank you) via email, and looking at the addresses you sent it to it should have appeared here, I guess something went wrong.

I will wait for your re-post to reply to it because I think once everyone reads it they will agree with you in the fact that we are better off doing our own CAN implementation than depending on CANAerospace.

-- Mariano 

[crashmatt]

I hit reply to author by mistake. Classic user problem.

Mariano, Please can you either post it back to me or post it in the
forum on my behalf.

The post is only my opinion based on a relatively quick read of the
specification.
It would be wise for at least one other person in the group to form an
opinion based on their own understanding of it.

Regards Matt

[malife]

Here is the Matt's Response:

====

Good question. Much of this depends on application.

Not being compliant means we have to make something up for ourselves
and we can not connect to CANaero devices.
CANaero has lots of nice shiny features such as software download to
nodes.
There is quite a bit of future proofing features for those who are
dreaming of bigger systems.

On the down side:
Any one existing CANaero instrument is likely to double the mass of my
complete airframe.

We loose lots of bandwidth. CANaero demands a separate message for
each of my actuators and radio channels. 8 inputs, 7 outputs = 15
messages.
CANaero appears to demand an acknowledge message for every data
transmission so thats an extra 15 messages.
My system does all this in 4 messages.

Compliance might be tough for some of the smaller processors. The
UDB2 for example is completely out of resources.
If we end up with many nodes in a system, we need lower power, smaller
size and lower mass = small processors.
You may be running a quadrotor with a flight time of 10mins. You
spend most of your energy keeping it up.
I am flying a glider with a flight time of hours. I spend most of my
energy thinking about keeping it up.
A many node system seems to be the point of CANaero. If the system
uses CANaero it might not be able to have many nodes.

Examples:
A small node in the tail to connect to the servos and a TEK probe.
A node in each plug on wing to connect to flap, aileron, spoiler
servos and pitot-static probes.
Total node weight should be 10gram max, preferably 5gram.

Software libraries are critical. Writing a compliant software library
will not be easy.
Making the software library portable and scalable will be a greater
challenge.

I am not sure how the data units are defined.
For example with aileron position. Is it full scale degrees, % of
full scale or milliseconds of servo movement?

I have been trying to find how CANaero determines the difference
between a command and a reading. A flight surface needs both command
and feedback. It must be there somewhere.

There is also ARINC825 to consider. This is pretty much CANaero using
the extended identifier.
I cant find a specification for ARINC825.

Second impression:
Moved from cautiously optimistic to outright pessimistic. Still open
to arguments for using CANaero or ARINC.

Regards Matt

==

[crashmatt]

Thanks for reposting

An observation on my statement about processor capability.

I have been taking a look at lower power processors with CAN
capability. Here are the rough current consumptions per processor:

All currents are at 16MIPS. We probably do not need more MIPS for a
satellite processor.
dsPIC30F ~100mA
dsPIC33F ~50mA
STM32F103 ~20mA max
PIC32 ~25mA max est
MAXQ7670 ~14mA max

The MAXQ is the best I could find but it has quite limited features
compared to the others.
The surprise is just how good the STM32 processor is.

To put this current consumption in context, a good digital servo can
consume 100-150mA @5V with no load.
Servomances have great data on servos. Check it out here http://www.aeroglide.net/

In conclusion: We could afford to put a 32bit 16MIPS processor on
every servo and not really notice the extra current consumption.

Regards Matt

[malife]

Hello Matt,
Thanks for the complementary information, I have a couple of other suggestions to add to your list.

For s satellite processor I think a full blown 32-bit micro might be an overkill, if you are looking for low power you should look at some of the XLP variants in microchip, for instance, this family: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en550200 claims to have a puny 1600 uA power consumption max at 4 Mhz which could be enough for low-bandwidth applications.

The other one I would suggest taking a look at is the MCP25050: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010402 this is sort of the middle ground between a microcontroller and CAN expander. It has 6 DIO, 4 ADCs and 2 PWMs which can be configured and controlled over CAN but the unit is stand alone ( it still needs a transciever though). This is the one we will be using for our nodes.

Now I think we need to discuss a proposed layout for the 29 bits available for the identifier. I will post later today or tomorrow a proposal, or you can probably tell us how you are currently doing it.

Cheers!

[crashmatt]

Hi,

Mariano,

First, there is one more player in the CANbus UAV arena to consider.

Roberto Navoni, the brains behind Multipilot32 has an interest in CAN
connected servos and ESC's. He is connecting his own ESC with I2C.
http://www.virtualrobotix.com/page/vr-bl-controller-10

He is writing drivers for MP32. If these are compatible with your CAN
protocol it will increase demand for your CAN extension modules and
CAN in general.

In my design the identifier has the following information:
1. Message priority (critical message, critical control, high priority
data, telemetry data, low priority update etc..)
2. What is transmitting the message (autopilot, radio interface,
flight director, actuator, sensor)
3. Who is transmitting the message (sub address of device, not
implemented in my code)
4. What language(protocol) is about to be spoken (raw processor data,
MAVlink, virtual serial port telemetry link, etc..)

and the rest is dependent on the protocol. My choice for the
remaining bits was:
5. Data identifier
6. Index into data type (where data type is an array)
or
6. Sub value for data type
Variable data length was used to carry information on how many entries
in an array were read or are to be written.

This allows:
Tight packing of small time critical data sets for real time control
purposes.
Generic formatted lower priority telemetry data.

Do we end up with two levels of MAVlink, one for the telemetry layer
and one for the time critical control layer?

Regards Matt

On Mar 6, 5:52 pm, malife <mal...@gmail.com> wrote:
> Hello Matt,
> Thanks for the complementary information, I have a couple of other suggestions to add to your list.
>

> For s satellite processor I think a full blown 32-bit micro might be an overkill, if you are looking for low power you should look at some of the XLP variants in microchip, for instance, this family:http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en550200claims to have a puny 1600 uA power consumption max at 4 Mhz which could be enough for low-bandwidth applications.
>
> The other one I would suggest taking a look at is the MCP25050:http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010402this is sort of the middle ground between a microcontroller and CAN expander. It has 6 DIO, 4 ADCs and 2 PWMs which can be configured and controlled over CAN but the unit  is stand alone ( it still needs a transciever though). This is the one we will be using for our nodes.

[malife]

Hello Matt,

 thanks for posting those links. I have kind of a love-hate with I2C, so I'm not to fond of it :-)

I am about to post a proposal that borrows a lot from your current bit distribution, except that it focuses solely on MAVLink, i.e. there would be no "virtual serial port" or "telemetry" field  but everything would be  MAVLink ready. Feel free to make any comments to that, this is the plan we currently have in place for our nodes but you have more experience on adjusting MAVLink to CAN so your feedback is really appreciated.

Cheers!

[crashmatt]

My CANbus project has restarted, driven by the need for less wires in a space limited airframe.  The aim is to carry sensor and actuator data in a robust and possibly failsafe way.

It makes much sense to use MAVlink over CAN since it has the message identification and pack/unpack needed.  The question is exactly how to implement it.

CAN is a multidrop bus where MAVlink is normally a point to point architecture.
CAN message packets are limited to 8 bytes which does not fit most MAVLink packets
CAN messages have a 29bit identifier plus header, checksum, data length.

Only the shortest MAVlink messages will fit inside a CAN message. There are some choices:

1. CAN simply carries a MAVlink datastream in the same way that serial or UDP does.
2. CAN specific MAVlink message are defined that fit inside the 8 byte limit.

Looking at the test case of servo output. There are two messages that could be used, SERVO_OUTPUT_RAW or MAV_CMD_DO_SET_SERVO. Neither of these fit in the CAN message. 

MAV_CMD_DO_SET_SERVO has the potential to fit if it goes on a strict diet.

SERVO_OUTPUT_RAW needs to be split into three CAN messages and then re-assembled at the receive end.  The message needs sending more than once for airframes using more than 8 channels.  Variable length mavlink messages could really help here.  

If you are doing MAVlink streaming over CAN, you also need to carry the header,length,sequence, system, component, message id and crc.  That is an extra CAN message just for the overhead. For the SERVO_OUTPUT_RAW message it is a total of 4 CAN messages.

For my 12 servo channels, the total is now 8 x 8-byte CAN messages. How bad is this?

An 8 byte CAN message is 128bits long or 128us.  Presuming that the servo message is highest priority and nothing else interrupts, the total send time is 1.04ms. 

This is not so bad but it is not great either.  The same information could be packed into only 3 CAN messages taking 0.38ms.

The efficiency will be better as the mavlink message length increases.  Using either a specific servo message or a variable length mavlink message would bring it down to 5 CAN messages.  That is a pretty good compromise.

MAVlink over CANbus coming soon.

/Matt

[Susurrus]

Matt,

There's been some interest by other people in my lab in adding CAN support to this for a while, so we're very excited to hear that you're still working on it. It looks like you were involved in the previous discussion with Mariano back in 2011 [https://groups.google.com/d/msg/mavlink/gGyHAQ9PAdE/HR6cOOEAmjsJ], so I'm sure many things have been hashed out, but I wanted to ask for me and the group anyways:

1. a) Has there been an exploration of the existing CAN standards and how they package data? If not for compatibility, maybe for spec reuse as I'm sure this problem's been solved before? It looks like avionics-based CAN protocols were explored, but was CANopen (open) or NMEA2000 (proprietary) ever examined? I know NMEA2000 has a fairly sophisticated method of encoding metadata in the 29-bit extended message ID.

1. b) Is this protocol going to be MAVLink packaged into CAN packets or a re-implementation keeping in line with CAN limitations and effectively reworking packets? Previous discussion suggested a MAVLink-on-CAN (your case 2) approach while it sounds like you are discussing a MAVLink-over-CAN (your case 1) here.

2. You mention fitting everything into the body of the message, but by requiring CAN2.0B we can leverage the 29-bit header file to embed a lot of data. Currently the header & footer of the MAVLink come to 64-bits. The two-byte checksum is a footer, but can be replaced by the CRC field in a CAN and also be handled in hardware on a per-CANbus-packet level. If we use a specific packet ID as part of the CAN message ID that removes the extra 1-byte message start indicator. I think the message sequence only makes sense as part of the payload, but that leaves: messageID, systemID, componentID, and packet start. Packet start does not need to be a whole byte, but can be a single bit here. So we might even be able to encode message length as the extra 4-bits in the ID field (in units of CAN messages) which allows for 8*16 bytes of data (128).

I'm really interested in MAVLink-on-CAN or MAVLink-over-CAN, whichever the implementation may be, and am curious as to how your protocol currently works. Right now I'm using NMEA2000 for my onboard CAN network but would like to switch to an open standard, especially if it builds off of MAVLink, if possible. Additionally I'm interested in the onboard implementation being friendly to systems besides MAVs or even airborne vehicle (I work with a boat and ground rover) and want to make sure this format would be amenable to those kinds of systems.

Bryant

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe MAVLink beigetreten sind.
Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out
 
 

[crashmatt]

Bryant,

Great to hear of someone also interested in CAN.  My involvement with CAN stopped when I discovered greater limitations in other parts of my system.  Now that is fixed, I am back on the case.

The original scheme proposed sending c structure packed data which limited how it could be used. It was heading towards being based on ARINC825.  My concern with ARINC825 is that it consumes some of the data space in metadata.  This is ok for boeing and airbus since they mostly have a physical CAN node per function.  Messages are more point-to-point than broadcast.

CANopen and NMEA2000 were not considered at the time.  CANopen is nice and simple with basic broadcast messaging.   At the opposite end is the fully featured ISO 11783 Multi-Packet with large packet handling and flow control at the expense of bad latency.

The number of mavlink rx buffers is a concern with CAN.  It is possible to have multiple MAVlink starts on the bus at the same time, even originating from the same node. Failure to support this means that a long low priority message can hold the bus or a long low priority message is never delivered.

A limited wishlist:

• Easy to setup - plug and play?
• Must support message prioritization
• Support multiple protocols
• Redundancy support
• An automatic discovery service
• Finds physical nodes and/or logical services

Message priority and protocol take a few bits each at the start of the identifier.   I get the feeling that the MAVlink metadata will not fit, especially if we add more features.

The start bit is an interesting idea. If the start bit is asserted, that CAN frame could consume some of the data space for metadata just for the first frame.

I have been thinking that CAN needs to carry the existing MAVlink messages efficiently which is wrong.  MAVlink doesn't have suitable standard messages for passing around internal sensor/actuator data.  A set of new messages are required anyway.  We have the opportunity to define short messages suitable for a single CAN packet.

So do you choose a simple broadcast based system or a complex connection based system? The conclusion we came to was that you should do both at the same time.

The most difficult aspect of this is usability.  How will a user setup a system? How will the system know what to expect and what to do with the data?

Regards Matt

[crashmatt]

Here is a link to the MAVCAN document written in 2011.  It has a good description of broadcast messaging and an outline of how PTP messaging will work.

https://docs.google.com/document/d/1ktoPuBBSJjqZNDilymhvGytV-ucAk_wcWkDTwpa9IY0/edit?usp=sharing

Please request access to this document.  It is not public release

[malife]

Hello Matt and Bryant,

 It is great to see there is interest to start working on this again. Back in 2011 at some point we made a list of "requirements" and it was further corrected. I have added what has been discussed in the last week to the list as follows:

1. The 29-bit Extended identifier is preferred in order to have space to layout enough information in the identifier. This identifier would be used, among other things to implement message prioritization, messageID, systemID, componentID, and packet start.
   
2. There are two items living in the network: nodes and channels. A node is the access point to the network; a node itself can have multiple channels, for instance there could be a right wing node, that has four channels: two servos for ailerons, one servo for flaps and one to control lights. The channels do not have direct access to the network but only through its controlling node.
3. There are two main trains of thought about how to assign addresses to the channels (nodes):
• All the addresses are pre-compiled (defined either in an XML style file that gets converted to C or an outright header file), the user is in charge of making sure no ID collisions exist and that if a channel (node) needs to know about another it does so at compilation time.
• There is a central place where upon connection of a new channel (node) this central place assigns an address to it and it announces it on the network. Therefore there exists a network manager.
4. It is preferred that the messages do not exceed the maximum of 8 available bytes in CAN if possible.
5. A connectionless scheme is preferred but it was pointed out that different filters (in the CAN sense)  could be used to have peer-to-peer connections and connectionless messages live in the same node, just on different filters. It was further suggested to have the 1st set runs small, fast critical control data with no connection while the
     2nd set runs everything else in connected mode.
6. Those who prefer connectionless scheme then suggest that there are two types of messages: periodical (like a sensor reporting data) and asynchronous (for instance a command to move a servo or a camera, or report the movement of a servo or a camera).
7. Everyone agrees to keep it as simple as possible.
8. There were some suggestions about adopting one of the existing CAN in aerospace standards, either CANAerospace or ARINC 825. Those that have read about the standard feel like they are much more complex than what is needed for small research/amateur MAVs and that little is gained by being compliant.
9. The channels (or nodes) that are related to actuators (servos mainly) should have a "zero position" (which could be no signal or no drive.) upon boot and until it gets a command from another node on the network.
10. The chosen implementation should not be a forcing of MAVLink into CAN but rather something that is as simple as MAVLink to implement on board and use but at the same time makes sense from a CAN perspective.
11. The last issue on the table was how to go about assigning addresses. Everyone agreed that precompiled addresses was a no-go since this could lead to a lot of recompiling in event of a change in addressing. The only option left was that these addresses be assigned at runtime either read from an EEPROM, via a DIP Switch or some other way but seemed like this was going to be left to the end user to decide must likely at the hardware level. Just recently it has been suggested to implement an automatic discovery system (see item 3 bullet 2).
12. Redundancy support.
13. It should be universal and not only designed to be used by UAVs.

I've requested access to the document you linked before so I can take a look at it and see if we can decide upon the correct requirements and structure.

Cheers!

[crashmatt]

Mariano,

Great to hear from you again.  I had forgotten how much we had discussed about this.  Many thanks for the reminder.

I did have my doubts about ARINC825 but in the end it became quite attractive. if we operate with the "special message" bit set, we can stay close to ARINC825 without the burden of 100% compatibility.

I can now see the need for three communication modes.  Broadcast, PTP streaming and PTP messaging.  PTP streaming is to carry raw MAVlink.  PTP messaging is to do node discovery and setup.

We started to discuss how a user might setup a system.  I think we need to put more detail on this.  There are some options between having an eeprom based or hard coded setup. My more paranoid side leans towards hard coded, especially for it's simplicity.

Regards Matt

[Meier Lorenz]

Hi all,

I've looked in the meantime a bit at the different standards. I'm not convinced there is much to win to force MAVLink onto the bus, since the scope of the message set and length / overheads / update rates do not match well.

I still think this is a very good platform to discuss this, because the groups having contributed to MAVLink similarly are interested in CAN.

So far my main concerns are:

1) MAVLink might not really fit the bus well

2) ARINC 825 has very expensive standard documents (correct me if I'm wrong) and a pretty broad scope

3) CANOpen might be attractive as there is a lot of work already in the classic robotics domain - has anybody worked with it and can comment on this?

4) CANAerospace has public and pretty compact docs. Despite the simplicity, I had no hard time identifying most messages of interest for me.

I agree on matt's analysis of this:

I can now see the need for three communication modes. Broadcast, PTP streaming and PTP messaging. PTP streaming is to carry raw MAVlink. PTP messaging is to do node discovery and setup.

And discovery / setup is certainly really, really important. Has anyone worked out some more detail, or can comment on ARINC 825 in this regard?

Note that I think it's important that we aim for a standard that fits the needs / scope / ecosystem, and should not try to squeeze it into something that was made for a different purpose scope (else everybody would be running SAE AS-4 on their telemetry links now, but somehow only few do (any examples?)).

-Lorenz

------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

On Jun 12, 2013, at 2:28 PM, crashmatt <uavfligh...@gmail.com<mailto:uavfligh...@gmail.com>> wrote:

Mariano,

Great to hear from you again. I had forgotten how much we had discussed about this. Many thanks for the reminder.

I did have my doubts about ARINC825 but in the end it became quite attractive. if we operate with the "special message" bit set, we can stay close to ARINC825 without the burden of 100% compatibility.

I can now see the need for three communication modes. Broadcast, PTP streaming and PTP messaging. PTP streaming is to carry raw MAVlink. PTP messaging is to do node discovery and setup.

We started to discuss how a user might setup a system. I think we need to put more detail on this. There are some options between having an eeprom based or hard coded setup. My more paranoid side leans towards hard coded, especially for it's simplicity.

Regards Matt


On Wednesday, June 12, 2013 6:49:41 AM UTC+2, malife wrote:
Hello Matt and Bryant,
It is great to see there is interest to start working on this again. Back in 2011 at some point we made a list of "requirements" and it was further corrected. I have added what has been discussed in the last week to the list as follows:

1. The 29-bit Extended identifier is preferred in order to have space to layout enough information in the identifier. This identifier would be used, among other things to implement message prioritization, messageID, systemID, componentID, and packet start.
2. There are two items living in the network: nodes and channels. A node is the access point to the network; a node itself can have multiple channels, for instance there could be a right wing node, that has four channels: two servos for ailerons, one servo for flaps and one to control lights. The channels do not have direct access to the network but only through its controlling node.
3. There are two main trains of thought about how to assign addresses to the channels (nodes):
* All the addresses are pre-compiled (defined either in an XML style file that gets converted to C or an outright header file), the user is in charge of making sure no ID collisions exist and that if a channel (node) needs to know about another it does so at compilation time.
* There is a central place where upon connection of a new channel (node) this central place assigns an address to it and it announces it on the network. Therefore there exists a network manager.
4. It is preferred that the messages do not exceed the maximum of 8 available bytes in CAN if possible.
5. A connectionless scheme is preferred but it was pointed out that different filters (in the CAN sense) could be used to have peer-to-peer connections and connectionless messages live in the same node, just on different filters. It was further suggested to have the 1st set runs small, fast critical control data with no connection while the

2nd set runs everything else in connected mode.

6. Those who prefer connectionless scheme then suggest that there are two types of messages: periodical (like a sensor reporting data) and asynchronous (for instance a command to move a servo or a camera, or report the movement of a servo or a camera).
7. Everyone agrees to keep it as simple as possible.
8. There were some suggestions about adopting one of the existing CAN in aerospace standards, either CANAerospace or ARINC 825. Those that have read about the standard feel like they are much more complex than what is needed for small research/amateur MAVs and that little is gained by being compliant.
9. The channels (or nodes) that are related to actuators (servos mainly) should have a "zero position" (which could be no signal or no drive.) upon boot and until it gets a command from another node on the network.
10. The chosen implementation should not be a forcing of MAVLink into CAN but rather something that is as simple as MAVLink to implement on board and use but at the same time makes sense from a CAN perspective.
11. The last issue on the table was how to go about assigning addresses. Everyone agreed that precompiled addresses was a no-go since this could lead to a lot of recompiling in event of a change in addressing. The only option left was that these addresses be assigned at runtime either read from an EEPROM, via a DIP Switch or some other way but seemed like this was going to be left to the end user to decide must likely at the hardware level. Just recently it has been suggested to implement an automatic discovery system (see item 3 bullet 2).
12. Redundancy support.
13. It should be universal and not only designed to be used by UAVs.

I've requested access to the document you linked before so I can take a look at it and see if we can decide upon the correct requirements and structure.

Cheers!

On Tuesday, June 11, 2013 2:03:10 PM UTC-5, crashmatt wrote:
Here is a link to the MAVCAN document written in 2011. It has a good description of broadcast messaging and an outline of how PTP messaging will work.

https://docs.google.com/document/d/1ktoPuBBSJjqZNDilymhvGytV-ucAk_wcWkDTwpa9IY0/edit?usp=sharing

Please request access to this document. It is not public release

On Monday, June 10, 2013 2:37:46 PM UTC+2, crashmatt wrote:
Bryant,

Great to hear of someone also interested in CAN. My involvement with CAN stopped when I discovered greater limitations in other parts of my system. Now that is fixed, I am back on the case.

The original scheme proposed sending c structure packed data which limited how it could be used. It was heading towards being based on ARINC825. My concern with ARINC825 is that it consumes some of the data space in metadata. This is ok for boeing and airbus since they mostly have a physical CAN node per function. Messages are more point-to-point than broadcast.

CANopen and NMEA2000 were not considered at the time. CANopen is nice and simple with basic broadcast messaging. At the opposite end is the fully featured ISO 11783 Multi-Packet with large packet handling and flow control at the expense of bad latency.

The number of mavlink rx buffers is a concern with CAN. It is possible to have multiple MAVlink starts on the bus at the same time, even originating from the same node. Failure to support this means that a long low priority message can hold the bus or a long low priority message is never delivered.

A limited wishlist:

* Easy to setup - plug and play?
* Must support message prioritization
* Support multiple protocols
* Redundancy support
* An automatic discovery service
* Finds physical nodes and/or logical services

Message priority and protocol take a few bits each at the start of the identifier. I get the feeling that the MAVlink metadata will not fit, especially if we add more features.

The start bit is an interesting idea. If the start bit is asserted, that CAN frame could consume some of the data space for metadata just for the first frame.

I have been thinking that CAN needs to carry the existing MAVlink messages efficiently which is wrong. MAVlink doesn't have suitable standard messages for passing around internal sensor/actuator data. A set of new messages are required anyway. We have the opportunity to define short messages suitable for a single CAN packet.

So do you choose a simple broadcast based system or a complex connection based system? The conclusion we came to was that you should do both at the same time.

The most difficult aspect of this is usability. How will a user setup a system? How will the system know what to expect and what to do with the data?

Regards Matt

On Sunday, June 9, 2013 8:36:27 PM UTC+2, Bryant wrote:
Matt,

There's been some interest by other people in my lab in adding CAN support to this for a while, so we're very excited to hear that you're still working on it. It looks like you were involved in the previous discussion with Mariano back in 2011 [https://groups.google.com/d/msg/mavlink/gGyHAQ9PAdE/HR6cOOEAmjsJ], so I'm sure many things have been hashed out, but I wanted to ask for me and the group anyways:

1. a) Has there been an exploration of the existing CAN standards and how they package data? If not for compatibility, maybe for spec reuse as I'm sure this problem's been solved before? It looks like avionics-based CAN protocols were explored, but was CANopen (open) or NMEA2000 (proprietary) ever examined? I know NMEA2000 has a fairly sophisticated method of encoding metadata in the 29-bit extended message ID.

1. b) Is this protocol going to be MAVLink packaged into CAN packets or a re-implementation keeping in line with CAN limitations and effectively reworking packets? Previous discussion suggested a MAVLink-on-CAN (your case 2) approach while it sounds like you are discussing a MAVLink-over-CAN (your case 1) here.

2. You mention fitting everything into the body of the message, but by requiring CAN2.0B we can leverage the 29-bit header file to embed a lot of data. Currently the header & footer of the MAVLink come to 64-bits. The two-byte checksum is a footer, but can be replaced by the CRC field in a CAN and also be handled in hardware on a per-CANbus-packet level. If we use a specific packet ID as part of the CAN message ID that removes the extra 1-byte message start indicator. I think the message sequence only makes sense as part of the payload, but that leaves: messageID, systemID, componentID, and packet start. Packet start does not need to be a whole byte, but can be a single bit here. So we might even be able to encode message length as the extra 4-bits in the ID field (in units of CAN messages) which allows for 8*16 bytes of data (128).

I'm really interested in MAVLink-on-CAN or MAVLink-over-CAN, whichever the implementation may be, and am curious as to how your protocol currently works. Right now I'm using NMEA2000 for my onboard CAN network but would like to switch to an open standard, especially if it builds off of MAVLink, if possible. Additionally I'm interested in the onboard implementation being friendly to systems besides MAVs or even airborne vehicle (I work with a boat and ground rover) and want to make sure this format would be amenable to those kinds of systems.

Bryant

On 06/08/2013 11:44 PM, crashmatt wrote:
My CANbus project has restarted, driven by the need for less wires in a space limited airframe. The aim is to carry sensor and actuator data in a robust and possibly failsafe way.

It makes much sense to use MAVlink over CAN since it has the message identification and pack/unpack needed. The question is exactly how to implement it.

CAN is a multidrop bus where MAVlink is normally a point to point architecture.
CAN message packets are limited to 8 bytes which does not fit most MAVLink packets
CAN messages have a 29bit identifier plus header, checksum, data length.

Only the shortest MAVlink messages will fit inside a CAN message. There are some choices:

1. CAN simply carries a MAVlink datastream in the same way that serial or UDP does.
2. CAN specific MAVlink message are defined that fit inside the 8 byte limit.

Looking at the test case of servo output. There are two messages that could be used, SERVO_OUTPUT_RAW or MAV_CMD_DO_SET_SERVO. Neither of these fit in the CAN message.
MAV_CMD_DO_SET_SERVO has the potential to fit if it goes on a strict diet.
SERVO_OUTPUT_RAW needs to be split into three CAN messages and then re-assembled at the receive end. The message needs sending more than once for airframes using more than 8 channels. Variable length mavlink messages could really help here.

If you are doing MAVlink streaming over CAN, you also need to carry the header,length,sequence, system, component, message id and crc. That is an extra CAN message just for the overhead. For the SERVO_OUTPUT_RAW message it is a total of 4 CAN messages.

For my 12 servo channels, the total is now 8 x 8-byte CAN messages. How bad is this?

An 8 byte CAN message is 128bits long or 128us. Presuming that the servo message is highest priority and nothing else interrupts, the total send time is 1.04ms.
This is not so bad but it is not great either. The same information could be packed into only 3 CAN messages taking 0.38ms.

The efficiency will be better as the mavlink message length increases. Using either a specific servo message or a variable length mavlink message would bring it down to 5 CAN messages. That is a pretty good compromise.

MAVlink over CANbus coming soon.

/Matt

On Tuesday, March 8, 2011 2:07:58 AM UTC+1, malife wrote:
Hello Matt,
thanks for posting those links. I have kind of a love-hate with I2C, so I'm not to fond of it :-)

I am about to post a proposal that borrows a lot from your current bit distribution, except that it focuses solely on MAVLink, i.e. there would be no "virtual serial port" or "telemetry" field but everything would be MAVLink ready. Feel free to make any comments to that, this is the plan we currently have in place for our nodes but you have more experience on adjusting MAVLink to CAN so your feedback is really appreciated.

Cheers!

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe MAVLink beigetreten sind.
Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out




--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe MAVLink beigetreten sind.

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com<mailto:mavlink+u...@googlegroups.com>.
Weitere Optionen: https://groups.google.com/groups/opt_out

[malife]

Hello, 

See my comments inline

On Wednesday, June 12, 2013 9:15:22 AM UTC-5, lm wrote:

Hi all,

I've looked in the meantime a bit at the different standards. I'm not convinced there is much to win to force MAVLink onto the bus, since the scope of the message set and length / overheads / update rates do not match well.

I too agree on this: I think MAVLink-over-CAN is really not a good idea,  and this has been a concern since the discussions back in 2011

 

I still think this is a very good platform to discuss this, because the groups having contributed to MAVLink similarly are interested in CAN.

So far my main concerns are:

1) MAVLink might not really fit the bus well

Agree, whatever we end up doing has to have the same spirit as MAVLink but it has to be completely tailored to work in the CAN "philosophy".

 

2) ARINC 825 has very expensive standard documents (correct me if I'm wrong) and a pretty broad scope

3) CANOpen might be attractive as there is a lot of work already in the classic robotics domain - has anybody worked with it and can comment on this?

4) CANAerospace has public and pretty compact docs. Despite the simplicity, I had no hard time identifying most messages of interest for me.

I agree on matt's analysis of this:
I can now see the need for three communication modes.  Broadcast, PTP streaming and PTP messaging.  PTP streaming is to carry raw MAVlink.  PTP messaging is to do node discovery and setup.

I too agree with the need for these three modes, but  PTP streaming should be geared to carry a stream of bytes, raw MAVLink or anything else. 

Also I think it is now a good time to prioritize the implementation of these three modes. Thus, which is the first one that needs to be implemented? I propose that we implement (1) Broadcast, (2) PTP messaging, and (3) streaming.

 

And discovery / setup is certainly really, really important. Has anyone worked out some more detail, or can comment on ARINC 825 in this regard?

I too agree this has a very high priority and should be implemented from the get go. 

The only issue left is address assignment, where it seems to be leaning towards being "hard coded" either in software (maybe preconfiguration via an XML file like MAVLink for message ID) or via hardware configuration (EEPROM, DIP Switch, etc...).

 

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com<mailto:mavlink+unsu...@googlegroups.com>.
Weitere Optionen: https://groups.google.com/groups/opt_out

[crashmatt]

Lorenz, Mariano,

I agree that mavlink doesn't fit well over CAN.  Using the existing mavlink parser is simply convenient, especially if editing mavlink parameters of CAN nodes. 

My understanding is that CANAero and ARINC825 are similar or one is based on the other.  I am now not so sure what we started with. 

CANopen has well established stacks and toolchains and I can see the benefit of that.  I have been reading into it a bit.  It suspect it is too complex for the majority of users.

As a user, I might like a system that looks like:

  Sensor type A is number N on Node X and transmits every T seconds

  User of type A number N on Node Y and expects a message every T seconds.

  Actuator source type B number 0 to N on node Y transmits every t seconds

  Actuator type B number N on node X takes expects a message every t seconds.

  Datastream source type C is number N on Node Y

  Datastream sink type C is number N on Node X

Putting this information in an xml file is not so difficult.  I wonder if it is possible to compile this into a CANopen compatible setup/format.

There is a particularly nice setup gui in the IXXAT CANopen configuration tool which would be user friendly:

http://www.ixxat.com/portal/pics/canopen_configstd_obj_linker.gif

Not sure that the gui justifies the effort.

Regards Matt

Hello, 

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com<mailto:mavlink+unsubscribe@googlegroups.com>.
Weitere Optionen: https://groups.google.com/groups/opt_out

[crashmatt]

A significant difference between CANopen and CANaero is the data addressing.  

  CANopen uses a linear list of data object identifiers.  

  CANaero uses a node type, node number and data object number.

CANopen needs a separate data object for every thing on the network.  It's list of data objects change depending on what is attached to the network.  Every node on the network needs it's data object list synchronizing.

CANaero allows up to 126  functions of any type to be added to the network without changing the data object definition.

I see CANaero as being easier to maintain and debug so I am now leaning towards CANaero/CANMAV as my favorite.

I might be wrong and I might change my mind again.

Regards Matt

[crashmatt]

My work on CAN is on hold again until I work out how to make my mavproxy modules compatible with the new mavproxy version.

[crashmatt]

More thoughts on linear identifier list or service type + service identifier

mavlink works as a linear identifier list enumerated into MAV_COMPONENT

Example: If you wish to parse messages from all servos, you need to filter for all components between 140 and 153

MAV_COMP_ID_SERVO1 or  MAV_COMP_ID_SERVO2 or  MAV_COMP_ID_SERVO3   etc...

Every time a new component type is added, it needs a suitable range  and a long filter statement.  This is ok if you can automate code generation for this bit of the parser.  You would still need some parent type assigned so that the automatic code generation knows that it should lump all of these into the same class./parsing.

The linear addressing also makes fast data transfer to many nodes of the same type difficult.  Say you output servo positions as an array or group command them to failsafe positions.

It looks much easier to parse directly on service type.  It also looks more CAN filter compatible.  Can't think of any negatives at the moment.

Maybe this component addressing change should also be a recommendation for mavlink 2.0

Regards Matt

[crashmatt]

Does MAVCAN need to be part of mavlink?

A valuable part of mavlink is the data packing. Why is that needed for MAVCAN?

The data packing allows easy communication between mav and gcs which can be using different languages.

Communication over CAN is not so much of a problem.  It is most likely that there is C at both ends.

The same c library of data structures can be used at both ends.  

Result:MAVCAN does not need to have its enumerations and messages defined in mavlink

Going to take a fresh look at NMEA 2k

[malife]

I did not want to continue posting until I had actually gone and read the CANAerospace Interface specification So I downloaded it (Version 1.7) and read it with some detail.

It turns out that I think the CANAerospace does pretty much everything that we've discussed. I think the only thing I slightly dislike about CANAersopace is the use of 4 bytes of payload to further characterize the message, this could've been done using the 29-bit identifier with almost the same result and having 8 bytes available for payload. But besides that I think it has been well thought out. 

I think there are a few things that are not fully explained on the Interface Specification, like for instance what is the correct sequence of events when a new node joins a network, or a node wants to discover the nodes in the network. In that sense I was expecting a more detailed description like the one offered for the Interface Protocol or the Waypoint Protocol in MAVLink. But that is something that can be solved with documentation or examples, because the spec takes both cases into account.

The implementation I looked at in C (https://bitbucket.org/pavel_kirienko/canaerospace) I think is too platform dependent for my taste. It is focused on the STM32 (nothing wrong with that, just not a part I use :-) ) but besides that, it is well documented and could be easily forked to make it more platform independent, or at least decouple hardware from the actual protocol.

What is it that any of you particularly dislike about CANAerospace that could be better implemented in MAVCAN?

[crashmatt]

Mariano,

That was the very thing that bugged me about CANaero.  If the message carries a float value, there is not even space to put a timestamp next to it.  We can do better than that.

Whatever the CAN protocol is there does need to be a groundstation for configuration of the bus.  The best way for us to communicate is to use the existing telemetry communication.  None of us wants to add a new physical interface to our groundstation platform.  Transferring CANbus packets over telemetry might be a good way and that means CANbus over MAVlink.  That may also drive requirement for xml defined language and generated parsers, especially if python is involved.

Due to yet more distractions I need to keep this simple.  I will stick with a broadcast based protocol that can be expanded to add a connection based protocol with the discovery service.  It looks like I will be delayed until winter at earliest.

Also: NMEA2K does not feel like a good choice.  There is a cost of access to the standard.  This pretty much means reverse engineering it to get support from marine specific tools that are no use to mav.

Regards Matt

[Lorenz Meier]

Hi Folks,

To move this discussion a bit to the more problem-solving side - we have started to implement the CAN driver on PX4FMU, and we're tinkering with a CAN enabled electronic speed controller. Both is very early days, but potentially something where others might be interested to contribute to.

We have decided to give CANaerospace a shot, and will base our effort on Pavel Kirienko's library:

https://bitbucket.org/pavel_kirienko/canaerospace

The current WIP is here:

https://github.com/PX4/Firmware/tree/can-device

As a lot is currently going on with PX4 and so this is (not yet) our current main focus, we would be in particular very interested in people tinkering on the bringup of the CAN peripheral.

This does not imply that CANaerospace will be sufficient, but before attempting to create a new standard that unifies everything but becomes competing standard #111 instead, we'd like to see if we can start with this and extend if / where needed.

That said, a basic level of ARINC 825 would also be interesting (which to my understanding CANaerospace in many way is) - but because the specs are not freely available, it would need a group who re-creates the required document in a copyright-clear fashion.

-Lorenz

[Pavel Kirienko]

Hi Mariano,

Thanks for the feedback!

However, this part is not exactly perfectly correct:

> I think is too platform dependent for my taste. It is focused on the STM32

Nope. Wrong.

It is designed to be as hardware-agnostic as possible. Probably I failed to document this feature properly, hence the misunderstanding - I'll try to improve the documentation in this regard.

The CANaerospace logic is decoupled from the hardware drivers through the simple interface.

It is not a big deal to bind any other CAN driver via this set of calls. The library includes two completely different drivers out of the box: STM32 and Linux SocketCAN, and both of them are interfaced in the same manner.

Could you please describe what hardware you are going to use with CANaerospace? Maybe I can give some hints on this matter, or we can consider adding a driver into the main branch.

Thanks again,

Pavel.

[Marek M.]

W dniu środa, 4 września 2013 17:54:41 UTC+2 użytkownik Pavel Kirienko napisał:

Could you please describe what hardware you are going to use with CANaerospace? Maybe I can give some hints on this matter, or we can consider adding a driver into the main branch.

Hi Pavel,

Just found this place about CANaerospace - and... here is a lot of usefull info.

I just starting a new project for integration of RC control and telemetry(radiomodems) based on AutoPilotMega hardware.

During research and design - one of main issues is amount of connectors :)

So my first idea is to split suystem into several modules - CANaerospace looks very interesting as a "connector" between them.

First module - RF transmission unit + main processor - is based on RFD4432F27 modules (434/868 MHz, 500 mW) and STM32F415RG. This particular processor - mainly for its embedded crypto features.

Second - servo/serial/i2c interface. Connection - CAN 1 Mbit/s. Processor - STM32F1?? or similar (wish to stay on STM32 line).

If you have any suggestions - hardly welcome :)

Best

Marek 

[Pavel Kirienko]

Hi Marek,

Hardly I can suggest you a lot. :) Your considerations look fair to me.

If you're concerned about future compatibility with 3rd party hardware, this may come useful: https://groups.google.com/forum/#!topic/mavlink/dHDkRd1vT3k

Best regards,

Pavel.

[crashmatt]

CANaerospace = standard 11 bit CAN identifier

At 1Mbps maximum frame rates are

Standard ~8116Hz

Extended ~6993Hz

Standard frame has 4byte payload

Extended frame has 8byte payload (given all overhead in 29bit identifier)

Total bandwidth capacity

Standard ~32.5kbyte/s

Extended ~55.9kbyte/s

Please correct me on this if I am wrong:

CANaerospace is based on transmitting single system values per frame.  An 8ch servo system takes 8 frames.

Transmitting a compact structure or array of int16_t servo positions takes 16bytes.  In extended that is 2 frames.

So servo refresh rate for 8 servo channels only

CANaerospace ~4kHz

Extended alternative ~14kHz

of which you can use about 50% of this bandwidth to keep the system reliable.

Now say you have a CAN based failsafe.  That might be 8 RC channels, 8 autopilot channels and 8 servo outputs and 8 servo/ESC feedbacks, total 32 frames

CANaerospace is down to ~510Hz refresh rate with bandwidth de-rating

If you can't broadcast data structures, how does the CAN messaging system connect with the PX4 internal messaging system?

I can't help feeling that CAN aero is limited but this may be based on my bad interpretation of the standard.

Regards Matt

[Pavel Kirienko]

Hi Matt,

The main points of your message are absolutely correct.

1. CANaerospace assumes that one message carries exactly one parameter;

2. CANaerospace is NOT efficient in the sense of data overhead.

Regardless of the statements above, your approach to transferring parameters as raw servo positions is not exactly correct.

The philosophy of CANaerospace assumes that each parameter that can be transferred over the bus represents some abstract data item, such as measurement or high-level command, rather than raw directive to some particular node of some particular setup. Applying this idea to your servo node: you have to define what devices are driven by the connected servos, and by which CANaerospace parameters they should be controlled.

Example: a servo driving node is connected to rudder and elevator servos.

Proper approach: let the node listen to the parameters 403 (Yaw control position) and 400 (Pitch control position) and drive the servos accordingly (consult with the specification for other parameter codes).

Improper approach: define a set of parameters for servo node, drive servos directly by these parameters (this is against CANaerospace philosophy).

See, CANaerospace as well as other CAN-based protocols should not be mistaken with low-level raw data interfaces. It should be considered as a system component that allows to hide any implementation details behind well-defined set of parameters.

Regarding the throughput:

> Extended frame has 8byte payload (given all overhead in 29bit identifier)

No, extended identifiers are used for redundancy support. Refer to the chapter 7 of the specification.

However, it is possible to pack 6 bytes into one extended message as I described in the comment to this post: http://diydrones.com/profiles/blogs/can-bus-conventions-for-small-uav

Throughput is what I am concerned about, too. CANaerospace seems to be inefficient in terms of CAN message format. I can easily imagine better frame format that allows to carry all the required fields along with 8-byte payload per one extended CAN message, as well as I can imagine some very good uses for 8-byte payload. But I am not going to propose a better protocol until I've seen CANaerospace v2.0 specification, which I should get around November. Then we should decide if we need to design our own ultimate CAN protocol, or CANaerospace 2.0 is good enough. As for current CANaerospace standard - we could do better for sure.

Best regards,

Pavel Kirienko.

[crashmatt]

Pavel,

I do understand the broadcast or generator consumers approach with CAN, very much like the PX4 code with uORB.  I used to think that the simple short message delivery was the right way until I looked at uORB.  Then I started to think that CAN should be an extension of uORB.

I also understand the importance of layering up and abstracting away the hardware.  No arguments there.

Interesting that CANaero 2.0 is about to arrive.  If that has more of the services available in ARINC825 that would be good.

Say you transmit the rc channels from failsafe to autopilot in single pieces.  Something at the failsafe has to split up and transmit each channel.  Something on the autopilot end has to collect together the data transmissions and determine when you have properly received the whole rc frame.  Then it would present that result to uORB.  This is one case.  You then need to hand code all the other cases.  I just can't see how this nicely fits in the system.

On the horizon somehwere is CAN VBR which packs up to 64bytes of data into the same timeframe using the same transceiver hardware.  Be a while before processors are available but it will be fun when they arrive.

Regards Matt

[Pavel Kirienko]

Matt,

Can you please elaborate on CAN VBR, 64 bytes per the same timeframe? This sounds interesting, shame I have not heard about it before, and some googling was not rewarding.

Regards,

Pavel.

--
Sie erhalten diese Nachricht, weil Sie in Google Groups ein Thema der Gruppe "MAVLink" abonniert haben.
Um Ihr Abonnement für dieses Thema zu beenden, rufen Sie die URL https://groups.google.com/d/topic/mavlink/GsAzERgnegE/unsubscribe auf.
Um Ihr Abonnement für diese Gruppe und alle ihre Themen zu beenden, senden Sie eine E-Mail an mavlink+u...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out

[Piotr Esden-Tempski]

I think Matt means CAN FD.

http://www.can-wiki.info/doku.php?id=can_fd

Cheers Piotr

Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "MAVLink" sind.
Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out

[crashmatt]

Esden,

That's the one.   I got it confused with video encoding.  I only came across it recently.

Just to be completely clear about "structure" transport.  The lower layers would split, carry and reconstruct data longer than a single CAN packet.  It is up to the application layer to determine the shape of the data to be sent.  Need to improve my terminology.

/Matt

[crashmatt]

I can't see a control #N position message in MAVaero so the following messages would be needed to support a wider range of airframes:

Left inboard flap position

Right inboard flap position

Left inboard-mid flap position

Right inboard-mid flap position

Left outboard-mid flap position

Right outboard-mid flap position

Airbrake position vs speedbrake position, may need bothfor some aircraft

Left spoiler/speedbrake position

Right spoiler/speedbrake position

Left rudderbrake/ruddervon position

Right rudderbrake/ruddervon position

Doesn't seem to be much spare message space in the low 300's where these high priority data messages are placed.

/Matt

[Pavel Kirienko]

Hi Matt,

> Doesn't seem to be much spare message space in the low 300's where these high priority data messages are placed.

Yes.

I tried to extend the standard identifier layout: https://bitbucket.org/pavel_kirienko/canaerospace/src/903d4fb7ed02968cdb9837e27aba4ef4efe3df32/canaerospace/include/canaerospace/param_id/uav.h?at=default

Now I think that we need to define the new message ID layout from scratch.

For reference, there is the default ID distribution: https://bitbucket.org/pavel_kirienko/canaerospace/src/903d4fb7ed02968cdb9837e27aba4ef4efe3df32/canaerospace/include/canaerospace/param_id/nod_default.h?at=default

If you're ready to start defining new ID distribution for UAVs, that's cool. We can integrate this into libcanaerospace at once. Otherwise I am going to address this and some other CAN related issues somewhere at the end of November.

Regards,

Pavel.

[crashmatt]

Pavel,

I am not ready to make changes.  I am just thinking a bit before doing.

Starting from scratch makes sense.  I can't see much need for some existing messages such as "propeller #n ice guard DC current" and "Landing gear #n bra­ke pad thickness"

A uav is dependent on a fly-by-wire system which a full-size light aircraft can have but normally doesn't.  A full size aircraft tends to have simple mechanical connections to its flight surfaces so CANaero is more focused on auxillary system messages.  

A failsafe is a node which receives command from the ground used to control the aircraft and can fly the aircraft without need of the autopilot.  There can be more than one failsafe node for redundancy.  The mixer must be in the failsafe or the nodes driving the servos.  There needs to be messaging for each of the layers of signals depending on where you want to put them.

Something I have not understood about CANaero is exactly what a node is.  

What happens if you take multiple barometeric pressure sensor readings aroudn the aircraft and merge them?  Each sensor could be identified by having a different node number.  This is in conflict with how the other messages are defined.  The engines are the best example where they are defined as engine #N

A full scale aircraft is likely to have a CAN node per function. A uav is much more likely to have multiple functions per node.  Space and cost constraints make a a node per function prohibitive.

CANaero does not fit all cases.  The above issues are just some extra cases that I am thinking of for my particular system.  Everybody will have different needs.  If I define a fixed list of messages it would almost certainly be wrong.

I would not start with a list of messages.  I would start with a way to make the list easier to change.

Regards Matt

[Pavel Kirienko]

Matt,

> What happens if you take multiple barometeric pressure sensor readings aroudn the aircraft and merge them?  Each sensor could be identified by having a different node number.  This is in conflict with how the other messages are defined.  The engines are the best example where they are defined as engine #N

> A full scale aircraft is likely to have a CAN node per function. A uav is much more likely to have multiple functions per node.  Space and cost constraints make a a node per function prohibitive.

No, node numbers (Node IDs) have nothing to do with functions. Node IDs should be used mainly for maintenance purposes (configuration, monitoring, network discovery), rather that participate in higher-level logic.

In your example with barometers you described the use case for redundancy channels: Multiple nodes that perform the same function shall provide Redundancy Channel ID for each message that is being transmitted to the bus. Note that Node ID is not involved at all. Every node that is interested to receive messages from redundant nodes shall implement some logic to decide which instance of redundant nodes to listen to. Different techniques exist for that: there might be simplest possible logic that considers a node to be functioning properly as long as it transmits all required messages; or a node can include some sort of figure-of-merit number into every transmitted message (CANaerospace specs suggests to use Service Code field for that) so that other nodes can select the best data provider among available according to this metric of sanity.

Regardless of all that stuff - yes, CANaerospace is not perfect.

And the points about the "structure" transport you brought here earlier are also pretty valid.

Best regards,

Pavel.

[crashmatt]

Pavel,

The redundancy channel is not quite right for that use case. It needs all of the measurements with equal priority.  More like the #N in the engines case.

Strange that the standard broadcast messages carry the Node ID rather than a channel ID.  Maybe it makes for simpler and safer user setup.

I would be tempted to define messages with #N channels for flexibility.  For example, having servo #N instead of aileron servo, elevator servo etc.  It means that the system is a little more difficult to setup but no worse than what we have now.

Talk of that figure of merit.  Transmitting estimated error with every measurement might be useful.  A Kalman filter could use that dynamic error estimate to great advantage, ignoring bad data and choosing good data.

On the subject of structure transport, I have been investigating how possible it is to transport mavlink packed structures.  Having nodes speaking mavlink and mavlink parameters is useful for setup considering all the tools that speak mavlink.  Why not then re-use the machine independent, xml defined mavlink structures?

Most of my 'good' ideas turn out to be junk.  Just a matter of time before I figure out why.

Regards Matt

[crashmatt]

More thought experimentation:  If multi-packet broadcast structured data is used, what handles received data and how does it need to act on it?

Say you receive a mavlink data packet over CAN. Note this is not full mavlink, only the data structure and the identifier.

1. Decide if you are interested in this packet, if not then ignore it.  Some nodes will not have resources to accept everything.
   
2. Find the expected structure size for the mavlink identifier.
3. Once the complete mavlink structure is received it is parsed

Each of these needs a specific filter for each message.  Since mavlink messages are named functions with named constants, the code needs to connect to the relevant mavlink code.  This feels like a case for auto generated code.

The structure size could be transmitted with every structure or learned from the mavlink definition.  Learning from mavlink is the most efficient and robust but adds a little code complexity.

Several ways of parsing the received data.  The method used is optional but worth investigating to understand the extent of effort needed to implement a complete system.

1. Immediate translation into actions
2. Translating mavlink data into internal data structures
3. Internal broadcast of the mavlink data (ie. uORB)

#1 and #2 are the ways we have normally done this.  #3 is very attractive for its simplicity but it has some challenges.

Every module that communicates structures with other modules must have the structures defined through mavlink. Each module is responsible for parsing data but this is not much different from using any other data structure.

How should the mavlink structures be addressed?  Several ways to organise this:

1. A FunctionID each with a list of ObjectIDs.
   
2. A linear list of mavlink objects (like CANaero)

#1 Has great object structure which would allow easier construction of function related parsers. As new functions are added they would have their own parsers.  It would need translation from FuncID/ObjID to mavlink IDs which is ugly.

#2 Direct mapping of mavlink object ID is very simple.  Maybe more suited to the uORB type implementation.

Why stress about all of this?

I am naturally lazy so I hate hand writing parsers. I prefer to write something once and that is all.  The mavlink toolchain get's a mighty +1, thumbs up, smiley and a halfbakery bun.  If I can use mavlink tricks to reduce long term effort I will do.

So just a thought experiment for now.

/Matt

[Pavel Kirienko]

Matt,

> The redundancy channel is not quite right for that use case. It needs all of the measurements with equal priority.  More like the #N in the engines case.

OK, sorry I got your example wrong. This is not the case for redundancy channels indeed.

> For example, having servo #N instead of aileron servo, elevator servo etc.  It means that the system is a little more difficult to setup but no worse than what we have now.

I'm not sure this is right. Yes it gives some flexibility, but aside from rendering the system prone to misconfiguration it also brings the communication logic a level lower, to less abstract context.

Considering our example, that would mean that instead of producing some abstract "roll command"/"pitch command" we would need to lookup the current airframe configuration, perform some mixing, map the outputs to the corresponding servo channels and send the results to the bus. What I strongly dislike in this scenario is that we run a high-level control logic and low-level actuator driving logic on the same node.

Curious contradiction, this makes the system less flexible in some way.

> On the subject of structure transport, I have been investigating how possible it is to transport mavlink packed structures.  Having nodes speaking mavlink and mavlink parameters is useful for setup considering all the tools that speak mavlink.  Why not then re-use the machine independent, xml defined mavlink structures?

I don't have strong points on this yet, but I don't think that we can layer the existing MAVLink messages over an on-board CAN.

Looking at the standard MAVLink messages (https://pixhawk.ethz.ch/mavlink/) I can see some features that are completely useless or simply wrong for an on-board bus, for instance:

- System ID is good for ground-to-vehicle or vehicle-to-vehicle communication, but completely meaningless for our case;

- Some messages are useless (ex: heartbeat, auth_key, change_operator_control*);

- Some messages are by design incompatible with abstraction concept described above (ex: rc_channels*, servo*);

- Most of the messages are too large for CAN bus concept. This is not about the structure size which is not an issue, provided that we've developed a good transport for that, but this is about the number of loosely related parameters packed into single message (which is good for kind of transports MAVLink was designed for, but not for CAN);

Speaking of packet filtering (whether a node needs a passing CAN frame or not), I think this should not be an issue thanks to CAN hardware filters. Or maybe I misunderstood your concern.

Best regards,

Pavel.

[crashmatt]

Pavel,

> The redundancy channel is not quite right for that use case. It needs all of the measurements with equal priority.  More like the #N in the engines case.

OK, sorry I got your example wrong. This is not the case for redundancy channels indeed.

> For example, having servo #N instead of aileron servo, elevator servo etc.  It means that the system is a little more difficult to setup but no worse than what we have now.

I'm not sure this is right. Yes it gives some flexibility, but aside from rendering the system prone to misconfiguration it also brings the communication logic a level lower, to less abstract context.

The channel number to control name abstraction can be done on a different layer.  The significant thing is to define a protocol that doesn't care about the names or the number of actuators you have.  I suggest that the names are a higher application layer feature.  If the naming is is an enumeration in something like mavlink then it can be modified and distributed to all nodes.  You can have standard naming but you can also extend an enumeration with specific naming.

The nice thing about this is that you only create and test one message and then it is maintenance free.

 

Considering our example, that would mean that instead of producing some abstract "roll command"/"pitch command" we would need to lookup the current airframe configuration, perform some mixing, map the outputs to the corresponding servo channels and send the results to the bus. What I strongly dislike in this scenario is that we run a high-level control logic and low-level actuator driving logic on the same node.

Similar to the actuator, if the protocol will carry command #N instead of named commands, the #N to named commands can be done on an upper layer.

I don't know why mixing different levels of logic on a node is a problem.  This happens on all the existing autopilots. 

A failsafe is the worst case I can think of. It has to make high level decisions and yet do the low level mixing and servo outputs.  Perhaps it is best to do some sketches of what is happening where.

 

Curious contradiction, this makes the system less flexible in some way.

Maybe we don't understand each other yet. 

> On the subject of structure transport, I have been investigating how possible it is to transport mavlink packed structures.  Having nodes speaking mavlink and mavlink parameters is useful for setup considering all the tools that speak mavlink.  Why not then re-use the machine independent, xml defined mavlink structures?

I don't have strong points on this yet, but I don't think that we can layer the existing MAVLink messages over an on-board CAN.

Looking at the standard MAVLink messages (https://pixhawk.ethz.ch/mavlink/) I can see some features that are completely useless or simply wrong for an on-board bus, for instance:

- System ID is good for ground-to-vehicle or vehicle-to-vehicle communication, but completely meaningless for our case;

I agree that complete MAVlink messages don't fit well with CAN.  This is why mavlink on CAN concept was thrown out some time ago.

I am proposing to only transmitting the mavlink defined structure and message identifier.  It would not include SysID, CompID, length, delimiters, crc etc.

The existing mavlink messages are not fitting particularly well.  New messages would need defining which is no problem since it is so very easy.

As an added bonus it is quite easy to send any of the CAN messages over mavlink for debug purposes.

 

- Some messages are useless (ex: heartbeat, auth_key, change_operator_control*);

I agree.  That's ok.  Nobody uses all of the messages anyway.

 

- Some messages are by design incompatible with abstraction concept described above (ex: rc_channels*, servo*);

rc_channels and servo are the two messages that do work with the #N concept.  Do abstraction at a different layer and it doesn't matter.

 

- Most of the messages are too large for CAN bus concept. This is not about the structure size which is not an issue, provided that we've developed a good transport for that, but this is about the number of loosely related parameters packed into single message (which is good for kind of transports MAVLink was designed for, but not for CAN);

Say you have a remote AHRS, maybe a failsafe.  Transporting part of a rotation matrix is dangerous so you want to transport everything before using the data .  If the CAN packets have structure address there is nothing to stop you transmitting reasonable sized structures.  I have done this.   AHRS on one node, autopilot on another.  It works.

AHRS data is the most extreme example.  You can apply the same reasoning to smaller data sets between other modules.

Speaking of packet filtering (whether a node needs a passing CAN frame or not), I think this should not be an issue thanks to CAN hardware filters. Or maybe I misunderstood your concern.

It doesn't matter much if the filtering is in hardware or software.  It is deciding how to configure the filters according to user setup that needs more thinking.

Regards Matt