Call opened at 16.07 by Richard Parker
Group introductions were completed by each call member. Unfortunately, Marcos Osorno was experiencing audio issues and thus was unable to contribute [added to apologies section].
It was agreed that the primary focus of the Airspace Management Group shall be the completion of Mandate Objective #1 until further notice.
Discussion progressed quickly into efforts to understand what each member of the management group could contribute, based on their experience within the UAS (“Drone”) industry today.
Airphrame have already been working with Dronecode on the introduction of ADS-B 'avoidance' capability. Tom Pittenger gave the group a good overview of how this works, pros/cons, and introduced the concept of a MavLink packet that already exists that may have potential for re-use elsewhere in terms of position reporting.
It was noted that there are many challenges associated with communicating with an external data provider from a drone, drone control station or controler app, most notably to do with 'what' is being communicated; regardless of whether this is to acquire airspace data, to share it, or for aerial separation.
Different on-board sensors provide different capabilities with respect to precision of measurement, or even the types of measurement that are possible. In the case of 'Altitude' position reporting, there are sometimes varying degrees of precision available based on whether or not the reporting device is present and how sensitive it is.
Altitude Angel noted that they have defined an
API entity that permits an end-user to specify the sensor type, it's reported precision and accuracy and it's presence, which they use within their
API. They agreed to share a definition of this entity to seed the group.
The group had various concerns around the use of/standardisation of units of measure (UoM). It was noted that Aerial Information Providers should have some way to deal with units in whatever the device is locally using/capable of handling, provided that such device is capable of reporting the unit.
The notion of a common protocol for aerial information exchange is required for the purposes of permitting the drone to receive information about the airspace and landscape around it as well as for the reporting of its position, and the sending/receiving of commands.
The group felt it was best to focus on first the standardisation of UoM for communicating with Airspace Management APIs.
Altitude Angel agreed to provide the group with access to its
API sandbox environment for Airspace data, ground hazards, compliance and environmental data. Interested parties should ask Altitude Angel for a developer key until self-registration is online.
Altitude Angel was asked about aerial separation and agreed to publish more information on this on the Wiki so that group members and contributors can access the technology and test separation in the sandbox environment.
It was agreed that the group should meet twice-monthly on a call to 'kickstart' the working group and ensure momentum.
It was agreed the next call would be in early January 2016 (after the Holiday period).
It was agreed that the Altitude Angel team would create and populate the wiki initially, with some of the actions assigned to them, but that other airspace management group members would contribute separately in late December and early January 2016.
There being no further business, the call was closed at 17.15 GMT.