-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
common.xml: MISSION_CURRENT progress notification #2029
base: master
Are you sure you want to change the base?
Conversation
What about number of repetitions from |
It is true that this isn't exposed anywhere, and if you aren't always connected to the vehicle there is no way of guessing where you are at in the jump cycle without this kind of information. I can kind of imagine how you might use this to show a repeating route - ie mark it in some kind of separate colour and have a counter display near the start or end. A generalization of tracking turns. Maybe. Thanks. |
We would have wished for this a few times during testing, in endurance flights after lap 15 nobody knows the count anymore for sure ;) But I realise now that, even tough your proposal is well generalised, the issue with the jump count is that you are not staying at the same waypoint. So the MISSION_CURRENT message might not even be sent out for it. |
After thinking more about this, the jump repeat count is more a mission level (or "lap") state, not a waypoint state. It would be misuse of this new waypoint progress indicator. The better approach for repeat updates might be to provide a partial mission update to the GCS when the count changes. |
I'm pretty sure when we first implemented goto on the PX4 side we made the mission count down, so if you were to download the mission from the vehicle, the count would go down accordingly. It's not pretty but it seemed a way to transmit that information. I'm not sure that's still how it works though, I'd have to test it. And we should probably note/spec it either way. |
Thanks for this @hamishwillee and @julianoes. I would prefer if the Vehicle was the source of truth for this data, rather than having the GCS infer it, for two reasons:
I also think we should have an enum that defines the type for these progress fields. The specific use case I'm thinking of is And I think the following also need a progress:
and possibly also:
|
@julianoes I think you are saying that you get the mission lap by downloading the whole mission, looking for MAV_CMD_DO_JUMP instances. Each time a jump iterates, you count the repeat number down? That feels pretty heavyweight. We could use items for this and force a jump item to emit a MISSION_CURRENT with a count. Otherwise likely you'd miss them (I assume MISSION_CURRENT may emit non waypoint mission items, such as camera triggers, but generally it won't because those all get executed very quickly).
Yes. no way to infer them from telemetry.
Maybe. You can kind of see this on the map already - its not like delays and turns for which it is hard to work out what is going on from telemetry.
Maybe. Or you could say that progress is not reported for anything except the hold time. Of course you'd still want the type in this case (and I think that does make things a little easier, for the cost of just one byte). |
message_definitions/v1.0/common.xml
Outdated
</description> | ||
<field type="uint16_t" name="seq">Sequence</field> | ||
<extensions/> | ||
<field type="uint16_t" name="total" invalid="UINT16_MAX">Total number of mission items on vehicle (on last item, sequence == total). If the autopilot stores its home location as part of the mission this will be excluded from the total. 0: Not supported, UINT16_MAX if no mission is present on the vehicle.</field> | ||
<field type="uint8_t" name="mission_state" enum="MISSION_STATE" invalid="0">Mission state machine state. MISSION_STATE_UNKNOWN if state reporting not supported.</field> | ||
<field type="uint8_t" name="mission_mode" invalid="0">Vehicle is in a mode that can execute mission items or suspended. 0: Unknown, 1: In mission mode, 2: Suspended (not in mission mode).</field> | ||
<field type="uint8_t" name="item_progress_units">0: not used. 1: distance (m), 2: time (seconds), 3: count (laps)</field> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, to replace with enum if whole strategy agreed.
OK, updated in line with discussion so far. Does not consider jumps in mission. |
@sypaq-nexton We discussed in mav call last night:
|
Co-authored-by: Nick Exton <NExton@sypaq.com.au>
Co-authored-by: Nick Exton <NExton@sypaq.com.au>
<field type="uint8_t" name="item_progress_units" enum="MISSION_ITEM_PROGRESS_UNITS">Units for remaining/original progress fields. MISSION_ITEM_PROGRESS_UNITS_NOT_USED (0) if not reporting progress. Units depend on particular mission item.</field> | ||
<field type="uint8_t" name="item_progress_percentage" units="%" invalid="UINT8_MAX">0-100: Percentage remaining (countdown). 0 if progress not being reported (item_progress_units is MISSION_ITEM_PROGRESS_UNITS_NOT_USED).</field> | ||
<field type="uint16_t" name="item_progress_remaining" invalid="0">Remaining time/distance/count to complete current mission item (units in item_progress_units). 0: progress not reported or item complete.</field> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sypaq-nexton @julianoes @auturgy (FYI @MaEtUgR ) I've just updated the docs in line with our discussion on the dev call plus some minor mods based on what is actually needed.
This reports both percentage and remaining progress as a countdown, and omits the "initial count". We're really interested in how long we have to wait or our percentage through - we don't care so much what we started with - and if we do, then we can get it from the mission item.
We only report this for things that you can't infer - such as loiter/delay.
We don't report this for travel time in waypoints, which can be inferred. We don't report it for unlimited delays - they have no "progress'.
I am quite happy with this, with one minor caveat. It is harder to report "turns=3/5" as you would have to estimate by dividing by the percentage and rounding to a whole number (note, you do not have to worry about this for time based delays since remaining time or % are how you would report those). I think the saving of 2 bytes and the simplicity of what gets reported is worth it.
Does this work for everyone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can work with this. Thanks!
@hamishwillee wrote:
If you really wanted to allow counting up, you could potentially capture it in the
But I'm not sure the value justifies the extra complexity. |
Yes. It doesn't to me. |
@auturgy @julianoes You OK with this too? Or are we waiting on a @nexton-winjeel to create an implementation and then we merge (this has to be on common.xml, so if we approve, it's live). |
@nexton-winjeel We discussed this in the call last night. This has "general approval" as a workable system. Because we don't like merging things into common.xml until there is some testing/prototyping we need to see this appearing in a flight stack/GCS before we merge. Do you have a plan/timeline for that implementation? FYI that there is another PR for mission_current related to detecting mission changes, so the actual position of fields might change depending on which gets prototyped/accepted first. |
@hamishwillee: It's on my roadmap. Planned for sometime this year, but I don't have a firmer date than that. |
Thanks @NaterGator - much appreciated. |
@hamishwillee, @auturgy, @julianoes: Initial implementation for QGC and ArduPilot available at:
(Note that neither of these will build because they don't include the MAVLink changes in this PR). But with the changes in this PR, it looks like the following: I'll update those branches and raise PRs once this PR is merged. |
@nexton-winjeel So in a loiter you're reporting distance to destination then number of turns remaining? Didn't we agree we only reported the things you couldn't work out from GCS. I'm happy to discuss/modify, we just shouldn't do stuff we decided against. See
|
@hamishwillee: These QGC and ArduPilot changes don't have to be the final solution. It was done this way to demonstrate that:
|
Does this mean you need a proof-of-concept like I've done, or that you need this functionality merged into a flight stack/GCS? |
I'm not saying I don't like this, I'm saying that the implementation must be compliant with the specification. That specification currently says:
Don't get me wrong, I like what you've done and I don't think it breaks anything, as long as there is no expectation in the GCS that this information will be provided. Just making sure that when someone does an implementation it is compliant, and if we do choose to provide distance in an implementation, the docs say that is OK. In summary "the spec should be something all flight stacks can develop to and likely end up with the behaviour".
Usually it would need broad commitment from the flight stack to take your changes. If you have that, what you have done is probably enough. We'd discuss that in the dev call next week if you think you have that agreement? I.e. has Peter Barker or JamesP looked at this? |
@nexton-winjeel We discussed in the call. What is needed is a PR in ArduPilot (or PX4) so that we can see discussion and assess ArduPilot's commitment to taking this. We think it's "good" but we're wary of creating orphan fixes that never end up in a flight stack. |
@hamishwillee: ArduPilot PR here: ArduPilot/ardupilot#25249 I'll discuss it with them in the next dev call. |
Thanks! Good luck. I would like this as part of the standard. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only works in AUTO, but the same information also makes sense in RTL, GUIDED, QRTL and many other modes. How will they be handled?
maybe this should be a new message, which is requested via message intervals by the GCS?
this proposal also doesn't work for ship landing, doesn't work for precland doesn't work for follow, in each case the destination is not in the mission. Also doesn't work for rally points, again missing the destination
also, how does the flight controller know if the user wants time or distance?
in a new msg it could have float time and float distance, with NaN for unknown
Following discussion with @tridge and the ArduPilot devs, we probably want a new message that looks something like: <message id="11045" name="NAV_CONTROLLER_PROGRESS">
<description>Progress of the current Nav Controller item.</description>
<field type="uint8_t" name="percentage_complete">Percentage complete. Set to 0 if unknown.</field>
<field type="float" name="distance_remaining" units="m" invalid="NaN">Distance remaining (in metres) until the current Nav Controller item is complete. Set to NaN if unknown, or not applicable.</field>
<field type="float" name="time_remaining" units="s" invalid="NaN">Time remaining (in seconds) until the current Nav Controller item is complete. Set to NaN if unknown, or not applicable.</field>
<field type="float" name="count_remaining" invalid="NaN">Count remaining until the current Nav Controller item is complete. Set to NaN if unknown, or not applicable.</field>
<!-- MAV_MISSION_TYPE field here so we can reference Rally points? -->
<field type="uint16_t" name="seq">Sequence (mission item number). Set to 0 if not a mission item.</field>
<field type="int32_t" name="x" invalid="INT32_MIN">X pos/Latitude of nav target. Set to INT32_MIN if no target, or to use the location of the corresponding mission item.</field>
<field type="int32_t" name="y" invalid="INT32_MIN">Y pos/Longitude of nav target. Set to INT32_MIN if no target, or to use the location of the corresponding mission item.</field>
<field type="float" name="alt" units="m" invalid="NaN">Altitude of nav target. Set to NaN if no target, or to use the location of the corresponding mission item.</field>
<field type="uint8_t" name="frame" enum="MAV_FRAME">Coordinate frame of target.</field>
</message> |
All excellent points. There are many other situations where the GCS can't know what the vehicle thinks it is doing so this is much better. I don't know enough about ship landing or precland to know what you need there. Can you outline what the GCS would want to present for progress and what the vehicle would need to supply? Ditto for Follow? Isn't that an unbounded operation - we decided that you would only report for times, distances that you could know. Follow is more like an unlimited orbit. Or to put it another way "what is the progress" in this case?
So is the point here that you want to include a destination so the GCS always knows where the vehicle thinking it needs to go in cases such as rally points, where the vehicle makes a decision and does not communicate it? Nice
We've been saying that it isn't up to the user. Are we OK to leave this up to the flight stack? Do we want to allow both as proposed @peterbarker One reason I was thinking in the mission context was to avoid new messages/additional flash memory cost. What is ArduPilot's appetite for a message as proposed above. |
Discussed at Mavlink dev call again - all supportive of proposed changes/new message, waiting for update |
Note, above message should be created in a new PR in development.xml. As above, happy enough with the message proposed but would like to expand on what we expect it to be for various cases such as precland and ship landing etc so that we can be sure all the information needed is present. |
This is on my backlog, but unlikely to get to it this side of Christmas. |
This attempts to design a solution #2023 for reporting the progress in individual waypoints, in particular for loiter progress.
It adds
MISSION_CURRENT.progress
and.progress_final
which are uint_16s that represent the progress and final progress to be reached. The units of these values depend on the mission item - I have added some possible values to waypoint and loiter waypoints.@julianoes @sypaq-nexton So from above, for travel between points you can work out progress from knowledge of the mission and knowledge of current position of the vehicle.
The exceptions are loiter time and loiter turns, which you can work out from GCS if you are always connected, but not if you lose telemetry at some point.
The values can be zero'd if we expect the info to come from the GCS so no particular additional cost.
Anyway, have a think - is this "good". Are there other things that would need non-zero values, or be better if were non-zero values?