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.
Some smooth cinematic video on 3.1 rc7
Philosophically speaking, we should not use a projected future stopping point at all because it's like foreseeing the future by iterating a crippled algorithm.
Instead a good strategy for reaching desired velocity would be "Always accelerate/decelerate with WPNAV_ACCEL then accept newly reached position".
And one more comment: The deceleration of 5m/s^2 is caused not by pure drag but from horizontal component of engine thrust.
Thanks Dragu - You are fully right with the idea for short term actions based on a target velocity. The stop point is attained through a fluid medium and requires projection points in the distance not immediate. So when within 10 meters or ? the actions should be acceleration/deceleration calcs based on desired point. But, as you get closer to the desired point 5m(?), relative to current velocity, the aggressiveness of the accel/decell must be relaxed and the stop point become a specific hovering velocity not accel/decel to a hard waypoint.
This ideal would help with their spline programming also. A smooth fluid flight as the goal over a jerky angular flight.
Hi Randy & Developers around the world,
Can we work now for battery efficiency? I know some of you are skeptical, but I believe there are a lot of brilliant minds here!
There are strings in the forum addressing long flight, building battery packs and carrying heavier payloads. Do you have an idea about battery efficiency?
I understand that the APM does its processing using very little power. The motors only use what they require for the machines to fly. What did you have in mind? How would the developers of the APM software address battery efficiency. The APM does not draw much power from my limited understanding.
There are other strings in the forum in which the guys are building and re-building motors. Also strings regarding design and building other ESCs. These use the power. Have you read any of those to help?
Where would the programmers be able to change battery efficiency for the machines? Insight - currently our vehicles are not like our lousy cell phones using all the battery through turning on a lot of garbage applictions or waste time trying to connect to non-existent resources. Our machines are on actively trying to fly. If you turn off resources the things drop and do not perform.
My BarAlt seems very noisy to me. Is this something to do with 3.1-rc7 or is that I am getting too much prop wash? I also noticed that the foam (that protects the Barometer) inside my 1 year APM 2.5 is not as flexible and a little flattened as when it was new. I moved the AMP 2.5 further to the back of my Hex recently instead of it being centered. My flight was fine and Alt-hold was fine. But I am still concerned. What do you think?
The AC platform is performing stuff that you'd have to pump alot of $$ into a DJI platform to get close comparing it to.
Finances aside, the bottleneck here is the aged 8-bit 16 MHz processor. Shortcomings that the Pixhawk platform will solve, soon(tm).
As for flight efficiency, yes, you can gain some percentages using a custom motor/prop combo, but a real increase will only come with a technology leap in either storage or production of energy.
Does this mean that I have to change the props direction on my Y6 to upgrade to the new RC8?
No, both prop configurations will be supported.
Thanks to those who submitted videos, in the end I had a hard time putting it together into a sexy release video so Marco was kind enough to create one. I've added links to your videos at the bottom of the release discussion and please PM me if I've missed one that you'd like included.
Thanks again for all the testing you all did, putting your copters at risk in the process. I'm sure it's contributed massively to making it a good release.
By the way, we're going to push out AC3.2-dev later today. This release candidate is a special release mostly for the people who will be receiving the Pixhawk 2.4 boards in the next couple of weeks and has "dual sensor support" including fail-over to the backup accels, gyros and compass. The Pixhawk hardware people want this available so they can do more evaluation of the ST accels/gyros vs the MPU6k.