Do not allow vehicle to fly near airports

[rmackay9]

To keep copter and planes from accidentally interfering with manned aircraft we should add features that keep the vehicles away from airports.

Some ideas include downloading a list of airports from http://openflights.org/data.html and landing the vehicle if it gets within a certain distance (10km? 1km?) of an airport.

Another idea is to automatically configure the fence (aka geofence) to keep vehicles out of the way of the airports.

As with nearly all features, we would allow the user to disable the safety check. This is necessary because all safety checks have occasional false positives or there may be a very good reason why the vehicle should be flying near the airport.

There is a related issue here for the mission planner to display nearby airport information to the user: https://github.com/diydrones/MissionPlanner/issues/455

[Felixrising]

It's an excellent idea, to limit accidental incursion into restricted airspace. There are of course also airports where flying model aircraft is specifically permitted, usually small regional infrequently used ones, so simply disabling flight in those areas would be improper... as you suggested, a warning and safety check and ability to disable these would be required.

[jaydrones]

I like the idea of configuring the fence (geofence).

[JonoParrott]

We could then extend this to a ceiling as well for appropriate countries. Eg, Australia is maximum 400ft AGL unless approved. However the problem with having a ceiling is that it will be calculated where you take off, and not necessarily what is directly under the aircraft unless ground proximity detection is enabled. Just a thought.

[proficnc]

Actually in Australia, it is 400ft in controlled airspace, which covers most major cities, however, it does not limit to 400ft outside controlled airspace. It does however limit to line of sight, which wouldn't be much higher for your average copter. This is listed under the CASA website, and I confirmed this directly with CASA this week. This makes it much harder to set blanket rules, however, 400ft would be a great hard limit to set

[jpkh]

1km from airport should be ok. 10km is too long distance. For example me. We are living 4.7kms away from Suvarnabhumi airport. Around our area there are several small clubs flying RC planes. But then question arises, how to determine what airport is in active use and which is not.

[proficnc]

In Australia, we would need to differentiate between an ALA and an airport.... An airport is a no negotiation 5.5km unless you are certified. An ALA, is between you and the operator of the field..... As an ALA can be a farm etc.

[shaggee]

1km arming limit 5km auto mode limit That settings will be OK.

[sgofferj]

As long as there is an off switch... Because it's close to impossible for an open source project to maintain an uptodate list of active airports worldwide and it's even more impossible to include opening hours or specific regulations for all airports worldwide into that. See my article about the DJI system which includes very small airports with less than 10 movements per week and even airfields which are closed for decades...

[rmackay9]

@ADrone @sgofferj , As mentioned in the description of the issue, "As with nearly all features, we would allow the user to disable the safety check."

[steveomg]

This should not be a feature that is implemented (even as a safety check) unless it is in agreement with the law - otherwise it is just an annoyance to operators who are responsible. You can not fix lack of knowledge or bad processes with software .

In US you can fly all day in class G airspace and other space as well though there are some standards that should be followed. With proper permission you can even fly ON an airport (think airshows, exhibits, film work, etc). This is covered in FAA Advisory Circular 91-57 which lays out some decent guidelines (IE not rules) for operation of model aircraft.

Until there is a ruling on what is a drone, what is unmanned, and laws drawn up about it; this should be reference marks only - as currently implemented as a 3nm ring.

[haygood]

If the option is as simple as applying the GeoFence settings to airports listed in MP, that would be helpful. If find the new 3nm rings around airports in MP very useful, and would be fine having these generally set as additional fence boundaries. "Land" is not likely the appropriate behavior, but RTL very likely is. Since you can pick from either as an option when hitting the GeoFence, applying the same choice to fences around airports makes sense.

I fully intend to fly within 3nm of airports; with their permission. We have traditionally done testing at airports with full cooperation and permission of the airports, whlie monitoring air traffic communications, etc. So, as long as I can figure out how to turn it off, I think this is a great idea I would use on most flights.

