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
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel