search

mavlink / qgroundcontrol

Cross-platform ground control station for drones (Android, iOS, Mac OS, Linux, Windows)
http://qgroundcontrol.io
3.22k stars 3.56k forks source link

Feature Request: interface for autopilots to inform QGC about planned path (that might deviate from waypoints) #6976

Open thomasgubler opened 5 years ago

thomasgubler commented 5 years ago

Currently QGC displays the waypoints as set up by the user. In reality however, the autopilot might fly a slightly different route.

Reasons for this are:

In the dronecode strategy call 2018-10-30 the following idea was discussed for a first iteration that improves the situation with obstacle avoidance: Obstacle avoidance in mission mode currently works by modifying the waypoints. The idea was that these modified waypoints could simply be streamed back and then displayed in QGC somehow. No details on how this would look in terms of UI were discussed yet.

There were previous discussions also about having a common trajectory library in avodiance, qgc, px4.

FYI @mrivi @baumanta @dagar

mrivi commented 5 years ago

@thomasgubler The avoidance doesn't modify the auto waypoints (triplets). The avoidance sends to the FCU velocity or position setpoints and it is always overwrites the setpoints generated by the FlightTaskAuto even when there aren't any obstacles. What would you like to show in QGC?

dagar commented 5 years ago

Related issue https://github.com/mavlink/qgroundcontrol/issues/6016

thomasgubler commented 5 years ago

@thomasgubler The avoidance doesn't modify the auto waypoints (triplets). The avoidance sends to the FCU velocity or position setpoints and it is always overwrites the setpoints generated by the FlightTaskAuto even when there aren't any obstacles. What would you like to show in QGC?

@mrivi ok, sorry for brushing over the details. Basically the avoidance module generates a output setpoint as a function of the FlightTaskAuto setpoint. So if there are no obstacles the output setpoint is equal to the FlightTaskAuto setpoint. If there are obstacles the output setpoint is different from the FlightTaskAuto setpoint. A very first proof of concept I see would be: display the output setpoint of the avoidance on the map. Then a user can understand better why the system flies towards that setpoint.

mrivi commented 5 years ago

@thomasgubler I completely understand what you want to achieve and I think it's a necessary step.

However we cannot achieve what you're describing with the current avoidance status. If there isn't any obstacle the setpoint out of the avoidance is different from the setpoint generated by FlightTaskAuto. The avoidance always recomputes its own setpoints. This is due to historical reasons. The avoidance was first developed in offboard that requires a continuos generation of setpoints.

I think this is a good opportunity to have the avoidance replay back the setpoint generated by the autopilot if there isn't any obstacle. I believe this would benefit the avoidance performance since right now it's handing generation of takeoff, slowing down not to overshoot at waypoints etc. Features already handled in the Firmware. What needs to be evaluate if the introduced delay is acceptable.

This is something that I have been thinking for a while and I actually have a proof-of-concept branch that replays back the setpoints from the Firmware. I can share that with everyone. What call would it best to discuss these developments? Next week strategy call?

thomasgubler commented 5 years ago

I suggest very high level in the strategy call and then a technical discussion in the px4 dev call to talk about the interface.