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.
It is already implemented in the beta versions
Ah! See, I just bought some new square aluminum tube to rebuild my Octo, and I noticed that the aluminum twisted as it was extruded! Not cool.
I'll get you a log today Leonard. I'm travelling tonight through next weekend, but will get you that log as well as an Autotune log with -rc5 in the next little bit to review.
Good to know Randy, thanks. I saw a test recently on youtube (I thought it may have been yours?) where the terminal was displaying feedback from the ESCs and the FC was using that feedback to determine motor/esc failure, and can see the vision here that if this works, it'll take not only failure-handling, but autotune and stability and everything else with the platform to a whole new place. Pretty exciting potential!
Ok Leonard, Successfully got Autotune to run, and have attached that dataflash log as well as the motor log. The Autotune log is +IMU, as well.
First attempt at Autotune actually stalled, so I landed, disarmed, re-armed, re-positioned, and re-engaged, and it completed successfully. Having the message on the vhud of MP was awesome! I've flown it around a bit and I do like it and I think it solved some of the problems I was having. I knew my tuning needed work but I didn't want to spend too much time on it because I wanted let Autotune do its magic.
Here are the results, I really hope this formats correctly:
Interesting changes, but so far I'm happy with them. I'm hoping I can go make a quick FPV run later but time is tight with my flight out this evening, so we'll see.
Attached are the two logs as well, for both Autotune (+IMU) and ACRO vs STAB (+MOTORS). The condition is still present with the current MP version of -rc5 and I switched back and forth 3 times for a total of 6 mode changes (maybe 7 but I think it was 6)
No. especially if sold for a frame commercially. For sure it gets worse with bigger props but...
I have had a problem with the quad performing in Alt-hold under sonar.
The quad seems to drift within a zone of about 2m and then suddenly overreacts as it tries to correct. This progresses into an uncontrolled oscillation.
I have tried changing the PI parameters on THR_RATE on ALTITUDE.
It looks to me like there is logic error/bug in the code. I say this very tentatively as I am not an expert at these things.
This is my take on what is happening:
get_throttle_surface_tracking(pilot_climb_rate) is called. pilot_climb_rate is the value from the Tx stick.
Why do we go through 2 iterations of calculating a distance error, does the second iteration not nullify the first calculation based on the sonar readings?
My suggestion for terrain following would be to:
Am I stupid?
Hi Guys. I'm hoping someone here can help me out. I just had a crash today using arducopter 3.0.1. I was flying in loiter, then when I switched to stabilise all motors stopped and the quad crashed. I can see from the logs that my throttle input was about 50% however throttle out decreased to almost zero when I switched to stabilise mode.
Logs and more info is available here: http://diydrones.com/forum/topics/crash-switch-to-stabilise-cut-all... .
Here is throttle in and out. Any help will be greatly appreciated:)!
Have a great day:)!
Well after so many years of tinkering it will be my first bug find. I seriously thought it couldn't be in the code. I even had a battery cable (+) that got hit by a propeller and cut through about half of the wires. I continued using it since I'm under the amp draws anyway but then suspected that was it so repaired it. Then I saw all my batteries doing it so started looking else were on the wiring. It all seems good.
I'm using 2 receivers and a repeater. ezUHF on the copter, connected via ppm. It's Tx is connected to the repeater that is connected to my 9ch spektrum rx for my JR9ch. This way the ezUHF isnt' hanging off the Tx and the ezUHF Tx can be put high up on a pole. I have the same setup for other copters like my octo and planes and haven't seen this so I don't suspect it's a problem.
I will do the reset and post back. I just did 3 flights now and didn't see the problem at all. It's like that sometimes coming in groups and then not doing it for a few flights.
The reason for this is the delay in the measurement used for alt hold is very small compared to the sonar. So we can make very accurate and fast controller based on the altitude but we can only make a very soft and slow controller based on the sonar.
So we look at the sonar error and then use that to do a slow control of the altitude but then use the measured altitude to control the actual height. This lets us get the most out of the controller.
So if you have a good Alt Hold and a poor terrain following then the sonar gain is the problem, not the Alt Hold gains.
Finally the velocity term you said we didn't need. You are right we don't but having it allows us to react much faster. This technique is known as feed forward.
Yeh, this is a strange one. Had Randy and I scratching our heads for about 2 hours with no luck!