3D Robotics

ArduPlane software roadmap

3689503868?profile=original

On the APM developer mailing list, the team recently posted their software roadmaps. Everyone is welcome to join the dev list themselves and follow this, but for those who aren't already signed up, I thought I'd post them here. 

As most of you know, the big recent leap has been full ArduPlane support for the 32-bit PX4 autopilot board, which is now complete and we'll talk about more soon. But in the meantime, here's the ArduPlane software near term to-do list, from team lead Andrew Tridgell:

As long as everyone understands that roadmaps tend to change, then I'm
happy to give an outline of the development that I'm aiming for over the
next few months.

It really divides into 3 categories:

 - vehicle specific changes (plane, rover, copter)

 - board specific changes (APM1/APM2/px4/vrbrain)

 - platform changes (basic system capabilities, build, libraries etc)

Within each category we have various people who 'own' the category. For
example, Randy is the ArduCopter lead, so he has some goals for the
vehicle specific components of ArduCopter. Randy has posted a nice
roadmap of what he is working on there.

For the platform and board changes, in the short term we want to get a
number of things fixed up so that px4 is a really good basis for
development. That means changes to the build system to make it easy to
do development on Windows, plus adding support for high rate logging to
the sdcard, both of "flash" logs and of telemetry style logs.

We also have a lot of docs to write on how people can use px4, how to
set it up, how to flash new firmware etc. Heaps to do there.

After that I'd like us to start taking advantage of the power of the
px4. For example, I think it would be great to be able to choose to use
the PX4 Kalman filter that James has been working on, and also use the
PX4FLOW board for highly accurate positioning. That will require some
restructuring of our library APIs, either within the AHRS framework, or
as a new library.

I also want to continue the process of library cleanup and consolidation
that we have been doing for a long time now. A good example is the new
AP_Mission library that Brandon has done. That library will allow us to
move a lot of mission logic into a common library, which lowers
maintainence costs and makes plane/rover/copter more consistent.

Similarly I would like to move a lot of what is now in GCS_MAVLink.pde
to a library shared by copter/plane/rover, so maintainence costs are
lower and improvements affect all 3 vehicle types.

A really big goal for me is to introduce a scripting layer into the core
autopilot, as an alternative to the current very simple mission
system. It seems likely at this stage that the scripting layer would be
based on pymite (a lightweight python implementation). It would only be
available on our ARM ports (not on APM1 and APM2) as the AVR doesn't
have enough memory to support it.

The scripting layer would allow for users to write simple or complex
scripts to control their vehicles, giving much better control over their
autonomous behaviour than we have now.

While all this is going on we also have the day-to-day process of bug
fixes and accepting patches and small enhancements.

For the rover code, I've been slowly working to cleanup the core rover
code to be a good basis for future development. That has taken much
longer than I hoped it would, but I would like to get a decent release
out soon.

In the plane code we have a number of interesting things pending,
including navigation improvements. Longer term I really want to get 4DT
path planning and sense-and-avoid capabilities.

I hope this gives you a bit of an idea of how I see things going. I'm
sure I've left some major things out, so please ask if your favouite
pending feature isn't listed.

You may also notice that I haven't put dates on things. That is
deliberate, as one of the things that is certain about software
development is that dates are always wrong!

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Developer

    Hi Dwgsparky,

    Do I assume from this that the future of APM 2.5 is dead?

    No, I plan on keeping both APM1 and APM2 working with new ArduPlane releases for a long time. What will happen though is that some of the new features will only be available on PX4, because the new feature uses either too much memory or too much CPU for the AVR microcontroller on the APM1/APM2.

    Cheers, Tridge

  • Moderator

    Thanks for the roadmap, very interesting.

    Do I assume from this that the future of APM 2.5 is dead? is it expected that PX4 will make the APM obselete? It will be very important to know as I am getting ready for the summer and the developement of my business as I am sure many others are doing. 

This reply was deleted.