A Game of Drones

There is one thing that will, without doubt, induce fear in the heart of any undergraduate computer scientist: group project. The problem is that they come with all the responsibility of paid work, but none of the accountability. Maybe I'll revisit the game theory of Warwick group projects in a later post.

The topic we chose for ours was one I'd been wanting an excuse to explore for a while: quadcopters. After some brainstorming we decided that the best approach we could take given that this was an academic project was to devise some framework for reasoning about drone networks, and to devise a way of writing high level scripts that could task them. I think the particular use case we had as an example was monitoring forest fires.

The problem is though, that the FOSS software available for simulating sensor networks is *really bad* from a beginners perspective. The de facto network simulation application is NS3 (yes, as imaginatively named as you think), but the learning curve is really high. The hands on section of the sensor networks module at Warwick for *third years* spends weeks building up to the point of moving some nodes around. Suddenly it began to dawn on us that we had bitten off rather more than we anticipated.

Upholding a long tradition of software engineers everywhere, we took a fresh look at the problem and decided that it would be easier to create our own simulation software than to learn the intricacies and quirks of NS3. To be honest, it's done wonders for my understanding of the domain, as well as the specific problems we are trying to model. The best example of this probably lies in the communications side of things. If we had used NS3, I would have experimented with a few different message routing models before trying to piece together a conclusion based on what the corresponding Wikipedia articles told me was supposed to be going on. As it stands, I've actually taken the RFC for Ad hoc on demand distance vector routing and implemented it in C++.

Credit: David Richardson

We made a conscious effort with the project (named octoDrone) to keep things as modular as possible. To this end, the simulator, communications processing, programs that run on drones, and scripts that define simulations are all separate and configurable. This payed dividends when it came to deploying our software on to real drones instead of simulated ones, as we were able to swap out the code that simulated the operating environment for one that sent the same instructions to real hardware (I'll cover the deployment in a separate post as it's something I could talk a lot about). The other goal during development was to cut out a lot of the bloat that plagued NS3. Instead of it taking half an hour and a handful of tutorials to visualise a simulation, the application *should just do that for you*. Instead of having to access node components by passing strings with the same name (eugh), you should just be able to access them through code the way you normally would.

At the end of a year of work we're left with a lightweight simulation package that does exactly what one would want a drone simulator to do, and nothing more. Being able to run the same programs on real drones as you do in a simulation is a real selling point (and that it works at all on the drones we had to test on is a point of personal pride). It even got to the point where I seriously considered running my coursework assignment in octoDrone instead of NS3, which serves to show just how far we've come.

GitHub: https://github.com/mcnutty26/octoDrone