[haygood]

Dare I raise the issue of other "no fly" zones? These are hard enough for real full scale pilots to keep track of. "Don't fly over the White House" is easy to remember, but "Hey, the President decided to fly into New Orleans today, so your flight is grounded" comes as more of a surprise. Like we do in full-scale, this probably has to be left for the individual to take responsibility for on their own, despite the inherent difficulties in doing so. There may be a few isolated "Prohibited areas" to watch for. If in doubt, you can check places like Skyvector.com and see what is around you.

Sorry if this thread is a little more discussion than usual for Git, but the official request is to consider adding charted FAA prohibited areas (not restricted or military operations areas - we fly through those all the time) to MP. No, it is not clear to me whether we are actually prohibited from flying in prohibited areas, but I think it would be a very good idea not to. I'm sure the Secret Service would enjoy the target practice.

[squilter]

DroidPlanner reads warnings when your altitude exceeds 400ft. There are also plans to throw warnings when it gets close to airports (hopefully droneshare will tell DroidPlanner to throw those warnings). Is that good enough?

[rmackay9]

No, I don't think that's sufficient. At least the original intention of this issue was to force the vehicle to land if it flies too close to an airport. Of course, as mentioned above, the user should be able to disable the feature.

[haygood]

Force it to land, or just treat it like a fence? If it responded with the fence settings, that would make sense to me. I'd much rather have it RTL than just plop itself on the ground, water, freeway, or whatever we happen to be above.

[rmackay9]

@haygood, Yes, that's a good point. No reason why it would necessarily need to LAND and people generally don't like failsafes to cause LAND because it can come down on someone's head, or into a tree, etc. thanks for the suggestion.

[haygood]

No problem. Thanks for doing the hard part!

[rmackay9]

This is related to this other issue: https://github.com/diydrones/ardupilot/issues/391

[dscassid]

Does anyone know if airport warning messages or exclusion zones were implimented??

[k5njm]

How about also allowing user-defined "keep out zones". This may fall under an additional issue. I have an application where I would like autonomous flight over an area but would like to avoid pre-defined tall objects such as towers or particular trees. A "keep out" or exclusion zone would be sort of an inverse geofence, so if the Path between waypoint 1 and 2 were to intersect this zone, the autopilot would maintain distance and follow the perimeter of the zone, or compute a more efficient route that avoids it.

[rmackay9]

@kd5ftn, the "keep out" zone is captured in issue #391. There's some on and off progress on object avoidance going on (which could be used as the basis for tihs) but it's not there yet.

[k5njm]

Thanks for identifying that for me Randy. I'll bring my communication over there!

[squilter]

Has anybody put any more thought into this? I might try taking this on.

[magicrub]

The implementation is not hard, the real issue is having an up-to-date list that makes everyone happy and where to store it.

On Tue, Jul 21, 2015 at 12:32 PM, squilter notifications@github.com wrote:

Has anybody put any more thought into this? I might try taking this on.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1056#issuecomment-123455292 .

[WickedShell]

The implementation that satisfies the most people is probably the most difficult part. Within the US I'd almost argue that you would want to know the class of the airport and the controlled space associated with it. Unfortunately this locks out cities and takes up a large amount of space. And as was pointed out you would ideally want to know the local NOTAMs (the president is here, this airspace is closed etc).

I don't know, I haven't given to much thought to it, it's a feature I can't see ever enabling and using in my use of the system. (And if it's simply a parameter that people can disable I'd guess a lot of people will just turn it off the first time it bothers them).

[squilter]

A csv file with all airports in the world is less than 10mb. The questions are now:

• How to upload initially
• How to update

Or maybe require the gcs to poll nearby airports from a website like this. It should solve the up-to-date problem. But that would require that the gcs has an active internet connection. Unlikely.

Then there's the FAA app. It's not released yet, but maybe I could email them and ask if there's a database that we could use.

