Looking for collaborators to build an FRP autopilot for hobbyist AUVs in Haskell

[Doug McClean]

Dear Boston Haskellers,

Over the last several years there have been several successful hobbyist efforts to create autopilot hardware and software for small unmanned aerial vehicles, with a particular focus on multicopters. There's also been a great deal of recent research on functional reactive programming, and a whole bunch of Haskell FRP libraries released implementing that research. We also now have an ARM backend for GHC which enables running on some cheap, low power, physically small, (moderately) low memory platforms.

Is anyone interested in a project to combine these developments? I'd like to work from one of the existing hardware platforms to perform all the sensing and command all the actuators, but move the autopilot and mission planning into a separate FRP program. I'm especially interested in DSLs for mission planning. Working on autopilots for fixed wing aircraft is also of more interest to me because the requirement to maintain airspeed (which doesn't exist for multicopters) imposes constraints that make planning much more interesting.

It actually isn't all that complicated to get something basic that works, and the performance requirements aren't all that high. 50 Hz seems to be more than enough for the control loops, everything faster than that (AHRS, motor control) is already handled by existing hardware and software. I have a prototype implementation in signal-function-oriented C# that does a nice job of flying the FlightGear simulator even in gusty crosswinds.

If anyone is interested, I'd like to organize a meeting to brainstorm some solid foundations for the proposed Haskell implementation. There are some tricky architectural issues when you consider that different platforms often have very different sets of control surfaces, that bumpless transfer between control regimes is important, and that control laws for some aerobatic maneuvers aren't in the general case separable along roll/pitch/yaw lines. Each of these influences can lead to an almost immediate lack of modularity under several simple approaches I've tried; achieving the bumpless transfer part without giving up some useful static guarantees seems especially thorny and might require some extensible records chicanery or even a separate static analysis.

Once we get something that works reasonably well in the simulator and does interesting things, we can present it to the BAHUG and get some broader feedback and move on to integrating with some actual hardware. This hardware is cheap and getting cheaper, a complete airframe with servos, a motor, batteries, sensors, wireless modem, and controller is around $500. It's surprisingly resilient in crashes, too, especially for aircraft with pusher propellers.

At any rate, if you have any comments or questions or would like to participate please email me at douglas...@gmail.com.

Thanks,
Doug