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)
- 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)
- 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!
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.
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:
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.
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,
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:
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.
In the discharge zone: ArduCopter-2.7.4-Gamma.zip
Gamma release for testers only!
Improvements (over 2.7.4-Beta):
- improved stability patch to reduce "climb-on-yaw" problem
- rate controller targets moved to body frames (yaw control now works properly when copter is inverted)
- improved yaw control (less bounce)
- resolved SPI bus conflict with OpticalFlow sensor and DataFlash
- DMP works again by adding "#define DMP_ENABLED ENABLED" to APM_Config.h You can also log DMP vs DCM to the dataflash by adding "#define SECONDARY_DMP_ENABLED ENABLED"
- ACRO "Axis" mode enabled by default (now hold last attitude in acro mode by default)
Improvements (over 2.7.3):
- bug fix to resolve last waypoint being skipped.
- bug fix to resolve loss of altitude if alt hold is engaged before first GPS lock.
- thrust curve added to linearize pwm->thrust. Removes deadzone found above 90% throttle in most ESC/motors.
- Optical flow sensor enabled for APM2.5. Now automatically detects which SPI bus the sensor is on.
- more timing improvements (main loop is now tied to MPU6000s interrupt).
- expected GPS lag reduced from 1sec to 0.5sec for UBLOX.
- increased default Loiter Rate P to 5 (was 2.4), reduced Loiter Rate I to 0.04 (was 0.08).
- logging improvements (log I terms, dump all settings at head of dataflash log)
- GPS NMEA bug fix from Alexey Kozin
- code cleanup - removed INSTANT_PWM
Thanks Scott, that's interesting (and objective). Let us know how they compare when they're both up and flying?
2.7.4 beta is flying awesome so far. I tried Alt holt, loiter and RTL with success but is it normal that changing flight mode takes around one second? I don't like this behavior as changing back to stabilize must be fast if an auto mode is getting crazy. Also, worst of all, if I turn off the radio and failsafe is triggered, the copter will remain is stabilize for that second with motors off (quickly losing altitude) before entering RTL.
Is this an issue I should post in the issue section or is there a way already to trim this delay?
Did my first waypoint flight just the other day and it went very well.
Still having a problem with Loiter in that it is constantly making minor corrections that make the video too jerky to watch. In Stabilize or AltHold, I can make the quad hover in one spot perfectly without any jerky movements with minor movements of the sticks and the video is excellent. What settings should I be messing with to tune out the jerky movements in loiter? Loiter_Speed_P and Rate_Loiter_P?
If someone can give me a definitive answer, that would be GREAT! There's a lot of conflicting info on the pages. I'm sure someone has answered this (maybe more than once) but I can't find a search feature.