Mission load and save #86

SamuelDudley · 2019-01-21T22:33:31Z

A query with an id other than loaded will be extracted from the database and sent to the front end
A query with an id of loaded will bring the current flight controller mission to the front end
A mutation with an id other than loaded will save a mission to the database
A mutation with an id of loaded will cause an update to the flight controller waypoints
Add sqlite database support

Modifications to the database occur via a separate mechanism (possibly mutation on missionDatabase)

The text was updated successfully, but these errors were encountered:

SamuelDudley · 2019-01-22T00:20:26Z

This returns the current mission that is loaded on the flight controller / autopilot

SamuelDudley · 2019-01-22T00:43:02Z

mission database query example:
http://newdev.maverick.one:7000/graphiql?query=%7B%0A%20%20MissionDatabase(id%3A%20%22*%22)%20%7B%0A%20%20%20%20id%0A%20%20%20%20missions%20%7B%0A%20%20%20%20%20%20id%0A%20%20%20%20%20%20mission%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D%0A

This returns all missions that are save in the database in the api to the client.

SamuelDudley · 2019-01-22T02:18:29Z

SamuelDudley · 2019-01-22T02:36:07Z

SamuelDudley · 2019-01-22T02:39:12Z

@fnoop Can you please review the above to make sure it aligns with what was discussed in gitter? Thanks!

fnoop · 2019-01-26T12:56:06Z

Could we please have a 'name' and 'description' field as well as 'id' field? this is so we can list the missions in the interface and the user will have some way of differentiating between different missions. Name could be a short title (eg. Map Field 1) of say max 16 or 32 chars and Description could be a longer text eg. 'Auto take off, Start from bottom left of field 1 and perform linear transects until field is entirely mapped, then auto land at takeoff point'.

SamuelDudley · 2019-01-26T17:00:20Z

Sure, no problem. We can keep adding fields to missionlist as we require them.

SamuelDudley · 2019-01-27T02:36:39Z

@fnoop I have added the values. Currently the loaded mission will not return a name or description, but all database missions will

query
http://dev.maverick.one:7000/graphiql?query=%7B%0A%20%20MissionList(id%3A%20%22test%22)%20%7B%0A%20%20%20%20id%0A%20%20%20%20total%0A%20%20%20%20updateTime%0A%20%20%20%20name%0A%20%20%20%20description%0A%20%20%20%20mission%20%7B%0A%20%20%20%20%20%20seq%0A%20%20%20%20%20%20isCurrent%0A%20%20%20%20%20%20autocontinue%0A%20%20%20%20%20%20frame%0A%20%20%20%20%20%20command%0A%20%20%20%20%20%20param1%0A%20%20%20%20%20%20param2%0A%20%20%20%20%20%20param3%0A%20%20%20%20%20%20param4%0A%20%20%20%20%20%20latitude%0A%20%20%20%20%20%20longitude%0A%20%20%20%20%20%20altitude%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D%0A

fnoop · 2019-01-27T11:12:56Z

Great! Thanks :)

fnoop · 2019-01-29T23:33:12Z

Is it possible to have a proper name+description for loaded mission, or is there a reason you leave it blank?

SamuelDudley · 2019-01-29T23:51:37Z

Yes it is possible but more complex than the 10min it took to add the other feature :)
If the loaded mission is coming from the database then we can pass the name and description over, but as the loaded mission is initially populated from ROS (i.e. from the vehicle) we don't have access to that information for display.

One way around this might be to add a computationally cheap hash to each of the missions in the database. When we first get the mission from the vehicle we can generate a hash and compare against the database. If we find a match, keep the mission items as is but apply the name and description that we have stored.

This also might fail as the home point is updated, changing the mission hash? Perhaps we would need two hashes, one with a home point for an exact match and one without the home point as a more general match... unsure until we try...

Can you think of another way of persisting the mission name and description?

fnoop · 2019-01-30T08:23:36Z

I actually meant just something simpler than that - to manually add a fixed name/description to the 'loaded' id mission?

fnoop · 2019-01-30T09:18:05Z

So eg. for a waypoint, the current MissionList message provides these fields:

However there are more available, eg in the mavlink meta data for the waypoint command, it says these are available params:

    "MAV_CMD": {
        "16": {
            "name": "NAV_WAYPOINT",
            "description": "Navigate to waypoint.",
            "param": {
                "1": "Hold time in decimal seconds. (ignored by fixed wing, time to stay at waypoint for rotary wing)",
                "2": "Acceptance radius in meters (if the sphere with this radius is hit, the waypoint counts as reached)",
                "3": "0 to pass through the WP, if > 0 radius in meters to pass by WP. Positive value for clockwise orbit, negative value for counter-clockwise orbit. Allows traje
ctory control.",
                "4": "Desired yaw angle at waypoint (rotary wing). NaN for unchanged.",
                "5": "Latitude",
                "6": "Longitude",
                "7": "Altitude"

Two questions:

Are these extra parameters available and can they be exposed in graphql?
Can the mavlink metadata be output with the fieldname instead of enumerated index? (ie. 'latitude' instead of '5')?

SamuelDudley · 2019-01-30T11:41:47Z

Re 1 the all the required fields are already exposed (see below).
Re 2 I'm struggling to work out why you would want that. as there are always 7 params and they map to the seven fields of the graphql message isn't it easier to access each text string by its index and display that in a form 7 columns wide?

Taking the example of NAV_WAYPOINT above the parameters are already exposed in graphql.

1: param1
2: param2
3: param3
4: param4
5: latitude
6: longitude
7: altitude

For example
Based on the text information above I know that the param in index 1 of NAV_WAYPOINT will control the hold time for a waypoint. This can be passed into the graphql mission by mutating a float value in the param1 field of the graphql mission.

The mission schema always has these 7 fields so normally the following occurs as you plan a mission:

Make a new mission item.
The user selects from the list of actions, waypoints, do commands etc. The corresponding interger to this action is stored in the command graphql field.
Next the seven parameter are looked up for that particular command and the discription text is displayed informing the user what each of the seven fields do for that particular command. The seven param fields map back to the graphql message as I described before. Lastly they select the frame which is also looked up to provide discriptions to the user. The mission item is then complete and another can be added to form a missionList.

SamuelDudley · 2019-01-30T12:00:26Z

@fnoop I'm not saying it has to occur that way, but that is what I have experienced and it seems to work reasonably well. I feel that if we index the parameters by the labels they will always be changing, where as by using the numbers you can easily map what each param does to the correct graphql message field. I hope this makes sense, let me know if I'm not explaining myself clearly :)

fnoop · 2019-01-30T12:09:58Z

Ah no, that makes perfect sense! Me being stupid.

fnoop · 2019-01-30T14:24:06Z

Params 5, 6, 7 are not always latitude, longitude and altitude, eg:

       "23": {
            "name": "NAV_LAND_LOCAL",
            "description": "Land at local position (local frame only)",
            "param": {
                "1": "Landing target number (if available)",
                "2": "Maximum accepted offset from desired landing position [m] - computed magnitude from spherical coordinates: d = sqrt(x^2 + y^2 + z^2), which gives the maximum acce
pted distance between the desired landing position and the position where the vehicle is about to land",
                "3": "Landing descend rate [ms^-1]",
                "4": "Desired yaw angle [rad]",
                "5": "Y-axis position [m]",
                "6": "X-axis position [m]",
                "7": "Z-axis / ground level position [m]"
            }
        },

        "30": {
            "name": "NAV_CONTINUE_AND_CHANGE_ALT",
            "description": "Continue on the current course and climb/descend to specified altitude.  When the altitude is reached continue to the next command (i.e., don't proceed to t
he next command until the desired altitude is reached.",
            "param": {
                "1": "Climb or Descend (0 = Neutral, command completes when within 5m of this command's altitude, 1 = Climbing, command completes when at or above this command's altitu
de, 2 = Descending, command completes when at or below this command's altitude.",
                "2": "Empty",
                "3": "Empty",
                "4": "Empty",
                "5": "Empty",
                "6": "Empty",
                "7": "Desired altitude in meters"
            }
        },

        "32": {
            "name": "DO_FOLLOW",
            "description": "Being following a target",
            "param": {
                "1": "System ID (the system ID of the FOLLOW_TARGET beacon). Send 0 to disable follow-me and return to the default position hold mode",
                "2": "RESERVED",
                "3": "RESERVED",
                "4": "altitude flag: 0: Keep current altitude, 1: keep altitude difference to target, 2: go to a fixed altitude above home",
                "5": "altitude",
                "6": "RESERVED",
                "7": "TTL in seconds in which the MAV should go to the default position hold mode after a message rx timeout"
            }
        },

Should the message fields be renamed to param5, param6, param7?

fnoop · 2019-01-30T14:33:50Z

Also looks like the param values are descriptions, are short names available?

        "23": {
            "name": "NAV_LAND_LOCAL",
            "description": "Land at local position (local frame only)",
            "param": {
                "1": "Landing target number (if available)",
                "2": "Maximum accepted offset from desired landing position [m] - computed magnitude from spherical coordinates: d = sqrt(x^2 + y^2 + z^2), which gives the maximum acce
pted distance between the desired landing position and the position where the vehicle is about to land",
                "3": "Landing descend rate [ms^-1]",
                "4": "Desired yaw angle [rad]",
                "5": "Y-axis position [m]",
                "6": "X-axis position [m]",
                "7": "Z-axis / ground level position [m]"

SamuelDudley · 2019-01-31T05:44:47Z

Should the message fields be renamed to param5, param6, param7?

Yes. I think this is a good idea.

Also looks like the param values are descriptions, are short names available?

When I wrote the extraction tool (some time ago) there was no further information available. This may have changed with later versions. As I recall MAVProxy was doing some level of hackery to generate units and short names from the longer descriptions

SamuelDudley · 2019-01-31T05:50:19Z

Just confirming the point about the lack of short name or units for the params:
https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/common.xml#L756

As you can see the information isn't available. If we require it we will need to try and extract it before generating the json... How badly do you want it? :)

cglusky · 2019-01-31T14:41:15Z

Can we just create our own (average) human readable name and map it to the name value on the client? Perhaps something like what they do to make UI's multi-lingual. Just a flat file with a look-up.

fnoop · 2019-01-31T14:42:57Z

Yes but trying to avoid manual work where possible. If it already exists elsewhere then best to use other people's hard work :)

cglusky · 2019-01-31T14:47:02Z

you could strip off the prefix and underscores of the name field.

name="MAV_CMD_NAV_WAYPOINT"

WAYPOINT

"MAV_CMD_NAV_LOITER_UNLIM"

LOITER UNLIM

And then use the description in a tool tip.

fnoop · 2019-01-31T14:49:46Z

Yes that's effectively what we're doing for the waypoint types - this is more about the waypoint parameters now. From the example above:

"1": "Landing target number (if available)",
                "2": "Maximum accepted offset from desired landing position [m] - computed magnitude from spherical coordinates: d = sqrt(x^2 + y^2 + z^2), which gives the maximum acce
pted distance between the desired landing position and the position where the vehicle is about to land",
                "3": "Landing descend rate [ms^-1]",

These should have short parameter names eg:

1. Target Number
2. Position Offset
3. Descent Rate

cglusky · 2019-01-31T14:52:55Z

ah. well, if not available then i guess you are stuck with a look-up table.

SamuelDudley · 2019-01-31T15:17:48Z

Yes, I think we will have to do the work by hand on this occasion...

SamuelDudley self-assigned this Jan 21, 2019

SamuelDudley added the enhancement New feature or request label Jan 21, 2019

This was referenced Jan 21, 2019

Add mavlink waypoint data #19

Closed

Mission support #17

Closed

fnoop mentioned this issue Jan 22, 2019

Add support for Mission and MissionList gql messages goodrobots/maverick-web#96

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mission load and save #86

Mission load and save #86

SamuelDudley commented Jan 21, 2019 •

edited

Loading

SamuelDudley commented Jan 22, 2019 •

edited

Loading

SamuelDudley commented Jan 22, 2019 •

edited

Loading

SamuelDudley commented Jan 22, 2019 •

edited

Loading

SamuelDudley commented Jan 22, 2019

SamuelDudley commented Jan 22, 2019

fnoop commented Jan 26, 2019

SamuelDudley commented Jan 26, 2019

SamuelDudley commented Jan 27, 2019 •

edited

Loading

fnoop commented Jan 27, 2019

fnoop commented Jan 29, 2019

SamuelDudley commented Jan 29, 2019 •

edited

Loading

fnoop commented Jan 30, 2019

fnoop commented Jan 30, 2019

SamuelDudley commented Jan 30, 2019

SamuelDudley commented Jan 30, 2019

fnoop commented Jan 30, 2019

fnoop commented Jan 30, 2019

fnoop commented Jan 30, 2019

SamuelDudley commented Jan 31, 2019

SamuelDudley commented Jan 31, 2019

cglusky commented Jan 31, 2019

fnoop commented Jan 31, 2019

cglusky commented Jan 31, 2019

fnoop commented Jan 31, 2019

cglusky commented Jan 31, 2019

SamuelDudley commented Jan 31, 2019

Mission load and save #86

Mission load and save #86

Comments

SamuelDudley commented Jan 21, 2019 • edited Loading

SamuelDudley commented Jan 22, 2019 • edited Loading

SamuelDudley commented Jan 22, 2019 • edited Loading

SamuelDudley commented Jan 22, 2019 • edited Loading

SamuelDudley commented Jan 22, 2019

SamuelDudley commented Jan 22, 2019

fnoop commented Jan 26, 2019

SamuelDudley commented Jan 26, 2019

SamuelDudley commented Jan 27, 2019 • edited Loading

fnoop commented Jan 27, 2019

fnoop commented Jan 29, 2019

SamuelDudley commented Jan 29, 2019 • edited Loading

fnoop commented Jan 30, 2019

fnoop commented Jan 30, 2019

SamuelDudley commented Jan 30, 2019

SamuelDudley commented Jan 30, 2019

fnoop commented Jan 30, 2019

fnoop commented Jan 30, 2019

fnoop commented Jan 30, 2019

SamuelDudley commented Jan 31, 2019

SamuelDudley commented Jan 31, 2019

cglusky commented Jan 31, 2019

fnoop commented Jan 31, 2019

cglusky commented Jan 31, 2019

fnoop commented Jan 31, 2019

cglusky commented Jan 31, 2019

SamuelDudley commented Jan 31, 2019

SamuelDudley commented Jan 21, 2019 •

edited

Loading

SamuelDudley commented Jan 22, 2019 •

edited

Loading

SamuelDudley commented Jan 22, 2019 •

edited

Loading

SamuelDudley commented Jan 22, 2019 •

edited

Loading

SamuelDudley commented Jan 27, 2019 •

edited

Loading

SamuelDudley commented Jan 29, 2019 •

edited

Loading