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

Views: 3085

Comment by automatik on April 14, 2009 at 1:24am
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.
Comment by Reto on April 14, 2009 at 6:46am
I am sure Chris and Jordi have some thoughts about your questions, automatik, and I would also be interested in those, of course.
What is always possible if some users/developpers want to go a different road, is just to create a new blog post and a new code repository. Or, if evolution is going very different, create a new parallel Ning social network for the new approach.
Anyhow, I feel some "locomotives" are necessary to get the train running. In this aspect, Chris and Jordi are just doing a fantastic job, and their train gained a lot of wagons! Some new smaller trains could as well go interesting routes, though. But are there some people to take a coordinating lead?

3D Robotics
Comment by Chris Anderson on April 14, 2009 at 7:05am
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.
Comment by Torin Segstro on April 14, 2009 at 10:14am
I think these base rules work well Chris. I do have one question.
I am testing some code that utilizes an I2C ultransonic range sensor which detects the height of the plane above ground. ( http://www.robotshop.ca/srf02-ultrasonic-range-finder-1.html )
I'm working on a way for the plane to follow a pattern and land in a grass field autonomously.

I can create another class/tab for this in the ardupilot code, however, what is the process in which we add it to the control loop? Should we define a specific method to do this?
Comment by Torin Segstro on April 14, 2009 at 10:23am
I should clarify what I mean in my post above. What I am asking, is should we define a process for adding sensor calls and control modifiers to the control loop without having to continually modify the control loop itself. This way, we can add any number of sensor calls and control surface modifiers in a modular way.

3D Robotics
Comment by Chris Anderson on April 14, 2009 at 10:48am
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.
Comment by Torin Segstro on April 14, 2009 at 12:35pm
Thanks Chris, and good luck with Sparkfun competition!
Comment by Michael on April 15, 2009 at 5:20am
@ automatik

Are you going to post your exe anywhere for people to try?

3D Robotics
Comment by Chris Anderson on April 15, 2009 at 5:49am
Torin,

I talked to Jordi about a sensor layer, and he says that because every sensor is so different and has such different function, he can't see how to make a standard interface, like an API. The closest thing we have to that is Arduino's built-in analog read function. But I suggest one tab per additional sensor as a way to at least make it easy to read the code.
Comment by Torin Segstro on April 15, 2009 at 11:37pm
Fair enough. In my mind, I was thinking it would be setup like so....

At all times, Ardupilot has a single target in 3D space that it is trying to hit as well as a single target speed. I'm not talking about waypoints here, but a 3D target which is calculated by all the various conditions which include the next waypoint as well as min/max parameters, sensor feedback, etc.

The control surfaces and throttle are manipulated to hit this 3D/speed target. What the sensors essentially change, is that 3D/speed target, and the time curve that is acceptable to achieve that target. In this way, you could have a single system which could take all sensor input and calculate a single 3D/speed target.

Example:
- X/Y/Z thermopile sensors indicate downward pitch, so 3D target is elevated past current altitude.
- The airspeed sensor (pitot) indicates that the aircraft is over speed and reduces the speed target
- The ultrasonic sensor returns a surface at 5 meters and elevates the altitude of the 3D target to try and avoid the ground.
- The waypoint threshold is met, so the next waypoint is loaded and moves the 3D target toward the new waypoint (via a circle path of course)

The parameters for the three sensors, and the waypoint input would be as follows:
X/Y/Z sensors - Priority 1 - Controls:ailerons,elevator - enabled condition:channel2
Airspeed sensor - Priority 1 - Controls:throttle - enabled condition:channel2
Ultrasonic sensor - Priority 1 - Controls:elevator - enabled condition:altitude<50
Waypoints - Priority 2, Controls:elevator, throttle, ailerons, enabled condition:channel2

The first parameter is the sensor name
The second is the priority level which can be used to ensure the safety of the plane over, say, camera control.
The third is what surfaces or controls the sensor can influence.
The fourth is the conditional criteria(or test) which enables the sensor input

So, with a few calculations, you would come up with a final 3D target above the current altitude, as well as a reduction in throttle. Due to the fact that the priority 1 ultrasonic sensor is below the max altitude, the priority 2 tasks are delayed until the priority 1 tasks are stable.

This is pretty high level, but gives you an idea of my line of thinking. I know it wouldn't be easy, but it sure would be cool.

Comment

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

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service