[WickedShell]

My point with the airports is that in the US I'd like to actually load the correct radius's of controlled airspace (IE the class delta airport foo has a radius of X centered on this point). It gets worse if you look at the inverted cake shape on class C and B airports. And it gets worse still when coupled with the fact that every airport can be unique (not all class D's have the same radius). Anyways I suspect this makes it to difficult to look at this information easily/compile it, but it really limits the usefulness in my opinion and is a reason you would want to only look at a constant radius from the airport.

[rmackay9]

@squilter, yes, I think making the GCS responsible for providing the data to the vehicle similar similar to how we transfer the terrain data might be good. http://mavlink.org/messages/common#TERRAIN_REQUEST http://mavlink.org/messages/common#TERRAIN_DATA http://mavlink.org/messages/common#TERRAIN_REPORT

I think the storage of the data could be similar to terrain data with the airport's lat,lon location and stay-out radius stored instead of the terrain altitude. A bit unlike terrain data there could be multiple airports within a grid if the grid is very large.

Probably best to ping ideas around with Tridge a bit who wrote the terrain handling.

[abvgdeyoj]

Emergency landings should be the last resort, not the first. I vote against this feature, as I believe that the current functionality in the MP is more than what is needed, and the feature is too specific.

[squilter]

@abvgeej I don't use mission planner, and I know plenty of other people that don't either. Sometimes people use mobile apps (Tower or Solo app). Some people fly with only an rc.

[earsneyes]

The airport restrictions DJI Innovation built into their systems are wrong for my country and it forces me to drive far away to test things that are actually permitted where i like to fly ("near" airport).

Very annoying thing. At least we would need an option too disable it. On the other side.. The average DJI user might need that feature for our all safety. Not so sure if that is valid for average ardupilot user.

[rmackay9]

I'm tentatively targeting Copter-3.4 for this feature but no promises

[govsux]

re-"As with nearly all features, we would allow the user to disable the safety check" My brother has a Dji and after an update his phantom is useless to him in the area he flew %90 of the time and it's completely silly because the airport is rarely used and he is far enough away even at a 1/2 mile away that the planes are FAR higher than 400. PLEASE keep this as a user defined warning or action.

[R-Lefebvre]

I thought the DJI NFZ's were easy to defeat in the app?

[govsux]

It used to be user selectable but not anymore. It made a lot of people angry as they did not mention this was part of a FW update.

[R-Lefebvre]

Right, but my understanding is that you can simply disable the restriction, by registering an account with DJI, and then a couple easy taps on the app will allow flight in restricted areas. Is that not the case?

[govsux]

Hmmmm I don't think he is aware of that I'll let him know and confirm thx

[OXINARF]

Rob that's in the new Geo system that, as far as I know, is still in beta - but even in this one there are areas that you can't fly no matter what. The current system is the No Fly Zones where you can't fly near airports.

[IX-Erich]

I am just beginning to work on my private pilots license, so am obviously not an expert , but planning ahead to take advantage of the 2020 ADS-B deadline for all aircraft in US airspace, it might be interesting to add some ADS-B receiver integration. I gather there are some fairly inexpensive and small receivers that, while not transponders, could pick up traffic info along with weather and NOTAMs.

For LOS operations, the receiver could be pretty useful even just as part of ground station. I just ordered a Stratus 2S, which might be prohibitively expensive overkill for hobbyists, but drives the ForeFlight Apps that offer some pretty nifty features, including hazard avoidance for well marked items on Sectional Charts (someone mentioned towers, etc). One imagines these features could be implemented as part of this project with a generic receiver. Scratch that - need to be aloft to pick up transmitters...

This integration would give the platform a leg up in adapting to future regulatory regimes. NOTAMs could dynamically contribute to geofencing, etc.

[magicrub]

Erich,

Please visit http://plane.ardupilot.com/wiki/common-ads-b-reciever/ On Jan 18, 2016 11:03 AM, "erich-comsIO" notifications@github.com wrote:

I am just beginning to work on my private pilots license, so am obviously not an expert , but planning ahead to take advantage of the 2020 ADS-B deadline for all aircraft in US airspace, it might be interesting to add some ADS-B receiver integration. I gather there are some fairly inexpensive and small receivers that, while not transponders, could pick up traffic info along with weather and NOTAMs.

For LOS operations, the receiver could be pretty useful even just as part of ground station. I just ordered a Stratus 2S, which might be prohibitively expensive overkill for hobbyists, but drives the ForeFlight Apps that offer some pretty nifty features, including hazard avoidance for well marked items on Sectional Charts (someone mentioned towers, etc). One imagines these features could be implemented as part of this project with a generic receiver.

This integration would give the platform a leg up in adapting to future regulatory regimes. NOTAMs could dynamically contribute to geofencing, etc.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1056#issuecomment-172553551 .

[IX-Erich]

You mean someone already thought of this, lol… Sorry to waste space and thanks for the link - super cool!

On Jan 18, 2016, at 6:07 PM, Tom Pittenger notifications@github.com wrote:

Erich,

Please visit http://plane.ardupilot.com/wiki/common-ads-b-reciever/ On Jan 18, 2016 11:03 AM, "erich-comsIO" notifications@github.com wrote:

I am just beginning to work on my private pilots license, so am obviously not an expert , but planning ahead to take advantage of the 2020 ADS-B deadline for all aircraft in US airspace, it might be interesting to add some ADS-B receiver integration. I gather there are some fairly inexpensive and small receivers that, while not transponders, could pick up traffic info along with weather and NOTAMs.

For LOS operations, the receiver could be pretty useful even just as part of ground station. I just ordered a Stratus 2S, which might be prohibitively expensive overkill for hobbyists, but drives the ForeFlight Apps that offer some pretty nifty features, including hazard avoidance for well marked items on Sectional Charts (someone mentioned towers, etc). One imagines these features could be implemented as part of this project with a generic receiver.

This integration would give the platform a leg up in adapting to future regulatory regimes. NOTAMs could dynamically contribute to geofencing, etc.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1056#issuecomment-172553551 .

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1056#issuecomment-172677380.

[magicrub]

Which reminds me... That wiki needs to be updated On Jan 18, 2016 9:50 PM, "erich-comsIO" notifications@github.com wrote:

You mean someone already thought of this, lol… Sorry to waste space and thanks for the link - super cool!

On Jan 18, 2016, at 6:07 PM, Tom Pittenger notifications@github.com wrote:

Erich,

Please visit http://plane.ardupilot.com/wiki/common-ads-b-reciever/ On Jan 18, 2016 11:03 AM, "erich-comsIO" notifications@github.com wrote:

I am just beginning to work on my private pilots license, so am obviously not an expert , but planning ahead to take advantage of the 2020 ADS-B deadline for all aircraft in US airspace, it might be interesting to add some ADS-B receiver integration. I gather there are some fairly inexpensive and small receivers that, while not transponders, could pick up traffic info along with weather and NOTAMs.

For LOS operations, the receiver could be pretty useful even just as part of ground station. I just ordered a Stratus 2S, which might be prohibitively expensive overkill for hobbyists, but drives the ForeFlight Apps that offer some pretty nifty features, including hazard avoidance for well marked items on Sectional Charts (someone mentioned towers, etc). One imagines these features could be implemented as part of this project with a generic receiver.

This integration would give the platform a leg up in adapting to future regulatory regimes. NOTAMs could dynamically contribute to geofencing, etc.

— Reply to this email directly or view it on GitHub < https://github.com/diydrones/ardupilot/issues/1056#issuecomment-172553551> .

— Reply to this email directly or view it on GitHub < https://github.com/diydrones/ardupilot/issues/1056#issuecomment-172677380 .

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1056#issuecomment-172704459 .

[hsteinhaus]

Alternative idea to on-board no-fly zones: overlay correct and up-to-date schematics of air spaces in the GCS map display, plus some help button showing a vertical cross-section and explaining the implication of the different airspace classes. While getting up-to-date and correct data is the hard part, the help display should be very simple to implement, as there is only a very limited number of airspace categories.

Idea behind: I guess 99% of the violations happen by lack of knowledge, not by intention. However, an evil pirate that plans to violate an airspace intentionally, can remove the no-fly-zone feature from source.

Advantage of this approach: better user acceptance, better usability, e.g. for people doing their (legitimate) flying on airfields

TLDR: make a software idiot-proof and somebody will build a better idiot.

[rmackay9]

There is a partial fix to this included in Copter-3.4-rc2 if the user has an ADSB sensor (like the Ping from uAvionix). The vehicle will not arm if the sensor reports it is within range of another vehicle. It can also avoid vehicles.

[squilter]

I am still interested in developing this feature with airspace 'tiles'. Maybe we can restart this conversation. Here are some notes:

• The code should be shared between PX4Firmware and ardupilot. The library can be a dronecode project that is submoduled by both.
• 3dr added airpace info to the Solo app. Getting the info into a gcs is definitely easier than this whole tile thing.
• If we wait until the standard board is a linux board, then we could use something nice like JSON within the tiles. Otherwise we will likely need to develop some proprietary format in order to save memory and cpu cycles.
• There were a couple startups interested in supplying the airspace data to us. Any updates from them?

[magicrub]

There were a couple startups interested in supplying the airspace data to us. Any updates from them?

The startups are AirMap https://www.airmap.com/ and Altitude Angel https://www.altitudeangel.com/, both are DroneCode members. There was a DroneCode working group to integrate them but it didn't go anywhere. Altitude Angel did most of the talking, mostly about what they have to offer and their interface. They were busy building out their own platform and could not allocate resources to add it to any DroneCode autopilot. So, someone just needs to do it.

On Tue, Aug 9, 2016 at 10:21 AM, Sebastian Quilter <notifications@github.com

wrote:

I am still interested in developing this feature with airspace 'tiles'. Maybe we can restart this conversation. Here are some notes:

• The code should be shared between PX4Firmware and ardupilot. The library can be a dronecode project that is submoduled by both.
• 3dr added airpace info to the Solo app. Getting the info into a gcs is definitely easier than this whole tile thing.
• If we wait until the standard board is a linux board, then we could use something nice like JSON within the tiles. Otherwise we will likely need to develop some proprietary format in order to save emory and cpu cycles.
• There were a couple startups interested in supplying the airspace data to us. Any updates from them?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/1056#issuecomment-238625023, or mute the thread https://github.com/notifications/unsubscribe-auth/AEj7G6iZkCaIgIdhYcQMmlUTix5YuUWnks5qeLb9gaJpZM4B5s5F .

[rmackay9]

One thing that will make implementing this easier is that Copter-3.4 now supports polygon fences and stopping at the fence (see AC_Avoidance). So once the no-fly-zone data is in the flight controller (still a big problem to solve), the next step is just to add a new function below "adjust_velocity_circle" and "adjust_velocity_poly" which consumes the new data and shortens the desired velocity if necessary.

[squilter]

@rmackay9 @magicrub I put some thought into this today. See here: http://discuss.dronecode.org/t/no-fly-zones/243

[rmackay9]

Out of time for Copter-3.4 so bumping to Copter-3.5.

[Naterater]

Does this belong here: https://github.com/ArduPilot/ardupilot/issues/391?

If not, then this discussion should probably be more about airports and mandatory/default exclusion zones. The DJI Geo system has recently faced a lot of consumer criticism (but probably government praise). Their new 2.0 system paired with AirMap is quite restrictive, even beyond the regulations here in the US. I'm not in favor of including this at all, but it may be required in certain circumstances.