Ardupilot 2.1 is out and can be downloaded by the mission planner (or with Git). You must have the latest version of MP to be compatible. If you're compiling with Arduino, you must use the "mrelax" version of Arduino that is in our downloads section. This is because Arduino was never tested with code larger than 128K. And since our code is probably the most complex Arduino project ever, we found the issue. This altered version of Arduino allows you to specify a special compiler flag that makes it work again. Otherwise it's functionally identical to version 22. When we transition to 1.0 of Arduino, you won't need to use a modified version, since they have patched it for us.


This version has a few new features, but is mostly a bug fixes and compatibility with APM2.  The nav routines have been updated and well tested. I'm getting very reliable results now. 

One new feature that I snuck in was SuperSimple mode, which re-calibrates simple mode when you are flying with GPS > 20m from home. It allows you to fly in any direction in Simple outside of this radius. Check the wiki for more info.

Added Auto_land mode to help with Failsafe implementations.


Here's a video I took flying WPs using CH 7 to toggle record them. I flew back and forth over the park to se how straight a line I could maintain and how repeatable it was, then I recorded a few waypoints to the left and right, then I recorded a landing wp by toggling CH7 when the copter was on the ground. The landing could be improved, it was trying to maintain a location and didn't level out in the last meter to the ground as it should. I was missing the screw holding my Arm in place so it folded in just a bit, no real damage done. BTW, this video is W/O a sonar.


The next video is of the Loiter control. I improved loiter a bit with a bug fix and the stability patch from the stabilization. Wind was mild. Could be tuned just a little higher.



Here's a video from Dec 17 showing WP recording. The radio was on the ground the entire video. The 3DR frame did not have a sonar on it. The landing was recorded as well.



Tridge wrote a Geo - fence routine to restrict flight within a certain area for Arduplane. We'll port that over to AC. You'll be able to fly acro inside a safe area and have it go into AP if you loose control!

We need one more pass to finalize the Optical flow integration.

Finalization of the Z Accel code.


Have fun and fly safe,







Views: 41364


Reply to This

Replies to This Discussion


You can buy an i2c board for the MS5611 from here Then you can write a library to interface the board and integrate it in to the arducopter code.

This is DIY after all

Thanks, was what i was looking but i'm not a programmer, i can only contribute to the project by testing the work of others, i recognize my limits... :-)
But inside the library of APM GIT i see "AP_Baro_MS5611.cpp/.h", for connection in the standard "SPI port"... :-/


The MS5611 has both i2C/SPI interface and you can select which interface you want on the board agmatthews mentioned.

Cool thanks!

I remember at the beginning of the year having to make a choice on what hardware to follow and pursue.  For the price, features and group energy it was the right choice for me.

And this is a DIY project with the hardware to do anything you what to do.  For example, I just added SimonK's esc FW to my 2.1 quad.  And it was a great leap in stability.  I can build and tinker all I want, and add ideas from other's.  Great hobby.



Hi Chris...

Could not agree more... I think that for the past 12 months that I followed and tested Arducopter development, I can only say that it is improving exponentially (with some setbacks that are expected in opensource).

The only "problem" is that allot of people have allot of ideas what to add to the new code, but only few of them participate in development of the code to implement those ideas. 

And then when I hear some people say "Mikrokopter this" and "Wookong that" my hear goes skyhigh.

I appreciate when those critics are constructive like Marco's, that is actually testing the code, but when someone just bulls***s about it, it makes me sick!  

I felt Jason's frustration with some posts, so just wanted to ask the DEV team to keep up a great work, and gather strength to fine tune those child illnesses.



Setbacks are most of the time very fastly corrected. I don't think it is something specific to Opensource, but more related to the number of developpers working on the project and to the development rate. It is not always possible for every team member to catch up with all the exchanged messages. But most of the time it is only a matter of a couple days to solve a problem. If you watch at big commercial projects, setbacks are not inexistants.

Anyway, i feel that APMv1.4 is working very nicely, and that with APM2.0 we have the hardware to get even more performances thanks to the better sensors and to the new available DSP, that will free up ressources for more advanced motor control and navigation functions like more precise loiter and waypoints navigation. New functions like SuperSimple mode (an advanced simple mode where you can fly all around without yaw worry) are just coming in the game and i'm sure we'll see a couple other one like this in the next monthes. But be assured that the team is always focused on reliability and performance enhancements before to play with toys. In fact i feel that about 80 - 90 % of the team time is devoted to code performance enhancements / bug corrections and about 10 - 20 % to add  new functions. Adding new functions is not always the more difficult task and is necessary to keep everyone happy, from team members to users and keep competitors unhappy :=)

I'm watching closely code developement every day. I can say that the amount of work done is impressive. The APM 2 integration as asked a lot of work so I feel that the development team will have now a bit more time to concentrate on code enhancements to get the same level of performance, or perhaps better, than commercial projects with the big advantage of being not only opensource but also low cost and open to user propositions and ideas. As an ArduCopter user as well as a team member i would like to thank all the community for all the good ideas and the nice work that has been done.

I would like as well to highlight again the opening and completeness of the project, with the possibility for a lot of users to get what they need, from beginners to expert or pro users, hardware or software specialists, everyone can find a good basis in the Ardupilot projects softwares and hardwares.

Good remark Chris, I fully agree with you about this.

ArduCopter is the Best One, the cheapest and the fully opened development plateform for multicopters WorldWide... I really enjoy with this dev and research tool today.

Regards, Jean-Louis

Here is a maybe a simple solution for more stability:

Will it get better stability and a smooter regulation using governor esc's used in trad traditional helis. 

APM will be able to command these esc's to exact RPM that maybe extracted from a table that is intended for propeller and engine size. Such a table is easy to make for different engines and propellers by measuring the speed and thrust at different RPM. This setup will give the esc's more of the work with steady thrust These esc's are able to maintain a very precise RPM regardless of load.

This is the point 5 of the DJI manual (Matters Need Attentio)

5. GPS/Compass is sensitive to magnetic interference, should be far away from any electronic devices

Then I my ask: Will it be a great advantage to put the compass and GPS in the upside of an aluminum platform 10 to 20 cm over all other electronics

I don't think aluminium will do anything about magnetic interference.  It might reflect some high frequency EM interference but  I think distance is by far the best interference supressor.

I'd also like to say that I've been with arducopter for about a year now, and I've had lots of fun with it, both tinkering and flying.  Bang for buck arducopter is unbeatable and it also has the best featureset and can be tailored to your wishes (if you take the learningcurve)

Great job development team !!!

I think creating a shielding ground plane below the GPS antenna might be a good idea:

And distance is not too abundant on our slightly crowded little flying things.

Applying some alu tape on the platform below the GPS might do good things. 

I might even help shield the sensors and other EMI sensitive stuff on the APM from the radio energy emitted from XBee and video downlink (if you have one).

I also think moving the XBee out from the hub might be a good idea. But not righ on to a ESC... ;)


DIY Drones Monthly


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2016   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service