About once a year we post our software roadmap for the next 12 months. Last year, we promised we would take ArduPlane and ArduCopter into their 2.x generation, with full two-way MAVLink control and a full featured ground station and setup process. The 2.x generations of the code were intended to give APM-based vehicles all the features of professional-quality autopilots at a tiny fraction of the cost. With a huge amount of effort from the whole dev team, which now numbers nearly a hundred people across its many projects, we've completed that. Yay!

 

The 2.x generations of ArduPlane and ArduCopter are now being flown by thousands of people, making the APM platform the most popular open source autopilot in the world.  With the introduction of APM 2 (above), with vastly improved sensors, lower price and fully-assembled delivery, this growth looks likely to accelerate. After a shipment of 150 boards to early-adopters last month, full production of APM 2 will resume in early Feb. The current 2.x codebases already fully support the new APM 2 boards.

 

So at this point the 2.x codebases are essentially feature complete, and we can move on to 3.x. (That said, the 2.x software will see continued updates to improve performance and reliability. In particular the traditional heli version of ArduCopter is a couple versions behind the more mature multicopter code, and will continue to evolve over the next few months--helis are hard!).  

 

As the dev teams focus on the 3.x code, you should see far fewer public code updates for a period of about three months (until April 2012). Lots of work will be going on behind the scenes in the Git repositories, but we will not be rolling out public releases of new features that risk drowning the team in tech support and documentation demands. Again, we will continue to fix any issues that are identified in the 2.x code and otherwise ensure that it's flying well for everyone, but we won't be adding new features to it during this period.

 

The 2012 Software Roadmap

 

The main objective of the 3.x codebases will be a new architecture that emphasizes modularity and portability. This is to help with the following:

  • Better reliability by making the code easier to understand, debug and maintain
  • Easier accessibility for new dev team members
  • Easier portability to new hardware platforms
  • RTOS compatibility, to prepare for the forthcoming ARM-based versions of APM

Examples of Planned New 3.x Features:
  • MPU-6000 DMP support. 
  • Inertial dead reckoning drift compensation
  • Full scriptable camera control on both ArduPlane and ArduCopter, with interactive camera gimbal setup
  • Auto-trim:  sets RC trim points when exiting manual mode
  • Loss of signal failsafes for GCS link
  • ArduCopter: Autonomous "follow me/look at me" control with handheld GPS groundstation
  • ArduCopter: Support for I2C/SPI/CAN motor controllers and forthcoming "smart" motor controller/PDB board
  • ArduPlane: Support for Flaps with automatic speed dependent deployment
  • ArduPlane: Servo control loop gains with speed scheduling
  • ArduPlane: Airspeed nudging from the RC TX in autonomous modes
  • ArduPlane: Inverted flight mode and scriptable acrobatics
  • ArduPlane: Sonar flare control

Architecture changes:

Make RTOS support possible:
  • Eliminate global state in sketches. This is a broad, fundamental change required to effectively use an RTOS.
  • Modularize sketch code into classes with interfaces. This will improve code comprehension and help enforce communication with messages rather than global state (again, required for RTOS)
  • Replace loop()-style structures with explicit periodic scheduling. This will increase code comprehension, enforce non-reliance of ordering of loop items (& global state), and make it easier to move to RTOS later.
  • Eliminate remaining synchronous blocking IO
Coding style:
  • Rename library class methods and members to meet coding standards
  • Run automated ‘indent’ script on all source, implement indent bot which fixes whitespace issues checked into repository nightly
  • Dramatically reduce reliance on preprocessor in sketches: features like HIL & ArduCopter traditional heli will be implemented using standard interfaces rather than source code manipulation
Logging:
  • Proposal: switch from special dataflash logging packets to MAVLINK 1.0 data
  • Modularize logging, move to libraries directory
  • Add SD card support for APM2

 -------------------

Join us!

If you'd like to join the dev teams, please read this post on the best ways to do it. (Short form: pick something specific that you'd like to help with and show some familiarity with the code). We're always looking for more programmers, but we're careful about taking time to figure out how to integrate them best and on which project, both for their sake (to have the highest impact soonest) and for the sake of the existing dev team members, who have limited time. 

 

