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

Reply to This

Replies to This Discussion

Some updates.

Here is short movie showing the issue:

* Mode is properly set to X, confirmed with console.

* ESC/motor are ok, confirmed with plugging directly to receiver.

* After switching ESC/motors from CH1 to CH2 to check if it's problem of 1st ESC or 1st CH on APM2 strange thing happen. The same motor is not spinning!

* Using CLI: setup, motors does nothing. It stays the same as on video above.

What could be wrong? After switching 2 esc/motors and the same motor is not spinning I could bet that ESC burned BUT.. it works like a charm after connecting directly to receiver. I'm out of ideas.

Any help will be much appreciated.

Hi! Have you tried to set pwm from 490 to 400HZ Missionplaner?

I just tried this. No changes.

Bill, I have simular problems. Tried several missions the last days. They allways exiting  with loiter and land before the last WP. Yesterday tried a 4 WP square. Stop was on WP three. Then I tried a mission with take off, one WP and RTL without problems. RTL after 3 or more WP never worked before. When I check WP with CLI, all WP with index look ok. Up to now, no idea what is going wrong or where I make a mistake in mission planning.

Flying, loiter, Althold and navigation (with APM2.0 GPS) is great with my 3DR stock quad


I think, that this problem is related to fast waypoints. Currently in AUTO mode, AC reads one WP ahead to calculate angle. I don't know yet where is the bug, but I'm checking...

You can use mono on Linux and I would suppose that it also works with mac

On linux you just run the exe file like "mono ArdupilotMega10.exe"

So I ran another mission with 20 WPs and the same issue, but since I know it ignores the last WP, I just made an extra one to compensate.

Other than that oddity the mission flies near perfectly, really fast, really smooth, really accurate.

Were you, or anyone else here, using the Auto Land feature?

I am having some issues with it at the moment and am interested if it just my settings or a general problem.

The hexa descends ok but then accelerates the decent in the last 5m or so, resulting in a hard landing and then bounces.

Jason's just checked in a bug fix for the premature mission exit bug and I've done a quick flight test and it does resolve the issue.


As a number of you above have noticed, this was causing missions to abort after the 2nd last way point was completed.


The fix will be out to everyone when we release 2.7.4 (release date TBD).  I suspect you can temporarily get around the problem by duplicating the last way point although i haven't actually tried that work around.


On behalf of the dev team, sorry! 


When a mission completes, what default mode does it go back to?

Is this the code that executes?


Line 204
static void exit_mission()


Great! Good to have a community that helps find bugs and developers that help solve them! Look forward to the bug fixes, in the meanwhile I'm just adding an extra waypoint at the end.

Randy ***Quote*** On behalf of the dev team, sorry!

No need to oppologise!

Wer'e just glad of both the direct communication with the dev team and the unending support...


Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service