-
-
Notifications
You must be signed in to change notification settings - Fork 504
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
Download mission capability #145
Conversation
plugins/mission/mission.h
Outdated
* | ||
* The mission items are downloaded from a drone. | ||
* | ||
* @param mission_items reference to vector of mission items. |
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.
Capitalise R in reference
plugins/mission/mission.h
Outdated
* The mission items are downloaded from a drone. | ||
* | ||
* @param mission_items reference to vector of mission items. | ||
* @param callback callback to receive result of this request |
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.
Capitisalise C in "Callback to ..."
plugins/mission/mission.h
Outdated
|
||
/** | ||
* @brief Starts the mission (asynchronous). | ||
* | ||
* Note that the mission must be uplaoded to the vehicle using `send_mission_async()` before | ||
* Note that the mission must be uplaoded to the vehicle using `upload_mission_async()` before | ||
* this method is called. | ||
* | ||
* @param callback callback to receive result of this request |
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.
Capitalise sentence
plugins/mission/mission.h
Outdated
@@ -49,21 +51,37 @@ class Mission | |||
typedef std::function<void(Result)> result_callback_t; | |||
|
|||
/** | |||
* @brief Sends a vector of mission items to the device (asynchronous). | |||
* @brief Uploads a vector of mission items to the device (asynchronous). | |||
* | |||
* The mission items are uploaded to a drone. Once uploaded the mission can be started and | |||
* executed even if a connection is lost. | |||
* | |||
* @param mission_items reference to vector of mission items. | |||
* @param callback callback to receive result of this request |
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.
Capitalize C in sentence. Add full stop.
Can we have
|
So to be very clear, you can't download a "partial mission". It either fails and returns nothing or succeeds. Correct? So is the assumption that a user will create mission in QGC (say) and that DroneCore will allow you to download it if it is valid? Are we expecting people to then manipulate the mission in DroneCore and reupload? How useful is this? I have created linked issue to update the mission example and guide docs when this goes in. I still think that as a user I'd sometime like to bypass DC altogether and upload/download raw mavlink mission files. Then I could support any mission I liked. Not as "robust" but an easy way to get dronecore working with any vehicle. This looks fine to me, but leave to @mrpollo to do proper C++ review. |
|
Correct. I don't want bugs or corner cases because something gets omitted or changed.
No, that's not really the use case. This is to download DroneCore missions or super simple QGC missions if really needed.
Thanks.
The point of DroneCore is to give you a thoroughly tested API. Once more functionality is tested and implemented easy to use, then we can add that. If somebody wants to write its own mission, they can just write their own mission plugin or use something else altogether. I know this is very opinionated but I see people struggling with the mavlink API every day and if we just replicate that with DroneCore we are no better but only added another layer.
Yes please. |
d17aebd
to
f6d5247
Compare
So yes to almost everything. The "no" is I still don't see why we are bothering. Consider
Yes, but if you're not going to manipulate them, why would you bother? If its a DroneCore mission you already created it in your app, so why bother downloading it from the vehicle? Just seems a bit pointless. Perhaps doesn't matter for this PR, but for the docs it is nice to be able to explain why functionality exists. |
Good point. Because it is on my feature todo list 😄. One reason could be that you plan a mission using a desktop application and upload it to the drone. Later when you view the telemetry using an app on your phone you can download the mission, so you can follow the progress. |
@hamishwillee here's the list of supported commands this PR introduces
from |
Thanks @mrpollo - #145 (comment) not above very useful. I won't do update in my docs tree until this has been merged into develop. @julianoes What other ones are supported - I should add them all. |
It's just these, I think. |
Thanks. Any ETA on this going into develop? |
It seems more intuitive to "upload" a mission than to "send" it. Also, once the functionality to download a mission, it would be awkward to call it "receive" a mission.
And don't forget to set activity.
When we implement mission item download we need to have a unique mapping from mavlink messages to mission items, otherwise we can't compare uploaded to downloaded mission items. Previously, we omitted gimbal and speed settings if the previous mission item had the same setting. However, this would mean that we don't have a unique mapping when downloading a mission item. For instance if we have two mission items with speed 5 m/s, we would only send one mission item and omit the speed setting in the second mission item. When downloading the mavlink items for this, we get NAN for the speed of the second mission item because we don't if it was actually set or omitted when set. By always setting the speed, we have a bit more overhead but it makes it explicit and we don't lose information when doing multiple transfers. To save mission item "space" it is always possible to set the speed to NAN which means no mavlink item is sent for it.
This should make the mission module somewhat thread-safe.
This adds the feature to download mission items from a vehicle. This currently fails if any command or waypoint is downloaded that is not implemented. Implemented means what can be uploaded.
f6d5247
to
af5007d
Compare
@hamishwillee rebased, if CI goes through we can merge it. |
Looks like some checks were not successful :-( |
This changes the API from
send_mission_async()
toupload_mission_async()
and addsdownload_mission_async
.This allows missions created with DroneCore to be downloaded from the vehicle. However, DroneCore only supports a subset of the mavlink mission protocol and will fail with the
Result::UNSUPPORTED
for anything it does not know.