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:
- 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
- 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
- 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.
Comments
Matt,
You should check out this thread re the follow-me functionality as it's apparently already been at least partially implemented in the mission planner although not tested.
Who is working on the "Autonomous "follow me/look at me" control with handheld GPS groundstation" feature called out here? I've been thinking about doing just this for follow-cam type filming for action sports, but that's just one of many possible applications. How could I help out with this particular effort? I'm experienced with C, C++, and Python, but am fairly new to the Arduino platform. I'm happy to help out any way I can.
Johann: sonar and airspeed has been working on APM 2 since last year.
@johann,
You're talking about the arducopter code? Sonar should be working for APM2 for Arducopter. I'm working away at optical flow..getting closer although maybe still a couple of weeks away.
With much respect to the ArduCopter developers, I would at the very least like to see code that can loiter, nav say, 10 way points, and do RTL.
Jason does seem to at least keep the 1280 owners in view, thanks Jason.
My question is as follows, is there stable code for the 1280 boards, other than the old Pirates code?
(I know, it couldn't nav )
Ravi: we have not announced a hard date yet for production to resume (we're waiting for a new baro sensor, which is in very short supply). We're hoping another batch can ship in early Feb, but we have not committed to a hard date yet. If we can't hit that date, we'll refund any pre-orders or otherwise offer some compensation for the long wait.
Ellison: Yes, at some point all hardware reaches the end of life, but I don't see that anytime soon for APM 1. It's certainly got at least a year or more of full support. After that, you're right that the community would take over support, but we're nowhere near having to organize that yet.
hi chris, can u please tell me when the fresh batch of APM2 (purple) would be shipped. I reserved mine about a month back. very keen to get it.
Chris, maybe misunderstood the last answer you gave. I thought the road plan would be to eventually phase out the APM1 and phase in full functionality of the APM2. This would mean that eventually all new features would require APM2 hardware and the APM1 software would stop evolving. My suggestion was that since there are thousands of APM1 owners out there, and this is perfectly fine hardware for an autopilot, in its own right, there was no need to retire it eventually. So if a team is spun off to continue developing firmware for it, separate from the APM2 stream, it would probably be useful for all the APM1 users who are happy with it, and have no intention to upgrade to APM2.
Eillison: I'm not sure I understand your question. We plan to make the 3.x features available on both APM 1 and APM 2, based on the same codebase. The only difference should be the performance of the two boards, due to the differences in sensors.
-
1
-
2
-
3
-
4
-
5
of 5 Next