Open Source OBJECT ORIENTED auto pilot software and hardware...



I'm new to this community and don't know the most appropriate forum topic for this post to be in.  Forum Admins please move this to the correct forum.


I'm wondering, is there currently an object oriented open source initiative for doing something similar to what the ardupilot and arducopter support?


I'm a seasoned C# and VB.NET developer, and have been eyeing the Netduino and the Microsoft Gadgeteer...  But am also eyeing the android OS and it's JAVA based development environment.  I can see why ArduPilot has gained so much success on the arduino platform, as it's such an inexpensive hardware platform, but as faster hardware gets cheaper and cheaper, it seems like having an object oriented language could considerably accelerate development efforts.


Is there an OO project already out there that I'm not familiar with?  Has there been prior interest in an OO based development platform?


Thanks for the information, I appreciated the time!


Matt Christenson

Views: 567

Reply to This

Replies to This Discussion

There are a few fully custom C++ (So I assume OO) flight controllers coming out based on 32bit microcontrollers - see for e.g the PX4.

I have seen some one make a flight control using .Net Micro Framework, however I believe the concencus was that to make that viable, some seperation would have to be made between the .Net flight control logic and the 'tight loop' sensor & motor control code, which would have to be native in a driver or something.

So probably the most pragmatic approach would be to use an arducopter (or similar) running permanently in stabalize, and run your own OO code on a seperate 'Nav control' computer, and communicate via Mavlink on a serial board to board connection.

In that case, the Nav board could be anything that supports serial, so Netduino, or whatever. Even a Rasberry PI if you can get one.

Hmm, I wonder what the thoughts are behind the flight control logic needing to be procedural code... While there is extra overhead in an OO solution, the arduino runs at 16MHz, the $38 Netduino runs at 48MHz, The $50 Netduino go runs at 168MHz and has 386KB of code storage. The Gadgeteer runs more expensive at $120 and only 72MHz, so we'll probably cross that off the list...

The next step would be taking this to a Cell phone based Andriod or Windows mobile device. With the device costing closer to $350 (although I see Google’s selling a tablet for $200 now)... While the cell phones or tablets are more expensive, they DO come with their own accelerometers, gyroscopes, and magnetometers…   So now, $200 compares easily to an APM2 device but harnesses dual core 1.4GHz processors!


Maybe it’s my lack of experience with low level coding, but as I am reading through this ArduPilot code, I keep thinking how great it would be if we could use more of a “provider model” to architect modules and allow them to fit nicely together…  We could define a nice set of interfaces such as an IAccelerometerProvider, ISonarProvider, etc…  Then – when someone has new hardware to test they just create a class that implements that interface, with its own control logic nicely encapsulated in itself… and then changes a .config file to point to that new provider…  (or perhaps we create some ‘plug and play’ discovery logic to attempt to discover what devices are attached to the main board and through which ports.)

In the end, I think we would have a system that is easier for new developers to ‘jump into’ and extend, because they will need to be familiar with a smaller portion of the code base before they start making changes.

Also, in my experience OO software is considerably easier to create API documentation for, using model diagrams such as those outlined in UML and other modeling languages.

Again, maybe I’m just spoiled having been working with C# for the last 10 years, but I really do think that an OO based project could dramatically accelerate the evolution of this project, but making it possible for more developers to contribute quickly, and to experiment on their own by making small changes to the code with less overhead (time invested).



Thanks again!


Matt Christenson

The uFramework CLR while running at a faster clock rate on the netduino, runs (a lot of) interpreted IL, so isn't a like for like comparison. Moreover, it is still managed, so you still have to contend with the non deterministic GC collections which interrupt your flight control PID loop. Anyway like I said solvable by making a 'driver' in native code, but that gets complicated. Hence the suggestion of the dedicated flight control micro might be an easier way forward.

You should have a look at the PX4 project - I believe they are doing some POSIX kind of stuff like abstracting sensors behind 'devices'. Sounds like it may be more down your street.

Reply to Discussion


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service