Why Another Autopilot?
Posted by: Mariano I. Lizarraga
One of the first questions I got from both of my advisors when we started discussing about developing SLUGS was “Why another autopilot?” Certainly there are many fine open source and commercial options, and it would seem like every week there is a new one. It was my believe then and still is now, that all of the available autopilots where geared towards users who, most of the time, wanted a turn-key solution. That is users that wanted an autopilot to fly their UAV to some waypoints and relay information back, some in real-time others by logging data onboard. But very few were actually geared towards facilitating research on control systems. If you wanted to modify say the Kalman filter in one of the open source options, you were in for some serious high level programming and debugging.
One of the first questions I got from both of my advisors when we started discussing about developing SLUGS was “Why another autopilot?” Certainly there are many fine open source and commercial options, and it would seem like every week there is a new one. It was my believe then and still is now, that all of the available autopilots where geared towards users who, most of the time, wanted a turn-key solution. That is users that wanted an autopilot to fly their UAV to some waypoints and relay information back, some in real-time others by logging data onboard. But very few were actually geared towards facilitating research on control systems. If you wanted to modify say the Kalman filter in one of the open source options, you were in for some serious high level programming and debugging.
By that time we had been working with Simulink’s Real-Time workshop with PC104 computers for five years and, most of the time, not requiring any C-code at all. It was from there that we decided to have an autopilot that we could program completely from Simulink. In that way we could run software simulations, HIL simulations and download to the board the exact same model.
We researched many microcontrollers and microprocessor options and we finally settled on using Microchip’s dsPICs. First because I knew the architecture from previous projects I had been involved in. And second because we tested Lubin Kerhuel’s dsPIC blockset for Simulink and were quite pleased with its performance and ease of use. By using Simulink and the Real-Time workshop the SLUGS autopilot can also take advantage of all of Smulink’s additional blocksets and tools such as State Flow, the Fixed Point blockset, and many more.
All of us who are working on the SLUGS Autopilot strongly believe that this autopilot will allow us, once it is finished, to rapidly prototype new algorithms in simulation and, once they are shown to work, download them to the autopilot. This we believe is what makes SLUGS different to any other open source or commercial autopilot currently available.