Thomas Burrow


My portfolio of engineering projects.


Quadrotor Flight Control (2014)


One of the last classes I took at MIT ended with a controls project. My team chose to make a quadcopter fly to arbitrary GPS coordinates and then land on a small platform. The platform has a camera underneath it, pointed straight up, for image processing to provide feedback for landing. GPS is good enough to get the quadrotor within sight of the camera, with enough altitude.

My role included writing all the code for the image processing algorithm and the two-dimensional PID controller, in MATLAB. We used a python framework called AutoFlight to interface with our quadrotor's control system. Our system was too slow to use in any amount of wind, but it worked fairly well indoors. Check out this windy outdoor video (code further down):

The code used for image processing and PID control can be viewed here (excuse the js brush). The quadrotor interface we used was called Autoflight. Several of my innovative features are worth pointing out:

1) Automatic camera calibration (line 192): Depending on how sunny it is outside, the code will have to adjust its black/white threshold brightness. Otherwise, it won't be able to trace the quadrotor's outline with camera data. When the quadrotor is sitting on the landing pad, I know how far away from the camera it is. Therefore I know exactly how big the silhouette should be, and I can adjust the brightness threshold effectively. This is done at the beginning of each flight.

2) Altitude compensation (line 71): Camera resolution can be increased, but it slows down the framerate of the algorithm. I realized that this would need to be adjusted with altitude. At low altitude, the quadrotor is relatively large in the camera frame. It also doesn't have to move very far in the x-y plane to exit the camera frame. Therefore, I need higher framerate to keep up, but I can get away with lower resolution. Conversely, at high altitude, higher resolution is needed to keep track of the quadrotor. The lower framerates are okay because it would take longer for the quadrotor to leave the camera frame.

3) 2D PID controller (line 337): Using the center of the camera frame as the target, and the centroid of the quadrotor silhouette as its current location, this controller returns control values in x and y directions.

4) Persistent search (line 291): One of the vulnerabilities of this algorithm boils down to losing track of the drone. It has to find the right white "blob" to compute the centroid of. Usually, the blob doesn't move very much between cycles (so the search starts where the drone was last seen), but it could have moved. In that case, it looks in the direction the drone was last moving. Failing that, it checks closer to the middle of the frame (hoping somehow corrections took place and the drone is where it should be). Finally, it begins an infinite loop of checks around the edges of the screen. If any of these attemps works, a boolean variable is flipped and normal operation is restored.

<< Back to Portfolio


Like this project? Get in touch...