Now that the EA-DDDAS framework has been put through the paces, we're planning two days of flight testing that allow the system operate fully autonomously. This means that the high-level planner and trajectory optimization layer will be left to their own devices to communicate, generate聽energy-aware trajectories, and send seamlessly stitched trajectories to the aircraft in real-time. The goal is to have no user intervention once the system has been launched and a goal has been set. We're planning to use the decommissioned聽Reese airfield to conduct flights upwards to 1.75 km away from the ground station using stationed observers who are always in communication with the pilot in command.
One of the recent challenges faced in the field was the ability (or lack thereof) to continuously send new trajectories to the PixHawk autopilot without causing the aircraft to RTL (return to loiter). Since the planners are generating paths ahead of the aircraft position, a method was needed to feed the trajectories to the aircraft with the correct timing. An additional constraint was the number of waypoints that are manageable on-board the aircraft. Since we use a 900 MHz radio link for long distance聽command and control, data rates are slow and packets are often lost during transfer. We found that a 100 waypoint plan is workable with the given data rates we see over the 900 link. With this in mind, we designed a circular buffer mission plan algorithm that allows trajectories to be continuously updated to the aircraft. Using a partial write command, we update certain ranges in the 100 waypoint plan. If a plan goes beyond聽the 100 waypoint limit, the plan is broken into two plans that wrap around back to the 1st waypoint using a DO_JUMP command. While this works well, it introduces another issue. If plans are being generated too quickly for the aircraft to follow, a queue will develop. To prevent this queue from over-writing points that the aircraft still needs to fly, the MISSION_CURRENT MavLink message is checked to see where the aircraft is in the circular buffer. This provides the necessary logic to delay the next waypoint write so only old waypoints are overwritten!
Sorry for the lack of generated optimal trajectory pictures聽so far, we haven't had a chance to dig through all of the logged data. Once we're back in CO, we'll be sure to have some results up ASAP.