So due to the recent discussions seems like there is enough interest to have MAVLink Support CAN in one way or another. The current 7 Bytes + payload works really well in serial streams but unless we are willing to sacrifice payload bytes, they won't fit in the 29 bits (max) available to identify a CAN packet. The two checksum bytes are unnecessary since CAN has its own 15-bit CRC, but that still leaves us with 40 bits (the 5 remaining bytes). Here is the structure I'd like to propose for they 29-bit CAN extended identifier and a brief discussion about each field (image attached):
<https://lh3.googleusercontent.com/_p0S_V6F1kuk/TXVI69Qqm0I/AAAAAAAAA0...> Recall that all this proposal is based on the fact that this is an "in-system" protocol, which means that these packets are not intended to leave the Autonomous Vehicle, but rather to communicate individual components inside the vehicle (or the ground station).
2-Bytes PRIORITY: Although CAN inherently supports priority, it only supports either high or normal. From Matt's post here (https://groups.google.com/d/msg/mavlink/GsAzERgnegE/DGnad3eSqpoJ) I like his idea to have our own set of at least 4 priorities that can be distinguished at application level.
7-Bytes SOURCE TYPE ID: Not to be confused with system ID in the MAVLink sense, the Type ID would pertain to a type of node: Servo, Camera Control, Sensor, Landing gear. We could support up to 128 different device types.
5-Bytes SOURCE NODE ID: These is not a unique ID but a unique node for that type of node, which means that the unique ID is built by Type ID - Node ID. For instance, the Camera Control Type can have node 01 and Servos can also have node 01. These means that we could address up to 32 different nodes per type.
8-Bytes MESSAGE ID: This is the same as in the MAVLink message-ID sense.
4-Bytes PACKETS LEFT: Most of MAVLink's messages are larger than the 8-bytes that a CAN packet can deliver, therefore the messages would have to be assembled as multiple CAN packets, this field would allow the receiver to know when it is done receiving this particular MAVLink message and can now proceed to decode the whole message (and put it in a structure if necessary).
There are a couple of things to note from this proposal:
1.- I have not proposed a target in the 29-bit identifier. The reason behind this is because in my experience most of the CAN messages you write on the bus and the CAN acceptance filter configuration is the one that "decides" if that message shows up in your receive buffers.
2.- This follows what MAVLink currently does; in the current implementation all packets have a source ID (System ID- Component ID) and the target is optional for those packets that do require it.
3.- Note that we could potentially have 4096 different nodes (2^7 types + 2^5 nodes for each type) which is well above the recommended amount of nodes. Depending on the standard you read, those oscillate from as few as 32 to as many as 110 (see for instance here<http://www.computer-solutions.co.uk/info/Embedded_tutorials/can_tutor...>) so it would be up to the end-user to decide how many to use or do sub-networks.
4.- There are still three bits free which could be used for some other purpose.
I think it would be a bad design choice to try to splat MAVlink on top
of CAN in the way you're describing.
There are some cases where it might make sense to tunnel MAVlink
messages over CAN, but in general if you want to talk between two
nodes on the CAN, you're better off using a native protocol.
If nobody is willing to spring for a copy of ARINC 825 and act as an
oracle, then it probably makes sense, as noted in a related thread
here, to start with CANaero, pull in the publicly disclosed parts of
ARINC 825 and work within the spirit of the existing implementation.
It might also make sense to check in with the libcanaero folks (http://
cross-simulator.com/) as they would probably have some input on the
subject.
= Mike
On Mar 7, 5:08 pm, malife <mal...@gmail.com> wrote:
> So due to the recent discussions seems like there is enough interest to have
> MAVLink Support CAN in one way or another. The current 7 Bytes + payload
> works really well in serial streams but unless we are willing to sacrifice
> payload bytes, they won't fit in the 29 bits (max) available to identify a
> CAN packet. The two checksum bytes are unnecessary since CAN has its own
> 15-bit CRC, but that still leaves us with 40 bits (the 5 remaining bytes).
> Here is the structure I'd like to propose for they 29-bit CAN extended
> identifier and a brief discussion about each field (image attached):
> <https://lh3.googleusercontent.com/_p0S_V6F1kuk/TXVI69Qqm0I/AAAAAAAAA0...>
> Recall that all this proposal is based on the fact that this is an
> "in-system" protocol, which means that these packets are not intended to
> leave the Autonomous Vehicle, but rather to communicate individual
> components inside the vehicle (or the ground station).
> 2-Bytes PRIORITY: Although CAN inherently supports priority, it only
> supports either high or normal. From Matt's post here
> (https://groups.google.com/d/msg/mavlink/GsAzERgnegE/DGnad3eSqpoJ) I like
> his idea to have our own set of at least 4 priorities that can be
> distinguished at application level.
> 7-Bytes SOURCE TYPE ID: Not to be confused with system ID in the MAVLink
> sense, the Type ID would pertain to a type of node: Servo, Camera Control,
> Sensor, Landing gear. We could support up to 128 different device types.
> 5-Bytes SOURCE NODE ID: These is not a unique ID but a unique node for that
> type of node, which means that the unique ID is built by Type ID - Node ID.
> For instance, the Camera Control Type can have node 01 and Servos can also
> have node 01. These means that we could address up to 32 different nodes per
> type.
> 8-Bytes MESSAGE ID: This is the same as in the MAVLink message-ID sense.
> 4-Bytes PACKETS LEFT: Most of MAVLink's messages are larger than the
> 8-bytes that a CAN packet can deliver, therefore the messages would have to
> be assembled as multiple CAN packets, this field would allow the receiver to
> know when it is done receiving this particular MAVLink message and can now
> proceed to decode the whole message (and put it in a structure if
> necessary).
> There are a couple of things to note from this proposal:
> 1.- I have not proposed a target in the 29-bit identifier. The reason behind
> this is because in my experience most of the CAN messages you write on the
> bus and the CAN acceptance filter configuration is the one that "decides" if
> that message shows up in your receive buffers.
> 2.- This follows what MAVLink currently does; in the current implementation
> all packets have a source ID (System ID- Component ID) and the target is
> optional for those packets that do require it.
> 3.- Note that we could potentially have 4096 different nodes (2^7 types +
> 2^5 nodes for each type) which is well above the recommended amount of
> nodes. Depending on the standard you read, those oscillate from as few as 32
> to as many as 110 (see for instance here<http://www.computer-solutions.co.uk/info/Embedded_tutorials/can_tutor...>)
> so it would be up to the end-user to decide how many to use or do
> sub-networks.
> 4.- There are still three bits free which could be used for some other
> purpose.
Hello Mike, Thanks for your feedback. We had a previous discussion about CANAerospace here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and it seemed like it had many disadvantages and very few advantages. If you think that adopting either ARINC 825 or CANAerospace has advantages to the current state of MAVLink could you please tell us?
Now, I am not sure I understand what you mean by a "native protocol". I've extensively used CAN before, just not in Aero applications; do you mean the way the IDs and the messages are laid out?
The end goal here is to be able to automatically generate all the convenience functions (that when hand-coded are very error-prone) to send and receive data (as it is currently done for serial data) based on an XML description of the CAN messages. The way I think we see it is not a forcing of Mavlink into CAN but rather an extension of Mavlink to support CAN devices on board. For instance, QGC would send a pan/tilt/zoom command to a camera gimbal on the UAV using Mavlink; once the command is received on board the central processor (presumably the autopilot) would decode that message and create a new CAN message with the received commands and forward them to the Camera. Now this scenario is identical regardless if we use CANAerospace, ARINC 825 or any other convention we choose to use, the only differences would be how the IDs are formed and the layout of the payload in the CAN packets (that is of course if we ignore the physical layer requirements, for instance CANAerspace requires you to opto-isolate all your signals to be considered compliant).
We are trying to improve MAVLink so any feedback is more than welcome. I'll read about libcanaero and as much as I can find about ARINC 825 on the web and post back my impressions.
I have followed the discussion here on the list, but had no time to
dig into the actual docs yet. I think Mariano really provided a clear
and important description of what the current main gol with CAN/
MAVLink is. I did a little specs review today and one can summarize:
- CANAerospace is used in some italian drones, but does not seem
widely adopted
- ARINC 825 is a kind of successor to CANAerospace (support by the
same companies and now used by Boeing and Airbus.)
Now interestingly ARINC 825 comes with a broadcast mode, which may
make it easier to tunnel MAVLink, as Mariano described.
I do see a need for a transparent MAVLink tunnel over CAN, this is
probably the first application we'll have and it'll allow to use the
full spectrum of MAVLink. I think it would be nice though to have this
tunnel operate in a mode which is compatible with one of the major
aerial CAN buses, preferably ARINC 825. This would not hinder any use
of MAVLink, but also allow to use this device together with
standardized ARINC 825 devices. I can well imagine ARINC 825 payloads
being available for MAVs soon, e.g. gimbal cameras.
Implementing the full ARINC 825 specs from scratch might be also
tedious, because, as Mariano said, one would have to write a mapper
between each ARINC and MAVLink message. Utilizing the tunnel scheme
would allow to start off with pure MAVLink, ARINC only as tunnel and
then add ARINC 825 support as needed (e.g. per platform).
The only downside over reassigning the ID fields and thus not having
compatibility (like initially proposed) is that we have to send the
ARINC/CANaerospace header and then a few additional bytes for the
MAVLink header. If this buys us however compatibility with a major bus
system, this might be something to consider. Especially since MAV
networks are likely not that large (8-20 nodes) and cabling is not
that long (allows higher speeds) bus bandwidth from a slightly
increased header size should not be a major problem.
I'll try to see if we can buy a copy of the standard to figure out how
well it would support such a tunnel mode.
On 8 Mrz., 09:38, malife <mal...@gmail.com> wrote:
> Hello Mike,
> Thanks for your feedback. We had a previous discussion about CANAerospace
> here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and
> it seemed like it had many disadvantages and very few advantages. If you
> think that adopting either ARINC 825 or CANAerospace has advantages to the
> current state of MAVLink could you please tell us?
> Now, I am not sure I understand what you mean by a "native protocol". I've
> extensively used CAN before, just not in Aero applications; do you mean the
> way the IDs and the messages are laid out?
> The end goal here is to be able to automatically generate all the
> convenience functions (that when hand-coded are very error-prone) to send
> and receive data (as it is currently done for serial data) based on an XML
> description of the CAN messages. The way I think we see it is not a forcing
> of Mavlink into CAN but rather an extension of Mavlink to support CAN
> devices on board. For instance, QGC would send a pan/tilt/zoom command to a
> camera gimbal on the UAV using Mavlink; once the command is received on
> board the central processor (presumably the autopilot) would decode that
> message and create a new CAN message with the received commands and forward
> them to the Camera. Now this scenario is identical regardless if we use
> CANAerospace, ARINC 825 or any other convention we choose to use, the only
> differences would be how the IDs are formed and the layout of the payload in
> the CAN packets (that is of course if we ignore the physical layer
> requirements, for instance CANAerspace requires you to opto-isolate all your
> signals to be considered compliant).
> We are trying to improve MAVLink so any feedback is more than welcome. I'll
> read about libcanaero and as much as I can find about ARINC 825 on the web
> and post back my impressions.
> I have followed the discussion here on the list, but had no time to
> dig into the actual docs yet. I think Mariano really provided a clear
> and important description of what the current main gol with CAN/
> MAVLink is. I did a little specs review today and one can summarize:
> - CANAerospace is used in some italian drones, but does not seem
> widely adopted
> - ARINC 825 is a kind of successor to CANAerospace (support by the
> same companies and now used by Boeing and Airbus.)
> Now interestingly ARINC 825 comes with a broadcast mode, which may
> make it easier to tunnel MAVLink, as Mariano described.
> I do see a need for a transparent MAVLink tunnel over CAN, this is
> probably the first application we'll have and it'll allow to use the
> full spectrum of MAVLink. I think it would be nice though to have this
> tunnel operate in a mode which is compatible with one of the major
> aerial CAN buses, preferably ARINC 825. This would not hinder any use
> of MAVLink, but also allow to use this device together with
> standardized ARINC 825 devices. I can well imagine ARINC 825 payloads
> being available for MAVs soon, e.g. gimbal cameras.
> Implementing the full ARINC 825 specs from scratch might be also
> tedious, because, as Mariano said, one would have to write a mapper
> between each ARINC and MAVLink message. Utilizing the tunnel scheme
> would allow to start off with pure MAVLink, ARINC only as tunnel and
> then add ARINC 825 support as needed (e.g. per platform).
> The only downside over reassigning the ID fields and thus not having
> compatibility (like initially proposed) is that we have to send the
> ARINC/CANaerospace header and then a few additional bytes for the
> MAVLink header. If this buys us however compatibility with a major bus
> system, this might be something to consider. Especially since MAV
> networks are likely not that large (8-20 nodes) and cabling is not
> that long (allows higher speeds) bus bandwidth from a slightly
> increased header size should not be a major problem.
> I'll try to see if we can buy a copy of the standard to figure out how
> well it would support such a tunnel mode.
> On 8 Mrz., 09:38, malife <mal...@gmail.com> wrote:
> > Hello Mike,
> > Thanks for your feedback. We had a previous discussion about CANAerospace
> > here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and
> > it seemed like it had many disadvantages and very few advantages. If you
> > think that adopting either ARINC 825 or CANAerospace has advantages to the
> > current state of MAVLink could you please tell us?
> > Now, I am not sure I understand what you mean by a "native protocol". I've
> > extensively used CAN before, just not in Aero applications; do you mean the
> > way the IDs and the messages are laid out?
> > The end goal here is to be able to automatically generate all the
> > convenience functions (that when hand-coded are very error-prone) to send
> > and receive data (as it is currently done for serial data) based on an XML
> > description of the CAN messages. The way I think we see it is not a forcing
> > of Mavlink into CAN but rather an extension of Mavlink to support CAN
> > devices on board. For instance, QGC would send a pan/tilt/zoom command to a
> > camera gimbal on the UAV using Mavlink; once the command is received on
> > board the central processor (presumably the autopilot) would decode that
> > message and create a new CAN message with the received commands and forward
> > them to the Camera. Now this scenario is identical regardless if we use
> > CANAerospace, ARINC 825 or any other convention we choose to use, the only
> > differences would be how the IDs are formed and the layout of the payload in
> > the CAN packets (that is of course if we ignore the physical layer
> > requirements, for instance CANAerspace requires you to opto-isolate all your
> > signals to be considered compliant).
> > We are trying to improve MAVLink so any feedback is more than welcome. I'll
> > read about libcanaero and as much as I can find about ARINC 825 on the web
> > and post back my impressions.
ARINC is great for airliners with 200 CAN nodes.
ARINC may not be so good for a large community of open source
developers who need to understand and debug the system.
CANaero identifiers will not help us with much of the information that
we want, e.g. servo current.
The vast majority of home UAV users will never see a piece of standard
ARINC UAV equipment.
The cost for approved ARINC compatibility is too high. Those
manufacturers want some big $$$$ margin.
A subtle question about addressing that I believe is relevant:
Are satellite modules addressed in a logical or physical way?
If a position is sent to a servo, that servo needs a channel number.
Either the servo needs to know its channel number or
The transmitter needs to know the address of the servo with that
channel.
This determines how the user can/will use the system.
It also determines which kind of messaging is suitable.
I suggest a list of use cases and behaviour would help to decide which
protocol is most appropriate.
Regards Matt
On Mar 8, 10:16 am, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> On 8 Mrz., 09:59, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > I have followed the discussion here on the list, but had no time to
> > dig into the actual docs yet. I think Mariano really provided a clear
> > and important description of what the current main gol with CAN/
> > MAVLink is. I did a little specs review today and one can summarize:
> > - CANAerospace is used in some italian drones, but does not seem
> > widely adopted
> > - ARINC 825 is a kind of successor to CANAerospace (support by the
> > same companies and now used by Boeing and Airbus.)
> > Now interestingly ARINC 825 comes with a broadcast mode, which may
> > make it easier to tunnel MAVLink, as Mariano described.
> > I do see a need for a transparent MAVLink tunnel over CAN, this is
> > probably the first application we'll have and it'll allow to use the
> > full spectrum of MAVLink. I think it would be nice though to have this
> > tunnel operate in a mode which is compatible with one of the major
> > aerial CAN buses, preferably ARINC 825. This would not hinder any use
> > of MAVLink, but also allow to use this device together with
> > standardized ARINC 825 devices. I can well imagine ARINC 825 payloads
> > being available for MAVs soon, e.g. gimbal cameras.
> > Implementing the full ARINC 825 specs from scratch might be also
> > tedious, because, as Mariano said, one would have to write a mapper
> > between each ARINC and MAVLink message. Utilizing the tunnel scheme
> > would allow to start off with pure MAVLink, ARINC only as tunnel and
> > then add ARINC 825 support as needed (e.g. per platform).
> > The only downside over reassigning the ID fields and thus not having
> > compatibility (like initially proposed) is that we have to send the
> > ARINC/CANaerospace header and then a few additional bytes for the
> > MAVLink header. If this buys us however compatibility with a major bus
> > system, this might be something to consider. Especially since MAV
> > networks are likely not that large (8-20 nodes) and cabling is not
> > that long (allows higher speeds) bus bandwidth from a slightly
> > increased header size should not be a major problem.
> > I'll try to see if we can buy a copy of the standard to figure out how
> > well it would support such a tunnel mode.
> > On 8 Mrz., 09:38, malife <mal...@gmail.com> wrote:
> > > Hello Mike,
> > > Thanks for your feedback. We had a previous discussion about CANAerospace
> > > here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and
> > > it seemed like it had many disadvantages and very few advantages. If you
> > > think that adopting either ARINC 825 or CANAerospace has advantages to the
> > > current state of MAVLink could you please tell us?
> > > Now, I am not sure I understand what you mean by a "native protocol". I've
> > > extensively used CAN before, just not in Aero applications; do you mean the
> > > way the IDs and the messages are laid out?
> > > The end goal here is to be able to automatically generate all the
> > > convenience functions (that when hand-coded are very error-prone) to send
> > > and receive data (as it is currently done for serial data) based on an XML
> > > description of the CAN messages. The way I think we see it is not a forcing
> > > of Mavlink into CAN but rather an extension of Mavlink to support CAN
> > > devices on board. For instance, QGC would send a pan/tilt/zoom command to a
> > > camera gimbal on the UAV using Mavlink; once the command is received on
> > > board the central processor (presumably the autopilot) would decode that
> > > message and create a new CAN message with the received commands and forward
> > > them to the Camera. Now this scenario is identical regardless if we use
> > > CANAerospace, ARINC 825 or any other convention we choose to use, the only
> > > differences would be how the IDs are formed and the layout of the payload in
> > > the CAN packets (that is of course if we ignore the physical layer
> > > requirements, for instance CANAerspace requires you to opto-isolate all your
> > > signals to be considered compliant).
> > > We are trying to improve MAVLink so any feedback is more than welcome. I'll
> > > read about libcanaero and as much as I can find about ARINC 825 on the web
> > > and post back my impressions.
I think your points about the scope are very valid, so I think we
should make sure to distinguish in this discussion between the "right"
technical approach and the one appropriate for the scope of the
typical low-cost autopilots. Although we might have different
positions (only at least at this instant now), I think we totally
agree on this one. I think there is also a reason MAVLink is now
widely used and not SAE-AS4 (even though AS4 is kind of similar, just
really HUGE), mostly because of the simplicity and (in comparison to
AS4) small footprint.
So I'm very interested to see where the pros and cons will take us,
but keeping the scope in mind is indeed important.
On 8 Mrz., 13:45, crashmatt <uavflightdirec...@gmail.com> wrote:
> ARINC is great for airliners with 200 CAN nodes.
> ARINC may not be so good for a large community of open source
> developers who need to understand and debug the system.
> CANaero identifiers will not help us with much of the information that
> we want, e.g. servo current.
> The vast majority of home UAV users will never see a piece of standard
> ARINC UAV equipment.
> The cost for approved ARINC compatibility is too high. Those
> manufacturers want some big $$$$ margin.
> A subtle question about addressing that I believe is relevant:
> Are satellite modules addressed in a logical or physical way?
> If a position is sent to a servo, that servo needs a channel number.
> Either the servo needs to know its channel number or
> The transmitter needs to know the address of the servo with that
> channel.
> This determines how the user can/will use the system.
> It also determines which kind of messaging is suitable.
> I suggest a list of use cases and behaviour would help to decide which
> protocol is most appropriate.
> Regards Matt
> On Mar 8, 10:16 am, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > This document might be helpful for a protocol overview:
> > On 8 Mrz., 09:59, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > > I have followed the discussion here on the list, but had no time to
> > > dig into the actual docs yet. I think Mariano really provided a clear
> > > and important description of what the current main gol with CAN/
> > > MAVLink is. I did a little specs review today and one can summarize:
> > > - CANAerospace is used in some italian drones, but does not seem
> > > widely adopted
> > > - ARINC 825 is a kind of successor to CANAerospace (support by the
> > > same companies and now used by Boeing and Airbus.)
> > > Now interestingly ARINC 825 comes with a broadcast mode, which may
> > > make it easier to tunnel MAVLink, as Mariano described.
> > > I do see a need for a transparent MAVLink tunnel over CAN, this is
> > > probably the first application we'll have and it'll allow to use the
> > > full spectrum of MAVLink. I think it would be nice though to have this
> > > tunnel operate in a mode which is compatible with one of the major
> > > aerial CAN buses, preferably ARINC 825. This would not hinder any use
> > > of MAVLink, but also allow to use this device together with
> > > standardized ARINC 825 devices. I can well imagine ARINC 825 payloads
> > > being available for MAVs soon, e.g. gimbal cameras.
> > > Implementing the full ARINC 825 specs from scratch might be also
> > > tedious, because, as Mariano said, one would have to write a mapper
> > > between each ARINC and MAVLink message. Utilizing the tunnel scheme
> > > would allow to start off with pure MAVLink, ARINC only as tunnel and
> > > then add ARINC 825 support as needed (e.g. per platform).
> > > The only downside over reassigning the ID fields and thus not having
> > > compatibility (like initially proposed) is that we have to send the
> > > ARINC/CANaerospace header and then a few additional bytes for the
> > > MAVLink header. If this buys us however compatibility with a major bus
> > > system, this might be something to consider. Especially since MAV
> > > networks are likely not that large (8-20 nodes) and cabling is not
> > > that long (allows higher speeds) bus bandwidth from a slightly
> > > increased header size should not be a major problem.
> > > I'll try to see if we can buy a copy of the standard to figure out how
> > > well it would support such a tunnel mode.
> > > On 8 Mrz., 09:38, malife <mal...@gmail.com> wrote:
> > > > Hello Mike,
> > > > Thanks for your feedback. We had a previous discussion about CANAerospace
> > > > here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and
> > > > it seemed like it had many disadvantages and very few advantages. If you
> > > > think that adopting either ARINC 825 or CANAerospace has advantages to the
> > > > current state of MAVLink could you please tell us?
> > > > Now, I am not sure I understand what you mean by a "native protocol". I've
> > > > extensively used CAN before, just not in Aero applications; do you mean the
> > > > way the IDs and the messages are laid out?
> > > > The end goal here is to be able to automatically generate all the
> > > > convenience functions (that when hand-coded are very error-prone) to send
> > > > and receive data (as it is currently done for serial data) based on an XML
> > > > description of the CAN messages. The way I think we see it is not a forcing
> > > > of Mavlink into CAN but rather an extension of Mavlink to support CAN
> > > > devices on board. For instance, QGC would send a pan/tilt/zoom command to a
> > > > camera gimbal on the UAV using Mavlink; once the command is received on
> > > > board the central processor (presumably the autopilot) would decode that
> > > > message and create a new CAN message with the received commands and forward
> > > > them to the Camera. Now this scenario is identical regardless if we use
> > > > CANAerospace, ARINC 825 or any other convention we choose to use, the only
> > > > differences would be how the IDs are formed and the layout of the payload in
> > > > the CAN packets (that is of course if we ignore the physical layer
> > > > requirements, for instance CANAerspace requires you to opto-isolate all your
> > > > signals to be considered compliant).
> > > > We are trying to improve MAVLink so any feedback is more than welcome. I'll
> > > > read about libcanaero and as much as I can find about ARINC 825 on the web
> > > > and post back my impressions.
Thank you all for your excellent analysis so far. I've put now
additionally a posting up on DIYDrones to invite any non-aware
developer to join the discussion. I think at this stage of collecting
initial feedback and rough ideas the more feedback we get, the better.
On 8 Mrz., 14:09, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> I think your points about the scope are very valid, so I think we
> should make sure to distinguish in this discussion between the "right"
> technical approach and the one appropriate for the scope of the
> typical low-cost autopilots. Although we might have different
> positions (only at least at this instant now), I think we totally
> agree on this one. I think there is also a reason MAVLink is now
> widely used and not SAE-AS4 (even though AS4 is kind of similar, just
> really HUGE), mostly because of the simplicity and (in comparison to
> AS4) small footprint.
> So I'm very interested to see where the pros and cons will take us,
> but keeping the scope in mind is indeed important.
> On 8 Mrz., 13:45, crashmatt <uavflightdirec...@gmail.com> wrote:
> > qgc, thats a great overview document.
> > First thought: Keep it simple.
> > ARINC is great for airliners with 200 CAN nodes.
> > ARINC may not be so good for a large community of open source
> > developers who need to understand and debug the system.
> > CANaero identifiers will not help us with much of the information that
> > we want, e.g. servo current.
> > The vast majority of home UAV users will never see a piece of standard
> > ARINC UAV equipment.
> > The cost for approved ARINC compatibility is too high. Those
> > manufacturers want some big $$$$ margin.
> > A subtle question about addressing that I believe is relevant:
> > Are satellite modules addressed in a logical or physical way?
> > If a position is sent to a servo, that servo needs a channel number.
> > Either the servo needs to know its channel number or
> > The transmitter needs to know the address of the servo with that
> > channel.
> > This determines how the user can/will use the system.
> > It also determines which kind of messaging is suitable.
> > I suggest a list of use cases and behaviour would help to decide which
> > protocol is most appropriate.
> > Regards Matt
> > On Mar 8, 10:16 am, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > > This document might be helpful for a protocol overview:
> > > On 8 Mrz., 09:59, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > > > I have followed the discussion here on the list, but had no time to
> > > > dig into the actual docs yet. I think Mariano really provided a clear
> > > > and important description of what the current main gol with CAN/
> > > > MAVLink is. I did a little specs review today and one can summarize:
> > > > - CANAerospace is used in some italian drones, but does not seem
> > > > widely adopted
> > > > - ARINC 825 is a kind of successor to CANAerospace (support by the
> > > > same companies and now used by Boeing and Airbus.)
> > > > Now interestingly ARINC 825 comes with a broadcast mode, which may
> > > > make it easier to tunnel MAVLink, as Mariano described.
> > > > I do see a need for a transparent MAVLink tunnel over CAN, this is
> > > > probably the first application we'll have and it'll allow to use the
> > > > full spectrum of MAVLink. I think it would be nice though to have this
> > > > tunnel operate in a mode which is compatible with one of the major
> > > > aerial CAN buses, preferably ARINC 825. This would not hinder any use
> > > > of MAVLink, but also allow to use this device together with
> > > > standardized ARINC 825 devices. I can well imagine ARINC 825 payloads
> > > > being available for MAVs soon, e.g. gimbal cameras.
> > > > Implementing the full ARINC 825 specs from scratch might be also
> > > > tedious, because, as Mariano said, one would have to write a mapper
> > > > between each ARINC and MAVLink message. Utilizing the tunnel scheme
> > > > would allow to start off with pure MAVLink, ARINC only as tunnel and
> > > > then add ARINC 825 support as needed (e.g. per platform).
> > > > The only downside over reassigning the ID fields and thus not having
> > > > compatibility (like initially proposed) is that we have to send the
> > > > ARINC/CANaerospace header and then a few additional bytes for the
> > > > MAVLink header. If this buys us however compatibility with a major bus
> > > > system, this might be something to consider. Especially since MAV
> > > > networks are likely not that large (8-20 nodes) and cabling is not
> > > > that long (allows higher speeds) bus bandwidth from a slightly
> > > > increased header size should not be a major problem.
> > > > I'll try to see if we can buy a copy of the standard to figure out how
> > > > well it would support such a tunnel mode.
> > > > > Hello Mike,
> > > > > Thanks for your feedback. We had a previous discussion about CANAerospace
> > > > > here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and
> > > > > it seemed like it had many disadvantages and very few advantages. If you
> > > > > think that adopting either ARINC 825 or CANAerospace has advantages to the
> > > > > current state of MAVLink could you please tell us?
> > > > > Now, I am not sure I understand what you mean by a "native protocol". I've
> > > > > extensively used CAN before, just not in Aero applications; do you mean the
> > > > > way the IDs and the messages are laid out?
> > > > > The end goal here is to be able to automatically generate all the
> > > > > convenience functions (that when hand-coded are very error-prone) to send
> > > > > and receive data (as it is currently done for serial data) based on an XML
> > > > > description of the CAN messages. The way I think we see it is not a forcing
> > > > > of Mavlink into CAN but rather an extension of Mavlink to support CAN
> > > > > devices on board. For instance, QGC would send a pan/tilt/zoom command to a
> > > > > camera gimbal on the UAV using Mavlink; once the command is received on
> > > > > board the central processor (presumably the autopilot) would decode that
> > > > > message and create a new CAN message with the received commands and forward
> > > > > them to the Camera. Now this scenario is identical regardless if we use
> > > > > CANAerospace, ARINC 825 or any other convention we choose to use, the only
> > > > > differences would be how the IDs are formed and the layout of the payload in
> > > > > the CAN packets (that is of course if we ignore the physical layer
> > > > > requirements, for instance CANAerspace requires you to opto-isolate all your
> > > > > signals to be considered compliant).
> > > > > We are trying to improve MAVLink so any feedback is more than welcome. I'll
> > > > > read about libcanaero and as much as I can find about ARINC 825 on the web
> > > > > and post back my impressions.
My subtle question put a better way:
CAN is normally connectionless.
Will the new protocol need to support connections?
How are connections managed?
What stores the knowledge of a connection?
On Mar 8, 3:12 pm, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> Thank you all for your excellent analysis so far. I've put now
> additionally a posting up on DIYDrones to invite any non-aware
> developer to join the discussion. I think at this stage of collecting
> initial feedback and rough ideas the more feedback we get, the better.
> On 8 Mrz., 14:09, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > I think your points about the scope are very valid, so I think we
> > should make sure to distinguish in this discussion between the "right"
> > technical approach and the one appropriate for the scope of the
> > typical low-cost autopilots. Although we might have different
> > positions (only at least at this instant now), I think we totally
> > agree on this one. I think there is also a reason MAVLink is now
> > widely used and not SAE-AS4 (even though AS4 is kind of similar, just
> > really HUGE), mostly because of the simplicity and (in comparison to
> > AS4) small footprint.
> > So I'm very interested to see where the pros and cons will take us,
> > but keeping the scope in mind is indeed important.
> > On 8 Mrz., 13:45, crashmatt <uavflightdirec...@gmail.com> wrote:
> > > qgc, thats a great overview document.
> > > First thought: Keep it simple.
> > > ARINC is great for airliners with 200 CAN nodes.
> > > ARINC may not be so good for a large community of open source
> > > developers who need to understand and debug the system.
> > > CANaero identifiers will not help us with much of the information that
> > > we want, e.g. servo current.
> > > The vast majority of home UAV users will never see a piece of standard
> > > ARINC UAV equipment.
> > > The cost for approved ARINC compatibility is too high. Those
> > > manufacturers want some big $$$$ margin.
> > > A subtle question about addressing that I believe is relevant:
> > > Are satellite modules addressed in a logical or physical way?
> > > If a position is sent to a servo, that servo needs a channel number.
> > > Either the servo needs to know its channel number or
> > > The transmitter needs to know the address of the servo with that
> > > channel.
> > > This determines how the user can/will use the system.
> > > It also determines which kind of messaging is suitable.
> > > I suggest a list of use cases and behaviour would help to decide which
> > > protocol is most appropriate.
> > > Regards Matt
> > > On Mar 8, 10:16 am, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > > > This document might be helpful for a protocol overview:
> > > > > I have followed the discussion here on the list, but had no time to
> > > > > dig into the actual docs yet. I think Mariano really provided a clear
> > > > > and important description of what the current main gol with CAN/
> > > > > MAVLink is. I did a little specs review today and one can summarize:
> > > > > - CANAerospace is used in some italian drones, but does not seem
> > > > > widely adopted
> > > > > - ARINC 825 is a kind of successor to CANAerospace (support by the
> > > > > same companies and now used by Boeing and Airbus.)
> > > > > Now interestingly ARINC 825 comes with a broadcast mode, which may
> > > > > make it easier to tunnel MAVLink, as Mariano described.
> > > > > I do see a need for a transparent MAVLink tunnel over CAN, this is
> > > > > probably the first application we'll have and it'll allow to use the
> > > > > full spectrum of MAVLink. I think it would be nice though to have this
> > > > > tunnel operate in a mode which is compatible with one of the major
> > > > > aerial CAN buses, preferably ARINC 825. This would not hinder any use
> > > > > of MAVLink, but also allow to use this device together with
> > > > > standardized ARINC 825 devices. I can well imagine ARINC 825 payloads
> > > > > being available for MAVs soon, e.g. gimbal cameras.
> > > > > Implementing the full ARINC 825 specs from scratch might be also
> > > > > tedious, because, as Mariano said, one would have to write a mapper
> > > > > between each ARINC and MAVLink message. Utilizing the tunnel scheme
> > > > > would allow to start off with pure MAVLink, ARINC only as tunnel and
> > > > > then add ARINC 825 support as needed (e.g. per platform).
> > > > > The only downside over reassigning the ID fields and thus not having
> > > > > compatibility (like initially proposed) is that we have to send the
> > > > > ARINC/CANaerospace header and then a few additional bytes for the
> > > > > MAVLink header. If this buys us however compatibility with a major bus
> > > > > system, this might be something to consider. Especially since MAV
> > > > > networks are likely not that large (8-20 nodes) and cabling is not
> > > > > that long (allows higher speeds) bus bandwidth from a slightly
> > > > > increased header size should not be a major problem.
> > > > > I'll try to see if we can buy a copy of the standard to figure out how
> > > > > well it would support such a tunnel mode.
> > > > > > Hello Mike,
> > > > > > Thanks for your feedback. We had a previous discussion about CANAerospace
> > > > > > here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and
> > > > > > it seemed like it had many disadvantages and very few advantages. If you
> > > > > > think that adopting either ARINC 825 or CANAerospace has advantages to the
> > > > > > current state of MAVLink could you please tell us?
> > > > > > Now, I am not sure I understand what you mean by a "native protocol". I've
> > > > > > extensively used CAN before, just not in Aero applications; do you mean the
> > > > > > way the IDs and the messages are laid out?
> > > > > > The end goal here is to be able to automatically generate all the
> > > > > > convenience functions (that when hand-coded are very error-prone) to send
> > > > > > and receive data (as it is currently done for serial data) based on an XML
> > > > > > description of the CAN messages. The way I think we see it is not a forcing
> > > > > > of Mavlink into CAN but rather an extension of Mavlink to support CAN
> > > > > > devices on board. For instance, QGC would send a pan/tilt/zoom command to a
> > > > > > camera gimbal on the UAV using Mavlink; once the command is received on
> > > > > > board the central processor (presumably the autopilot) would decode that
> > > > > > message and create a new CAN message with the received commands and forward
> > > > > > them to the Camera. Now this scenario is identical regardless if we use
> > > > > > CANAerospace, ARINC 825 or any other convention we choose to use, the only
> > > > > > differences would be how the IDs are formed and the layout of the payload in
> > > > > > the CAN packets (that is of course if we ignore the physical layer
> > > > > > requirements, for instance CANAerspace requires you to opto-isolate all your
> > > > > > signals to be considered compliant).
> > > > > > We are trying to improve MAVLink so any feedback is more than welcome. I'll
> > > > > > read about libcanaero and as much as I can find about ARINC 825 on the web
> > > > > > and post back my impressions.
If we have to buy a copy of the ARINC specification, does it mean that
it is not open source?
Does this mean that the open source community can not use it?.
This is the scheme I now prefer:
1. No data packets are longer than the CAN data packet
2. No connection is required, communication is based on broadcast only
3. Data requests are not normally performed. Control data is sent at
regular intervals.
4. Each node has a unique address for identification by cli or over
MAVlink
5. Each node will present a list of resources on request.
6. All node resource types have an XML descriptor so that MAVlink/GCS
can understand what the resource is.
7. Each resource type has a set of messages that it supports. These
are described in XML.
8. Each resource on a node will be allocated a channel independent of
the node address.
9. For servo and radio connections the channel is the same as the RC
radio channel
10. It is the responsibility of the cli or user to not program two
resources with the same logical channel
11. There will be a set of messages that send data to channels, not
specific node addresses.
Pros
Efficient communication
Relatively easy to implement in software
Lowest processor resource requirement
Nodes do not have to store the unique address of other resources, only
the channel number is known.
Failsafe compatible - very important.
Cons
Needs a way to store allocated channel numbers.
Long data packets are not possible. We may consider adding a
connected mode.
Communication is not so secure.
I could easily change my mind so please do not take any of this as a
hard line.
Regards Matt
On Mar 9, 7:40 am, crashmatt <uavflightdirec...@gmail.com> wrote:
> My subtle question put a better way:
> CAN is normally connectionless.
> Will the new protocol need to support connections?
> How are connections managed?
> What stores the knowledge of a connection?
> On Mar 8, 3:12 pm, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > Thank you all for your excellent analysis so far. I've put now
> > additionally a posting up on DIYDrones to invite any non-aware
> > developer to join the discussion. I think at this stage of collecting
> > initial feedback and rough ideas the more feedback we get, the better.
> > On 8 Mrz., 14:09, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > > I think your points about the scope are very valid, so I think we
> > > should make sure to distinguish in this discussion between the "right"
> > > technical approach and the one appropriate for the scope of the
> > > typical low-cost autopilots. Although we might have different
> > > positions (only at least at this instant now), I think we totally
> > > agree on this one. I think there is also a reason MAVLink is now
> > > widely used and not SAE-AS4 (even though AS4 is kind of similar, just
> > > really HUGE), mostly because of the simplicity and (in comparison to
> > > AS4) small footprint.
> > > So I'm very interested to see where the pros and cons will take us,
> > > but keeping the scope in mind is indeed important.
> > > On 8 Mrz., 13:45, crashmatt <uavflightdirec...@gmail.com> wrote:
> > > > qgc, thats a great overview document.
> > > > First thought: Keep it simple.
> > > > ARINC is great for airliners with 200 CAN nodes.
> > > > ARINC may not be so good for a large community of open source
> > > > developers who need to understand and debug the system.
> > > > CANaero identifiers will not help us with much of the information that
> > > > we want, e.g. servo current.
> > > > The vast majority of home UAV users will never see a piece of standard
> > > > ARINC UAV equipment.
> > > > The cost for approved ARINC compatibility is too high. Those
> > > > manufacturers want some big $$$$ margin.
> > > > A subtle question about addressing that I believe is relevant:
> > > > Are satellite modules addressed in a logical or physical way?
> > > > If a position is sent to a servo, that servo needs a channel number.
> > > > Either the servo needs to know its channel number or
> > > > The transmitter needs to know the address of the servo with that
> > > > channel.
> > > > This determines how the user can/will use the system.
> > > > It also determines which kind of messaging is suitable.
> > > > I suggest a list of use cases and behaviour would help to decide which
> > > > protocol is most appropriate.
> > > > Regards Matt
> > > > On Mar 8, 10:16 am, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> > > > > This document might be helpful for a protocol overview:
> > > > > > I have followed the discussion here on the list, but had no time to
> > > > > > dig into the actual docs yet. I think Mariano really provided a clear
> > > > > > and important description of what the current main gol with CAN/
> > > > > > MAVLink is. I did a little specs review today and one can summarize:
> > > > > > - CANAerospace is used in some italian drones, but does not seem
> > > > > > widely adopted
> > > > > > - ARINC 825 is a kind of successor to CANAerospace (support by the
> > > > > > same companies and now used by Boeing and Airbus.)
> > > > > > Now interestingly ARINC 825 comes with a broadcast mode, which may
> > > > > > make it easier to tunnel MAVLink, as Mariano described.
> > > > > > I do see a need for a transparent MAVLink tunnel over CAN, this is
> > > > > > probably the first application we'll have and it'll allow to use the
> > > > > > full spectrum of MAVLink. I think it would be nice though to have this
> > > > > > tunnel operate in a mode which is compatible with one of the major
> > > > > > aerial CAN buses, preferably ARINC 825. This would not hinder any use
> > > > > > of MAVLink, but also allow to use this device together with
> > > > > > standardized ARINC 825 devices. I can well imagine ARINC 825 payloads
> > > > > > being available for MAVs soon, e.g. gimbal cameras.
> > > > > > Implementing the full ARINC 825 specs from scratch might be also
> > > > > > tedious, because, as Mariano said, one would have to write a mapper
> > > > > > between each ARINC and MAVLink message. Utilizing the tunnel scheme
> > > > > > would allow to start off with pure MAVLink, ARINC only as tunnel and
> > > > > > then add ARINC 825 support as needed (e.g. per platform).
> > > > > > The only downside over reassigning the ID fields and thus not having
> > > > > > compatibility (like initially proposed) is that we have to send the
> > > > > > ARINC/CANaerospace header and then a few additional bytes for the
> > > > > > MAVLink header. If this buys us however compatibility with a major bus
> > > > > > system, this might be something to consider. Especially since MAV
> > > > > > networks are likely not that large (8-20 nodes) and cabling is not
> > > > > > that long (allows higher speeds) bus bandwidth from a slightly
> > > > > > increased header size should not be a major problem.
> > > > > > I'll try to see if we can buy a copy of the standard to figure out how
> > > > > > well it would support such a tunnel mode.
> > > > > > > Hello Mike,
> > > > > > > Thanks for your feedback. We had a previous discussion about CANAerospace
> > > > > > > here <https://groups.google.com/d/topic/mavlink/GsAzERgnegE/discussion> and
> > > > > > > it seemed like it had many disadvantages and very few advantages. If you
> > > > > > > think that adopting either ARINC 825 or CANAerospace has advantages to the
> > > > > > > current state of MAVLink could you please tell us?
> > > > > > > Now, I am not sure I understand what you mean by a "native protocol". I've
> > > > > > > extensively used CAN before, just not in Aero applications; do you mean the
> > > > > > > way the IDs and the messages are laid out?
> > > > > > > The end goal here is to be able to automatically generate all the
> > > > > > > convenience functions (that when hand-coded are very error-prone) to send
> > > > > > > and receive data (as it is currently done for serial data) based on an XML
> > > > > > > description of the CAN messages. The way I think we see it is not a forcing
> > > > > > > of Mavlink into CAN but rather an extension of Mavlink to support CAN
> > > > > > > devices on board. For instance, QGC would send a pan/tilt/zoom command to a
> > > > > > > camera gimbal on the UAV using Mavlink; once the command is received on
> > > > > > > board the central processor (presumably the autopilot) would decode that
> > > > > > > message and create a new CAN message with the received commands and forward
> > > > > > > them to the Camera. Now this scenario is identical regardless if we use
> > > > > > > CANAerospace, ARINC 825 or any other convention we choose to use, the only
> > > > > > > differences would be how the IDs are formed and the layout of the payload in
> > > > > > > the CAN packets (that is of course if we ignore the physical layer
> > > > > > > requirements, for instance CANAerspace requires you to opto-isolate all your
> > > > > > > signals to be considered compliant).
> > > > > > > We are trying to improve MAVLink so any feedback is more than welcome. I'll
> > > > > > > read about libcanaero and as much as I can find about ARINC 825 on the web
> > > > > > > and post back my impressions.
On Thursday, March 10, 2011 12:47:04 AM UTC-6, crashmatt wrote:
> If we have to buy a copy of the ARINC specification, does it mean that > it is not open source? > Does this mean that the open source community can not use it?.
This is a great question and I think both answers are: no, we can not buy one copy and then make the implementation publicly available. Otherwise, someone already would have bought the standard and published a library.
> This is the scheme I now prefer: > 1. No data packets are longer than the CAN data packet
I think this is quite a restriction. For instance, I like what you propose on point 5, but announcing a list of resources with only 8 bytes is virtually impossible, or maybe I misunderstood the meaning of point 5.
2. No connection is required, communication is based on broadcast only
Yes, this is important and makes onboard implementation simple and requires very little resources.
> 3. Data requests are not normally performed. Control data is sent at > regular intervals.
Yes, once again except for point 5.
> 4. Each node has a unique address for identification by cli or over > MAVlink
Could you expand on this a little bit? Do you mean that component-system ID be unique across MAVLink and MAVCANLink?
> 5. Each node will present a list of resources on request.
What I understand from this point is something like the current parameter interface, where, upon request, a node announces which resources it has available.
6. All node resource types have an XML descriptor so that MAVlink/GCS
> can understand what the resource is.
Can you elaborate on this? I don't understand what you mean.
> 7. Each resource type has a set of messages that it supports. These > are described in XML.
Yes, very much like Mavlink
> 8. Each resource on a node will be allocated a channel independent of > the node address.
Not sure what you mean by a "channel", do you mean an acceptance filter? a buffer?
> 9. For servo and radio connections the channel is the same as the RC > radio channel
Again, please elaborate on what you mean by channel
> 10. It is the responsibility of the cli or user to not program two > resources with the same logical channel
> 11. There will be a set of messages that send data to channels, not > specific node addresses.
> Pros > Efficient communication > Relatively easy to implement in software > Lowest processor resource requirement > Nodes do not have to store the unique address of other resources, only > the channel number is known. > Failsafe compatible - very important.
> Cons > Needs a way to store allocated channel numbers. > Long data packets are not possible. We may consider adding a > connected mode. > Communication is not so secure.
> I could easily change my mind so please do not take any of this as a > hard line.
> On Thursday, March 10, 2011 12:47:04 AM UTC-6, crashmatt wrote:
> > If we have to buy a copy of the ARINC specification, does it mean that
> > it is not open source?
> > Does this mean that the open source community can not use it?.
> This is a great question and I think both answers are: no, we can not buy
> one copy and then make the implementation publicly available. Otherwise,
> someone already would have bought the standard and published a library.
> > This is the scheme I now prefer:
> > 1. No data packets are longer than the CAN data packet
> I think this is quite a restriction. For instance, I like what you propose
> on point 5, but announcing a list of resources with only 8 bytes is
> virtually impossible, or maybe I misunderstood the meaning of point 5.
This is still possible by using arrays of elements. As long as each
of the elements in the array is not bigger than the 8 byte CAN
message, it works ok.
Each thing in the array can be a collection of variables. Say a servo
status message could be:
Channel: 1 byte
Set Position: 2 bytes
Actual Position: 2 bytes
Current: 1 byte
Voltage: 1 byte
Temperature: 1 byte
= 8 bytes total
For a resource list the elements could be shorter. With elements
shorter than 4 bytes you can pack two or more into a CAN message.
pros:
No connections and receive buffers required
cons:
writing the code to handle the arrays is not so easy.
> 2. No connection is required, communication is based on broadcast only
> Yes, this is important and makes onboard implementation simple and requires
> very little resources.
This connectionless scheme was implemented on a UDB2 which had no
space left for any receive buffer of any sort.
I am not at all sure this is significant any more. We are unlikely to
be using processors with that little capacity again.
> > 3. Data requests are not normally performed. Control data is sent at
> > regular intervals.
> Yes, once again except for point 5.
> > 4. Each node has a unique address for identification by cli or over
> > MAVlink
> Could you expand on this a little bit? Do you mean that component-system ID
> be unique across MAVLink and MAVCANLink?
> > 5. Each node will present a list of resources on request.
> What I understand from this point is something like the current parameter
> interface, where, upon request, a node announces which resources it has
> available.
Excellent. Must read up on this bit.
> 6. All node resource types have an XML descriptor so that MAVlink/GCS
> > can understand what the resource is.
> Can you elaborate on this? I don't understand what you mean.
More like a description of physical attributes. For example, a sensor
or actuator has an IO range.
> > 7. Each resource type has a set of messages that it supports. These
> > are described in XML.
> Yes, very much like Mavlink
> > 8. Each resource on a node will be allocated a channel independent of
> > the node address.
> Not sure what you mean by a "channel", do you mean an acceptance filter? a
> buffer?
See 9 below
> > 9. For servo and radio connections the channel is the same as the RC
> > radio channel
> Again, please elaborate on what you mean by channel
Channel = standard radio channel as we think of it in RC radio
equipment
Channel 1 = Pitch, Channel 2 = Roll or
Channel 1 = Elevator, Channel 2 = left aileron etc...
The alternative is for a servo to be known as node address xx,
resource #n
The community is used to working with channel numbers. A scheme that
is familiar would be adopted more easily.
Does this make sense?
> > 10. It is the responsibility of the cli or user to not program two
> > resources with the same logical channel
> The user.
> > 11. There will be a set of messages that send data to channels, not
> > specific node addresses.
> > Pros
> > Efficient communication
> > Relatively easy to implement in software
> > Lowest processor resource requirement
> > Nodes do not have to store the unique address of other resources, only
> > the channel number is known.
> > Failsafe compatible - very important.
> > Cons
> > Needs a way to store allocated channel numbers.
> > Long data packets are not possible. We may consider adding a
> > connected mode.
> > Communication is not so secure.
> > I could easily change my mind so please do not take any of this as a
> > hard line.
> I took a quick for open source ARINC libraries. Seems to be some
> ARINC libraries around but nothing for the 800 series.
> Comments on comments below.
> Please let me know if you do not understand something again. I will
> try and explain myself better.
> Regards Matt
> On Mar 10, 3:46 pm, malife <mal...@gmail.com> wrote:
> > Please find my comments inlined below
> > On Thursday, March 10, 2011 12:47:04 AM UTC-6, crashmatt wrote:
> > > If we have to buy a copy of the ARINC specification, does it mean that
> > > it is not open source?
> > > Does this mean that the open source community can not use it?.
> > This is a great question and I think both answers are: no, we can not buy
> > one copy and then make the implementation publicly available. Otherwise,
> > someone already would have bought the standard and published a library.
> > > This is the scheme I now prefer:
> > > 1. No data packets are longer than the CAN data packet
> > I think this is quite a restriction. For instance, I like what you propose
> > on point 5, but announcing a list of resources with only 8 bytes is
> > virtually impossible, or maybe I misunderstood the meaning of point 5.
> This is still possible by using arrays of elements. As long as each
> of the elements in the array is not bigger than the 8 byte CAN
> message, it works ok.
> Each thing in the array can be a collection of variables. Say a servo
> status message could be:
> Channel: 1 byte
> Set Position: 2 bytes
> Actual Position: 2 bytes
> Current: 1 byte
> Voltage: 1 byte
> Temperature: 1 byte
> = 8 bytes total
> For a resource list the elements could be shorter. With elements
> shorter than 4 bytes you can pack two or more into a CAN message.
> pros:
> No connections and receive buffers required
> cons:
> writing the code to handle the arrays is not so easy.
> > 2. No connection is required, communication is based on broadcast only
> > Yes, this is important and makes onboard implementation simple and requires
> > very little resources.
> This connectionless scheme was implemented on a UDB2 which had no
> space left for any receive buffer of any sort.
> I am not at all sure this is significant any more. We are unlikely to
> be using processors with that little capacity again.
> > > 3. Data requests are not normally performed. Control data is sent at
> > > regular intervals.
> > Yes, once again except for point 5.
> > > 4. Each node has a unique address for identification by cli or over
> > > MAVlink
> > Could you expand on this a little bit? Do you mean that component-system ID
> > be unique across MAVLink and MAVCANLink?
> > > 5. Each node will present a list of resources on request.
> > What I understand from this point is something like the current parameter
> > interface, where, upon request, a node announces which resources it has
> > available.
> Excellent. Must read up on this bit.
> > 6. All node resource types have an XML descriptor so that MAVlink/GCS
> > > can understand what the resource is.
> > Can you elaborate on this? I don't understand what you mean.
> More like a description of physical attributes. For example, a sensor
> or actuator has an IO range.
> > > 7. Each resource type has a set of messages that it supports. These
> > > are described in XML.
> > Yes, very much like Mavlink
> > > 8. Each resource on a node will be allocated a channel independent of
> > > the node address.
> > Not sure what you mean by a "channel", do you mean an acceptance filter? a
> > buffer?
> See 9 below
> > > 9. For servo and radio connections the channel is the same as the RC
> > > radio channel
> > Again, please elaborate on what you mean by channel
> Channel = standard radio channel as we think of it in RC radio
> equipment
> Channel 1 = Pitch, Channel 2 = Roll or
> Channel 1 = Elevator, Channel 2 = left aileron etc...
> The alternative is for a servo to be known as node address xx,
> resource #n
> The community is used to working with channel numbers. A scheme that
> is familiar would be adopted more easily.
> Does this make sense?
> > > 10. It is the responsibility of the cli or user to not program two
> > > resources with the same logical channel
> > The user.
> > > 11. There will be a set of messages that send data to channels, not
> > > specific node addresses.
> > > Pros
> > > Efficient communication
> > > Relatively easy to implement in software
> > > Lowest processor resource requirement
> > > Nodes do not have to store the unique address of other resources, only
> > > the channel number is known.
> > > Failsafe compatible - very important.
> > > Cons
> > > Needs a way to store allocated channel numbers.
> > > Long data packets are not possible. We may consider adding a
> > > connected mode.
> > > Communication is not so secure.
> > > I could easily change my mind so please do not take any of this as a
> > > hard line.
1. The 29-bit Extended identifier is preferred in order to have space to layout enough information in the identifier. 2. There are two naming suggestions for each of the participants in the network: nodes and channels. 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. 5. A connectionless scheme is preferred but some have suggested to have peer-to-peer connections in order to open "streaming"channels. 6. Those of us 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 has been 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 (nodes) that are related to actuators (servos mainly) should have a "zero position" upon boot and until it gets a command from another channel (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/use and at the same time makes sense from a CAN perspective.
Feel free to comment/expand on that list. Maybe it is time to decide specially on those points where there are opposing points of view, and then move on to a clearer proposal. Any feedback is more than welcome.
A minor addition.
CAN nodes can have many channels which can include both sensors and
actuators.
Suggestion: Each sensor or actuator could have a channel number
assigned for identification.
A slight change to #9 if it is relevant.
"zero position" could be no signal or no drive.
#4 and #5 is only a preference if it really does keep things more
simple. This may yet to be proven.
A full list of pros and cons might help a decision.
Many thanks, Matt
On Mar 11, 7:49 pm, malife <mal...@gmail.com> wrote:
> 1. The 29-bit Extended identifier is preferred in order to have space to
> layout enough information in the identifier.
> 2. There are two naming suggestions for each of the participants in the
> network: nodes and channels.
> 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.
> 5. A connectionless scheme is preferred but some have suggested to have
> peer-to-peer connections in order to open "streaming"channels.
> 6. Those of us 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 has been 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 (nodes) that are related to actuators (servos mainly)
> should have a "zero position" upon boot and until it gets a command from
> another channel (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/use
> and at the same time makes sense from a CAN perspective.
> Feel free to comment/expand on that list. Maybe it is time to decide
> specially on those points where there are opposing points of view, and then
> move on to a clearer proposal. Any feedback is more than welcome.
An addition to the list:
Efficient use of message filters to limit processing of unwanted
messages
For anyone not familiar:
There are two sets of message filters on a CAN node. Each set has a
filter mask. Each set has a number of filter values.
The minimum requirement is 2 filters values on the first set and 4
filter values on the second. Some CAN implementations have more.
The address/channel of the target node in the identifier would help
and that means a connected system.
The two separate filter sets mean that two different protocols could
run together.
Suggestion:
1st set runs small, fast critical control data with no connection
2nd set runs everything else in connected mode.
A node would have the option of implementing either of these depending
on resources and functionality.
This makes it easier for developers to get something working. They
can add on the fancy features afterwards.
There are at least 4 filters available so 4 connections would be
possible.
I have not read through the new reading material so no idea if it is
the same.
Regards Matt
On Mar 11, 9:34 pm, crashmatt <uavflightdirec...@gmail.com> wrote:
> A minor addition.
> CAN nodes can have many channels which can include both sensors and
> actuators.
> Suggestion: Each sensor or actuator could have a channel number
> assigned for identification.
> A slight change to #9 if it is relevant.
> "zero position" could be no signal or no drive.
> #4 and #5 is only a preference if it really does keep things more
> simple. This may yet to be proven.
> A full list of pros and cons might help a decision.
> Many thanks, Matt
> On Mar 11, 7:49 pm, malife <mal...@gmail.com> wrote:
> > 1. The 29-bit Extended identifier is preferred in order to have space to
> > layout enough information in the identifier.
> > 2. There are two naming suggestions for each of the participants in the
> > network: nodes and channels.
> > 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.
> > 5. A connectionless scheme is preferred but some have suggested to have
> > peer-to-peer connections in order to open "streaming"channels.
> > 6. Those of us 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 has been 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 (nodes) that are related to actuators (servos mainly)
> > should have a "zero position" upon boot and until it gets a command from
> > another channel (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/use
> > and at the same time makes sense from a CAN perspective.
> > Feel free to comment/expand on that list. Maybe it is time to decide
> > specially on those points where there are opposing points of view, and then
> > move on to a clearer proposal. Any feedback is more than welcome.
Ok, so I finally got the difference between node and channel :-) Thanks for clarifying that!
I really like this idea of using the two filters for different things, I think it makes #5 moot since it would essentially support both, connectionless and connection driven communications. I guess this only leaves #3 to decide upon. Do we want pre-compiled addresses or do we want a network manager?
Precompiled addresses:
PROS: Easier to implement as every node and channel knows ahead of time who is where and who it needs to talk to. I would also make the auto code generator easier to implement. If only the connectionless mode is implemented then no state machine is needed at all. CONS: Adding a node could potentially mean recompiling the code on every node. Hot plugging is not supported
Network Manager: PROS: Hot plugging supported. Adding a node does not require recompilation of any code CONS: Hard to implement since a network manager has to be able to recognize any node on the network upon connection, register the node and its channels and communicate the address to those who need to know about it. Doing the auto code generator is potentially more complicated. Even if only the connectionless mode is implemented a state machine needs to be implemented to do the handshaking and address delivery.
Sorry, I can't follow up on the whole discussion, but regarding the
general design I would strongly discourage both assigning addresses at
compile time and network manager. A managed network is implicitly not
any more stateless plus its substantial overhead for each node and
especially for implementing the network manager. Configuring stuff at
compile time is also not a good path, since it requires to flash 5
servos with 5 different HEX files. I rather would advice to use EEPROM
config options or DIP switches on the device for configuration
options. This is however not dependent on the communication protocol.
So my point is: Each device should have a fixed assigned function and
the aircraft should know which devices it expects / uses. From a
control perspective it makes anyway no sense detecting e.g. an
additional servo, since the system would not know what to do with it.
This does not mean that the devices on the network should not announce
their presence e.g. in form of a heartbeat, but this is not the same
thing as a managed network.
I will try to follow up on the general protocol layout / ARINC /
CANaerospace next week. Looking forward to your RFC. I just wanted to
provide this input, because I think having a managed network would
drop one of the core benefits of MAVLink: being stateless and simple
to implement for most of its functionality.
On 12 Mrz., 15:53, malife <mal...@gmail.com> wrote:
> Ok, so I finally got the difference between node and channel :-) Thanks for
> clarifying that!
> I really like this idea of using the two filters for different things, I
> think it makes #5 moot since it would essentially support both,
> connectionless and connection driven communications. I guess this only
> leaves #3 to decide upon. Do we want pre-compiled addresses or do we want a
> network manager?
> Precompiled addresses:
> PROS: Easier to implement as every node and channel knows ahead of time who
> is where and who it needs to talk to. I would also make the auto code
> generator easier to implement. If only the connectionless mode is
> implemented then no state machine is needed at all.
> CONS: Adding a node could potentially mean recompiling the code on every
> node. Hot plugging is not supported
> Network Manager:
> PROS: Hot plugging supported. Adding a node does not require recompilation
> of any code
> CONS: Hard to implement since a network manager has to be able to recognize
> any node on the network upon connection, register the node and its channels
> and communicate the address to those who need to know about it. Doing the
> auto code generator is potentially more complicated. Even if only the
> connectionless mode is implemented a state machine needs to be implemented
> to do the handshaking and address delivery.
In the case of assigned channel numbers, it should not matter how the
channel number is stored or set.
It could be done by any of the methods suggested.
In the case of using a failsafe device the network manager has to be
the failsafe.
If the network manager is not the failsafe, the failsafe does not know
how to control CAN actuators on its own.
This means that the failsafe has to communicate and be dynamically
programmable. It kind of looses its failsafe qualities.
If the node (not resource) has unique mac address, it can be found by
iteration or some announcement scheme.
This would allow the user to re-program channel numbers if necessary.
It also allows the user to easily introduce new equipment.
It feels like there is a good combination where we get most of the
best of everything.
Started to read into ARINC. It does use the dual mode system for
broadcast and point-to-point support. Looks like I re-invented the
wheel yet again.
Regards Matt
On Mar 12, 4:00 pm, qgroundcontrol <m...@qgroundcontrol.org> wrote:
> Sorry, I can't follow up on the whole discussion, but regarding the
> general design I would strongly discourage both assigning addresses at
> compile time and network manager. A managed network is implicitly not
> any more stateless plus its substantial overhead for each node and
> especially for implementing the network manager. Configuring stuff at
> compile time is also not a good path, since it requires to flash 5
> servos with 5 different HEX files. I rather would advice to use EEPROM
> config options or DIP switches on the device for configuration
> options. This is however not dependent on the communication protocol.
> So my point is: Each device should have a fixed assigned function and
> the aircraft should know which devices it expects / uses. From a
> control perspective it makes anyway no sense detecting e.g. an
> additional servo, since the system would not know what to do with it.
> This does not mean that the devices on the network should not announce
> their presence e.g. in form of a heartbeat, but this is not the same
> thing as a managed network.
> I will try to follow up on the general protocol layout / ARINC /
> CANaerospace next week. Looking forward to your RFC. I just wanted to
> provide this input, because I think having a managed network would
> drop one of the core benefits of MAVLink: being stateless and simple
> to implement for most of its functionality.
> On 12 Mrz., 15:53, malife <mal...@gmail.com> wrote:
> > Ok, so I finally got the difference between node and channel :-) Thanks for
> > clarifying that!
> > I really like this idea of using the two filters for different things, I
> > think it makes #5 moot since it would essentially support both,
> > connectionless and connection driven communications. I guess this only
> > leaves #3 to decide upon. Do we want pre-compiled addresses or do we want a
> > network manager?
> > Precompiled addresses:
> > PROS: Easier to implement as every node and channel knows ahead of time who
> > is where and who it needs to talk to. I would also make the auto code
> > generator easier to implement. If only the connectionless mode is
> > implemented then no state machine is needed at all.
> > CONS: Adding a node could potentially mean recompiling the code on every
> > node. Hot plugging is not supported
> > Network Manager:
> > PROS: Hot plugging supported. Adding a node does not require recompilation
> > of any code
> > CONS: Hard to implement since a network manager has to be able to recognize
> > any node on the network upon connection, register the node and its channels
> > and communicate the address to those who need to know about it. Doing the
> > auto code generator is potentially more complicated. Even if only the
> > connectionless mode is implemented a state machine needs to be implemented
> > to do the handshaking and address delivery.
This is my mistake for not being clear enough. When I meant "at compile time" I should have said "By run time" meaning that by the time I am on the network I should know (1) my address and (2) the addresses of those who I want/need to communicate with. How do I get this? Can be via a dip-switch, someone at DIY Drones suggested a hall effect sensor and passing a magnet to identify a node (which I think is an overkill but quite clever :-) ), can be via an EEPROM, etc. The thing is that this would be left completely to the end user. We could provide a facility to the end-user to describe in his XML file the address directory, but how each node (and channels) get their ID would be the end-user responsability. There is still the potential to recompile some code, because if I add a new servo (say for a payload drop) and it was not there before, the autopilot code will have to be recompiled to contain the address of that new servo (or the eeprom will have to be reprogrammed to add that addr ess to the scan list) so I can actually send commands to it.
I too agree that we should not use a managed network, it requires lots of code to actually work. I am even not convinced that a heartbeat is necessary since that would add unnecessary traffic to the network
On Saturday, March 12, 2011 at 9:00 AM, qgroundcontrol wrote: > Sorry, I can't follow up on the whole discussion, but regarding the > general design I would strongly discourage both assigning addresses at > compile time and network manager. A managed network is implicitly not > any more stateless plus its substantial overhead for each node and > especially for implementing the network manager. Configuring stuff at > compile time is also not a good path, since it requires to flash 5 > servos with 5 different HEX files. I rather would advice to use EEPROM > config options or DIP switches on the device for configuration > options. This is however not dependent on the communication protocol. > So my point is: Each device should have a fixed assigned function and > the aircraft should know which devices it expects / uses. From a > control perspective it makes anyway no sense detecting e.g. an > additional servo, since the system would not know what to do with it.
> This does not mean that the devices on the network should not announce > their presence e.g. in form of a heartbeat, but this is not the same > thing as a managed network.
> I will try to follow up on the general protocol layout / ARINC / > CANaerospace next week. Looking forward to your RFC. I just wanted to > provide this input, because I think having a managed network would > drop one of the core benefits of MAVLink: being stateless and simple > to implement for most of its functionality.
> On 12 Mrz., 15:53, malife <mal...@gmail.com> wrote: > > Ok, so I finally got the difference between node and channel :-) Thanks for > > clarifying that!
> > I really like this idea of using the two filters for different things, I > > think it makes #5 moot since it would essentially support both, > > connectionless and connection driven communications. I guess this only > > leaves #3 to decide upon. Do we want pre-compiled addresses or do we want a > > network manager?
> > Precompiled addresses:
> > PROS: Easier to implement as every node and channel knows ahead of time who > > is where and who it needs to talk to. I would also make the auto code > > generator easier to implement. If only the connectionless mode is > > implemented then no state machine is needed at all. > > CONS: Adding a node could potentially mean recompiling the code on every > > node. Hot plugging is not supported
> > Network Manager: > > PROS: Hot plugging supported. Adding a node does not require recompilation > > of any code > > CONS: Hard to implement since a network manager has to be able to recognize > > any node on the network upon connection, register the node and its channels > > and communicate the address to those who need to know about it. Doing the > > auto code generator is potentially more complicated. Even if only the > > connectionless mode is implemented a state machine needs to be implemented > > to do the handshaking and address delivery.
> This is my mistake for not being clear enough. When I meant "at compile time" I should have said "By run time" meaning that by the time I am on the network I should know (1) my address and (2) the addresses of those who I want/need to communicate with. How do I get this? Can be via a dip-switch, someone at DIY Drones suggested a hall effect sensor and passing a magnet to identify a node (which I think is an overkill but quite clever :-) ), can be via an EEPROM, etc. The thing is that this would be left completely to the end user. We could provide a facility to the end-user to describe in his XML file the address directory, but how each node (and channels) get their ID would be the end-user responsability. There is still the potential to recompile some code, because if I add a new servo (say for a payload drop) and it was not there before, the autopilot code will have to be recompiled to contain the address of that new servo (or the eeprom will have to be reprogrammed to add that addr
> ess to the scan list) so I can actually send commands to it.
> I too agree that we should not use a managed network, it requires lots of code to actually work. I am even not convinced that a heartbeat is necessary since that would add unnecessary traffic to the network
> --
> Mariano
> On Saturday, March 12, 2011 at 9:00 AM, qgroundcontrol wrote:
> > Sorry, I can't follow up on the whole discussion, but regarding the
> > general design I would strongly discourage both assigning addresses at
> > compile time and network manager. A managed network is implicitly not
> > any more stateless plus its substantial overhead for each node and
> > especially for implementing the network manager. Configuring stuff at
> > compile time is also not a good path, since it requires to flash 5
> > servos with 5 different HEX files. I rather would advice to use EEPROM
> > config options or DIP switches on the device for configuration
> > options. This is however not dependent on the communication protocol.
> > So my point is: Each device should have a fixed assigned function and
> > the aircraft should know which devices it expects / uses. From a
> > control perspective it makes anyway no sense detecting e.g. an
> > additional servo, since the system would not know what to do with it.
> > This does not mean that the devices on the network should not announce
> > their presence e.g. in form of a heartbeat, but this is not the same
> > thing as a managed network.
> > I will try to follow up on the general protocol layout / ARINC /
> > CANaerospace next week. Looking forward to your RFC. I just wanted to
> > provide this input, because I think having a managed network would
> > drop one of the core benefits of MAVLink: being stateless and simple
> > to implement for most of its functionality.
> > On 12 Mrz., 15:53, malife <mal...@gmail.com> wrote:
> > > Ok, so I finally got the difference between node and channel :-) Thanks for
> > > clarifying that!
> > > I really like this idea of using the two filters for different things, I
> > > think it makes #5 moot since it would essentially support both,
> > > connectionless and connection driven communications. I guess this only
> > > leaves #3 to decide upon. Do we want pre-compiled addresses or do we want a
> > > network manager?
> > > Precompiled addresses:
> > > PROS: Easier to implement as every node and channel knows ahead of time who
> > > is where and who it needs to talk to. I would also make the auto code
> > > generator easier to implement. If only the connectionless mode is
> > > implemented then no state machine is needed at all.
> > > CONS: Adding a node could potentially mean recompiling the code on every
> > > node. Hot plugging is not supported
> > > Network Manager:
> > > PROS: Hot plugging supported. Adding a node does not require recompilation
> > > of any code
> > > CONS: Hard to implement since a network manager has to be able to recognize
> > > any node on the network upon connection, register the node and its channels
> > > and communicate the address to those who need to know about it. Doing the
> > > auto code generator is potentially more complicated. Even if only the
> > > connectionless mode is implemented a state machine needs to be implemented
> > > to do the handshaking and address delivery.
I'm looking at working on this for a project this summer, is there still any interest or work being done on this? Or does anyone know of any recent movement on this elsewhere? I'd be keen to read up on anything further that already exists.
On Sunday, March 13, 2011 10:31:38 AM UTC+13, crashmatt wrote:
> Thanks for clearing that up.
> I have completely lost track of which ideas came from who or how many > people are communicating. Ah well...
> On Mar 12, 9:11 pm, "Mariano I. Lizarraga" <mal...@gmail.com> wrote: > > This is my mistake for not being clear enough. When I meant "at compile > time" I should have said "By run time" meaning that by the time I am on the > network I should know (1) my address and (2) the addresses of those who I > want/need to communicate with. How do I get this? Can be via a dip-switch, > someone at DIY Drones suggested a hall effect sensor and passing a magnet > to identify a node (which I think is an overkill but quite clever :-) ), > can be via an EEPROM, etc. The thing is that this would be left completely > to the end user. We could provide a facility to the end-user to describe in > his XML file the address directory, but how each node (and channels) get > their ID would be the end-user responsability. There is still the potential > to recompile some code, because if I add a new servo (say for a payload > drop) and it was not there before, the autopilot code will have to be > recompiled to contain the address of that new servo (or the eeprom will > have to be reprogrammed to add that addr > > ess to the scan list) so I can actually send commands to it.
> > I too agree that we should not use a managed network, it requires lots > of code to actually work. I am even not convinced that a heartbeat is > necessary since that would add unnecessary traffic to the network
> > -- > > Mariano
> > On Saturday, March 12, 2011 at 9:00 AM, qgroundcontrol wrote: > > > Sorry, I can't follow up on the whole discussion, but regarding the > > > general design I would strongly discourage both assigning addresses at > > > compile time and network manager. A managed network is implicitly not > > > any more stateless plus its substantial overhead for each node and > > > especially for implementing the network manager. Configuring stuff at > > > compile time is also not a good path, since it requires to flash 5 > > > servos with 5 different HEX files. I rather would advice to use EEPROM > > > config options or DIP switches on the device for configuration > > > options. This is however not dependent on the communication protocol. > > > So my point is: Each device should have a fixed assigned function and > > > the aircraft should know which devices it expects / uses. From a > > > control perspective it makes anyway no sense detecting e.g. an > > > additional servo, since the system would not know what to do with it.
> > > This does not mean that the devices on the network should not announce > > > their presence e.g. in form of a heartbeat, but this is not the same > > > thing as a managed network.
> > > I will try to follow up on the general protocol layout / ARINC / > > > CANaerospace next week. Looking forward to your RFC. I just wanted to > > > provide this input, because I think having a managed network would > > > drop one of the core benefits of MAVLink: being stateless and simple > > > to implement for most of its functionality.
> > > On 12 Mrz., 15:53, malife <mal...@gmail.com> wrote: > > > > Ok, so I finally got the difference between node and channel :-) > Thanks for > > > > clarifying that!
> > > > I really like this idea of using the two filters for different > things, I > > > > think it makes #5 moot since it would essentially support both, > > > > connectionless and connection driven communications. I guess this > only > > > > leaves #3 to decide upon. Do we want pre-compiled addresses or do we > want a > > > > network manager?
> > > > Precompiled addresses:
> > > > PROS: Easier to implement as every node and channel knows ahead of > time who > > > > is where and who it needs to talk to. I would also make the auto > code > > > > generator easier to implement. If only the connectionless mode is > > > > implemented then no state machine is needed at all. > > > > CONS: Adding a node could potentially mean recompiling the code on > every > > > > node. Hot plugging is not supported
> > > > Network Manager: > > > > PROS: Hot plugging supported. Adding a node does not require > recompilation > > > > of any code > > > > CONS: Hard to implement since a network manager has to be able to > recognize > > > > any node on the network upon connection, register the node and its > channels > > > > and communicate the address to those who need to know about it. > Doing the > > > > auto code generator is potentially more complicated. Even if only > the > > > > connectionless mode is implemented a state machine needs to be > implemented > > > > to do the handshaking and address delivery.
