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.
yes, really great video!
What're you setting WP in planner? Can are you show me please?
Josh, I am referring to the error being effectively reset to zero on the stabilize (for want of a better term) component of ACRO. This maybe causing what you see. There is nothing you can do about this if this is causing the problem. I would need to see a flash log with motors enabled where you attempt to keep everything constant other than the switch the mode before I could be confident.
As for the I2C thing I don't know about any I2C code to read the SimonK esc functionality. The most obvious use would be detecting the loss of a motor.
We've made ArduCopter 3.1-rc5 available through the mission planner's Beta Firmwares link (or it should appear there in 30min or so after this post). The source code can be found here. Improvements over 3.1-rc4 include:
1) Pixhawk USB reliability improvements
2) AutoTune changes:
a) enabled by default (sorry, it was meant to be enabled in -rc4)
b) status output to GCS (messages will appear on the HUD)
c) use 2 pos switch only
3) ch7/ch8 LAND
4) Tricopter stability patch improvements [thanks to texlan]
5) safety improvements:
a) slower speed up of motors after arming
b) pre-arm check that copter is moving less than 50cm/s if arming in Loiter or fence enabled
6) bug fix to loading missions while copter is armed.
All feedback welcome. I think this version is quite close to what will become the official AC3.1 release.
Re the I2C ESCs...I've heard very mixed reports on trying to use I2C for critical communication like with ESCs. That's not based on personal experience though.
I think we'd be happy to try and support alternative communciation methods with the ESCs especially if it allows two way communication. I think longer term we want to support the AutoQuad ESC32 escs (or compatible).
I will test it. Thank you Randy
Kevin, the Acceleration parameter I am thinking of would be very close to the maximum acceleration of the copter. Currently if we throw the sticks all the way over to do a roll and then let go of the sticks to command it to stop. It is impossible for the copter to stop that quickly so a little error is created that causes the copter to bounce back a little. Even though people may not even realize this is happening they may be able to feel that it isn't quiet what they want.
In any case we are so close at the moment any changes we make will be very subtle.
Indeed this does look better but I suspect you still have some movement based on how much the Rate P is reduced in the tune. I suspect that with a more solid mount/frame you would be getting closer to your manual values. This is just a guess though.
As for the Gain scheduling this is something we could do but I have not seen any need to do it yet. My general PID testing includes high and low throttle roll and pitch flicks as the copter climbs and descends and I have not seen a problem. This isn't to say that it would not be an improvement, however, we need to be sure we are doing it in the right way based on the physics of the system and that the improvement justifies the added complexity and cpu cycles.
Randy and I are working through a rewrite of the entire control code that will tidy up a few more issues that are hard to address under the current code. Once that is done we can start looking at things like this.
I agree Kevin,
I think Autotune should only be done on a copter that is tuned well enough to fly safely and I would put Alt_Hold working as part basic flight.
I am thinking of doing a version that will run from Loiter that will ensure that the copter is stationary before doing the next test. This will give better results in calm conditions but won't work as well in windy conditions.
We will see what feedback we get after the 3.1 release.
I am glad it worked well for you mate!
anyone managed to look at this?
2hrs or so,still no .rc5