mavlink / qgroundcontrol

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

Feature request: Ghost mode :) #4555

Open AndKe opened 7 years ago

AndKe commented 7 years ago

On BLOS/BRLOS , it's not uncommon for telemetry to die for a while, direct 433Mhz radio link may be barely obscured when going into a valley, cellular coverage may vary, and Iridium is just unreliable - regardless of technology, we lose link now and then.

The mission below, with the only landable/suitable Home location, is doomed to lose connection when going to WP 25,24,21,21,17,16 ... then one sits and awaits it's return.

screenshot from 2017-02-15 23-12-11

It would be very nice, if a loss of communication, were indicated by the aircraft symbol, but another, white/ghostly aircraft continued the path at average GS from the last ~5 waypoints, ..until telemetry is back. that would make a very clear when to expect the plane to be back.
I suggested average speed, because that would handle an possible head/tailwind, still resulting in a decent estimate.

dagar commented 7 years ago

Neat idea, although it gets complicated when you factor in configured firmware behaviour and any situation other than moving in a straight line. Something that would be much quicker (and hopefully still useful) to implement would be a counter displayed for when the vehicle was last heard from. That would at least help you estimate.

AndKe commented 7 years ago

Displaying seconds is better than nothing, but if there were a ghost flying at last average GS it would give some clue about when the plane should be expected to communicate again. Counting seconds does not really give a clue about that. I do not ask for full simulation of spline/turn radius, acceptance radius and so on, just a symbol moving along the line with a speed based on last few leg's average GS.
So the solution would be to collect and average GC, then, if signal lost, place an ghost plane between current/next waypoint(s) based on time x average speed.

dagar commented 7 years ago

It sounds great if we can make it work. My only concern is the number of cases where it could be misleading.

AndKe commented 7 years ago

I guess misleading is better than nothing, time seems to go extra slowly when awaiting telemetry packets :) during lost connection, most is just guesswork anyway , there can be strong crosswinds or headwind, maybe tailwind on the way back, it will not be perfect, but give a reasonable clue.

On 16 February 2017 at 19:30, Daniel Agar notifications@github.com wrote:

It sounds great if we can make it work. My only concern is the number of cases where it could be misleading.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mavlink/qgroundcontrol/issues/4555#issuecomment-280416694, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZpqjH1hgJl-AsfrjlgHI2JRrv6ndo6ks5rdJXHgaJpZM4MCUoh .