MAVLink: Flight Control Language vs Transport Layer (or both with clear distinctions)
314 views
Skip to first unread message
Peter Hollands
Mar 1, 2011, 8:36:28 AM3/1/11
to mav...@googlegroups.com
Folks,
I'm not a communications expert, but I would like to air one thought in my head ....
We may need a clear distinction, in future plans, between MAVLink the transport layer, and MAVLink the flight control language.
In the design of MAVLink,Do we want to be clear about which layers MAVLink is addressing in a the communications model (for example the 7 layer communications stack model) ?
As MAVLink moves up the communications stack, it will probably may include flight more, and more, control language semantics.
For example Waypoint commands in MAVLink are, already, in the domain of a flight control language.
Flips is an example of a flight control language that as no association with any transport layer.
(Disclosure I have dabbled with Flips and on the committ list).
I am not specifically advocating flips here, but want to give an example of where we may be headed in describing flight missions.
Here is a specific flips flight example. So that is a a flight control language operating at the top of the communications stack (not the transport layer).
MAVLink seems to be mixing up transport layer issues with flight control semantics all in one piece of code.
Should there be a clear separation of those roles in the communications layer stack ?
Best wishes, Pete
I'm not a communications expert, but I would like to air one thought in my head ....
We may need a clear distinction, in future plans, between MAVLink the transport layer, and MAVLink the flight control language.
In the design of MAVLink,Do we want to be clear about which layers MAVLink is addressing in a the communications model (for example the 7 layer communications stack model) ?
As MAVLink moves up the communications stack, it will probably may include flight more, and more, control language semantics.
For example Waypoint commands in MAVLink are, already, in the domain of a flight control language.
Flips is an example of a flight control language that as no association with any transport layer.
(Disclosure I have dabbled with Flips and on the committ list).
I am not specifically advocating flips here, but want to give an example of where we may be headed in describing flight missions.
Here is a specific flips flight example. So that is a a flight control language operating at the top of the communications stack (not the transport layer).
MAVLink seems to be mixing up transport layer issues with flight control semantics all in one piece of code.
Should there be a clear separation of those roles in the communications layer stack ?
Best wishes, Pete
On Tue, Mar 1, 2011 at 12:58 PM, qgroundcontrol <ma...@qgroundcontrol.org> wrote:
The goal of this thread is to develop / prioritize a community roadmap
for 2011. This serves two purposes: Contributors can align with the
plan and pick individual tasks to contribute. And adopters know when
new features are available or changes occur.
We should also prioritize new features. Here is an unordered list:
GENERAL:
- Support for n-bit bitfields (1 bit boolean, 4 bit value, etc.)
- Support for automatic scaled integer conversion (message can be
decoded either as integer or as double/float scaled with a factor.
Autopilot can use the integer format and save processing time and
computers / GCS can get the data in SI units without having to know
the conversion factor)
- Support for protocol-level ACK (currently application-level ACK)
- Support for an extended message format/header with more message ids
and maybe target ID for system and component. This would not conflict
with the current protocol and be fully compatible
WAYPOINT / MISSION INTERFACE
- Full support for MAV_CMD enum in COMMAND message (until May 2011)
- Removal of MAV_ACTION and ACTION message (until August 2011, will be
replaced by MAV_COMMAND)
- Extension of the MAV_CMD enum with some more relevant actions
- Addition of better waypoint transmission protocol (backwards
compatible, so no broken code) to support single waypoint
transmissions and reduce state machine burden in MCU
- Detection / negotiation mechanism to tell GCS which commands /
mission elements a MAV supports and which not. This could be either
based on individual MAV_CMD ids or based on a class, e.g. the MAV
supports only simple waypoints or the full mission set
LONG TERM / PROTOCOL:
- MAVLink/CANAerospace translation/mapping? MAVLink over CAN?
- Suggestions?
Cheers,
Lorenz
qgroundcontrol
Mar 1, 2011, 9:17:06 AM3/1/11
to MAVLink
I think we definitely need to distinguish these two, so you have point
there. I also think it makes sense to see how we can fit with other OS
projects in that direction.
What we're currently trying to establish is however a packet format,
not the actual mission component. This is then up to the adopters and
this is where it might make sense to either have another library on
top of MAVLink to do the actual mission handling or to establish a new
MAVLink (probably rather MAVLib) layer that does this. This would
however, as you noticed, independent of the actual communication
layer.
Can you assess how the current mission format and flips would fit? Any
path where this could be made compatible?
On 1 Mrz., 14:36, Peter Hollands <peter.holla...@gmail.com> wrote:
> Folks,
>
> I'm not a communications expert, but I would like to air one thought in my
> head ....
>
> We may need a clear distinction, in future plans, between MAVLink the
> transport layer, and MAVLink the flight control language.
>
> In the design of MAVLink,Do we want to be clear about which layers MAVLink
> is addressing in a the communications model (for example the 7 layer
> communications stack model <http://en.wikipedia.org/wiki/OSI_model>) ?
there. I also think it makes sense to see how we can fit with other OS
projects in that direction.
What we're currently trying to establish is however a packet format,
not the actual mission component. This is then up to the adopters and
this is where it might make sense to either have another library on
top of MAVLink to do the actual mission handling or to establish a new
MAVLink (probably rather MAVLib) layer that does this. This would
however, as you noticed, independent of the actual communication
layer.
Can you assess how the current mission format and flips would fit? Any
path where this could be made compatible?
On 1 Mrz., 14:36, Peter Hollands <peter.holla...@gmail.com> wrote:
> Folks,
>
> I'm not a communications expert, but I would like to air one thought in my
> head ....
>
> We may need a clear distinction, in future plans, between MAVLink the
> transport layer, and MAVLink the flight control language.
>
> In the design of MAVLink,Do we want to be clear about which layers MAVLink
> is addressing in a the communications model (for example the 7 layer
>
> As MAVLink moves up the communications stack, it will probably may include
> flight more, and more, control language semantics.
> For example Waypoint commands in MAVLink are, already, in the domain of a
> flight control language.
> Flips is an example <http://code.google.com/p/flips-uav/> of a flight
> As MAVLink moves up the communications stack, it will probably may include
> flight more, and more, control language semantics.
> For example Waypoint commands in MAVLink are, already, in the domain of a
> flight control language.
> control language that as no association with any transport layer.
> (Disclosure I have dabbled with Flips and on the committ list).
> I am not specifically advocating flips here, but want to give an example of
> where we may be headed in describing flight missions.
> Here is a specific flips flight
> example.<http://code.google.com/p/flips-uav/source/browse/trunk/examples/examp...>So
> (Disclosure I have dabbled with Flips and on the committ list).
> I am not specifically advocating flips here, but want to give an example of
> where we may be headed in describing flight missions.
> Here is a specific flips flight
> that is a a flight control language operating at the top of the
> communications stack (not the transport layer).
>
> MAVLink seems to be mixing up transport layer issues with flight control
> semantics all in one piece of code.
> Should there be a clear separation of those roles in the communications
> layer stack ?
>
> Best wishes, Pete
>
> communications stack (not the transport layer).
>
> MAVLink seems to be mixing up transport layer issues with flight control
> semantics all in one piece of code.
> Should there be a clear separation of those roles in the communications
> layer stack ?
>
> Best wishes, Pete
>
Doug Weibel
Mar 1, 2011, 11:12:00 AM3/1/11
to mav...@googlegroups.com
I have no comment or opinion about distinguishing between transport and
flight control layers. However I will make a small comment on flips. I
only know flips from looking at the link Peter provided, but based on that
we already have a more advanced flight instruction set in use in APM.
Moving to flips looks like a big step backwards.
flight control layers. However I will make a small comment on flips. I
only know flips from looking at the link Peter provided, but based on that
we already have a more advanced flight instruction set in use in APM.
Moving to flips looks like a big step backwards.
Doug
Peter Hollands
Mar 1, 2011, 12:07:43 PM3/1/11
to mav...@googlegroups.com
Hi Doug,
You wrote: "Moving to flips looks like a big step backwards." I'm sorry if I gave the impression that I was advocating that MAVLink should be incorporating flips. I was not. I was trying to outline that MAVLink needs to be clear about whether it's a Flight Control Language (FCL), or a communications protocol. (or has several distinct parts). I am not familiar with APM, and so could not refer to any APM flight control language.
In the case of MatrixPilot / UAV DevBoard, Flips proved a little large for our current dspic 30F4011 (2048 bytes of RAM ; 32K of program memory in ROM). So further investigation is delayed until the UDB4 which has 32K RAM and 256K ROM).
Ben Levitt did implement some of Logo as one of MatrixPilot's FCLs last summer, and had fun flying Logo artwork in the sky !
Best wishes, Pete
You wrote: "Moving to flips looks like a big step backwards." I'm sorry if I gave the impression that I was advocating that MAVLink should be incorporating flips. I was not. I was trying to outline that MAVLink needs to be clear about whether it's a Flight Control Language (FCL), or a communications protocol. (or has several distinct parts). I am not familiar with APM, and so could not refer to any APM flight control language.
In the case of MatrixPilot / UAV DevBoard, Flips proved a little large for our current dspic 30F4011 (2048 bytes of RAM ; 32K of program memory in ROM). So further investigation is delayed until the UDB4 which has 32K RAM and 256K ROM).
Ben Levitt did implement some of Logo as one of MatrixPilot's FCLs last summer, and had fun flying Logo artwork in the sky !
Best wishes, Pete
qgroundcontrol
Mar 1, 2011, 12:23:02 PM3/1/11
to MAVLink
I think successful projects have in the past shown that both is
needed: Some level of planning and architecture and some incremental
implementation.
Currently MAVLink has established a nice set of commands that are
quite common across systems - e.g. we're currently implementing a
Linux/C++ mission manager based on the MAV_CMD enum for an autonomous,
vision-enabled indoor quad for PIXHAWK while ArduPilotMega is
implementing an MCU-based mission management system using the same
messages for outdoor fixed wing. I think this point shows that we have
a reasonable state and managed to identify the core routines and data
formats.
Before deciding the further architecture I think we first want to see
both APMs mission management and the PIXHAWK mission management in
flight and incorporate the required changes. And if eventually it
seems that the mission management component can be used across systems
(it might also be very well that its not that portable), then we can
start working on an abstract library to be used on both APM and
PIXHAWK, which then might also involve a broader community and
autopilot projects.
Although I'm in general open for collaboration, the state of FLIPS you
describe plus the comments of Doug let me tend to the conclusion that
we should focus on getting the current approach to 100% working and
then see later where different autopilot projects can share code and
which mission management component is in which state.
And another point I'd like to contribute to the discussion: Copying
data between the mission manager and and the comm protocol is one of
the major tasks of the mission manager. It might be therefore
beneficial to settle a common mission manager on one specific protocol
to have a clean mapping of comm messages to the internal structure of
the mission manager. This intuitive choice of APM/PIXHAWK might be not
only convenient, but necessary to keep the code complexity and runtime
overhead low. In this sense I'd like to invite the MatrixPilot
community, since the work on FLIPS currently is frozen, to check
wether they would want to adopt the MAVLink mission format (which
would buy GCS compatibility for two major GCS, QGroundControl and
HappyKillmore GCS). With PIXHAWK, SLUGS, APM and several other
projects implementing the mission protocol, I think it will be a very
well tested piece of software.
Thank you for getting in touch Peter, I think it is important to
always check where projects can collaborate / converge.
-Lorenz
On 1 Mrz., 18:07, Peter Hollands <peter.holla...@gmail.com> wrote:
> Hi Doug,
>
> You wrote: "Moving to flips looks like a big step backwards." I'm sorry if
>
> I gave the impression that I was advocating that MAVLink should be
> incorporating flips. I was not. I was trying to outline that MAVLink needs
> to be clear about whether it's a Flight Control Language (FCL), or a
> communications protocol. (or has several distinct parts). I am not familiar
> with APM, and so could not refer to any APM flight control language.
>
> In the case of MatrixPilot / UAV DevBoard, Flips proved a little large for
> our current dspic 30F4011 (2048 bytes of RAM ; 32K of program memory in
> ROM). So further investigation is delayed until the UDB4 which has 32K RAM
> and 256K ROM).
>
> Ben Levitt did implement some of
> Logo<http://en.wikipedia.org/wiki/Logo_%28programming_language%29>as
> one of MatrixPilot's
> FCLs <http://code.google.com/p/gentlenav/source/browse/trunk/MatrixPilot/fl...>last
needed: Some level of planning and architecture and some incremental
implementation.
Currently MAVLink has established a nice set of commands that are
quite common across systems - e.g. we're currently implementing a
Linux/C++ mission manager based on the MAV_CMD enum for an autonomous,
vision-enabled indoor quad for PIXHAWK while ArduPilotMega is
implementing an MCU-based mission management system using the same
messages for outdoor fixed wing. I think this point shows that we have
a reasonable state and managed to identify the core routines and data
formats.
Before deciding the further architecture I think we first want to see
both APMs mission management and the PIXHAWK mission management in
flight and incorporate the required changes. And if eventually it
seems that the mission management component can be used across systems
(it might also be very well that its not that portable), then we can
start working on an abstract library to be used on both APM and
PIXHAWK, which then might also involve a broader community and
autopilot projects.
Although I'm in general open for collaboration, the state of FLIPS you
describe plus the comments of Doug let me tend to the conclusion that
we should focus on getting the current approach to 100% working and
then see later where different autopilot projects can share code and
which mission management component is in which state.
And another point I'd like to contribute to the discussion: Copying
data between the mission manager and and the comm protocol is one of
the major tasks of the mission manager. It might be therefore
beneficial to settle a common mission manager on one specific protocol
to have a clean mapping of comm messages to the internal structure of
the mission manager. This intuitive choice of APM/PIXHAWK might be not
only convenient, but necessary to keep the code complexity and runtime
overhead low. In this sense I'd like to invite the MatrixPilot
community, since the work on FLIPS currently is frozen, to check
wether they would want to adopt the MAVLink mission format (which
would buy GCS compatibility for two major GCS, QGroundControl and
HappyKillmore GCS). With PIXHAWK, SLUGS, APM and several other
projects implementing the mission protocol, I think it will be a very
well tested piece of software.
Thank you for getting in touch Peter, I think it is important to
always check where projects can collaborate / converge.
-Lorenz
On 1 Mrz., 18:07, Peter Hollands <peter.holla...@gmail.com> wrote:
> Hi Doug,
>
> You wrote: "Moving to flips looks like a big step backwards." I'm sorry if
>
> I gave the impression that I was advocating that MAVLink should be
> incorporating flips. I was not. I was trying to outline that MAVLink needs
> to be clear about whether it's a Flight Control Language (FCL), or a
> communications protocol. (or has several distinct parts). I am not familiar
> with APM, and so could not refer to any APM flight control language.
>
> In the case of MatrixPilot / UAV DevBoard, Flips proved a little large for
> our current dspic 30F4011 (2048 bytes of RAM ; 32K of program memory in
> ROM). So further investigation is delayed until the UDB4 which has 32K RAM
> and 256K ROM).
>
> Ben Levitt did implement some of
> one of MatrixPilot's
> FCLs <http://code.google.com/p/gentlenav/source/browse/trunk/MatrixPilot/fl...>last
> summer, and had fun flyingLogo artwork in the
> sky<http://groups.google.com/group/uavdevboard/msg/1c67aa0af373e0f0>!
Doug Weibel
Mar 1, 2011, 2:39:14 PM3/1/11
to mav...@googlegroups.com
Hi Pete,
I knew you weren’t advocating a move to flips. Just wanted to be sure no-one else picked up that idea to move forward with.
Your comment on memory limitations hits home with me… Although APM is using a more complicated FCL with “condition” type commands, our implementation is pretty light. It is tough to do that if you are trying to write for multiple platforms….
Any chance you are coming over for Sparkfun this year? I promise an even bigger better party!
Doug
Peter Hollands
Mar 1, 2011, 3:41:59 PM3/1/11
to mav...@googlegroups.com
Doug,
Your hospitality last year was amazing, and I have great memories. Thanks.
I would loved to have come again to Sparkfun , but we've got a Royal Wedding :-) . (Actually I have personal commitments)
Perhaps I can return your hospitality .... The time is coming soon when we should have a MAVLink Interoperability Fly In.
We need to choose a good place in Europe; fairly Central. Sounds like somewhere near Zurich to me. .. :-)
Best wishes, Pete
Your hospitality last year was amazing, and I have great memories. Thanks.
I would loved to have come again to Sparkfun , but we've got a Royal Wedding :-) . (Actually I have personal commitments)
Perhaps I can return your hospitality .... The time is coming soon when we should have a MAVLink Interoperability Fly In.
We need to choose a good place in Europe; fairly Central. Sounds like somewhere near Zurich to me. .. :-)
Best wishes, Pete
qgroundcontrol
Mar 1, 2011, 3:48:08 PM3/1/11
to MAVLink
If enough interest exists, we'd be happy to host a fly-in in Zurich or
the surrounding region ;-), including a compatibility competition.
Maybe a good occasion do to a small trip in Switzerland.
And some of the MAVLink/QGC/PIXHAWK developers will be again at IMAV
2011 in Delft/Netherlands:
http://www.imav2011.org/
On 1 Mrz., 21:41, Peter Hollands <peter.holla...@gmail.com> wrote:
> Doug,
>
> Your hospitality last year was amazing, and I have great memories. Thanks.
>
> I would loved to have come again to
> Sparkfun<http://www.sparkfun.com/products/10435>, but we've got a
> Royal
> Wedding<http://en.wikipedia.org/wiki/Wedding_of_Prince_William_of_Wales_and_K...>:-)
> > Behalf Of *Peter Hollands
> > *Sent:* Tuesday, March 01, 2011 10:08 AM
> > *To:* mav...@googlegroups.com
> > *Subject:* Re: [MAVLINK] Re: MAVLink: Flight Control Language vs Transport
>
> > Best wishes, Pete
the surrounding region ;-), including a compatibility competition.
Maybe a good occasion do to a small trip in Switzerland.
And some of the MAVLink/QGC/PIXHAWK developers will be again at IMAV
2011 in Delft/Netherlands:
http://www.imav2011.org/
On 1 Mrz., 21:41, Peter Hollands <peter.holla...@gmail.com> wrote:
> Doug,
>
> Your hospitality last year was amazing, and I have great memories. Thanks.
>
> I would loved to have come again to
> Royal
> Wedding<http://en.wikipedia.org/wiki/Wedding_of_Prince_William_of_Wales_and_K...>:-)
> . (Actually I have personal commitments)
>
> Perhaps I can return your hospitality .... The time is coming soon when we
> should have a MAVLink Interoperability Fly In.
> We need to choose a good place in Europe; fairly Central. Sounds like
> somewhere near Zurich to me. .. :-)
>
> Best wishes, Pete
>
>
>
> On Tue, Mar 1, 2011 at 7:39 PM, Doug Weibel <dewei...@gmail.com> wrote:
> > Hi Pete,
>
> > I knew you weren’t advocating a move to flips. Just wanted to be sure
> > no-one else picked up that idea to move forward with.
>
> > Your comment on memory limitations hits home with me… Although APM is
> > using a more complicated FCL with “condition” type commands, our
> > implementation is pretty light. It is tough to do that if you are trying to
> > write for multiple platforms….
>
> > Any chance you are coming over for Sparkfun this year? I promise an even
> > bigger better party!
>
> > Doug
>
> > *From:* mav...@googlegroups.com [mailto:mav...@googlegroups.com] *On
>
> Perhaps I can return your hospitality .... The time is coming soon when we
> should have a MAVLink Interoperability Fly In.
> We need to choose a good place in Europe; fairly Central. Sounds like
> somewhere near Zurich to me. .. :-)
>
> Best wishes, Pete
>
>
>
> On Tue, Mar 1, 2011 at 7:39 PM, Doug Weibel <dewei...@gmail.com> wrote:
> > Hi Pete,
>
> > I knew you weren’t advocating a move to flips. Just wanted to be sure
> > no-one else picked up that idea to move forward with.
>
> > Your comment on memory limitations hits home with me… Although APM is
> > using a more complicated FCL with “condition” type commands, our
> > implementation is pretty light. It is tough to do that if you are trying to
> > write for multiple platforms….
>
> > Any chance you are coming over for Sparkfun this year? I promise an even
> > bigger better party!
>
> > Doug
>
> > Behalf Of *Peter Hollands
> > *Sent:* Tuesday, March 01, 2011 10:08 AM
> > *To:* mav...@googlegroups.com
> > *Subject:* Re: [MAVLINK] Re: MAVLink: Flight Control Language vs Transport
> > Layer (or both with clear distinctions)
>
> > Hi Doug,
>
> > You wrote: "Moving to flips looks like a big step backwards." I'm sorry if
> > I gave the impression that I was advocating that MAVLink should be
> > incorporating flips. I was not. I was trying to outline that MAVLink needs
> > to be clear about whether it's a Flight Control Language (FCL), or a
> > communications protocol. (or has several distinct parts). I am not familiar
> > with APM, and so could not refer to any APM flight control language.
>
> > In the case of MatrixPilot / UAV DevBoard, Flips proved a little large for
> > our current dspic 30F4011 (2048 bytes of RAM ; 32K of program memory in
> > ROM). So further investigation is delayed until the UDB4 which has 32K RAM
> > and 256K ROM).
>
>
> > Hi Doug,
>
> > You wrote: "Moving to flips looks like a big step backwards." I'm sorry if
> > I gave the impression that I was advocating that MAVLink should be
> > incorporating flips. I was not. I was trying to outline that MAVLink needs
> > to be clear about whether it's a Flight Control Language (FCL), or a
> > communications protocol. (or has several distinct parts). I am not familiar
> > with APM, and so could not refer to any APM flight control language.
>
> > In the case of MatrixPilot / UAV DevBoard, Flips proved a little large for
> > our current dspic 30F4011 (2048 bytes of RAM ; 32K of program memory in
> > ROM). So further investigation is delayed until the UDB4 which has 32K RAM
> > and 256K ROM).
>
> > Ben Levitt did implement some of Logo<http://en.wikipedia.org/wiki/Logo_%28programming_language%29>as one of MatrixPilot's
> > FCLs <http://code.google.com/p/gentlenav/source/browse/trunk/MatrixPilot/fl...>last summer, and had fun flyingLogo artwork in the sky<http://groups.google.com/group/uavdevboard/msg/1c67aa0af373e0f0>!
>
> > Best wishes, Pete
Reply all
Reply to author
Forward
0 new messages