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.
I'm very, very thankful for that one Randy, as well as autotune. ;)
Randy, I am with 3.0.1 at apm2.5 and one thing I noticed was, when it lost the params I read the waypoints and it restored the last waypoints I sent which was my error, it was about 60WP, could that be the cause? Is there a way to check in the CLI if there is an eprom error? Will pixhawk tolerate better this kind of problem due it's memory size?
Thanks Randy, have you fixed that on RC4?
Happy now with 81
Randy and guys,
As there are some interpretations on what I am describing let me clarify. I am describing a problem in all altitude holding modes (e.g. ALTHOLD, LOITER). The problem is near aggressive over-/undershooting of the motors in altitude holding modes with external disturbances.The problem can not be observed in calm conditions.
In STAB mode the altitude is directly controlled by the pilot, no controller running. Just roll and pitch are stabilized by a PID controller. Tuning both the roll and pitch controller works very good meaning the signal processing and parameter range takes good care of the system dynamics including the dynamics of the actuators (prop rpm). In altitude hold one additional controller is activated. Instead of manual (visual) altitude control the system takes authority. All I am saying and seeing is the the althold controller is not modeled well enough to take care of the vertical system dynamics. It is either the sensor processing, the parameter range of the controller or the modelling of the actuator response that seems to be off.
I do not think this is vibration related (see picture for my quad in steady Stab hover). It is in my opinion maybe wrong assumptions about the system dynamics. Observe your stick reactions. Even in gusty conditions you react relatively slow and with minimal stick inputs to control altitude. It doesn't take a lot to maintain altitude. Maybe some sensor (accelerometer) processing/filtering or actuator processing/filtering to adjust time constants of the control loop might be necessary.
Hope that makes sense.
Actually, I wasn't actually suggesting this is the cause of MHA's problems. Just a general statement about aerodynamic vibrations, and the fact that it's not OK to hard mount the IMU, and balance the heck out of your motors to show no vibrations in a hover.
MHA's problems...I'm wondering if it's the processor lagging. That's what it felt like to me.
MHA, can you tell us what are you running? Quad, hex, octo. And what features are you using when you have the problem?
IDK, watching MHA's video that high frequency surging definitely sounded like vibes to me. That is exactly what my 450 was doing before I fixed it with foam/weight.
R_Lefevre and Kevin_B,
This is definitely not induced by vibrations. Please see my hover acc diagram in vib.jpg. My copter is a TBS Discovery quad. Again, if I fly the same maneuvers manually in Stabilize there is no motor oscillations at all.
Let me explain my problem with some logs. This is all from a simple auto mission. Look at auto5.jpg to understand the simple mission. Take off prior to 33.0. Hover for a few seconds above take off point. At 34.3 turn 90 degrees and fly about 100-200ft to WP1 climbing to a slightly higher target altitude. At 35.3 turn 180 degree and come back. At 36.3 I abort due to the increasing motor oscillations. The first leg is downwind. The way back into gusty wind.
Now look at auto1-4. It all starts at 35.3 when the copter turns into the wind. Auto3 shows that the actual altitude is following the desired altitude quite good. Auto2 shows the acc levels. All good up to the point when the copter has turned into the wind and disturbances happen. Auto1 really shows what is going on. Look at THR_OUT. It is heavily oscillating. And again, I don't believe this is due to the high z acc. Z acc just shows that the SimonK ESC's on a 900kv 4s setup with 10x5 props is capable of quite high vertical dynamics.
It is still my belief that the control loop is off and "overreacting". This happens btw with all throttle PID's set to their lowest limits too.
OK Rob, this should make it clear as day...
This was moongel with rubberbands, which obviously didn't work well. This was my first step to control vibes. Before I did the moongel thing, vibes were so bad it wouldn't even work hovering. Moongel made alt hold behave during hover, but as the log shows that broke down bad as soon as I sped things up a little. After some frustration on the vibe road, I got out the shotgun and killed it with my foam/weight approach. I was going to share a beautiful graph of vibes vs speed with this setup, but MP updated when I made that previous pic, closed it, and now it keeps "program has stopped working" upon repening, even after redownloading it. ARGH!!! LOL
Anyways I hope this serves to end all the the prop balancing panacea. The debate has already wasted way too many hours of development. :P
IDK Michael, looking at those graphs you just posted, it sure does appear to be following vibes, which actually get very bad during parts of the flight. What else would make your ACC go crazy like that? If it looks like a duck, quacks like a duck...
This could be a hen or egg discussion. My reasoning for not vibration related is that it is flying very smooth in Stabilize (controlling altitude manually). And that you only see the z axis increasing. Believe me, this has nothing to do with vibrations. Do a little experiment if you dare. Turn up the rate_D parameter of roll and pitch axes. At some point it will start vibrating with a high frequency. Now look at the x and y acc values. You will find that it now looks as if vibrations are causing the oscillations. You know better because you only turned up rate_D. So what I am saying is that a control loop with a very dynamic actuator can and will if not tuned right induce oscillations that can be misinterpreted as frame vibrations. And it is also a fact that a closed loop system can be (semi)stable in a steady state and are only waiting for external triggers to start oscillating when parameters, especially P is borderline.
This is a control loop problem!
Check out the graph I posted above... mostly z vibes... flew awesome in stab mode... absolutely horrible alt hold performance. I fixed vibes, and suddenly alt hold was excellent.
I kinda understand control loops, natural frequency, step response, and resonance. It's not my specialty, but I know enough to understand how you came up with your theory. A while back I did that high rate_D experiment (a result of tuning, not vibe analysis... coincidentally that has the same fast surging sound as alt hold vibes). It appeared more like a sine wave than random noise. I think that is because we measure ACC at 50hz sample rate and motors can't change RPM fast enough to appear like vibes (random noise), but I could be wrong.
Now assuming it was loop resonance. From my understanding of control theory, that can be fixed by simply changing gains, correct?
I think I have said all I can. I wish you good luck fixing your problem.