APM software roadmap update

Here's an update on the ArduPilotMeta software roadmap:

The current public (zip file) code is the ArduPilotMega 1.0 Beta. We update that every week or two with the latest bug fixes (the version that went up last night fixes a bug with centripetal acceleration handling. If you're using the 1.0 beta you should update it with this latest version). You can see if you have the latest code by looking at the upload date. This is a fully functional autopilot and many people are flying it now, but it is a beta so we're very keen to get flight and bug reports so we can improve it. As always, file bug reports in the Issue Tracker, not as comments here.
The next release will be APM 1.0 (not beta), which should be out in about a month. This will be integrated with a new Ground Station (GCS) that can handle in-flight uploading of mission command and PID gains, rather than just using the standard ArduPilot GCS in legacy mode is we do currently. It will also fully support the very cool Debug Terminal, which can give you very detailed data and control over APM functions in flight. You can watch our progress on this version in the SVN trunk, but we recommend that you do NOT try to run or fly this code; it changes every day and is often untested. We cannot offer support for this code or answer questions, simply because it's unfinished and if we have to explain our work in progress all the time we won't be able to finish it!
Planning work on the APM 2.0 code is underway. Goals include adaptive control (so you won't have to manually set PID gains), better AI, more camera control including automatic location tracking, and easier setup processes, including an installation file that can allow people to use APM without ever having to see code or touch the Arduino IDE if they don't want to. We're looking at spring 2011 for a public beta.
Meanwhile, the ArduCopter quadcopter and helicopter branches of the project are making rapid progress. The quad team, which already has a very smooth flying public beta, should be adding GPS position hold in the next week, and waypoints and GCS support shortly thereafter. The heli team (which is using the Trex 450 platform) has achieved good flying performance and should be releasing public code this month, too.

Chris: If I had the answers, I would have quit my day job already :) One thing seems clear to me is that sensor input accuracy and repeatability of that accuracy is critical for adaptive learning. One has to find a happy medium between the inherent limitations of control sensor accuracy and the averaging of sensor input data used as a baseline for control feedback. Capitalizing (relying) on the predictable and proven accuracy of some sensors in certain situations, and assigning less weight for others in the feedback loop maybe a way to mitigating overall control sensor accuracy problems. For example, if the GPS's altitude accuracy degrades 30% in 50 degree turns and as such it falls below the inherent accuracy of the barometer sensor, the barometer sensor takes over. Also, averging the input of several sensors that are measuring the same value, and assigning a weighted value to each in certain situations based on their inherent accuracy in that situation can help provide a more accurate overall feedback, I would think. The synergy effect of sensors measuring the same value may also allow the elimination of certain anomalies that may inherently effect one sensor more than the others, thus tuning the effected sensor out temporarily or assigning less weight to it in the overall feedback input. The questions is, how do you detect and establish these specific sensor inaccuracies for use in a basline correction, also how can do you mantain the achieved corrected sensor accuracy adaptively, at least for the duration of the flight?

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

Join diydrones

Comments

Colin November 18, 2010 at 11:55am

So after some more google-ing I saw on pages 51 and 52 of this thread that my question is answered.

My understanding is that Michael has shelved the ArduStationM project code; it is in a working but untested state.

I think the hardware control station that you can strap to your transmitter is a superb solution. So I will go ahead and order it and delve into the code as necessary :)
Colin November 17, 2010 at 4:01pm

Thanks for the update Chris,

Do you have any info on the status of the ArduStation project? I've searched the forums and blogs and seen the teasers from the beginning of the year on ArduStationMega in the form of new hardware, but nothing since April.

Is the current ArduStation being used by anyone with the APM, I see a branch exists for it in the SVN...

I'm thinking of buying one when I order my xbee's - would be a shame if it became obsolete in a month or two.

Regards,
Colin
Chris November 12, 2010 at 11:00am

if the calculations are too much for the atmega328 why dont you use the usb or telemetry to transmit the data to a pc that crunches the numbers and sends the adjustments back to the atmega to test, there by the PC does the crunching on the big stuff, and the atmega just sends/recieves the info, i mean its just for initially setting the info right? so technically could do it and then once it finds the right values switch out of "auto-config mode" and back to standard flight mode.

Hell if you dont want to or cant use the usb for this is the xbee interface fast enough?
FLick November 12, 2010 at 10:56am

Hi Chris, about the adaptive control I can only say it appear to be a big load for the mcu, it needs time.
I ran genetic algorithm (not my code, is on the net) on my atmega328 and is soo slow. just a demo not a gain finder.
genetic algorithm is the better way to find the right gains, I'm pretty sure because I'm trying to develop it for my autopilot since 1 year ago. see youtube someone did it with a quad hooked to a pc if I remember right.
Maybe you can just make some trial and error in decreasing steps but make it convergent needs time and this kind of time just crash the plane while the process is not convergent. The only way is to make it start from some known spots for the airframe. what are your options actually? was genetic one of them?
Tom in NOVA November 10, 2010 at 9:03pm

Chris: If I had the answers, I would have quit my day job already :) One thing seems clear to me is that sensor input accuracy and repeatability of that accuracy is critical for adaptive learning. One has to find a happy medium between the inherent limitations of control sensor accuracy and the averaging of sensor input data used as a baseline for control feedback. Capitalizing (relying) on the predictable and proven accuracy of some sensors in certain situations, and assigning less weight for others in the feedback loop maybe a way to mitigating overall control sensor accuracy problems. For example, if the GPS's altitude accuracy degrades 30% in 50 degree turns and as such it falls below the inherent accuracy of the barometer sensor, the barometer sensor takes over. Also, averging the input of several sensors that are measuring the same value, and assigning a weighted value to each in certain situations based on their inherent accuracy in that situation can help provide a more accurate overall feedback, I would think. The synergy effect of sensors measuring the same value may also allow the elimination of certain anomalies that may inherently effect one sensor more than the others, thus tuning the effected sensor out temporarily or assigning less weight to it in the overall feedback input. The questions is, how do you detect and establish these specific sensor inaccuracies for use in a basline correction, also how can do you mantain the achieved corrected sensor accuracy adaptively, at least for the duration of the flight?
3D Robotics

Chris Anderson November 9, 2010 at 10:31pm

Tom: Both. We're just in the research phase, trying to decide on the best method. Here's one. Do you have a suggestion?
Tom in NOVA November 9, 2010 at 3:46pm

Chris: is the adaptive control just a matter of time, or still a matter of finding a method of doing it?

Thank you,

Tom
Chris November 8, 2010 at 5:01pm

cant wait to see video of the heli branch, so i can see if i want to go heli or quad for my mapping project
Earl November 8, 2010 at 3:26pm

Chris
Talk about reliability.....I have had my APmega powered up for about 6 months now and it has NEVER hiccuped !
It has gone thru hundreds and hundreds of write cycles for testing now.
THIS is a very reliable product !
Earl
3D Robotics

Chris Anderson November 8, 2010 at 12:45pm

Davey: AP is a lower priority, since it's already pretty stable and works well as it is, and the hardware has less headroom for feature additions. But we'll probably go back and at least port it over to the APM architecture/libraries over the next several months. That would make it easier to maintain, and would at least bring parity in terms of hardware supported and state-of-the-art navigation routines.

But as I say, AP is mature and works well, so our main priority there is just to polish off any remaining rough edges there rather than huge feature enhancements. APM, with its more powerful hardware, is the core of our new features work.

of 2

This reply was deleted.