- 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
You need to be a member of diydrones to add comments!
Comments
Are you going to post your exe anywhere for people to try?
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.
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.
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...
-
1
-
2
-
3
-
4
of 4 Next