Many researchers have demonstrated significant and impressive results of UAVs flying in GPS-denied environments, typically using expensive (financially and/or computationally) sensors such as cameras and laser scanners. If many aerial robots are needed to perform a task collaboratively, it may be advantageous to outfit a few of the robots with expensive sensors and algorithms for global situational awareness (flight relative to a room, for instance), while keeping the rest of the vehicles simple, allowing them to navigate relative to the leader robots.
In an attempt to realize this goal, I developed a lightweight solution for estimating position and velocity relative to a known marker. The marker consists of three infrared (IR) LEDs in a fixed pattern. Using an IR camera with a 100 Hz update rate (a camera from a Wii remote), the range and bearing to the marker are calculated. I then fuse this information with inertial sensor information to produce state estimates at 1 kHz using a sigma point Kalman filter. The computation takes place on a 14 gram custom autopilot, yielding a lightweight system for generating high-rate relative state information. I compared the estimation scheme to data recorded with a motion capture system.
This is the autopilot I designed and built for the project, and the sensors that were used. The autopilot itself contains a dual-core TI microcontroller, inertial sensors, and a barometer. Externally, a sonar estimates height to the ground and the Wii camera (not see in this image), sees the IR LEDs on the known marker.
This is a rough block diagram of the data flow for the project, including the rates at which various sensors are read and algorithms are executed. I designed, manufactured, and programmed the autopilot from the ground up.
Finally, this is a diagram of the autopilot architecture, including the communication protocols for the sensors and the computation distribution between the two cores.
This was a really fun project and I learned a lot of valuable things. Here are a few:
- Hardware is hard. For instance, I spent many, many days trying to get the sigma-point filter code to fit in the available memory on the autopilot.
- Prototype with the right data. The original filter code was developed using a data-set collected by moving the autopilot around by hand. The vibrations induced by the motors during flight, though, were very significant and could have been accounted for had I collected the data set from a flying vehicle instead.
- Don't use cutting-edge microcontrollers. I originally thought that the new TI dual-core microcontroller was a really good idea, but it didn't have a big enough user base yet. Instead, I should have used two popular single-core microcontrollers and just sent data between them over SPI or another protocol.
- Hardware is really fun. I had a blast going from initial concept all the way through circuit design, hardware construction, programming, and flight testing.