When using Cockpit with BlueBoat, during mission planning I can see useful mission estimates (ETA, length, energy, coverage), like the panel shown while creating the mission.
During mission execution, I currently see the waypoint counter and the vehicle progress on the map, and the information shown in the info bar seems to be limited to the reached waypoint.
Is it possible (or planned) to show a live mission progress indicator during execution, similar to what is shown during mission planning?
Hi @MatteoBucci -
Glad you’re testing Cockpit with the BlueBoat - it is still maturing in many ways for this use case! The best way to submit this type of feedback is by creating an issue on the github repo, thanks!
That seems like a valuable expansion of the current system - thanks for the suggestion
There’s some in-progress work that’s vaguely in this direction, but I’ve linked your comment there in case your requests can be included in that effort, or turned into an Issue afterwards if not.
Hi @EliotBR ,
thanks a lot for the quick reply and for linking my request to the ongoing development — really appreciated!
I have two additional questions regarding mission execution:
Mission pause
During an AUTO mission, is there a proper way to pause the mission and then resume it?
For example, when another boat crosses the planned path.
At the moment the only workaround I found is switching from AUTO to MANUAL and then back to AUTO to continue the mission.
Is this the expected workflow, or is there a more correct/safer method?
Stopping and restarting a mission from the beginning
Is it possible to stop/terminate a mission and then restart it from the first waypoint?
In some cases I realize I need to modify the mission while it is running. When I stop, change something and then start again, the vehicle always resumes from the waypoint where it previously stopped instead of restarting from the beginning.
Am I missing a specific command or is this the current intended behavior?
I typically switch to loiter mode and then back to Auto, as the vehicle will then “stay put.” This is an expected workflow, and is correct/safe.
You can start from the beginning, or any waypoint, by selecting it and making it the next waypoint - this is possible in QGC, I’m not sure if doing this is supported in Cockpit yet, but should be eventually!
Hi @tony-white
Thanks a lot for the clarification and for the continuous work on Cockpit — we’ve been using it as our main control station and it’s improving very quickly.
As we are starting to plan multibeam surveys with the Cerulean 240-16, I’d like to ask for your advice:
for this kind of operation, would you recommend using Cockpit or QGroundControl as the primary mission planning tool?
Our main goal is to use the most complete and reliable planner for survey workflows (repeatable survey lines, easy editing in the field, and overall stability during long runs).
Are there relevant mission-planning features currently available in QGC that are not yet implemented in Cockpit and that would make it the better choice for this application?
Hi @MatteoBucci -
I think that for basic survey purposes, the two GCS solutions are equivalent! I’ve been pushing for some nice to have features in Cockpit, but they don’t even exist in QGC… I would recommend trying both and seeing what you prefer! As long as you’re not using them both at the same time, everything should work fine.
Because they use Mavlink for mission planning, a mission uploaded to the vehicle with one software can be downloaded and edited in the other.
Hi @rafael.lehmkuhl ,
thanks a lot! I’ll try the new version in the next few days and let you know how it goes.
I really appreciate your work on this.
thanks again for all your support and for the work you’re doing on Cockpit.
I have one more question about survey planning: is there currently any way, or is it planned, to create missions that avoid an internal obstacle area?
For example, during a lake survey I may have a structure in the middle that the boat must avoid. Even if I draw the area so that it is excluded, the generated survey lines still cross that zone.
Is there a way for the mission to respect that internal no-go area, or at the moment is the only solution to split the survey into multiple separate missions?
Concavity in planned survey regions is poorly handled (as you’ve found). We would like to improve that, and I’ve included some ideas for doing so in the linked Issue, but it’s not currently a high priority to fix (partly because at full complexity I believe it’s still academically an open problem). If it’s a blocker or significant source of frustration then we can try to put some time on it - I suspect there are some high yield approaches we could determine for at least some simple cases.
Outside of Cockpit, the autopilot firmware itself supports some Object Avoidance options, that may be sufficient for your use-case (even if that comes at the expense of some path planning optimality).
That said, I haven’t looked into that meaningfully, and I suspect there’s some work required to allow Cockpit to specify Fence regions to avoid. That is likely much more straightforward than survey planning algorithm improvements though, so could likely be prioritised sooner. I’ll try to look into it and open an Issue soon for what’s required.
Cockpit’s missions are not restricted to just one survey region - you should be able to draw additional survey polygons after you generate the waypoints for a previous one. That should at least be more convenient than defining and managing completely separate missions
Indeed implementing fences is much more straightforward and adds more value. ArduPilot already has the full support and knows how to handle it, and it solves for other problems as well (path navigation).
