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

[Meier Lorenz]

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@hidden> 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