paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chad Koehnen
Subject: Re: [Paparazzi-devel] MAVLink / QGroundControl v1.0.0 available
Date: Wed, 05 Oct 2011 17:05:46 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13

Seems to me like there is four approaches to doing this.

1)  A server that takes incoming data from the UAV on a real port and translates the messages to the MavLink protocol on a virtual port. Then you could use the standard software.

2) Make a plugin that does basically the same thing, and an option to switch to the plugin or not. This would be better for the GCS software, as it would improve the options.

3) standardize the data stream (maybe something more universal such as JAUS).

4) create a user selectable lookup table for the GCS messages, ie swap out ap_downlink to various versions. This would make paparazzi better.

Seems like both 1 and 4 are good approaches to take. 4 could be implemented on the UAV side if there is a lookup table for the ground messages, and one can swap lookup tables depending on which message set they want to see. This could be dynamic or static depending on implementation. I'd prefer dynamic.

Idea 4 would also let us support the various HUD's too, which is what I'd like to see.

Other ideas?

On 10/05/2011 10:10 AM, Felix Ruess wrote:
Hi Chris,

I hope you don't mind that I also sent my reply to the mailing list, so the others can join the effort/discussion as well...

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

I'm eager to spend some time trying to integrate MavLink and
Paparazzi, if I can get support/encouragement.

I'm on Andrew Tridgel's team for the Out Back Rescue Challenge 2012,
and fly ardupilot vehicles with him once or twice a month.Tridge has
been instrumental in recent MavLink development, writing PyMavLink and
MavProxy (and less recently but more famously, rsync and samba  - a
genuine guru). He's a nice friendly guy too, I think he would be
willing to help me out on the MavLink side.

Sounds very good indeed, would be great if you could sink your teeth into this!
As I said I can assist you on the side of the paparazzi airborne code integration,
but I'm not so familiar with the ground side of things (and to put it mildly: I suck at OCaml ...)
 
> First maybe just integrate it into the airborne code so you could see
> telemetry within QGroundControl (first without flight plans support).

Does this mean the autopilot would send a mixture of Paparazzi and
MavLink to the serial line? Would that be a problem? are you sure both
systems always safely ignore noise?

I'm not sure if it currently is be possible to just send a mixture of both over the same line and have the datalink agent safely ignore all non-paparazzi messages.
Gautier, Antoine, do you guys know?

Do you think telemetry would be factored into a new subsystem for
this? Two subsystems (telemetry + telecommand)? That would be really
cool.

I think it would be good to refactor telemetry (e.g. we have different ones for fixedwings and rotorcrafts and we should be able to avoid some of the redundancy). Downlink (telemetry) and datalink (telecommand) were separated from the start, but have some interdependencies (e.g. acknowledge of moved waypoints, sending current settings, etc.)
 
> 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.

what do you think about approaching it from another direction; Start
by developing a paparazzi flight plan that emulates MavLink semantics.
E.g. with a pool of hidden general purpose waypoints (like MOB), and
actions that moves / renames them as though they were being
created/destroyed in response to MavLink commands. etc.

Can't think of any reason why this should not work by writing the appropriate flight plan, so yes :-)
You can probably just give every waypoint their own block and only move the waypoints and switch to the corresponding block through MAVLink messages.

the general approach would be to start with a dumb translator (or
telemetry/telecommand subsystem) and lots of MavLink-like custom
messages, and once the MavProxy unit tests all pass then I could
incrementally make the translator (or subsystem) smarter while
removing custom messages. If the tests pass, maybe I could sneak a
paparazzi autopilot (with the special MavLink Flight Plan) to the HITL
setup Tridge uses for MavLink / Ardupilot development...

Chris Gough

Do you want to start with writing some translator that translates MAVLink messages to the Paprazzi Ground messages on the IVY bus (and vice versa?). Or Paparazzi telemetry messages to MAVLink?
Or you could first try to integrate MAVLink into the airborne code to add the possibility to send some common telemetry messages via MAVLink...

Cheers, Felix

 

On Mon, Oct 3, 2011 at 10: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


-- 

Regards, 

Chad Koehnen
Embedded Engineer

IEM Corporation
850 River Street, Troy, New York 12180-1239
T: (518) 268-1636 ext:27 | F: (518) 268-1639
Confidential Information: This communication is for the use of the intended recipient only to the benefit of the sender. It may contain information that is privileged and confidential. If you are not the intended recipient of this communication,any disclosure, copying, further distribution or use thereof is prohibited. If you have received this communication in error, please advise me by return e-mail or by telephone and delete/destroy it.

Attachment: ckoehnen.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]