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

Reply to This

Replies to This Discussion

Hi Peter, I might as got way to many props but not got the weather!!!

hello,

 Has anyone got the camera gimbal to work on anything but channels 10,and 11? I want to use 7, and 8 to take advantage of the extra speed available on these channels, but have not been able to get it to work. Using apm 2.

  thanks tristan

I often fly my quad with MTK GPS directly under some 500kV power lines. I have my GPS mounted on a proper backplane and I always get 14-15 sats (never higher than 15, is it a limitation?) according to the logs, and always 10-12 indoors. DIY battery (couldn't use jDrones one because of optimum groundplane spacing) and re-acquisition time is 2 blue LED flashes, however long that is. I power the MTK off whatever power source the APM (2.5) input side uses, which is a dedicated ESC BEC for now.

Am intending to be responding to person talking about noise with MTK...

Flew v2.7.4-Gamma briefly this morning, all seems well BUT my Loiter twitches are still there, I made a video to try demonstrate:

Mediatek GPS? Yes, i know...

I just ordered a UBLOX to replace the MTK on my quad, but now Im wondering.  Will the UBLOX also need replacement in the future if it is no longer good enough or not?  Thnx,

Yes Mediatek, but they've only been apparent since v2.7.1, in v2.7.0 there were no twitches in Loiter with the Mediatek.

Leonard Hall found a small bug with his new stabilize yaw controller so that bug fix has been incorporated and a new zip (2.7.4-Delta) is now in the downloads area.

By the way, not sure if people noticed but there's this item in the release notes:

Rate controller targets moved to body frames (yaw control now works properly when copter is inverted)

 

For me, I think this is super cool..what it means is that ArduCopter now uses the combination of props to best get it to the attitude that you're asking for.    This change is most obvious when you're inverted because previous the yaw control would have been completely backwards so if you got your copter up-side-down while in stabilize mode..besides trying to right itself it would also try and turn 180degrees.

This should also be useful for people wanting to make one of those copters that transitions smoothly from a vtol to a horizontal flying vehicle.  There would still be more changes required to support that sort of vehicle but this is probably the biggest and will help regular copters in some situations as well.

 

These are slightly ugly videos but they demonstrate the difference.  1st before the fix:

And here's after the fix:

 

 

The other big fix in 2.7.4 is the improvement in the stability patch for quads, octas, hexas.  This was a combination of ideas from Leonard Hall, Robert Lefebvre and I.

You can see the code here but in any case, the way it works is roll, pitch and a minimal yaw are of highest priority followed by throttle and lastly yaw.  So first we apply roll, pitch, throttle and a minimal yaw and then check if this causes any of the motors to go above their max or below their min, if 'yes' then we adjust the throttle up or down appropriately.  After that we check how much additional room we'vegot before the motors hit their limits and use it to provide any additional yaw control the pilot's asked for.  The difference is dramatic for people with overpowered copters..because.the 'climb-on-yaw' problem should be mostly gone for them....because what was happening was that with a strong yaw command, 2 motors would speed up a lot but the other two couldn't slow down because they were hitting their lower limits...so overall the total motor output was raised and the copter would rise.

This was causing havoc for me in auto missions because whenever it hit a waypoint it would climb 5m into the air as it spun towards the next waypoint.  In a demo I did yesterday for 100+ people there was none of that.  The copter just flew back and forth between the waypoints with no unexpected alt changes.

Nice. Looking forward to it.

Thanks bro! :-)
Today stress test...

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service