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

Reply to This

Replies to This Discussion

Matt, I agree with you.

Distance is about the only way to reduce interference fro the rest of the electronics

Maybe a long cabled, mag-on-a-stick approach might be a way forward... sound familiar?

Dave, the problem was it was missing a "wrap360" command.  It's a bit unclear exactly what this would do, I can't quite follow the math without spending a lot of time on it, but it could explain your problem.  I think it would be particularly bad as you passed North in either direction.

Find a local Ham Radio club and inquire if anyone has access to a UHF Spectrum Analyzer.

Well, I just took one for the team. :(

I was testing the 2.7.4 Epsilon, really thrashing it pretty hard in Stabilize mode.  Fast Forward with full simultaneous roll and yaw inputs.  It actually was doing pretty amazing.  Turning on a dime, literally.  Wish I had video.

But I guess I was flying too hard, one of the propellers exploded and it came down fast upside-down on concrete , smashed all the electronics, and at least two motors.

Sorry to hear that :-( 

that kind of crash is never nice.

Yeah, it's a bummer.  That was my test rig.

I really have to say though, with the earth to body frame rotations between the stabilize and rate controllers, flying aggressively in stabilize mode is completely transformed.  I always thought that the softness you feel is just... it's all this quad could do.  But I think it's actually because the rate controllers were fighting eachother because there were all kinds of cross-axis conflicts going on. It eventually got to where you were pointing it, but now it's EXACT.  It's like the difference between doing aerobatics with a Piper Cub vs. a Super Decathlon.

I'm going to have to find better props.  Actually, I had some APC's, but didn't put them on yet.

Hi Den,

     You should leave all that stuff commented out but FYI, here's what they control:

      #define MAG_ORIENTATION AP_COMPASS_COMPONENTS_DOWN_PINS_FORWARD  allows you to orientate your compass differently than the standard..only useful if you're using an external compass.

      #define DMP_ENABLED ENABLED  means that it will use the MPU6000's internal attitude estimation instead of DCM.  The results are pretty much identical in the limited testing that we've done.

      #define SECONDARY_DMP_ENABLED ENABLED will enable the MPU6000 but only in the background.  It will also dump the comparison of DCM vs DMP to the dataflash logs.

      #define INERTIAL_NAV ENABLED this is a work in progress and you definitely should not try to fly it.

      #define ACCEL_ALT_HOLD 0  another attempt at using accels for alt hold.  a work in progress.

      #define LOGGING_ENABLED DISABLED this allows you to turn off logging to the dataflash.  This use to be used by peopel to get the code down to the size so that it would fit on the ancient 1280.  It doesn't fit anymore though even with this.


So what kind of props does Warthox use? :evilgrin:

Uh... Thank you?

Kind of looks like my hex after one of my "learning" flights, but I bent an arm also.

Ugh - that sucks. Sorry man!

Flew both the MediaTek and the UBlox today - same location and mission, each unit mounted exactly the same - on velcro on top of a CD cover about 1 1/2" up from the APM and off to the side a bit. This is totally from observation, not measurement, but with the UBlox, it seemed like the quad flew more smoothly. Not sure why that would be. The MediaTek picked up 10 satellites and had an HDOP of 0.9 and held position very well in Loiter. The UBlox showed 8 satellites and an HDOP of 1.8 but seemed to hold position equally well. A simple 5 point diamond pattern mission with RTL and Land worked pretty much perfectly with both. In each case landing quite close to the home point. So, really, other than what may have been my imagination in thinking one was smoother than the other, they both worked quite well. I do suspect that the UBlox might be a little more succeptible to RF noise - and my quad is far from cleanly wired. I am going to experiment with putting the GPS further away and higher up from the main electronics to see what happens.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service