ArduCopter 3.0.1 has been released and is now available in the Mission Planner, firmware.diydrones.com, GitHub and the new Downloads Area.

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:

  • Inertial Navigation for Loiter and Auto meaning much more accurate control (Randy,Leonard,JonathanC)
  • 3D navigation controller follows straight lines in all dimensions between waypoints (Leonard,Randy)

         WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions

  • "compassmot" to compensate for interference on compass from the pdb, motors, ESCs and battery.  (Randy,JonathanC) (Set-up video here)
  • Safety improvements:
    • simple Tin Can shaped Geo Fence
    • pre-arm checks to ensure all calibration has been performed before arming (can be disabled by setting ARMING_CHECK to zero).  (video description here)
    • GPS failsafe - switches to LAND if GPS is lost for 5 seconds
    • stability patch improvements to stop rapid climbs in very overpowered or overtuned copters
  • Circle mode improvements including "panorama" when CIRCLE_RADIUS set to zero (Randy,Leonard)
  • SONAR_GAIN parameter added to allow better tuning of sonar surface tracking
  • CH8 auxiliary switch (same features as CH7)
  • works on PX4 (some minor features still not available) (Tridge,PatH)

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.

4. Although not directly related to this release, if you purchased an APM prior to March of 2013, update your PPM encoder to the latest firmware (instructions here).

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 MarcoDaveC 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 hereherehereherehere 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.

Views: 385226

Reply to This

Replies to This Discussion

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!

@ Jay,

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.

Regards,

Brian.

The shortest path to meaningful efficiency gain is lower weight airframes and larger slower spinning props. You can do this without any changes to the code. There are great threads on these.

To give you a handle on the impact of weight savings alone, my "bare frame" 550 will hover around 15 minutes on 3s 4400. Carrying my stabilized gimbal and camera, homing device etc. flight time drops to around 8 minutes.

You can soften tuning to save a few percent but it's less than you'd think based on my experience.

As for priorities I'd like to see continued focus on flight performance. There have been huge gains here in the last year and I think there is still opportunity until APM is " better" smoother / better loiter / better alt hold etc. than wookong naza etc.

Hello all,

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?

Thanks.

Attachments:

Steve.

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?

Thanks

No, both prop configurations will be supported.

Ok AC3.1 is released!

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.

Which is the default?

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service