Inner Loop / Navigation in Hardware-in-the-Loop
Posted by: Mariano I. Lizarraga
Waypoint tracking is one of the most sought-out features in an autopilot. Essentially it allows the end-user to program (generally via a map or an aerial picture) a path (composed of waypoints) that the UAV is commanded to track. When we started working on SLUGS it was clear that this would be the first high-level feature we would add. And today I am happy to report that it is fully working in software simulation and hardware-in-the-loop (HIL).
Waypoint tracking is one of the most sought-out features in an autopilot. Essentially it allows the end-user to program (generally via a map or an aerial picture) a path (composed of waypoints) that the UAV is commanded to track. When we started working on SLUGS it was clear that this would be the first high-level feature we would add. And today I am happy to report that it is fully working in software simulation and hardware-in-the-loop (HIL).
As any classical autopilot design it consists of an inner loop designed to track given set points, and an outer loop, that based on the path described by waypoints, it generates the required set points to track the desired path.
In our case the inner loop set points are altitude, airspeed and turn-rate commands. Implementation-wise, it is nothing earth-shattering, a set of PID loops with the correct protections (for saturation and anti-windup) divided in the traditional lateral and longitudinal channels.
The outer loop (navigation) is heavily based in Park, Deyst & How’s paper for tracking circular paths. If you are interested in navigation, make sure you read the paper. It presents a very elegant yet simple implementation for navigation that, at least in software simulation and HIL works really well.
Software Simulation
The following video presents an offline plotting of the data collected from a software simulation of the inner loop and navigation. The green dot represents the UAV position, the blue line represents the L1 vector as described in Park, Deyst and How’s paper and the cyan vectors show the Frenet frame attached to the aircraft. You can see in the video that currently the circles only define the turning point of the UAV and are not tracked during the turns. Thus tracking is only employed in linear segments of the path. We are currently working to add additional logic to include tracking of the circular segments during the turns.
Additional to the previous movie, we also have plots of the complete run, the Euler angles, the wind components and windspeed, and the high level commands (airspeed, turnrate and height) . Note also that since we decided to control airspeed with throttle, then when descending from a waypoint, the airspeed hold is not as effective as in level flight. Time permitting, we might change the way we control airspeed during climb or descend modes. But for now, we will keep the current architecture for the inner loop.
Hardware-in-the-Loop Simulation
After running the simulation with successful results we compiled the simulink model and downloaded the code to the SLUGS autopilot for HIL testing. The HIL architecture is the one described here. The following video shows a run of the simulator. The left part of the screen shows the ground station software and the right shows Google Earth display. This is exactly what the operator would see in a real flight. Those familiar with UCSC campus would recognize that this is by the East Remote parking lot.
Overall, we are satisfied with the results and are therefore ready for true flight tests. We expect that these will happen in late May at the latest and we will report this when that happens.
We are also on schedule to release the full project by the end of spring under the MIT Open Source license.
In our case the inner loop set points are altitude, airspeed and turn-rate commands. Implementation-wise, it is nothing earth-shattering, a set of PID loops with the correct protections (for saturation and anti-windup) divided in the traditional lateral and longitudinal channels.
The outer loop (navigation) is heavily based in Park, Deyst & How’s paper for tracking circular paths. If you are interested in navigation, make sure you read the paper. It presents a very elegant yet simple implementation for navigation that, at least in software simulation and HIL works really well.
Software Simulation
The following video presents an offline plotting of the data collected from a software simulation of the inner loop and navigation. The green dot represents the UAV position, the blue line represents the L1 vector as described in Park, Deyst and How’s paper and the cyan vectors show the Frenet frame attached to the aircraft. You can see in the video that currently the circles only define the turning point of the UAV and are not tracked during the turns. Thus tracking is only employed in linear segments of the path. We are currently working to add additional logic to include tracking of the circular segments during the turns.
Additional to the previous movie, we also have plots of the complete run, the Euler angles, the wind components and windspeed, and the high level commands (airspeed, turnrate and height) . Note also that since we decided to control airspeed with throttle, then when descending from a waypoint, the airspeed hold is not as effective as in level flight. Time permitting, we might change the way we control airspeed during climb or descend modes. But for now, we will keep the current architecture for the inner loop.
Hardware-in-the-Loop Simulation
After running the simulation with successful results we compiled the simulink model and downloaded the code to the SLUGS autopilot for HIL testing. The HIL architecture is the one described here. The following video shows a run of the simulator. The left part of the screen shows the ground station software and the right shows Google Earth display. This is exactly what the operator would see in a real flight. Those familiar with UCSC campus would recognize that this is by the East Remote parking lot.
Overall, we are satisfied with the results and are therefore ready for true flight tests. We expect that these will happen in late May at the latest and we will report this when that happens.
We are also on schedule to release the full project by the end of spring under the MIT Open Source license.