ADSB indicator on top toolbar

[dakejahl]

I am going to add an ADSB icon on the top toolbar. I am thinking the indicator will be green if no aircraft are detected, yellow if there are detections, and red if there are detections within X distance of the vehicle. When clicked, a popup menu will appear and show some information about the aircraft (similar to the other toolbar icons).

Is this something that would be an enhancement for QGC? If so, I'll do the work with the intent to submit a PR upstream. Otherwise I will find a way to isolate this to our custom plugin.

[Antiheavy]

green if no aircraft are detected

It could also just be a neutral color if nothing is detected (e.g. like the white or black default toolbar icon colors). There really isn't a lot of "green is good" status indicators in QGC, which is fine. There really should be more "red is bad" color indication though IMHO.

[DonLakeFlyer]

Sounds like a good feature. I would take it in steps. The first is to plumb through ADSB warning information as a FactGroup. And then ADSB settings values for warning distance.

For the ADSB FactGroup I would include this information:

• bool which indicates whether ADSB information is available at all or not
• count of total adsb vehicles
• count of adsb vehicles within warning range
• bool which is true if any vehicles within warning range

For the ADSB warning settings I could propose:

• min horizontal separation distance
• min vertical separation distance

If ADSB vehicle goes within the min bounds it is in warning state.

For ADSB settings I'd rework this:

To turn into a generic ADSB section, with both the server settings and warning distance inside it.

Id' take that as the first step and then we can talk toolbar. Also can you look at ArduPilot? I believe they have support for making the vehicle do something with respect to an ADSB vehicle coming close. Would be good to use that as information as to how they set warning intervals.

[DonLakeFlyer]

The other though would be whether there should be two levels of warning. A be on the lookout level and an oh shit level.

[dakejahl]

@DonLakeFlyer so I only see two examples of classes that inherit from FactGroup ... Vehicle and QGCCameraControl.

In both instances, these classes are instantiated and managed by a "manager" class. In the ADSB case the are two classes: ADSBVehicleManager and ADSBVehicle. If I were to follow the same pattern as the two other implementations, I would need ADSBVehicle to inherit FactGroup. The issue here is a new ADSBVehicle object is created for every ADSB identified aircraft, which then means a new FactGroup is also created. This is undesirable, as we want our "facts" to be related to the ADSB manager itself, not the vehicle tracks. So clearly the pattern won't work in this case. What I would need is for the ADSBVehicleManager to be a FactGroup, but this also doesn't work because "manager" classes are of type QGCTool.

I'm not entirely sure how to do this in a way that is congruent with the intended usage of "facts" and "fact groups". Do you have any suggetions?

Thanks

[DonLakeFlyer]

ADSB factgroup is in Vehicle. And the Vehicle object contains the plumbing needed to route the values from wherever they come from into itself to populate the data. Same as these for example:

    _addFact(&_missionItemIndexFact,    _missionItemIndexFactName);
    _addFact(&_headingToNextWPFact,     _headingToNextWPFactName);

This data comes from MissionController. And is plumbed out through Vehicle as a Fact.

[dakejahl]

Ahhh! Okay this all makes sense now. Thanks for the quick response!

[Antiheavy]

ADSB factgroup is in Vehicle.

does this mean ADSB indicator on the top toolbar will only show up if a vehicle is connected? What if the source of ADSB information is a SBS server such as dump1090 or some other network based stream unrelated to the vehicle?

[DonLakeFlyer]

does this mean ADSB indicator on the top toolbar will only show up if a vehicle is connected?

That is correct. There is no current support in QGC for showing things in the toolbar (or anywhere really) when a vehicle is not connected. It would be a nice new feature though but non-trivial.

[dakejahl]

bool which indicates whether ADSB information is available at all or not

How should we determine if ADSB data is available? There are two cases:

1. An ADSB receiver is connected to the aircraft. Which if I understand correctly, QGC only knows about this via the mavlink_adsb_vehicle_t message, which is only transmitted when vehicles are detected... which isn't really helpful, because the user will only know ADSB is "active" after the first track has been received, and will never know if the ADSB receiver somehow stops working.

2. An ADSB receiver is connected to the groundstation. We could "detect" this by using the state of the socket connection. Or we could use the same method as above (flag as active once the first message comes through).

min horizontal separation distance min vertical separation distance

Does this really make sense? Do we care about an aircraft 1000 meters above us that happens to come within the horizontal distance (and vice versa)? Why not use a single radial distance?

[dakejahl]

Regarding Ardupilot: they use on-vehicle parameters AVD_W_DIST_XY and AVD_W_DIST_Z and only one warning. They also have a flight mode you can enable that causes the vehicle to attempt evasive action based on those warning distance parameters as well as some other information like vehicle speed and heading. https://ardupilot.org/copter/docs/common-ads-b-receiver.html

[DonLakeFlyer]

How should we determine if ADSB data is available?

Looks like that isn't really possible then in any sane way.

Why not use a single radial distance?

Sounds fine

[Antiheavy]

Why not use a single radial distance?

I think this is an okay starting point and probably would work for the majority of small unmanned aircraft users. I suspect more advanced users will want separate vertical and horizontal separation distances eventually.

[DonLakeFlyer]

I suspect more advanced users will want separate vertical and horizontal separation distances eventually.

I woudl take that feedback and say do that now then.

[Antiheavy]

@dakejahl or @DonLakeFlyer what are the size requirements for a top-toolbar icon? I might be able to have our graphic designed whip up a few ideas for this.

[DonLakeFlyer]

I think they are mostly black and white SVGs where the size don't matter so much. That way you can color them as well. Jake should be able to pull some from the code.

[Antiheavy]

[DonLakeFlyer]

I think you guys are working on a new icon for the vehicles in the map as well. These two: map and toolbar should use the same based for the vehicle image.