You can always PM me with a request to join the team, and I'll generally start by adding you to the dev team mailllist so you can see how we work and get a feel for where you might fit in best.

Views: 6976

Comment by ThomasB on January 16, 2012 at 11:40pm

Sounds like a good roadmap. More structure in the code is really needed due to the grown complexity.

Comment by Gareth Rens on January 17, 2012 at 1:14am

Autonomous "follow me/look at me" control

Sounds AWESOME!

Comment by Fabien Bruning on January 17, 2012 at 2:08am

Sounds great, will the code also become more portable due to the elimination of global states? E.g. if someone wanted to switch the control algorithm. (though I suppose it's very possible now, haven't looked at the 2.0 code in a while)


Developer
Comment by Randy on January 17, 2012 at 2:52am

@Fabien,

     Basically yes,  Making the code more modular should make it easier for people (with programming skills) to change the control algorithms (or other parts of the code) without having to worry as much about unexpected impacts on other bits of the code.

     It is actually possible to some extent to switch the control algorithms but it's not too straight forward.  For example if you look in Arducopter's config.h  you'll see lines like this:

#ifndef ALT_HOLD_RP 
# define ALT_HOLD_RP  ROLL_PITCH_STABLE
#endif 

..what this means is that the Altitude Hold flight mode uses Stablilise Roll/Pitch controller...and then inside of ArduCopter.pde you can see where it has a big switch statement to decide which roll-pitch controller to call...and then finally in Attitude.pde you can see the actual control functions that are actually called.  Inside these controllers you'll see it accesses global variables.

so you could write your own control algorithm and fit it in there, and also update some other functions like reset_nav() and reset_rate_I() and it would work...but my understanding is that in 3.x we would try and make it so that you'd mostly just have to write one class and it's be more obvious what needs doing.

Comment by Anish on January 17, 2012 at 6:26am

this is awesome even some architecture, :) we are seeing near professional quality in all the processes involved. Congrats to everyone on the team


Developer
Comment by Adam Rivera on January 17, 2012 at 7:43am

This is great. I have definitely been hoping for a more organized (class/interface, indents) code base. Thanks for the update Chris.


Developer
Comment by Rob_Lefebvre on January 17, 2012 at 10:58am

"ArduCopter: Autonomous "follow me/look at me" control with handheld GPS groundstation"


Now that's what I'm talking about!  One of my main reasons for getting into this is for shooting video of outdoor activities.  Having a feature like this would be amazing!

Comment by Jeb Bailey on January 17, 2012 at 11:49am

I would REALLY like to see a more robust auto-takeoff/land system for ArduPlane.  The current code is basically turn on/off the motor and hope for the best.  A successful ROG takeoff is a rare thing without RC interevention.

While flaring is important (and I'm excited to see it on the list), I think that definable heading on takeoff (controlled by rudder) and landing (instead of locking in whatever heading it's on) is VITAL to truly successful operation of an advanced ArduPlane.  It seems to me that auto-takeoff/land cannot be called "feature complete" without this functionality.


3D Robotics
Comment by Chris Anderson on January 17, 2012 at 12:46pm

Jeb: Almost all small UAVs are hand or catapult launched--there are very few ROGs out there in this space (do you know of any?). We could certainly implement nosewheel steering, but it's a tricky thing to get right and generally not a priority for most users.  

Comment by Jeb Bailey on January 17, 2012 at 2:21pm

I don't know of any in the commercial sphere, but that's mainly because anyone who can afford something that needs a launcher can afford to buy one.  Most of the larger sUAS do actually land conventionally, and the commercial AP's I'm familiar with have the ability to define runways for use.  For instance, the Senior Telemaster is a great airframe, but needs ROG or a large and expensive catapult system.  Even an airframe as small as a .40 scale trainer is difficult to hand launch.

The real issue in my mind is the inability to preset a takeoff heading, and likewise a landing heading.  In both cases (currently), the heading held is automatically set to the current heading when a set of parameters are met.  While this my be a simpler way of doing things (I'm a novice coder at best), it seems like these modes have been put in as an after thought to an already very precise system.  Especially with the new APM2 having a built in compass, it seems silly not to utilize it for something that (at least to me) seems like it should be standard.

Comment

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

Join DIY Drones

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service