Today’s field test focuses on two features of our UASSP system: path planning and automatic task allocation. To support these features, our drone control code was also updated to follow waypoints with different altitudes in a robust way.

It’s quite easy to justify why we need path planning, especially in Okutama. Okutama is a very hilly place, so to safely fly a drone, the trajectory and flight plan must consider the local terrain elevation. Preparing the flight plan manually is tedious and error-prone, so the system does that for us. Given two waypoints, the system will consider the local elevation, the minimum legal altitude of 30 meters above ground, and compute a flyable path using the Theta* algorithm. As a research platform, our UASSP can also be extended to use different path planning algorithms. For example, we also implemented A*. We obtain the elevation data from Mapzen.

Aside from a minor bug, we validated that path planning was working as expected. However, we realized that, in the real world, we cannot depend on the “30 meters above ground” rule to guarantee flyable paths, as in Okutama there are many obstacles higher than 30 meters, for example, trees and poles around the baseball field.

Elevation model of Okutama
Elevation model of Okutama
Visualization of path planning
Visualization of path planning between Okutama baseball field and Okutama Junior High School

The second feature, automatic task allocation (ATA), aims to efficiently assign UAVs to tasks, considering the UAV capabilities, battery, payload and distance from tasks. To accurately compute the cost (distance) from the tasks, ATA uses our path planning algorithms. Since we only had one drone on the field today, the ATA tests we performed were quite simple. Heavier tests are being performed in-lab.

For both of these features, it is necessary that our UAV client can handle flight plans with many waypoints with different altitudes. This proved to be more complex than one would think. DJI drones have GPS and can obtain an altitude reading, but this reading is very inaccurate; we have measured errors of 30+ meters in the past. This is not something specific of DJI drones, it’s just how consumer GPS receivers work at low altitudes from the ground. There’s also the issue that GPS reports altitude relative to the WGS84 ellipsoid, and our elevation data is relative to the WGS84 geoid (mean sea level).

For more reliable height reading, we must depend on DJI’s “height above takeoff elevation”, which uses a barometer. Since our UASSP server sends waypoint data with absolute altitudes above the WGS84 geoid, the drone must also obtain its elevation from the server just before takeoff, and compute the differences so it can build its flight plan with heights above takeoff elevation. This feature was also tested today, is working reliably.