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

Reply to This

Replies to This Discussion

which board are you using APM1 or APM2?  APM1needs to be wired up properly for it to work so has this been checked?


Not sure if this was a reply to my YAW post, but just in case: using APM1 and did not wire something specifically.


I've been looking at the metal work extensively and have moved the APM slightly further away from the ESC's and shortened all the wiring between ESC's and motors (removed a total of 50grams of wiring!).


Have not had a chance to fly with these changes yet due to bad weather over here (Maryland, USA).



I use bigger props on top on my Y6, and it seems to work better. That is 11x.4.5 top and 10x4.5 bottom. Has anyone tried it??

I justed printed it off, have not read it yet. That being said: I see no problems with my X8 the way it is. Using 880kV and APC 11x47 props.


     ahrs.roll_sensor (for the angle in degrees * 100) or just ahrs.roll for the angle as a floating point number.

     the best way to find the mapping is to look in the Parameters.pde file.  You'll see the mavlink name in quotes (like "SONAR_TYPE") and the to the left of it the variable name in arducopter (i.e. sonar_type).

     hope that helps.


     Maybe the RC10_FUNCTION and RC11_FUNCTION parameters are still set to 7 and 8?  Could you try making them zero and then assigning other channels's function to 7 and 8?  i.e. RC7_FUNCTION = 7, RC8_FUNCTION=8.

     It may be that we have a small issue in the mission planner where it's not clearing out the function properly..let's see what you find and if that's the case we can ask Michael Oborne to fix it.


    What do you mean by simple mode not getting intialised?  is it that you take off and when you change to simple mode the direction is all wrong?  i.e. pitch isn't forward, roll isn't left/right?

     On the APM2.5, the compass is on the main board instead of on the daughter board.  That puts it a little closer to the other electronics but it's also about a 1/2cm closer to your frame, batteries, escs.

     If you take off your props and fire up your engines, do you see the heading change a lot in the HUD?

     Basically what I'm trying to determine it that the compass heading is off or is it some kind of software problem.  I've acutally looked a lot at trying to find a software problem involving simple mode but I haven't found one (yet).



I initialize plain stabilize without simple mode and when pressing forward takes it forward to the orientation of the to front blades but when I enable simple mode thru channel 5 (channel 7 is do nothing) it stil does presisely the same, forward is orientated to where the 2 front blades. So when I turn the quad 180 towards me the quad will move towards me when pressing forward not the other way from where I have set my quad to simple mode, i have 2 apm 2.5's and it does this with both of them but the apm 2.0 it works. 




Here is where I posted videos of what I am talking about.

O one more thing you can load my logs into the mission planner and press play, you will see what the magnometer is doing on the HUD right before the quad fell out of the sky.

Thanks John, good info. 

@Dani, could you explain your reasoning there? Isn't what you've done the opposite of what we think to be the best, you are giving the top motors more thrust, leaving the bottoms ones to deal with even more messed up air.

Aren't the bottom ones supposed to go faster/ deliver a bit more oomph, that the top ones? I've also read that increasing the pitch of the bottoms ones can help, although I'd rather just stick to one type of prop per airframe, i could however be convinced otherwise.

Anyway once the fix is made i will experiment, check this for a scary looking beast

It was fun wiring that up :)

Not looked properly into this yet, sorry, not much time atm, but just to rule something daft out...

As i understand it simple mode does not work inside 10m from home point. That's not the prob is it?

Apologies if this had been covered....

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

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service