qgroundcontrol, GCS_Mavlink for APM and waypoint upload

[Andre S]

Hi,

Sorry, already my second post today but what can I do, it's my free
weekend :-)

When uploading waypoints from qgroundcontrol (version 0.9.0) to APM
2.22 (looking at the SVN it should be the same with the trunk version)
it seems that regular mission waypointpoint updates have in their
options the relative altitude flag _not_ set. Is this a bug or a
feature?

The relevant code is here in GCS_Mavlink.pde:

void GCS_MAVLINK::handleMessage(mavlink_message_t* msg) {
...
case MAVLINK_MSG_ID_WAYPOINT:
...
switch (packet.frame)
{
case MAV_FRAME_MISSION:
case MAV_FRAME_GLOBAL:
{
tell_command.lat =
1.0e7*packet.x; // in as DD converted to * t7
tell_command.lng =
1.0e7*packet.y; // in as DD converted to * t7
tell_command.alt =
packet.z*1.0e2; // in as m converted to cm
tell_command.options =
0;
break;
}
...

This has caused me some confusion since I think in the usual
discussion about APM and mission planning the waypoint altitude is
always relative (please correct me if I am wrong). In addition to the
default altitude of 0 meters in qgroundcontrol this caused me even
more confusion and a couple of hairy situations when flying :-)

Would be great to know if this is intended this way and if so then if
there is a way to use a different kind of mission planning (or get the
home altitude set automatically in qgroundcontrol or something).

BR,

Andre

[qgroundcontrol]

If I interpret the code fragment right, then your problem is that APM
does not decode the message as expected? Or is the issue rather that
QGC sends wrong values?

Once you clarify this, I can make sure it gets fixed.

-Lorenz

[Andre S]

Hi,

Thanks for the quick reply.

On Sep 3, 11:43 am, qgroundcontrol <l...@student.ethz.ch> wrote:
> If I interpret the code fragment right, then your problem is that APM
> does not decode the message as expected? Or is the issue rather that
> QGC sends wrong values?

I don't know the mavlink protocol well enough but if mission waypoint
altitudes are by default relative to home then on the APM side one
need to set the option MASK_OPTIONS_RELATIVE_ALT for tell_command
(defined in defines.h) also in the case of MAV_FRAME_MISSION (and
maybe MAV_FRAME_GLOBAL?) since otherwise the home altitude is not
added (as far as I can see).

BR,

Andre

[tri...@samba.org]

Hi Andre,

> When uploading waypoints from qgroundcontrol (version 0.9.0) to APM
> 2.22 (looking at the SVN it should be the same with the trunk version)
> it seems that regular mission waypointpoint updates have in their
> options the relative altitude flag _not_ set. Is this a bug or a
> feature?

so is QGC sending waypoints with frame set to MAV_FRAME_MISSION?

Lorenz, can you point me at any documentation on how altitude in
MAV_FRAME_MISSION is supposed to be interpreted?

> This has caused me some confusion since I think in the usual
> discussion about APM and mission planning the waypoint altitude is
> always relative (please correct me if I am wrong).

APM supports incoming waypoints in either relative altitude or global
altitude format. For relative altitude with global lat/lon values
MAV_FRAME_GLOBAL_RELATIVE_ALT is the frame I would expect.

Cheers, Tridge

[PIXHAWK]

MAV_FRAME_MISSION should never be interpreted as navigation waypoint. The meaning of the altitude field depends solely on the MAV_CMD set in the waypoint. The mission frame essentially encodes that the altitude field should be interpreted as param7, not as altitude.

Essentially the mission frame could be left out if the MAV would check the individual action and handle the parameters individually. For some commands the frame would differentiate wether it is a global or local coordinate, for those which are currently spec'ed as mission frame the autopilot could just ignore the frame field since it has no meaning.

-L

[Andre S]

Hi,

Thanks for the clarification regarding MAV_FRAME_MISSION.

On 9/3/11 1:25 PM, tridge@... wrote:
> so is QGC sending waypoints with frame set to MAV_FRAME_MISSION?

I added more debugging output and it seems that the frame field is
zero, which according to mavlink_types.h means MAV_FRAME_GLOBAL.

> > This has caused me some confusion since I think in the usual
> > discussion about APM and mission planning the waypoint altitude is
> > always relative (please correct me if I am wrong).
>
> APM supports incoming waypoints in either relative altitude or global
> altitude format. For relative altitude with global lat/lon values
> MAV_FRAME_GLOBAL_RELATIVE_ALT is the frame I would expect.

This would seem appropriate. Should one then change QGC to choose
MAV_FRAME_GLOBAL_RELATIVE_ALT instead of MAV_FRAME_GLOBAL
when transmitting mission waypoints?

Could someone confirm that this is due to the QGC code and not some
problem in the mavlink libraries I have on APM side? Value 0 could be
also just uninitialized, no?

Thanks for the work on QGC, mavlink and integration to APM! (wanted
to have said that earlier already :)

Cheers,

Andre

[PIXHAWK]

I just checked QGC and everything seems correct.

Are you sure you entered the right values and selected the right options? Please find attached a screenshot showing two valid relative altitude waypoints in the SF bay area.

Please hover with the mouse over each field to learn what it means.

If the issues persist I'd be happy to track down the bug - right now everything seems however to work as expected.

-L

[Andre S]

Hi,

Thanks for the screenshot, it actually helped. I have to say that I'm quite
embarrassed that switching the waypoint frame type to Rel. Alt/Global
now sets the options flag as expected, so all is fine. Actually I wasn't
expecting so much sophistication in the mission planning at this
point, so I guess I should still go on learning how to use QGC.

Thanks for the comments, sorry for the unnecessary "code review".

Cheers,

Andre

Hi,

Thanks for the clarification regarding MAV_FRAME_MISSION.

On 9/3/11 1:25 PM, tridge@... wrote:

[PIXHAWK]

You can argue this as well the other way around - we obviously have to improve the usability of the UI and set better default values to make this more obvious ;-). QGC was never designed to require users a four-week training before they can use it.

This makes your feedback vary valuable, so thank you!