Re: [Paparazzi-devel] MAVLink / QGroundControl v1.0.0 available

[Felix Ruess]

Hi again,

integrating MAVLink into the airborne code for some basic telemetry stuff should not be too much work.

Although, as Gautier pointed out, completely supporting MAVLink for all messages is quite a bit more involved as e.g. some sensor modules directly send Paparazzi messages.

For some basic periodic messages we could start by replacing sw/airborne/ap_downlink.h (in the fixedwing case) and sw/airborne/firmwares/rotorcraft/telemetry.h (for rotorcrafts) along with the implementation of MAVLink itself. That should not be too hard... and you would fairly quickly have some telemetry status information available via MAVLink, e.g. to display in QGroundControl.

But that really doesn't give you much, you will be missing lots of things to have a usable system, and I'm not convinced that we can easily have both protocols running at the same time. So to really use the system you would need more or less complete support of all features (e.g. flight plans) in QGroundControl).

I think first of all the main question is what is wanted/needed?

* Do we just want to send some basic telemetry data via MAVLink?
  (Analog to what Gareth pointed out: the HappyKillmore GCS can show some basic telemetry like position from Paparazzi vehicles)
  This would also be enough to e.g. use some antenna tracking devices that only speak MAVLink,
  without extra translators on the ground.

* Do we want to properly support MAVLink as a protocol and message set in Paparazzi?
  Which would mean adding support for Paparazzi specific features/messages to MAVLink.
  Would also mean something along the lines of writing another datalink client that listens on the serial port
  for MAVLink messages and forwards them to the IVY Bus.
  This implies either translating back to the Paparazzi Ground messages or adding new messages there.

* Do we want to be able to use the Paparazzi GCS to control other (non-paparazzi) UAVs?
  This would mean properly supporting more or less the full MAVLink things in the GCS, quite a lot to do...

* Do people want to just have a way to use QGroundControl with Paparazzi equipped aircrafts,
  replacing the Paparazzi GCS (e.g on Windows)?
  In this case this would best be done on the QGroundControl side as Gautier said.


Personally I think it would be very nice to arrive at a common core message set for different autopilot systems, so that other systems can at least get some basic telemetry data from other vehicles and send some simple commands.
I also think that integrating MAVLink into the airborne code (at least for the most needed messages/functions) would be nice and a good reason to refactor the Paparazzi downlink (telemetry) and datalink (telecommand).
At the same time adding a datalink agent (with some sort of translator function) to show other vehicles in the Paprazzi GCS would be nice.

Cheers, Felix

On Wed, Oct 5, 2011 at 10:56 AM, Gautier Hattenberger <address@hidden> wrote:

Hi everyone,

Concerning, the choice of connecting QGC directly to the airborne code, I don't see it has an easy task at all. If the uplink is easier (the parsing is concentrated in datalink.c), all the downlink messages should be rewritten to match MAVLink. There is no reason for our PPRZ messages to have the same fields, and they are spread all other the code.

On the other hand, the ground protocol is for now common to all type of airframes and has been stable for some year now. The choice of a modular architecture for the ground station with Ivy was motivated to be able to extend functionality without touching existing parts or just replacing some of them.

If your goal is to provide a replacement for the graphical part of the gs, then it is only the GCS agent that should be replaced by a "bridge" to QGC that is in charge of translating PPRZ <-> MAVLink. This piece of software can even be a part of QGC if it has some kind of plugin mechanism that could connect to Ivy. This principal has already been done successfully at Enac to connect Paparazzi to two other architectures.

And a last word about standards : http://xkcd.com/927/

Gautier

On 04/10/2011 19:48, Meier Lorenz wrote:

I'm convinced that once we try to add MAVLink support to Paparazzi, this will automatically give the further GCS development a spin towards the needs of PPZ, I agree with Christophe.

Now for the first steps - does the current protocol survive to be interleaved with MAVLink? If it does, we could add support for IVY to QGC and use it as front-end. The other option would be to extend the PPZ server to forward all bytes it sees via UDP to QGC. This might be even safer, as it is a non-intrusive change.

The antenna tracking is for sure one possible first step. I don't know about onboard parameters in PPZ, but I could assume that the custom configurable sliders might be something that is worth implementing as first step as well.

Is there someone willing to push the onboard integration? I could assist with off-board implementation.

Cheers,
Lorenz

--- Ursprüngl. Mitteilung ---
Von:Chris Gough
Gesendet: 03-10-2011, 16:36
An: address@hidden
Betreff:Re: [Paparazzi-devel] MAVLink / QGroundControl v1.0.0 available

I think it would be great if we could seamlessly swap ground station
software (or autopilots) as easily as hats and boots, but failing
that, what sorts of "partial interoperability" would be most useful?

The simplest use-case for partial interoperability that I have come up
with is a tracking antenna that could be used with Paparazzi and
MAVLink systems.
I imagined a "protocol bridge" component that was both connected to
the ivy bus and was a MAVLink serial endpoint, and all it did was
translate identity and location messages between the two systems. The
tracking antenna could use either MAVLink or Paparazzi protocol
natively (e.g. the existing paparazzi tracking antenna solution), but
be used with either type of vehicle. Ardupilot-hunting games might be
fun too, but limited usefulness.

STANAG 4586 defines levels of interoperability between UAS components,
but that analysis seem focused on the information flow between assets
and commanders during military operations. I imagine the value of
interoperability between open source components would be more diverse,
with perhaps most of the benefit in development and education
contexts. The problem is not so much incorporating lots of different
things at the same time (or being able to expediently reassign
control, etc), it's more about learning and sharing with maximum
efficiency.

