NaN values in Mission waypoints saved with MAVWPLoader.save() create invalid .waypoints file for Mission Planner

[SabrCat]

https://mavlink.io/en/messages/common.html#MAV_CMD_NAV_WAYPOINT documents that I should use waypoint parameter4 as NaN if I want the vehicle to use system yaw.

However, if I create a MAVLink_mission_item_message with param4=math.nan and then write this to file by creating a MAVWPLoader object and calling save(), these NaNs are written to file (sort of as expected).

When I then try to load this waypoints file into mission planner, it fails claiming the line is invalid. Manually changing the NaNs to zero makes the file load correctly in mission planner. However I am not sure if it is then correctly using system yaw.

Test file the save spat out:

test.waypoints.txt

[peterbarker]

@hamishwillee @DonLakeFlyer I believe we'd like to be using NaN. This is going to slow us up a bit :-)

@HB-Stratos while we'd like to move to usuing NaN in place of zero for these things it is a transition. ArduPilot won't take kindly to NaNs in some areas.

Safest for now is to user zero, but I'm really glad that someone actually did go and do this experiment!

I am curious to know how well pymavlink does when round-tripping NaNs to a file - can you populate the wploader, save the result to disk (with "NaN" in the fields), but then get the wploader to load back in from that file and have NaNs in the data that the wploader can hand back to your Python script?

@HB-Stratos I don't suppose you know how well QGC does when reading in a file with NaN in the fields?

Pretty sure that MAVProxy's mission editor isn't going to like NaNs.... I don't think there's a way to enter that into the boxes, and would require a UI change ("Unset Value" or something) to accomplish.

Problem with fixing MissionPlanner is that we'll definitely have to go and fix ArduPilot then :-)

[hamishwillee]

Yes, "using the system value" means we aren't specifying, so do the default behaviour. We generally want to use NaN for to mean this for float fields because 0 is a meaningful value for many fields, such as yaw. MISSION_ITEM_INT doesn't make this clear, but COMMAND_INT does.

@peterbarker QGC uses null to represent this case in the plan file, as shown here:

            {
                "AMSLAltAboveTerrain": null,
                "Altitude": 50,
                "AltitudeMode": 1,
                "autoContinue": true,
                "command": 16,
                "doJumpId": 2,
                "frame": 3,
                "params": [
                    0,
                    0,
                    0,
                    null,
                    47.3988682,
                    8.54620662,
                    50
                ],
                "type": "SimpleItem"
            },

Note though, that I don't know what it sends - did not check wireshark logs. I did round trip it, and while there are rounding errors, this value round-trips fine.

I think ArduPilot should support the NaN case whether or not various system round trip it properly. That at least should likely work with QGC and we can move forward over time.

[DonLakeFlyer]

QGC supports the concept of NaN meaning the value is unchanged in the mission item. As Hamish points out in QGC json plan files null means NaN. And then for the definition of mission item ui in the json command tree stuff, the "nanUnchanged" property tells QGC to generate a UI like this:

Unchecked will set the Yaw param to NaN for unchanged. Checked will set it to a specific value.

As far as NaN in a text waypoints file, QGC doesn't support that. At least not specifically unless the Qt stream reader code works with "nan" string. Don't know. Happy to implement whatever works there.

[hamishwillee]

As far as NaN in a text waypoints file, QGC doesn't support that. At least not specifically unless the Qt stream reader code works with "nan" string. Don't know. Happy to implement whatever works there.

That's great. The file format definitely needs to be able to represent NaN (and once we're agreed, let me know what https://mavlink.io/en/file_formats/#mission_plain_text_file should say).

Let's see what the testing on mavproxy/mission planner shows up.