SAFMC 2016

It paid off.

SAFMC is an annual competition held by DSO, with five competition categories for different types of flying machines. This year, we decided to give Category D2 a try, to prepare for next year (and get a Judges Award again).

In category D2, we have to build and fly an autonomous drone through an obstacle course shared between category D1 and D2. The course is a artificial setup consisting of mostly walls.

The bullseye in the center of the hall is a ball drop, and following that there is a low-light area where we have to obtain a photograph of the code printed on the board. When we participated last year, it was an open area.

In December, we started work on a frame design. We chose a tic-tac-toe frame design because it was easy to build. For electronics, we used a Naze32 flight controller and a Raspberry Pi for our processing, mostly because we wanted to use the Raspberry Pi and not have any PWM problems.

The camera was supposedly for recording a video for playback later to extract the code written on the wall. But we ended up not using it.

At the back of the Raspberry Pi in the center of the board you can see part of the Naze32. We wired the serial port through a logic level shifter (the red board behind my thumb) and did all our control through that. Yes, I know, jumpers are a terribly unreliable interconnect, but it worked.

The frame had ultrasonic sensors on all four sides, also wired with jumpers to the Raspberry Pi.

Since we were writing our code in Java, it had to communicate with the Naze32 using the MultiWii Serial Protocol for RC. Searching online yielded no libraries for MSP parsing and serialising, so I wrote a library from ground up. It wasn't that hard a task surprisingly, as I have never written a parser and serialiser before (especially in Java). Performance-wise, Java didn't fail us. It ran our code without major issues.

Isaac was in charge of algorithms. To navigate the course, we used an abstract map fed with ranges for the drone to try and achieve. The drone is supposed to move until sensor values fell within a specified range, then proceed to the next step. Theoretically, it should behave well enough to be used for wall tracing, but we never tried.

Due to bad time management, we ended up going there with something that couldn't receive any sensor input. So, not wanting to give up, we brute forced precoded instructions for our drone, simply by setting throttle, roll and pitch values. It was intense for me (the rest of us couldn't do anything to help), but eventually at the last second we managed to fly it through the first hole before promptly smashing into the wall. It was random, it didn't behave as I expected but somehow it went in.

(Brute-forcing sometimes partially works)

(Photo of it not going in)

After the long exhausting day, we learnt one important thing. Time management is critical to our projects and for next year's SAFMC 2017 we needed to start early!