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: 41940


Reply to This

Replies to This Discussion

Many Kudos to all in this project- Jason, Chris, JLN and the rest of the devel team!  The dedication and motivation is awe inspiring. After a couple years of dabbling, I got serious this year.  I have been ordering parts for my project over the past few months- all the while learning from you all through the study of this forum.  The ongoing process of improvements is impressive and admirable.  As an end user (noob!) who would love to contribute more, I see a tall hill of a learning curve ahead of me- but then I have to look back down at how far your sharing has already helped me climb up this fairly steep grade.  This is a very cool and very sophisticated flying robot that just keeps getting smarter. Sincere thanks all.  Its been a fun process thus far- I can't wait to fly!

I think that you make valid points and valuable statements in your video. You must have misread what I have said: 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!  

Thank you


Governor is not the right mode for us. It is intended to keep a stable RPM. We need the opposite, fast change.

But using an ESC with a well known PWM to RPM curve could help.

I would also like to openly add my support and gratitude to the Dev team, who seemingly spend great quantities of their time, helping all of us maximize our experiences and enjoyment from the APM and all of it's derivatives. I maybe biased as a pure hobbyist and sideline observer in these forums, but daily wishing I had more knowledge and experience to actually be able to contribute something useful. I don't use Arducopter as 'tool' for any job, I became a participant in Arducopter for nothing more than the experience of open source projects and the learning and enjoyment that they bring. All inspired from a Internet video presentation given by Chris and blimp many years ago.

Long story short, a great thanks to the team for their tireless effort, and all who contribute here for their wanten progression of a fantastic concept. Well done all. (rant over, please continue :-)

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... ;)

I just ran another test using Pulso ESC's. These would not work with any multi rotor controller accept DJI (200 hz) so I gave them a try. The result was as expected and the stabilisation was totally degraded by the slower response. No amount of PID tuning would get it back to where it was with 400Hz.

Oliver, right on, It has to be as fast as we can get it.


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

The governor convert pwm to rpm. It is not nesseary to stay loced at one rpm

You right Tomas, I have tryed ground to the gps and shilelded xbee with alu tape and this make sense. The Gps lock in a minute, and work perfect indoor too:)

After studying the DJI / mk for a while now and flying arducopter for about 100 flights, it seems that it focuses too little on hw on Arducopter.
It can be made large improvements in the set so that noise and vibration are avoided in keycomponents such as magnetometer, gps, baro etc. It seems that the components of the apm is too naked and exposed to the most that may destroy a good operation. It does not help with a good software if eg magnetometer does not are doing well.  It does not help with a good barometer or magnetometer when there are 8 esc'er that makes noise and 8 engine that generates vibrations and damaging information to the software (apm). 

Well yes Arnt_inge, it does.

But all governors I know of have characteristics to keep a constant speed over some time. So the time constants involved in the control algorithms of the ESC governor would counteract our need for rapid response. The type of speed command you are thinking of would need another algorithm optimized for multicopter motor control.

I do not mean to use the governor without any further. As I mentioned might not be so clear, makethe engines follow predefined tables that are made for the engine, propeller and length of thearm.
Force * arm = Thrust

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"... :-/

Reply to Discussion



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

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service