Arducopter 2.7.2 is now in the mission planner and in the downloads area Some positive reports on testing can be found in this discusssion by John Hanson.

Note: just as the release was going out an issue was found re support for the all Camera Gimbals on the APM1s (it doesn't work) and with 3 axis gimbals on the APM2 (2-axis works ok but not 3).  If you're one of these people, please wait for 2.7.3 which will be out shortly. 


UPDATE: 2.7.3 is now in the Mission Planner


Functional Improvements over 2.7.1:

  • Fast waypoints (Jason) - if the turn angle between two waypoint the copter is less than 60 degrees it does not slow down
  • Navigation improvements and logging including switching to filtered location for distance calculations (jason)
  • Flip improvements - more aggressive and flexible flip code based on attitude instead of timing (Jason)
  • Improved camera control - you can now control any axis (roll, tilt, pan) with any rc channel.  it probably makes most sense that you will use 6 but others are possible too.  Unfortunately these changes required we change the set-up procedure so the mission planner gimbal set-up screen needs to be modified again.  Please refer to the AC_Camera wiki page for how to manually set-up the gimbal (Amilcar)
  • Flybar acro mode for TradHeli (Robert)
  • "Fast gains" - allows strong correction of attitude using accelerometers while the quad is stationary on the ground but relies more on gyros while flying (Tridge, Jason)
  • Baro filtering improvements (Tridge)


Bug Fixes:

  • DMP timing fix (Randy) - the MPU6000's dmp unit was inadvertantly turned on and caused timing delays in the main loop- xbee bricking issue (Craig / Tridge)
  • Dataflash fixes (Jason)
  • Engine ticking - was a combination of roll/pitch rate D term being too high and the dmp timing fix above (Randy, Emile)
  • Faster heading correction on start-up - resolves issue with simple mode getting incorrect heading if you took off very soon after start-up (Tridge)

Code Cleanup:

  • Increased maximum number parameters (Tridge)
  • Formatting changes to code (Pat)
  • Replaced "int" with "int16_t" everywhere (Randy)

As per usual PIDs are optimised for the 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.

There is still some question on whether the default Roll/Pitch Rate P (0.175) is high enough (it was 0.185 in 2.7.1) and also some people feel the Throttle Rate should be higher (currently 0.300 but some say 0.330 or even much higher would be better).

Please feel free to report issues you find in the discussion below and/or add them to the issues list.

Thanks and enjoy!

Views: 52720

Reply to This

Replies to This Discussion


After tuning my quad ( in the backyard by just changing rateP and stabP (rest on default). Althold worked well in the backyard. I did a test in the field. On althold my quad went 156m up in the air with a constant climbrate of 3m/s. LOL! I never dared to fly that high. At this hight i got slight jitter on my videoline so i switched back to stab mode and landed. I have the whole flight on my groundrecorder with minimosd overlay. The data in osd is correct, because after landing the groundhight is reported as 0m. Back home i adjusted throttle P and alt P from 0.3 down to 0.250. Perhaps my next field test will be better. I don't know what happened for sure but i suspect my mix for the flightmodes 3 position switch with another switch for RTH (set to 30m) inside my transmitter could have been the problem perhaps the rth switch was on and the other one on althold - so in the sum it produced a crazy signal so the apm20 didn't know that i wanted althold. In my opinion the problem is to 95% on my side, but i just wanted to report it because there is a slight chance of a software glitch as well. I will try to read out the log file as well.

So long

Kraut Rob

I don't know Den.

I read somewhere way back that to <correctly> compile arducopter, you should uncomment that line! Which I have always done(without problems).

ie APM_Config.h


It will compile with or without but I assumed that being commented out by default was meant for APM1 compilation.

Have also tried as an alternative, uncommenting this line:


I did this with the previous beta versions but that won't compile, some messed up code/syntax, never probed further...


I found the log and analyzed it. Like suspected during the whole flight Alt hold was NEVER ENGAGED - no wonder it didn't work then. The flightmode is recorded correctly because on another flight i can see me switching the flightmodes. So no problem with 2.7.3, just 100% my transmitter mixing fault.

So long

Kraut Rob

If I  edit  that line in config.pde




then wil  cause APM2 start crash.



Chris I've now noticed that after I've connected my APM and it starts to lag my CPU usage for MP sits at 50% and it doesnt even show the Google maps screen.  Only once I disconnect from the APM everything comes back to life.  Any thoughts perhaps?  Thanks

minomosd must to display actual flight mode

when assign modes - check ppm value must to be in the middle of range

my self-making 5-position digital switch

eagle schematic

arduino code


If you have a Dual Core CPU, and your MP is taking 50%, this shows that your MP is using 100% of one core.  Very strange.

Hi Ward.  Correctly noted. My one CPU is running at almost 100%.

Is there perhaps a way that I can go back to 1.2.9?  Everything worked fine with 1.2.9 for me...


I'm having loads of problems since the 2.7.3 upgrade and I think the gimbal code might be the source.  I have tried uploading the new version from two seperate machines and both seem to upload and verify ok.  After upload everything seems fine.  All my settings are obviously lost with the eeprom upgrade.  I even go so far as to factory reset to ensure default settings.
 I then recalibrate radio and enable my optional extra devices etc.  Everything is fine up to here.

However, the moment I enable CH6 either for camera pitch control from the gimbal config screen or for P value tuning from arducopter config screen my connection is lost and the com port starts repeatedly dropping in and out within windows. This gives me barely enough time to create a connection to perform another factory reset thus enabling me to re-establish a connection.  Its almost as if the APM is dropping the connection. I've tried this with both a USB and 3DR telemetry connection on two seperate laptops.

I'm running an APM2.0 on a 3DR Quad frame with sonar. Unfortunately since I can't subsequently reconnect without factory resetting, I have no logs.

Any ideas?

Many thanks,


try reload another firmware  as example plane 2.6 then erase eeprom and reset params from console and reload arducopter


Thank you very much for your extensive explanation and the cool hardwaresolution. I am using Flysky with er9x FW. My mixer seems to be setup correctly (hitting pwm values in the middle) and i haven't been able to reproduce the problem on the bench or in the backyard. I think i will delete my current mix and redo it. I don't know if the minimosd (connected with RX & TX) custom FW ( can "backfire" wrong settings to the apm2, because i've noticed the osd being sluggish with displaying the flightmodes. Seems unlikely.

Thank you

Kraut Rob

Thanks for the quick response.  I just tried your suggestion but still have the same problem.  The second I change the tilt 'Input Ch' on the camera gimbal page to RC6, I get the message "Serial connection has been lost" and I'm back to square one :-(

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service