MISSION_ITEM_INT for more precise mission items

[Andrew Tridgell]

Hi Randy and Lorenz,

This is a followup to a discussion we had on the weekly dev call about
int32 lat/lon varients of the MISSION_ITEM message, in order to get cm
level precision in missions.

We've all agreed we need a new MISSION_ITEM_INT message to get int32
lat/lon. The only question really is what triggers the GCS and autopilot
to use it.

The current MISSION_ITEM is used in two ways:

1) sent from GCS to vehicle in response to MISSION_REQUEST from the
vehicle to the GCS (mission upload)

2) sent from vehicle to GCS in response to a MISSION_REQUEST_LIST or
MISSION_REQUEST_PARTIAL_LIST from GCS to vehicle (mission download)

One way to decide if a new MISSION_ITEM_INT should be used is to add new
MISSION_REQUEST_INT, MISSION_REQUEST_LIST_INT and
MISSION_REQUEST_PARTIAL_LIST_INT messages. They would be combined with
timeouts to determine if the other end of the link could handle the new
message.

I don't think this is the best method though. The timeout handling will
be ugly, and what we're really trying to solve is a generic problem of
the GCS knowing what the vehicle is capable of.

Randy and I have discussed this a bit, and we think adding a new
AUTOPILOT_VERSION message like this might be a reasonable solution:

<message id="tbd" name="AUTOPILOT_VERSION">
<description>Version and capability of autopilot software</description>
<field type="uint32_t" name="capabilities">bitmask of capabilities (see AUTOPILOT_CAPABILITY enum</field>
<field type="uint32_t" name="version">Firmware version number</field>
</message>

this would be sent regularly by the vehicle, at a low rate (maybe
0.5Hz?). Initially only one AUTOPILOT_CAPABILITY bit would be defined,
AUTOPILOT_CAPABILITY_MISSION_ITEM_INT, which would say the autopilot
understands the MISSION_ITEM_INT message, but I am sure we will hit this
situation again and use more bits.

The version number is there to provide an alternative mechanism which
has been requested by GCS authors in the past so they can tell the
firmware version in the vehicle. The encoding of the
AUTOPILOT_VERSION.version field would be specific to the
existing HEARTBEAT.autopilot MAV_AUTOPILOT field. For ardupilot we will
probably encode is as 4 version bytes (major, minor, subminor and
patchlevel).

Note that this wouldn't solve the problem of the vehicle knowing if the
GCS can handle a MISSION_ITEM_INT message in response to a
MISSION_REQUEST_LIST message. We could have a version number in both
directions to solve this, but I don't think it is needed. Users tend to
update GCS software rapidly, and will soon notice if they can't download
missions from their vehicle. So I don't think we need to solve that.

Lorenz, what do you think of this approach?

Cheers, Tridge

[PIXHAWK]

Hi,

I think subset message support handling will definitely be needed. Before doing that I want to revisit the set of existing navigation computer interface messages and revise them. So far I think our lab is the main group using them, so refactoring them wouldn’t be too hard on the adopters.

There are other things that need to be addressed, most notably resolving the ambiguity in the current param interface (which led to APM’s interpretation suffering from the same problem as the mission item - you can’t send an accurate GPS position as parameter because you’re casting to floats). Its not a protocol issue as it had been supporting int32 native transmission from day one, but the API didn’t force the usage of the right union and made it easy for that bug / misinterpretation on the APM side to happen.

I will send a diff around for public comments on the whole change set and I will include a more complete approach for navigation computer set points including vector offsets in body frame (we’re using them internally already).

-Lorenz

> --
> Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "MAVLink" sind.
> Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an mavlink+u...@googlegroups.com.
> Weitere Optionen: https://groups.google.com/d/optout

[Lorenz Meier]

Hi,

I think subset message support handling will definitely be needed. Before doing that I want to revisit the set of existing navigation computer interface messages and revise them. So far I think our lab is the main group using them, so refactoring them wouldn’t be too hard on the adopters.

There are other things that need to be addressed, most notably resolving the ambiguity in the current param interface (which led to APM’s interpretation suffering from the same problem as the mission item - you can’t send an accurate GPS position as parameter because you’re casting to floats). Its not a protocol issue as it had been supporting int32 native transmission from day one, but the API didn’t force the usage of the right union and made it easy for that bug / misinterpretation on the APM side to happen.

I will send a diff around for public comments on the whole change set and I will include a more complete approach for navigation computer set points including vector offsets in body frame (we’re using them internally already).

-Lorenz


Am 28.05.2014 um 04:09 schrieb Andrew Tridgell <tri...@samba.org>: