ADSB Based GA Aircraft avoidance

[b14ckyy]

Current Behavior

Since we are now (soon™) getting affordable ADSB Receivers that can be installed in our Aircraft (ADSBee working on a tiny open source receiver and PicoADSB is in Pre-Release state) for around/less than 100$ it would be a shame to just use them for OSD info alone. With the Geozone Functionality implemented in INAV 8.0, we could combine these features into an automated aircraft avoidance system.

Desired Behavior

INAV can track the 4 closest Aircraft, that it sees on the ADSB datastream. We could automatically generate a No Fly Zone in a triangle shape with upper and higher limits based on these aircraft, so INAV can either show the pilot what way to fly to avoid or even take control and execute an automated avoidance maneuver.

Suggested Solution

The closest ADSB contact will generate a NFZ around itself. This could be a isosceles triangle with the ADSB contact sitting at the base. The triangle would point into the flight direction of that ADSB contact and its size would be determined by the speed of the contact.

The length should be determined by the covered distance in a given time, to prevent unnecessary early avoidance of far away planes and avoid too late intervention. 30s could be a reasonable time frame. That means, a plane that flies at 300kph, the triangle NFZ would be 2.5km in front of that plane. This would even give a slow fixed wing UAV at 50kph enough time to reach more than 500m separation to either side.
The baseline of the NFZ triangle should be 1km long at least but could be bigger, based on a certain percentage of the length. Maybe 1/5th of the length could then be the baseline length. The Zone is Updated every 5 or 10 seconds to avoid quick and erratic changes on somewhat unprecise data.

Altitude should also be taken into account to prevent unnecessary avoidance maneuvers caused by ADSB contacts high above the UAV. The upper and lower limit should be at least 300m of vertical separation relative to the UAV altitude. This could be extended the same way as the speed variation based on climb rates. Here the climb rate would be simply added to the 300m separation.
If the ADSB Contact flies at constant altitude, the FZ will have a lower ceiling of ADSB Altitude -300m and a upper ceiling of ADSB Alt +300m. If the ADSB Contact is Descending at 1000ft/min or ~300m/min then the lower ceiling gets extended to -600m below ADSB Altitude. Same for upper ceiling.

If ADSB avoidance kicks in while pilot has control (Angle, Horizon, Cruise, Course hold modes), the pilot can gain back control like in Geozones, after 5s, by moving the control sticks.

Differences to fixed Geozones:

• Vehicle avoidance must also take control of the Aircraft when in Waypoint mode. Waypoint mode gets paused until the airspace is clear again and then the mission can continue.
• Vehicle avoidance will never try to overfly a ADSB based NFZ. Only horizontal avoidance
• If the pilot pushes towards a ADSB NFZ from top or below, it will bounce of as it does for Geozones but if the NFZ space is breached, INAV will go into horizontal avoidance only.
• Vehicle avoidance will not take over control when below a certain configurable relative altitude (for example when below legal limits of 120m from launch) to avoid the system to crash into a hill or trees on autonomous low altitude missions or low flying cruise/angle modes.

Who does this impact? Who is this for?

Every long range pilot flying in somewhat busy or unpredictable airspace. Also great for commercial use with long missions like mapping, search and rescue or other BVLOS operations.

Additional context

[sensei-hacker]

That's a good idea. It sounds like you have thought it through pretty thoroughly and provided a good amount of detail in your post.

It may also be of interest to look at the professional version of approximately the same thing, designed by aviation experts. The TCAS system is used by manned aircraft and operates quite similar to what B14ckyy described. TCAS produces a similar triangle shape, though with a rounded "front" based on distance to the aircraft:

It has been found that ADS-B altitude information is more reliable than bearing/location, so TCAS resolution advisories always instruct the pilot to either climb or descend; never to turn. The aircraft that is currently lower is told to descend, the one that is higher is told to climb.

Of course, model aircraft operated by INAV are always operated below the altitudes where ADS-B aircraft operate, so as B14ckyy said an INAV model should never try to climb above a manned aircraft. It should only descend to to altitude appropriate for a model, and perhaps change course laterally.

[b14ckyy]

Thanks for the affirmation :)
Yes I thought about something like this as well, with a bigger bubble further away. But that would only make sense for a warning to the pilot, not for the Autopilot that avoids by itself. The Geozone code will bounce off a NFZ border like a reflection (on a circular one like a reflection from a tangent). That would mean if the ADSB contact comes head on, and we would have a circle or a border perpendicular to the ADSB flight path, INAV would turn around and fly on the same course as the approaching airplane. It will obviously be way too slow to "escape".

If the NFZ is breached and the UAV is inside the danger zone, it will fly out of that zone towards the closest border line, perpendicular to that border. So a triangle like shown will guarantee an evasive path away from the flight path, no matter from what side the UAV enters. The UAV could still crash into a mountain or hill but thats less likely than a crash into the ground, thats always there.

But overall we should all agree, that a controlled crash into a mountain is better than a crash into an airplane.

for normal Geozone operation we never dive below a zone either as we can't know if there is ground close to the lower ceiling. Also the usual descent rate of a UAV is somewhere between 5-10m/s, what means we would create much less separation than a horizontal course at 15-20m/s cruise speeds. Additionally a descent is always done by maintaining the current course. If the UAV flies towards the ADSB contact, it would significantly reduce the time before minimum separation, causing even closer passes.

With the triangle we would always have a sideways evade with some forward component to maximize the time to minimum distance.
For possible errors in the heading though, IF there is a possibility that its totally off, we could also add a circle around the ADSB contact to have some safety zone there as well.

[sensei-hacker]

But overall we should all agree, that a controlled crash into a mountain is better than a crash into an airplane.

Absolutely.

Also the usual descent rate of a UAV is somewhere between 5-10m/s, what means we would create much less separation than a horizontal course at 15-20m/s cruise speeds.

An RA descent is normally performed at a much faster descent rate than a cruise descent, so that's a possibility for future development. All planes can descend faster than they can fly level. Simply because (thrust + gravity) > thrust. Meaning you can always dive faster than you fly laterally.

Descending at around 10 degrees pitch down ALSO increases your lateral speed.

[b14ckyy]

The debate about Descent option or lateral only, is definitely worth some brainstorming and HITL testing.

One thing to consider is, that it would also complicate things when the UAV flies into a path of a descending GA Aircraft. In this case a Descent to avoid would be a very bad decision.

maybe an emergency descent could be considered above a certain relative altitude (but here we talk about realistic values of 500-1000m UAV fligth altitude). I just wonder what situation could happen to actually justify a rapid dive with a high risk of ground impact.

[error414]

I use ADSB on my planes for sometime, T1 ranger and T2 cruza, I'm not long range flyer, I fly just for fun, I don't have experinece with "long missions like mapping, search and rescue or other BVLOS operations". Durring flying I found out few points.

1. big planes are not ussually problem because they are high (if not fly near airport what is not good idea at all)
2. aicrafts which are problem are ballons, gliders, agriculture planes (have no idea how they are called), helicopters (mainly medic, police, army), ultralights, I got warnings from all of them and they are too fast compared to AUV, always was good idea to rapidly descend to under 40-50m.
3. managed aircraft closer than 8 km is a problem
4. managed aircraft never ever be under UAV

I see only one solution how to avoid collision is rapid descending. I would preffer to provide more information about aicraft to OSD, so far in OSD is only alt diff, distance and direction to aicraft, I would appriciate info about type of aicraft, direction of aicraft, and speed of aicraft. I'm not a big fan of automatic collision avoidance for hobby flying.

[b14ckyy]

@error414 This feature would be 100% optional and not forced. So for just hobby bashing around and if the OSD info is all you need, thats fair enough.
For more info options on the OSD, I guess a feature request would make sense.
We cannot just descent under a certain altitude automatically since we only know the relative altitude above launch and the MSL Altitude. We have no idea where the ground is. If a ADSB avoidance happens over a hill, it will be a guaranteed crash that is unnecessary.

[sensei-hacker]

If a ADSB avoidance happens over a hill, it will be a guaranteed crash that is unnecessary.

Avoiding crashing into a manned aircraft and killing people is not "unnecessary". It's extremely critical.
Protecting human life is THE most important thing. People's lives are more important than 10,000 model planes.

Keep in mind that manned aircraft carrying ADS-B transponders don't fly 100 feet over the top of a hill. They are going to be a minimum of 500 feet above the terrain, other than a small set of rare exceptions. So pretty much, if you have an altitude conflict with an aircraft that's transmitting ADS-B, there's not a hill 80 feet below you. It's theoretically possible sure, but a pretty remote possibility.

In such a situation, you have two choices:

Choice A: It's theoretically POSSIBLE (but rather unlikely) the toy could crash into a hill
Choice B: It's headed to crash into a plane full of people

I know which possible crash I would choose. For me, it's not difficult to choose between A and B.
When there is a manned aircraft, frankly I'm not worried about "theoretically that airliner could be skimming the hill tops".

[sensei-hacker]

when the UAV flies into a path of a descending GA Aircraft.

The standard approach is a 3° descent.
Some air fields double that to 6°.

Thus 10° for an RA - you are guaranteed to remain lower than a conflicting aircraft that is descending to land, guaranteed to increase separation from such aircraft.

[b14ckyy]

Keep in mind that manned aircraft carrying ADS-B transponders don't fly 100 feet over the top of a hill.
When the GA aircraft is already on top of the same hill, its too late :D

I see your point but we have to consider false alerts as well. I would be really pissed if a false alert made my plane crash into the ground. As an example: I often fly at a spot on a hill thats above a big valley. The hill peaks at around 200m above that massive 20km long flat valley. If a plane is 300m off the ground down there approaching my direction, and I fly a mission over head at 150m, that plane will NEVER get close to me but it will trigger that emergency descent, straight into the ground. Or the opposite, I am down at the lake and fly up that hill.

Thus 10° for an RA - you are guaranteed to remain lower than a conflicting aircraft that is descending to land, guaranteed to increase separation from such aircraft.
You have a thought mistake there.
If a GA plane descents at 100m/s flight speed (360km/h) at 3° it has ~5m/s descent rate
if a UAV at 16m/s cruise (~60km/h) descents at 10°, it has a ~3m/s descent rate.

the UAV would need to fly 110km/h at a 10° descent angle to descent faster than the GA plane on approach.

[error414]

the solution could be use NRA15/24 or implement to inav terrain data as ardupilot uses. https://terrain.ardupilot.org/

[b14ckyy]

Well, yeah maybe at some point in the future with a radar that probably costs more than most of the entire builds.
Ideas about terrain data are around but that needs A LOT of work. Especially the SD Driver is still an issue for that as its too slow or incapable of reading and writing mid flight while the PID loop is running.
But both are definitely things to consider in the future.

For now we have to make the best of what he have available. I have a 40m Lidar here that would already do the job well but 40m is still not enough to avoid Wind Turbines or powerlines either. So not perfect.

[error414]

NAR15 (120m) cost 178$ year ago. NRA24 (220m) = 250$. I use NRA15, it works like a charm, optical range finders are not good, they have problem with water, snow, grass.

For inspiration, https://ardupilot.org/plane/docs/common-ads-b-receiver.html#common-ads-b-receiver there is video how avoidance works in ardupilot.

So far I have no idea how avoidance should works in INAV :).