3D Robotics

ArduPilot Roadmap

As you'll see, we're releasing versions of ArduPilot at quite a clip. The difference between them can be a bit confusing, so here's a roadmap:
  • 1.0: Just navigation and altitude hold (released 1/09)
  • 2.0: Adds XY-sensor stabalization, EM406 only (released 3/09)
  • 2.0.1: Adds Z sensor, ground station support (released 4/09)
  • 2.1: Supports XY sensor in diagonal position, desktop setup utility (does not require Arduino IDE), throttle (if airspeed sensor/shield is connected). Due week of April 20th
  • 2.2: Requires ArduPilot 328 board (current board upgraded to the Atmega328 chip; stay tuned for details). Supports any GPS, fully configurable for different airframes, new navigation modes. Due early May
  • Shields: We will be releasing expansion boards (called "shields" in the Arduino world) that plug into the top of ArduPilot and add additional features and connectors. This first one just adds a differential pressure (airspeed) sensor, 3.3v power regulator, lots of handy ways to add other sensors and GPS modules, and a circuit that allows you to upload code without unplugging the GPS. The first board will be available in May.
  • 3.0: ??? Additional sensors (speed, power). Maybe IMU support?
  • ArduPilot Pro: new board based on Arduino Mega. IMU based. Winter 09
E-mail me when people leave their comments –

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

Join diydrones

Comments

  • @ automatik

    Are you going to post your exe anywhere for people to try?
  • 3D Robotics
    Good question. Right now there's not enough memory left in the atmega168 to support that, but in the 328 version with 2x memory, hopefully out in a few weeks, we can set up a layer for sensor integration. Jordi is the best person to decide on this. I'll chat with him this eve, when we meet up in Denver for the Sparkfun competition.
  • 3D Robotics
    Automatik raises a good question, which is how to make this a more mature open source project, with a proper code repository and a process for forking. Although we are hosting the code on a proper repository, Google Code, we're not actually using the SVN version control system (it's not set up for Arduino code, which isn't compiled with a make file).

    We'd be very happy for people to fork the project for their own needs and share the code, and I just have a few suggestions on how to do that:

    1) Please don't set up a separate community. There's plenty of room here for subprojects and the teams can set up and control their own pages here. Setting up a separate Ning site would require people to join that one, too, and it could be become a nightmare of cross-references.

    2) I'll give access to the Google Code repository to any team who has code and wants to share it. You won't be able to change our code there, but you can add your own. If you want to use the SVN version control/collaboration system, you can.

    3) As for contributions to the main ArduPilot project, I think it's best to remain do what Automatik did and specifically volunteer to do one thing. The code base has been small enough that one person (Jordi) has pretty much been doing it all, and so only one person really understands it fully. but as we branch out to groundstations and other support apps, we'll have to spread the load. I'll talk to Jordi about which projects he needs help on and we'll put out a call for participation.

    4) As for an outright fork, I think that's fine. The only thing we're worried about is people going in other directions and then asking us to support their code or help integrate changes we make in the core ArduPilot code. So, like all forks, it's closer to a "friendly divorce" than an "open marriage" ;-) Once you fork, you're on you own. With our best wishes and encouragement, of course, but not much help.
  • Hi all,
    I agree with Torin, Chris, and Reto with regards to SW development and open source statements, however I am not clear on how to proceed if I ( or someone else) wants to add code. Are we set up to do this - is there an official depository / source control system? I know that code is hosed by "Google code" but can we (beside Jordi/Chris) add code to it? What happens if there is branching of the code? Say Chris wants one functionality and I want something else - what happens then? Or what happens if 20 other members want some functionality which is not in alignment with ArduPilot road map? Since Chris initiated all this is he "the decider" (and that's fine I am just asking :) )? Of course there is always a possibility that everyone can develop their own specific branch of code, which is also fine and will suit individual needs (and in spirit of open source), but I don't think that few previous posts were hinting at that.

    Here is example from my own DIYdrone experience:
    When Jordi released LabVIEW code for ground station I was excited, for various reasons including that I have been using LabVIEW since mid 90's (I remember when "undo" functionality became available - which was a big deal :) ) . He mentioned that he couldn't compile the code because of certain issues. I looked at code, figured out "what and why" made a correction, and was able to compile the code (.exe) and make an installer for it as well. I emailed my code addition to Jordi as well as bundled installer. I purposely DID NOT post the code nor installer because I did not want to "step on Jordi's toes" - he worked on it and if he wanted to release it I left it up to him. Aditionally I don't have an ArduPilot board and figgured it should be tested on it before it goes into the "wild" (my simulation of inputting ArduPilor Data worked fine - two computers with one running compiled code and another sending data via serial port). I could of asked somebody with the board to test it, but wasn't sure of etiquette with regards to code (all issues I raised above).

    Additionally, and back to "source coding" what happens if same functionality is wanted but developer have different ideas about architecture / implementation? For example - Jordi did a good job on first pass for ground station, however due to ~15 years of LabVIEW experience I would of done few things differently as far as code architecture and implementation ( I sure hope this sentence doesn't come across in any derogatory manner).

    I think all this is part of "growing pains" and I am not advocating rigid rules and heavy bureaucracy, but I do think that ideas behind these questions should be addressed in some form, while still maintaining the current spirit of the site.
  • 3D Robotics
    Thanks Torin. Needless to say, he's right and I agree ;-)
  • No, the algorithm was scrapped because it was more memory intensive, but it was exact.

    Here's the post that it was posted as "changed" at:
    http://diydrones.com/profiles/blogs/new-ardupilot-pocket

    I don't know if it's a worthwhile change though...
  • 3D Robotics
    We're constantly fine-tuning the algorithms for better performance. More memory will allow us to do more, but just follow the code updates to see how exactly we improve navigation. It's rarely as simple as returning to an old algorithm. We're always on the search for better ones!
  • Also... will there ever be a mode that allows the plane to takeoff/land by itself? (I know it's a ton of code + more sensors, but...)
  • A while ago, you changed the trig algorithm (I think that that was what it was...) to make it faster for the ardupilot to compute, but reduces the accuracy long range... Any chance that you would change back to the old algorithm now that there will be a faster/bigger/better board?
  • 3D Robotics
    Michael, again, this is too early. ArduPilot Pro doesn't exist. Please hold your questions until it does.
This reply was deleted.