Warning #1: Compass calibration and reducing interference is far more important than with 2.9.1b
Warning #2: GPS glitches can cause sudden and aggressive position changes while in loiter mode. You may wish to reduce the Loiter PID P to 0.5 (from 1.0) to reduce aggressiveness (see image below of where this gain can be found in mission planner).
Warning #3: optical flow is not supported but will be back in the next release (AC-3.0.2 or AC-3.1.0).
Warning #4: loiter turns does not maintain altitude. This bug will be fixed in AC-3.0.2.
Warning #5: This release has only been lightly tested on Traditional Helicopters.
Improvements over 2.9.1b include:
WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions
How to upgrade:
1. Make sure you are using Mission Planner 1.2.59 or newer (get it here)
2. Click on the MissionPlanner's Hardware, Install Firmware screen. The version numbers should appear as "ArduCopter-3.0.1", then click the appropriate frame icon and it should upgrade as per usual.
3. Reduce the Loiter and Alt Hold PIDs if you have modified them from the defaults. The modified PID values for the 3DR frame can be seen in the image below.
Note: Nav parameters have been combined with Loiter so do not be concerned if you can't find them.
5. Try out the new version in stabilize mode first, then alt-hold, then loiter and finally RTL and Auto.
Numerous How-To videos are available:
Special Thanks to Marco, DaveC and the large number of testers on the pre-release thread who put their copters at risk during the extended testing period. Some of their videos can be found here, here, here, here, here and here. Thanks also to MichaelO for the MP changes required for this release.
All feedback welcome. Please put your questions, comments (good and bad!) below.
My setup is a TBS Frame, with RCtimer HP2212-1000KV motors, 20A Blueseries ESC with SimonK firmware, 4S 5000mah LIPO and 9x5x3 GWS propellers.
For vibration dampering, it's an home made sandwitch.
Attached, you'll find some pictures.
Could you tell what's strange in my logs ?
For information, I made maybe one minute flight with logs, to monitor vibrations, before disabling all log and launch Auto tune. I wanted to monitor the impact of motor balacing, before doing an auto tune.
Can you measure the motor locations and also measure as accurately as possible where your cg is. Also, how did you choose the location of your cg?
You'll find attached a picture with all dimensions. CG was calculated accorting to this manual : http://www.team-blacksheep.com/tbs-discovery-manual.pdf (page 30)
Because of the lake of space, the bottom of the APM is on the CG, not the position of the ACC / GYRO itself of the APM.
Maybe it could be nice to have a configurable parameter to tell the code where the CG of the frame is (X, Y and Z positions), regarding the position of ACC / GYRO of the APM, to correct some offset errors.
Actually the COG is at half the length of the red line. But I guess you are close enough.
Build you vehicle and calibrate the 'Trim'. By setting the 'trim' you are effectively adjusting for the CG of your vehicle. A trimmed vehicle will fly level until you change the CG by adding or removing items. Then, you 'trim' again.
No need for more configurations. They developers even promise this to be done almost automagically soon.
I think there's a little confusion, problem is not to stay level, problem is not to introduce movement errors with a rotation.
Rotation of your copter is done on the CG, so if your sensors aren't positionned exactly on CG, there's a movement errors introduced for every rotation.
The more your sensor (Gyro / Acc) are far from your CG, the bigger the result movement is for a rotation.
In that case, for example, if your copter rotate (only rotate) up, your sensor will tell you that your copter is rotating (same information) but it will also tell you your copter is moving up, which is wrong.
Maybe this error is not important, and maybe that's why there're no parameters to tell the distance of CG compare to the position of your Gyro/Acc sensors
MHA you are correct, however the grey line between the two half way points will also go through the half way point on the red line. So they are actually the same thing.
Airmamaf and Brian:
My concern with the position of the CG on a V frame is because the V frame is particularly susceptible to coupling between the roll, pitch, and yaw axis if the CG is in the wrong place.
By the looks of what Airmamaf has said here he has got everything spot on so we are looking for some other reason the tune has failed.
The other thing this could be is something that is not hard mounted, like the battery.
Finally the position of the APM sensors does not effect the roll, pitch and yaw measurement. You could place the apm on a solid stick 2m in front of the copter and not have a control problem in stabilize. This is because the rotation rate measurement is the same no matter how far the APM is from the CG. However, the acceleration measurement does change as we move the apm away from the CG. This is because if the sensor isn't precisely on the CG rotation of any type will result in a measured acceleration. Thankfully we don't need to be too fussy about this.
Brian, the trim really doesn't have anything to do with CG location. The trim is to do with the angle the copter is sitting in the air, and whether or not that produces a component of thrust in the X or Y direction. You want Zero X and Y thrust in a hover when it's trimmed out. The trim angle will not change if you move the CG around.
Leonard, I agree that it seems like the location of the APM seems to not matter much for Stabilizing, since ~99% of the AHRS solution comes from the gyros, not the accelerometers. There is of course some amount of error that would occur, but I'd guess it's several orders of magnitude lower than the error that occurs due to vibration.
However, if you did have the APM out on a long stick, this should affect Loiter? The aircraft would essentially be made to rotate around the APM, which would get pretty nasty. But for all realistic scenarios, this probably doesn't have any real effect.
I have wondered if the displacement on a typical helicopter installation is enough to cause problem. The displacement is typically on the order of several inches, which may start to become significant.
I don't see a THROTLE_IN_DEADBAND, where can I find that?
I did go through the advanced parameter list but it is not there (nor the DISARM_DELAY).
You'll find THROTTLE_IN_DEADBAND in Attitude.pde, and DISARM_DELAY in motors.pde
Hi David, could you tell me where is motors.pde. Thanks
Heading hold In Loiter.
As we all know, the position in loiter is fixed in space and the copter strongly attempts to get back to its original position when disturbed. However I have noticed that if its heading is disturbed there is no tendency to return to the original heading. There is a weak attempt to resist the yaw but then it is quite content to stay on the new heading. This may seem like an ‘I’ term function but I have tried adjusting many things to improve it but cant.
My gimbal, like most people’s is just 2 axis so I am relying on the copter to maintain an accurate heading while filming. The Loiter position holding is spectacularly good but the heading can get knocked off on a windy day.
Im still on the last ‘full’ release. 3.0.1?