The problem with mobilizing software volunteers

Here at DIY Drones, I've been working with other amateurs to create open technology platforms to make it easier for more people to build their own UAVs (for aerial imagery, high-res Google Maps mashups, contests and other flying robot fun).

The good news is that there are a lot of programmers out there happy to donate their time and talent to helping these project along. The bad news is that each of them has their own favorite programming language, and it's up to the organizer (ie, me) to somehow weave them all together into something useful for newcomers. Which means that the job of crowdsourcing software development requires the organizer to become a Rosetta Stone of software styles, which is tough if you're not a hard core programmer yourself. And I very much am not.

Let me give you an example: Our UAVs are using software written by at least 10 programmers, each of whom has contributed something valuable. The problem is that the various elements are all in different languages: NXT-G, Lua, Visual Basic, Python, Stamp Basic, LabView, C, and Parallax's Spin (for the Propeller chip).

It's not surprising that volunteers want to use their own favorite programming languages, and because they're volunteers I'm in no position to tell them what language to use. If this were just an open source software project, I imagine we'd just be pulling from within a community of people using one language. But because our UAV projects cross so many disciplines--software engineering, hardware engineering, robotics, R/C planes, GPS hacking, aerial photography and Lego, to name just a few--it's a programming language Tower of Babel.

Right now I'm porting the NXT-G autopilot to Lua, so I can integrate it with the Blutooth GPS code. This is after having already ported it to LabView to get access to floating point math. I'd like to combine our Widows Mobile cellphone autopilot with the cool GPS-tagging and image-sending of the Pict'Earth team, but they're using Python on a Symbian-based Nokia N95 and our Windows Mobile code is Meanwhile, I'm going to port our Stamp Basic autopilot to Spin, so we can use the more powerful Propeller chip, but to include gyros or accelerometers, I'll have to also port the open source inertial guidance software, which is written in C, to Spin.

And did I mention that I'm not a real programmer and the last language I was really comfortable in was Pascal, back in the 80s?

So that's the problem with herding an army of technology volunteers. Someone has to serve as the universal translator so that everyone's contribution works together. And that someone has to be a technology polymath, sufficiently fluent in all languages and dialects to be able to do that well. How many such people exist? Not enough.

Views: 223

Comment by paul hubner on July 26, 2007 at 9:16pm
I feel your pain Chris. I'm slogging through manuals again tonight trying to remember all there is about floating point math (argh). I know I knew this once...

Comment by toxicmouse on August 10, 2007 at 9:25am
if you choose a modular setup for the UAV, then you could group programmers according to language. each group would work on the same module. so one module could be the altitude hold, one for the navigation (rudder only), and one for horizontal stability. each module could be tested individually and each could function independently. this would also allow to mix and match systems from other projects. interoperation would not require a knowledge of programming, just set a protocol like serial 8 bits, 4800baud, 1 stop bit.


You need to be a member of DIY Drones to add comments!

Join DIY Drones


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service