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.
Guys, we should really bust this out into a new thread. It's a very interesting discussion, you both have some great ideas and data, and it's just going to get lost in the noise in thread. Pun intended. :)
This very much is a chicken or the egg discussion Michael. Are vibes creating thruster noise, or noise creating oscillation. I have no idea how to tell. We should really try to get Leonard in on this.
What I find interesting is your data seems to show that it is related to airspeed, instead of ground speed. It doesn't solve the chicken/egg question, but it is very interesting. It's clear that the vibrations go up a fair amount, but not as bad as it appears. If you look closely, you can see signal in that noise. There are high frequency vibes imposed on top of low frequency vibes.
I do not believe it's an algorithm problem. It's a physical effect. Either airflow causes flapping, which causes vibes, which creates noise on the alt-hold controller. Or, it's possible that at higher airspeeds, the props have more control-response than they do at low airflows. As such, they are overgained at high speeds when tuned to be critically damped at low speeds.
I know for sure this is a factor with helis. Just never seen evidence of it with quads. It's theoretically sound, but I don't know what speed you would need to cause the problem.
Rob, if you want to start a discussion go for it, and I'll repost my data there (or you can use it however you want). Just for the sake of clarity, I was flying on a calm day. So GS ~ AS. The flapping phenomenon is very easily understood if you consider prop blades as wings, which can have a variable angle of attack. With any crosswind, the AOA of each prop blade becomes sinusoidal... lift is proportional to AOA... 2+2 = sinusoidal lift, and we get a lot of vibes.
I don't mind posting to a new thread.
I'd like to trust your theory that this is induced by vibrations that in turn are caused by aerodynamic effects. But shouldn't I see the same vibrations flying manually? Have a look at my auto2 jpg. As soon as I switch to stabilize (36.2) the z acc log returns to normal values. At this point the quad had the same speed and keep in mind also the same motor/prop rpm. So if flapping had caused this there would have been no immediate change of z acc at the switching point.
And you are right, this should be fixable with adjusting gains. And I indeed saw a change with lowering the PID's. In fact increasing PID's makes the system even more responsive to disturbances. But it seems that I can not lower them below a set limit. I am not deep enough in the software to find if the gains have fixed low limits.
What I would like to try as a quick and dirty trial is some smoothing / low pass filtering on the motor outputs. I am convinced that the SimonK ESC's have an in this case undesired effect on the sensitivity of the controller. I guess what I am saying is that if the control loop works for standard ESC's it might be too sensitive for SimonK's. Makes sense?
Oh, and Rob. If you get in contact with Leonard please ask him what he did to fix the violent twitches when switching to Loiter mode in 3.0. I was the guy that sent him logs and he responded that he found a problem when switching to Loiter with SimonK ESC's.
Please post your log file
Just want to let you know I am reading this discussion. It may be because we can't run the alt hold controller fast enough so it's output becomes choppy under rough conditions. It's running at 40hz max on the APM. We could try boosting that up to 100hz on the pixhawk to see if that helps. In general we're going to try increasing the rates of everything by 2 to 4x on the pixhawk.
ah, good, thanks for the feedback.
ok sure. Actually -rc4 will be out within a week so I'll include it by default in that build.
It's smoother in -rc3 than it was in AC3.0.1 but we will slow it down a bit more for -rc4. I haven't made the change yet but I will for -rc4.
AC3.1-rc3 is now out in the mission planner's Beta Firmwares and includes improvements for the APM2 including GPS Glitch protection and a first attempt at an auto-tuner. It is becoming nearly impossible to add new features to the APM due to CPU and Flash (i.e. program size) constraints so after AC3.1 any new features for the APM2 will need to replace existing (less used) features. ArduCopter on the Pixhawk board is where you're going to continue to see real growth and improvements.
hmm..that doesn't sound good! 60 waypoints should not be a problem, we have space for somewhere around 120. Can you easily reproduce the issue? If yes, maybe you could give the precise order of things you do to recreate it including the mission file you're using? Feel free to send it to me via DIYDrones PM or email me at rmackay9 @ yahoo . com
Yes, it's fairly high on my to-do list. I think that'll go in for -rc4.
Yes, after Rob Lefebvre's post re his octo issues we've been digging into the APM performance in more detail and it's quite clear that the first control to be lost when the CPU load gets bad is altitude hold. We've found some efficiency gains and we're also going to reprioritise the alt hold controller higher in the scheduler so that when things get tight another feature will slow down instead. In particular dataflash logging seems like a good choice to be slowed down if necessary.