Mission file format clarifications
mairsbw opened this issue · comments
Documenting the current version
The mission file format is woefully under described. Right now the only documentation is here. This is not descriptive enough.
I propose the following documentation:
- Whitespace-delimited file.
- Carriage return/newline indicates the end of the line
- Metadata on the first line (separated by a space): "QGC", "WPL", VERSION
- VERSION is the version * 100, currently 120
- Following lines are tab-delimited and formatted in the same order as the fields for a MISSION_ITEM MAVLink message.
- Mission index, current waypoint, coordinate frame, command, param1, param2, param3, param4, param5/x/lon, param6/y/lat, param7/z/alt, autocontinue
Documenting 1.1 & 1.0
Now a question is what is the file format as specified in the 1.1 version, as MissionPlanner had been outputting that version string until recently (see discussion here). I'm unsure as this code has been moved around so much I got 3 commits deep and then gave up. Was there a difference between the 1.2 version now and the 1.1 version?
Standardizing on a common file format
Additionally, I propose extending the file format (bumping it to 130) to account for the home location. This can be important to save during a mission, as it's normally used for at least the aircraft's recovery if not also the take-off location. This is already done by Mission Planner, and possibly other software.
I suggest adding the home location as a "-1" index as the first mission listed and then the actual missions are listed from 0 to N. Mission Planner already outputs the first mission with a "0" index, so if there are a second 0-indexed mission, it should be interpreted as the "first" one and the previous one should be interpreted as the home location.
Handing version mismatches
A big problem with this file is that versioning isn't specified in any real sense so programs aren't sure how strictly to check the file format. This was part of the reason for MissionPlanner PR. I'd like to clarify the meaning of the version string. I suggest that it should follow semantic versioning. Such that the major versions (first number) indicates a change to the format that will likely cause parsing to fail. The minor version (second digit) indicates that the semantic meaning of fields within the format has changed and it could be misinterpreted.
Now with the version better defined, error checking should be:
- If the major version doesn't match, the user should be alerted that the file is incompatible and it shouldn't be imported given that previous version of this file format are not specified. Moving forward, as the file format becomes better specified, programs could implement parsing of older files as they see fit.
- If the minor version doesn't match, parsing will likely succeed, though the field values could be wrong during import. Therefore the user should be alerted, but could be allowed to proceed depending on how the program decides to handle this. I see a "Ok"/"Cancel" dialog here being useful for desktop applications to give the user this option.
References
What is going on with APM stack storing home position in first slot? It’s a bit more of Lorenz was saying that may be going away since it’s a bit odd depending on your point of view. If not, it would be good to get organized on a way to identify a mission file with that in it.
On Nov 19, 2015, at 8:51 AM, Bryant Mairs notifications@github.com wrote:
Documenting the current version
The mission file format is woefully under described. Right now the only documentation is here http://qgroundcontrol.org/mavlink/waypoint_protocol#waypoint_file_format. This is not descriptive enough.
I propose the following documentation:
- Whitespace-delimited file.
- Carriage return/newline indicates the end of the line
- Metadata on the first line (separated by a space): "QGC", "WPL", VERSION
- VERSION is the version * 100, currently 120
- Following lines are tab-delimited and formatted in the same order as the fields for a MISSION_ITEM MAVLink message.
- Mission index, current waypoint, coordinate frame, command, param1, param2, param3, param4, param5/x/lon, param6/y/lat, param7/z/alt, autocontinue
Documenting 1.1 & 1.0Now a question is what is the file format as specified in the 1.1 version, as MissionPlanner had been outputting that version string until recently (see discussion here ArduPilot/MissionPlanner#1050 (comment)). I'm unsure as this code has been moved around so much I got 3 commits deep and then gave up. Was there a difference between the 1.2 version now and the 1.1 version?
Standardizing on a common file format
Additionally, I propose extending the file format (bumping it to 130) to account for the home location. This can be important to save during a mission, as it's normally used for at least the aircraft's recovery if not also the take-off location. This is already done by Mission Planner, and possibly other software.
I suggest adding the home location as a "-1" index as the first mission listed and then the actual missions are listed from 0 to N. Mission Planner already outputs the first mission with a "0" index, so if there are a second 0-indexed mission, it should be interpreted as the "first" one and the previous one should be interpreted as the home location.
Handing version mismatches
A big problem with this file is that versioning isn't specified in any real sense so programs aren't sure how strictly to check the file format. This was part of the reason for MissionPlanner PR ArduPilot/MissionPlanner#1050. I'd like to clarify the meaning of the version string. I suggest that it should follow semantic versioning http://www.sitepoint.com/semantic-versioning-why-you-should-using/. Such that the major versions (first number) indicates a change to the format that will likely cause parsing to fail. The minor version (second digit) indicates that the semantic meaning of fields within the format has changed and it could be misinterpreted.
Now with the version better defined, error checking should be:
If the major version doesn't match, the user should be alerted that the file is incompatible and it shouldn't be imported given that previous version of this file format are not specified. Moving forward, as the file format becomes better specified, programs could implement parsing of older files as they see fit.
If the minor version doesn't match, parsing will likely succeed, though the field values could be wrong during import. Therefore the user should be alerted, but could be allowed to proceed depending on how the program decides to handle this. I see a "Ok"/"Cancel" dialog here being useful for desktop applications to give the user this option.
ReferencesWaypoint file format http://qgroundcontrol.org/mavlink/waypoint_protocol#waypoint_file_format
MissionPlanner file format PR ArduPilot/MissionPlanner#1050
—
Reply to this email directly or view it on GitHub #2243.
I don't quite understand all of your post, but it's easy to detect right now: if there are 2 0-index waypoints, the first would be the home location. My suggestion is to officially support optional home location storage as a part of the spec by using -1 (or 65535) as their index.
"if there are 2 0-index waypoints, the first would be the home location."
As far as I know that is not the way MP and APM-P work now. For APM Stack item 0 is home position. There is no double-0 concept. I had discussed it with Bill. For PX4 Stack, item 0 is just first mission item. There is not current way to determine the difference.
The issue with storing a home position in the mission file (or having the firmware assume position 0 is a home position) is that it is bogus. The home position is determined by the vehicle at arm time not part of a mission. Once the vehicle is armed the APM stack home position from the mission file gets stomped over. PX4 stack does not do this. There is no home position in a mission.
On Nov 19, 2015, at 9:45 AM, Bryant Mairs notifications@github.com wrote:
I don't quite understand all of your post, but it's easy to detect right now: if there are 2 0-index waypoints, the first would be the home location. My suggestion is to officially support optional home location storage as a part of the spec by using -1 (or 65535) as their index.
—
Reply to this email directly or view it on GitHub #2243 (comment).
I think it's useful from an saving point of view, like archiving. If you save a mission in MP, you know the exact route the vehicle was supposed to take for the entire flight. In QGC, you don't, since the home location isn't saved in the mission file.
I think letting it be an option in saving the mission is useful, but for loading it may not be. And different programs can choose what to do with this info when loading (like discard it).
The home position saved by APM stack is a fake waypoint. The firmware completely disregards it. There is no such thing as a "home position" in a mission file (unless you use the home position command_long) that will actually affect the mission. Home position is only set by the firmware when you arm the vehicle. I can set the home position in an APM mission file to Timbuktu, save it to a file and send it to the vehicle and it will have absolutely no affect on the mission. It will use the home position when the vehicle is armed.
Hence all the confusion around home positions and missions on the APM stack. It’s strange what they do.
Lorenz: Do you know what is going on with the fake home position on APM stack, At some point you said they were getting rid of this.
On Nov 19, 2015, at 10:23 AM, Bryant Mairs notifications@github.com wrote:
I think it's useful from an saving point of view, like archiving. If you save a mission in MP, you know the exact route the vehicle was supposed to take for the entire flight. In QGC, you don't, since the home location isn't saved in the mission file.
I think letting it be an option in saving the mission is useful, but for loading it may not be. And different programs can choose what to do with this info when loading (like discard it).
—
Reply to this email directly or view it on GitHub #2243 (comment).
When running a mission, the home location does affect the mission, as that's normally the start and end of a mission. So if you wanted to archive a mission and view it later, you can't understand the actual complete vehicle path without saving the home location as well.
Think of this scenario, that you were in a complex environment, say a forest, and you're flying your drone. You mission was planned a priori, but the home location depended on the environment and terrain. Now if you run the mission and save the waypoint file without the home location, there's no way to completely reproduce that entire flightpath. I want to be able to save the home location in the mission file for what I'm doing; basically I want a saved mission file to also indicate the start and end points of the mission, not just the cental coverage area, because I consider the home location "part of the mission". Now I think you disagree with that, but I think the Mission Planner folks might be going with that line of reasoning.
Now for loading, I agree with you, it doesn't make sense to load a home location into the vehicle, so on loading I don't know of any system that "restores" a home location. But I'm not talking about the home location in the file being used when loading a mission file.
@mairsbw What you're missing is that the mission is not necessarily loaded back to the GCS. So the logged home position might or might not be accurate. There is no point in storing it hence. An accurate home position is sent via MAVLink, which should and has to be used as reference: http://mavlink.org/messages/common#HOME_POSITION
This is what is happening on PX4 and what APM is moving towards. Nobody is interested in keeping home in the mission file, for the said fundamental issues with trying that.
You are not paying attention to what I am saying! As far as I know the APM stack completely disregards that home position that you dutifully created in Mission Planner. If you do this:
- Create a mission in say Los Angeles somewhere with a home position set in LA. That mission has one additional waypoint, say 100 meters away from the home position you set and then it does an RTL mission command
- Save that mission to a file
- Bring your vehicle to San Francisco, boot it up
- Load that saved mission from the file, send it to the vehicle
- Arm the vehicle
- Run the mission
- Your vehicle will fly to the waypoint in LA and the RTL to the San Francisco home position set at arm time in step #5
The home position from the file does nothing.
On Nov 19, 2015, at 10:41 AM, Bryant Mairs notifications@github.com wrote:
When running a mission, the home location does affect the mission, as that's normally the start and end of a mission. So if you wanted to archive a mission and view it later, you can't understand the actual complete vehicle path without saving the home location as well.
Think of this scenario, that you were in a complex environment, say a forest, and you're flying your drone. You mission was planned a priori, but the home location depended on the environment and terrain. Now if you run the mission and save the waypoint file without the home location, there's no way to completely reproduce that entire flightpath. I want to be able to save the home location in the mission file for what I'm doing; basically I want a saved mission file to also indicate the start and end points of the mission, not just the cental coverage area, because I consider the home location "part of the mission". Now I think you disagree with that, but I think the Mission Planner folks might be going with that line of reasoning.
Now for loading, I agree with you, it doesn't make sense to load a home location into the vehicle, so on loading I don't know of any system that "restores" a home location. But I'm not talking about the home location in the file being used when loading a mission file.
—
Reply to this email directly or view it on GitHub #2243 (comment).
There are two issues here. 1) Is this change the Mission planner, ArduPilot/MissionPlanner@225ce74#diff-6d0106ec23d1a73f157f880d3ab672f3L1522 it updates the fileformat to QGC 120 even though there are no changes in behaviour. I just questioned that change for MP, and that really it should be handled by a change in QGC to accept QGC 110 marked files (It's not clear to me why QGC even changed to 120 files, as they are identical to previous QGC 110. APM Planner just loads then as if they are 110 version) (Ignoring the first wp being HOME for APM) I just don't want to break the workarounds already in place by other tools.
- We should potentially update the Mission File format ie QGC 200 in which we agree a new format that can be interpreted correctly between GCSs better. It would be good if the Home Location (which can be set in APM using the SET_HOME cmd could be stored, and it would be good if we could also add other data sets, for example RALLY_POINTS (this is multiple 'home locations' aka safe landing points along a mission)
In any case, I think it's a good discussion to have, and enables transitions between GCSs smooth
Is the home position in MP/APMP always a set home command? I though it just disregarded the first waypoint.
On Nov 19, 2015, at 4:07 PM, Bill Bonney notifications@github.com wrote:
There are two issues here. 1) Is this change the Mission planner, ArduPilot/MissionPlanner@225ce74#diff-6d0106ec23d1a73f157f880d3ab672f3L1522 ArduPilot/MissionPlanner@225ce74#diff-6d0106ec23d1a73f157f880d3ab672f3L1522 it updates the fileformat to QGC 120 even though there are no changes in behaviour. I just questioned that change for MP, and that really it should be handled by a change in QGC to accept QGC 110 marked files (It's not clear to me why QGC even changed to 120 files, as they are identical to previous QGC 110. APM Planner just loads then as if they are 110 version) (Ignoring the first wp being HOME for APM) I just don't want to break the workarounds already in place by other tools.
- We should potentially update the Mission File format ie QGC 200 in which we agree a new format that can be interpreted correctly between GCSs better. It would be good if the Home Location (which can be set in APM using the SET_HOME cmd could be stored, and it would be good if we could also add other data sets, for example RALLY_POINTS (this is multiple 'home locations' aka safe landing points along a mission)
In any case, I think it's a good discussion to have, and enables transitions between GCSs smooth
—
Reply to this email directly or view it on GitHub #2243 (comment).
Bill: I guess I’m confused. You mention the SET_HOME command for home position but also talk about ignoring the first waypoint which I thought you had told me was just a fake WAYPOINT command. Which one is it?
As it currently stands QGC can support any mavlink standard mission item for file loading. It just can’t necessarily allow visual editing on all of them. Even if you can’t visual edit you can still load file and send the vehicle.
No idea why file format number on QGC was bumped. Before my time I think.
On Nov 19, 2015, at 7:04 PM, Donald Gagne don@thegagnes.com wrote:
Is the home position in MP/APMP always a set home command? I though it just disregarded the first waypoint.
On Nov 19, 2015, at 4:07 PM, Bill Bonney <notifications@github.com mailto:notifications@github.com> wrote:
There are two issues here. 1) Is this change the Mission planner, ArduPilot/MissionPlanner@225ce74#diff-6d0106ec23d1a73f157f880d3ab672f3L1522 ArduPilot/MissionPlanner@225ce74#diff-6d0106ec23d1a73f157f880d3ab672f3L1522 it updates the fileformat to QGC 120 even though there are no changes in behaviour. I just questioned that change for MP, and that really it should be handled by a change in QGC to accept QGC 110 marked files (It's not clear to me why QGC even changed to 120 files, as they are identical to previous QGC 110. APM Planner just loads then as if they are 110 version) (Ignoring the first wp being HOME for APM) I just don't want to break the workarounds already in place by other tools.
- We should potentially update the Mission File format ie QGC 200 in which we agree a new format that can be interpreted correctly between GCSs better. It would be good if the Home Location (which can be set in APM using the SET_HOME cmd could be stored, and it would be good if we could also add other data sets, for example RALLY_POINTS (this is multiple 'home locations' aka safe landing points along a mission)
In any case, I think it's a good discussion to have, and enables transitions between GCSs smooth
—
Reply to this email directly or view it on GitHub #2243 (comment).
I just tried it with MP. The first waypoint is not a SET_HOME command. It's just a fake waypoint. Is that really the way things are going to stay? Seems like a confusing user model making people think they are doing something pretty important they are not. Like Bryant’s forest mission use case. The fact that people think they are setting a real home position they will return to, when in fact they are not seems dangerous to me. Or do I still not get this whole thing? From a QGC user model I have not carried that across. Home is only shown when you have the vehicle send a real home position back. For APM stack connections I just send a bogus waypoint 0 across and expect one back. Is that really not going to change on the APM side?
If not, then we have to deal with file format issues:
- As it stands now there is no way to determine if a mission file has a fake home position in it. We should mark that somehow. I’m not sure the double 0, or -1 sequence number is the way to go. Reason being you’ve to massage the sequence numbers on every read/write. I’d probably just add an additional boolean field at the end of the first item which is true/false for fake home position.
- Semantic versioning is nice. But i’m not sure that isn’t hitting that problem with a sledgehammer for this use case. I really don’t care either way.
- In order to support Rally Points I think that needs to become part of the real mavlink spec for missions. There’s a command long for rally land, but there doesn’t seem to be a standard set for how you define the landing points. Am I missing something. How does APM do that?
- Doesn’t seem worthwhile to bump MP file format if we are just going to do it again to fix the above problems.
On Nov 19, 2015, at 7:09 PM, Donald Gagne don@thegagnes.com wrote:
Bill: I guess I’m confused. You mention the SET_HOME command for home position but also talk about ignoring the first waypoint which I thought you had told me was just a fake WAYPOINT command. Which one is it?
As it currently stands QGC can support any mavlink standard mission item for file loading. It just can’t necessarily allow visual editing on all of them. Even if you can’t visual edit you can still load file and send the vehicle.
No idea why file format number on QGC was bumped. Before my time I think.
On Nov 19, 2015, at 7:04 PM, Donald Gagne <don@thegagnes.com mailto:don@thegagnes.com> wrote:
Is the home position in MP/APMP always a set home command? I though it just disregarded the first waypoint.
On Nov 19, 2015, at 4:07 PM, Bill Bonney <notifications@github.com mailto:notifications@github.com> wrote:
There are two issues here. 1) Is this change the Mission planner, ArduPilot/MissionPlanner@225ce74#diff-6d0106ec23d1a73f157f880d3ab672f3L1522 ArduPilot/MissionPlanner@225ce74#diff-6d0106ec23d1a73f157f880d3ab672f3L1522 it updates the fileformat to QGC 120 even though there are no changes in behaviour. I just questioned that change for MP, and that really it should be handled by a change in QGC to accept QGC 110 marked files (It's not clear to me why QGC even changed to 120 files, as they are identical to previous QGC 110. APM Planner just loads then as if they are 110 version) (Ignoring the first wp being HOME for APM) I just don't want to break the workarounds already in place by other tools.
- We should potentially update the Mission File format ie QGC 200 in which we agree a new format that can be interpreted correctly between GCSs better. It would be good if the Home Location (which can be set in APM using the SET_HOME cmd could be stored, and it would be good if we could also add other data sets, for example RALLY_POINTS (this is multiple 'home locations' aka safe landing points along a mission)
In any case, I think it's a good discussion to have, and enables transitions between GCSs smooth
—
Reply to this email directly or view it on GitHub #2243 (comment).
Yeah, it looked like this really opened Pandora's box. We seem to have a few issues here:
- How groundstation software is handling the home location. I don't think this really matters for this discussion, as I think the different software suites should be free to deal with it as they like.
- The versioning of the mission file. Right now it's 120, which doesn't seem to be any different than 110 and is causing compatibility problems.
- The Home location is being stored as a first fake mission by Mission Planner, possibly other software. The legitimacy of that is still in question, but if it sticks around it should be standardized somehow.
- If the home location is standardized in the mission file, should this include Rally Points, though it doesn't seem like there is a clear consensus on how that would work.
- There is the thought that if a home location is in the waypoint file that it must be used. This a) isn't how Mission Planner does it (it prompts you if you want to use the file home location before clobbering your vehicle's one) and b) isn't necessary. QGC can continue to ignore home location or rally point data in the file if they want to. I think this should be a groundstation choice, but it should still be supported as part of this mission file standard.
At the end of the day all of these issues need to be resolved one way or another taking into account a) the current state of things, b) backwards compatibility/route of least breakage, and c) improved documentation and standardization.
So I don't understand your comment about massaging the sequence numbers on every read/write, since they're done in aggregate, not for individual lines, you just read & write files in 3 chunks: rally points, home location, regular missions. I don't think the ordering of rally points matters, but if they do rally points can be stored in reverse-sequential order so the "first" rally point is the -N, the "second" is -(N-1), and the "last" is -2.
My suggestion is as follows:
- Standardize the current mission file format as 120 and document it. It won't contain the home location. Mission Planner is fine with their current 110 version, as are everyone else as we'll just consider that version non-standardized.
- Create a new 130 mission format that everyone should support as well. The sequence ID is 0..N for missions, and -1 for the home location and -2..N for additional rally points. It is always in monotonically increasing order of sequence ID. Additionally, there is no obligation for ground stations to actually use the home location or rally points when loading the file (as QGC seems inclined to continue to do, but Mission Planner probably will use it). But this data should still be saved in these files if it has been set (so QGC's behavior should change here). With things bettern documented it should be easy for systems to support their current version along with the new 130 version (they could even support the 120 version which is what QGC is using right now).
If people are really ambitious there is the option of correcting the file ending to be .mission, which is more clear than .waypoints (in fact this was already done for the MISSION_* MAVLink messages long ago.
Hopefully some clarification. The current situation is that the first waypoint is ignored when loaded to a vehicle in APM as its the home WP as set by the autopilot. If you save a mission we save that WP0, but it's never set on upload, just ignored by Ardupilot. This relates to files marked QGC 110 saved by MP and AP2.
QCC bumped it version to QGC 120, I made AP2 accept that to aid interoperability. But we save as QGC 110 to also work with MP. Other tools (Tower for example) work with MP, so it's the dominant format here, hence why I questioned MP bumping the version. (I think QGC would be better to accept QGC 110 as well)
This just keeps compatibility as is for now.
For future fix, I'd like to see a file format that contained an explicit optional HOME waypoint as well as mission waypoints and rally points, Ardupilot supports setting of home using the MAV Link command, so it would be a nice to have that from a saved mission. Relying on where you armed is not always an accurate lock. I'd only like this feature for a new file format that was not ambiguous .
This doesn't solve the problem with APM essentially starting mission numbered from 1 at the moment. A fix is coming, but time frame is not predictable,,we should be able to handle that with the current system being implemented. And we need it since 3.3 just released and 3.4 are unlikely to be candidates that have a fix.
As an aside, maybe we can add the text APM-HOME as a the description for first waypoint, to help when we save mission from APM for now?
@billbonney I think what you're saying is in line with what I'm saying. I'm suggesting that we basically have three versions:
- 110 - This is the Mission Planner version. The first listed mission is actually the home location.
- 120 - This is what QGC uses, it is only mission items within it.
- 130- Here we standardize storing either/both home locations and missions in the mission file.
By separating all of these out as incompatible versions we fix a lot of things by making the version checking correct for all of these applications. People can actually implement support for reading all three versions, but writing should be switched over to the 130 format.
We'll just move to JSON or a similar format for missions for QGC which will put an end to all of this. The whole index magic is nasty and not how you architect a file format. Once we're in JSON world things can be added.
I need to check if an onboard parser can be written easily, since that is something being done right now and which I don't want to break.
I don't see what JSON adds besides more complexity. I'd rather not make this file format more complex than reading a line and splitting it with tabs, especially since it's easy to add a new field on a line to handle more metadata. For example we can specify HOME, RALLY_POINT, and MISSION as a new column which will handle things nicely. The reason I suggest using seq_id, is because it's actually a redundant field. They're always in order and never out of order, so the seq_id can be inferred from the line number. From a least-amount-of-work standpoint reusing the seq_id makes a hell of a lot of sense, and as far as ugliness goes, I don't see how this is that bad.
@LorenzMeier Maybe it's a idea to standardize on GeoJSON http://geojson.org as well
@mairsbw I'm saying we shouldn't drop the current tab delimited format, for now. It serves a purpose, but it quickly limited when you start do try and represent a more 'dynamic' type missions. Specifying mission based on a line by line, procedural set of actions get rather large set of waypoints quickly
For example, it would be awesome to be able to save a mission, not as a set of waypoints, but descriptions of higher order actions. A good example is for mapping an area, if that is stored as a polygon shape, you can create the lawnmower pattern based on conditions the day you fly, like flying with the current wind direction, you may have changed cameras, so it can recalculate distance between passes for a desired overlap etc...
Another example would be using a line string to plot a takeoff procedure. Or a line string for a path to inspect a Transmission Pylon, which is entered around a new current home point for each mission.
The lowest common denominator for a mission list would be a set of Mission-Items some with GeoPoints, some without.
@billbonney Sure, that sounds good moving forward. But I think that's out-of-scope for this current discussion. To unify the ground stations on the current missions that everyone is using is simple and easy to do with the current mission file format. I'm all for extending mission support moving forward, but I think that should be done for version 200, not this 130 versioning. And then switching to a more flexible format might make sense.
My suggestion would be to move straight to a new xml or json format. Lorenz says he’s been in discussion with Randy and the whole fake home position thing is going away. So, I’m not too interested in figuring out a file format around that. I’d much rather move forward.
Bill: APM stack has more things like you describe supported already. Do you want to take a stab at the first definition and we can go from there?
On Nov 20, 2015, at 9:43 AM, Bryant Mairs notifications@github.com wrote:
@billbonney https://github.com/billbonney Sure, that sounds good moving forward. But I think that's out-of-scope for this current discussion. To unify the ground stations on the current missions that everyone is using is simple and easy to do with the current mission file format. I'm all for extending mission support moving forward, but I think that should be done for version 200, not this 130 versioning. And then switching to a more flexible format might make sense.
—
Reply to this email directly or view it on GitHub #2243 (comment).
@mairsbw What you're proposing just ends up re-implementing a format like JSON incrementally, but at the cost of bugs and requiring the need to hand-craft parsers. A minimal JSON file is not really harder to parse in a tiny custom parser but allows to truly store the whole mission including all the very valid things Bill describes. If we introduce a new format and require the whole community to update code the cost of just doing that is much better justified with a format fixing all the corner cases and relieving adopters of writing their own parsers.
I'll try to find the time to show you the equivalent of a current mission in JSON - if you parse just that it won't be many more operations than now.
If you look at the part below you could in a naive parser just extract the mission items easily. Its a couple of operations more than in the old format, but its not going to take days to implement and can be done in plain C without dependencies. For anyone with access to a proper JSON library it becomes really easy to support more complex missions then and the format can be extended without breaking backwards-compatibility.
{
"format_version": "0001",
"default_speed": "10",
"mission_items":
[
{ "id": "0", "type": "2", "param1":"0", "param2":"1.1", },
{ "id": "1", "type": "2" },
{ "id": "2", "type": "3" },
{ "id": "3", "type": "2" },
{ "id": "4", "type": "2" },
{ "id": "5", "type": "1" },
{ "id": "6", "type": "2" }
]
}@DonLakeFlyer @LorenzMeier I find some time this week and write an example in a JSON format, with some idea on how it can be extended in future.
Awesome, thanks Bill.
On Nov 21, 2015, at 10:01 AM, Bill Bonney notifications@github.com wrote:
@DonLakeFlyer https://github.com/DonLakeFlyer @LorenzMeier https://github.com/LorenzMeier I find some time this week and write an example in a JSON format, with some idea on how it can be extended in future.
—
Reply to this email directly or view it on GitHub #2243 (comment).
I know it's been awhile but I have something similar to lorenz wrote.
I was thinking to have in the future the ability to have extended elements to be something like
e.g specify a polygon area to scan (essentially it’s a polygon as as in geoJson http://geojson.org/geojson-spec.html )
{ "type": "mission_area", "id": "5", "current": "0", "frame": "3",
"coordinates" : [
[120.0, 54.0, 20.0], [120.1, 54.0, 20.0], [120.1, 54.1, 20.0], [120.0, 54.0, 20.0], [120.0, 54.0, 20.0]
],
"properties": {
"heading" : 270.0,
"width" : 20.0,
"speed" : 50.0,
"alt" : 20.0
}
see https://gist.github.com/billbonney/8d8b8798ba5bb7a50fa8#file-mission_format_mavlink-json-L31
There definitely missing params probably, but you get the idea. We could use line-string to connect more action based commands as well.
These objects can then be down converted into mission_items if required. So either the onboard autopilot can handle the higher order object, or the SBC, or the GCS before sending to the autopilot.
Thanks Bill. I’ll use this as a starting point for integrating the survey stuff.
On Jan 2, 2016, at 9:03 PM, Bill Bonney notifications@github.com wrote:
I know it's been awhile but I have something similar to lorenz wrote.
I was thinking to have in the future the ability to have extended elements to be something like
e.g specify a polygon area to scan (essentially it’s a polygon as as in geoJson http://geojson.org/geojson-spec.html http://geojson.org/geojson-spec.html )
see https://gist.github.com/billbonney/8d8b8798ba5bb7a50fa8#file-mission_format_mavlink-json-L31 https://gist.github.com/billbonney/8d8b8798ba5bb7a50fa8#file-mission_format_mavlink-json-L31
There definitely missing params probably, but you get the idea. We could use line-string to connect more action based commands as well.These objects can then be down converted into mission_items if required. So either the onboard autopilot can handle the higher order object, or the SBC, or the GCS before sending to the autopilot.
{ "type": "mission_area", "id": "5", "current": "0", "frame": "3", "coordinates" : [ [120.0, 54.0, 20.0], [120.1, 54.0, 20.0], [120.1, 54.1, 20.0], [120.0, 54.0, 20.0], [120.0, 54.0, 20.0] ], "properties": { "heading" : 270.0, "width" : 20.0, "speed" : 50.0, "alt" : 20.0 }https://gist.github.com/billbonney/8d8b8798ba5bb7a50fa8 https://gist.github.com/billbonney/8d8b8798ba5bb7a50fa8
—
Reply to this email directly or view it on GitHub #2243 (comment).
Closing as stale.