If an "identity and location translator" provided the lowest level of
partial interoperability between MAVLink and Paparazzi, what is the
next level up (and what is it good for)?

Chris Gough

P.S. FWIW, this paper discusses approaches to harmonizing STANAG 4586 and JAUS:

http://www.ndia.org/Divisions/Divisions/Robotics/Documents/Content/ContentGroups/Divisions1/Robotics/Interoperability%20Standards%20Analysis%20(ISA).pdf

Unsurprisingly, they (a standards committee) conclude the best
approach is an new international standard... plus a "service oriented
architecture" implementation. And maybe a bigger office with a window.

On Mon, Oct 3, 2011 at 7:13 PM, Christophe De Wagter<address@hidden>  wrote:

Dear Lorenz,
I think in the interest of "the opensource autopilots community" combining
projects is probably a very good thing. It makes both projects consider the
strong and weaker assets of the other and I believe in term that should lead
to improvements everywhere.
There are a few difficulties as paparazzi flight plans are rather unique in
that they are complete programs with for instance payload control but even
control-loop interactions and so on. E.g. the flight plan triggers camera's,
takes pictures during some straight phases of search patterns but not during
turns, can reconfigure the control loops and automatically move waypoints
during landing, can include exceptions like coming back home when out of
radio range or battery voltage, can define forbidden zones, do step rolls,
polygon searching, catapult launching, formation flying, collision avoidance
and things like that which do not easily convert to a list of waypoints.
But combining projects might trigger QGCS to become even more
mission-driven. Even if I'll probably keep using the very stable, light
but powerful paparazzi GCS (system) I'm in for the adding mavlink support to
any feasible extend.
-Christophe



On Mon, Oct 3, 2011 at 1:13 AM, Felix Ruess<address@hidden>  wrote:

Hi,

just some quick thoughs on this as well:

I think it would be nice to integrate MAVLink into Paparazzi.
First maybe just integrate it into the airborne code so you could see
telemetry within QGroundControl (first without flight plans support).
The Paparazzi Flight Plans concept does not neatly fit into the
waypoint list based concept of QGroundControl (at least not on first
glance).
But we could add support for flight plans to MavLink and in principle
to QGroundControl as well I guess.

Not really sure what the best way is for the long run.
We could make another datalink client that reads MAVLink messages from
the serial port and posts them on the IVY bus.
But I haven't looked at the differences/similarities between the
standard MAVLink and Paparazzi messages so far.
So if we really want to support both, Paparazzi and MavLink messages
at the same time, we'll have to take a closer look at the common
messages.

I don't really have the time to do this myself, but I can provide
support to whoever wants to tackle this...

Cheers, Felix

On Thu, Sep 29, 2011 at 4:29 PM, Gareth Roberts
<address@hiddenmanchester.ac.uk>  wrote:

Hi Lorenz,

I am impressed with QGroundControl and use it with our ArduPilotMega
boards.  We also use MAVLINK extensively internally.

That said, I think there would be some reluctance within the community -
the paparazzi GCS is pretty much feature complete and also extremely
stable (more so that QGC in it's current form in my opinion).
The cross-platform nature of QGC is appealing though.

The problem you'll have is the architecture of the paparazzi system.

data_link ->  server ->  GCS
simulation ->        ->  Other stuff

This communication is via the Ivy bus and IMO is extremely useful; you
can subscribe other programs all of which can read and alter the status
of a UAV.

To get QGC working with paparazzi you'd either need to remove the
datalink and server components (which would break a lot of things),
alter datalink to also speak mavlink (but then QGC wouldn't work) or
alter QGC to understand the Ivy bus.

http://paparazzi.enac.fr/wiki/Overview

Cheers,
Gareth

On Thu, 2011-09-29 at 09:48 -0400, Lorenz Meier wrote:

Hi all,


MAVLink v1.0 will be released soon, bringing a number of new features
and a substantially cleaned up protocol to the community. It is
however still under review, so adopting MAVLink now would thus offer
you the opportunity to shape the protocol.


It would be great to have Paparazzi and QGroundControl working
together and I'm willing to help in the integration and adjust QGC
where needed.


I've substantially improved QGroundControl over the last few weeks,
the most notable differences are some cleanups in the user interface
and a factor of 2x-4x in speedup - it should consume substantially
less CPU now.
Here is a video of the latest features, including some customization
that would allow you to tune controllers.


http://www.youtube.com/watch?v=LaQ0bH0WW80




It should be rather straightforward to port MAVLink to Paparazzi. Of
course it would need some effort, but it shouldn't involve difficult
steps. I would be ready to help this process by active help on this
mailing list and changes to QGroundControl where needed.


For testing the current version, I recommend to build from source, it
is quickly set up, or to download the v10release binaries from the
downloads section of the website.
http://www.qgroundcontrol.org/dev/start


If you're on Mac OS or Windows and don't have a build environment
installed, you can download QGroundControl v1.0.0 here. PLEASE NOTE
THAT THESE ARE ALPHA BINARIES! They are well tested and did not crash
during the tests, but do not reflect at all the final application
stability.
https://github.com/mavlink/v10release/downloads


A few more links with useful information:


How to add MAVLink support to your autopilot:
http://www.qgroundcontrol.org/dev/mavlink_onboard_integration_tutorial


The new mission lib (makes parameter and waypoint support a lot
easier, see the testing folder / main.c for a working Linux example):
https://github.com/pixhawk/mavlink/tree/v10release/missionlib


Available ground control stations for MAVLink:
http://www.qgroundcontrol.org/mavlink/start#mavlink_ecosystem




Cheers,
Lorenz
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--
.

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel