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: 385198

Reply to This

Replies to This Discussion

 Just finish running autotune and I'd like to report that it works perfect for my quad! I think v3.1 now ready for it's official release.

Thanks to Randy, Leonard & members of Devteam!

Brian,

     Thanks for the link to Scott Berfield's blog.  I've added that link to the external leds and buzzer wiki page and maybe someone will transfer over the information to the wiki at some point.

     I'm 99% sure that the issue with your board is hardware related.  Maybe the solder joint on that led is broken.  I can't think of any software configuration issue that could lead to just that single led not working.

Ah, excellent.  There's a fairly big vibration dampening wiki page here which is the collection of many discussions on the forums.  I use 1/4" dubro foam but I hear moongel is better except that it breaks down when it gets hot.

The vibrations come from the motors and if you're using an 880kv motor and 3S battery (i.e. 12V) then the motors will spin at about 10,560rpm at full power which is 176hz (10560/60seconds).  the ArduCopter loops run at 100hz although the accelerometer collection runs at 1khz.

Ok, thanks for the report.  I'll have a look into that.  It's weird though because the mission planner can see the flight mode and they're listening to the same mavlink info.  We've made some unrelated changes to the GCS mavlink messages so perhaps something has gone wrong.

Anybody else tried -rc5 (or one of the earlier release candidates) with a minimOSD?

There's certainly reasons on both sides of this argument and many of the same points as above have been brought up on the drones-discuss list as well where I asked for feedback.  Personally I like them spinning (I didn't use to) but I'm leaning towards turning the feature off by default for the next release.  Mostly because historically that's how it's operated.  We can see how the community goes with it and consider again switching it on by default for AC3.2 release.

Now that I've started playing more with the Pixhawk one thing that I really appreciate is it's tone-alarm and it's LEDs.  That RGB LED actually works on the APM as well in AC3.1 and anybody can connect a piezo buzzer to the APM's A5 pin but not many do yet i think probably partially because 3DR doesn't sell them.

Thanks!  we've narrowed down on the issue.  It's this commit.  Rolling it back is easy but we want to investigate if there's another solution because this change saves about 3% of our CPU which we are horribly short of on the APM.  Ideally we would like to be able to sense failures and then slow down the bus so that those that have very low noise boards can take advantage of the higher speed.

@Detlef, 8Mhz is good because we need to pull multiple values from the accelerometers and gyros.  The faster we can get that data from the mpu6k chip into the main cpu the more time we have for other stuff.

Thank you Randy! I look forward to testing a solution. I'm anxious to try the autotune and other current features that others are bragging about! Looks like great stuff. BTW,any news on PixHawk availability?

Bruce.

I heard the Pixhawk was to be made available at the end of this month (i.e. now) but I think they're still at least 2 weeks away from opening the flood gates.  Of course anybody who ordered the "developer" IRIS has a pixhawk already but I think they have uncovered some niggling issues (as with any product roll-out) and I expect they will want to resolve all those before starting to sell them individually.  Let me qualify this by saying that I'm not really in the position to say so this is all my personal guess work.

Andre,

    Fair enough, I will add them all to the APM_Config.h file in a moment.

I'm sure it will be worth the wait.

OK --- I have seen this point regarding the spinning Armed props:

You should not be next to the machine when you Arm it. To Arm a vehicle should be a deliberate and thought out process with the deterministic decision to ARM. OK here! So, to have the machine propellers begin to slowly spin indicating that the machine is active is an EXCELLENT Safety Precaution. If you are scared about the propellers spinning you should not be Arming the vehicle. Nor should you be standing close to a vehicle when you Arm it. Why? Read the posts about the unexpected flips, rocketing into the air, props going full throttle, fly-aways, etc...

Another point in favor of the props spinning on Arming: As we will sometimes be among others and some who may not be aware of activities - If the props start to spin when we Arm - Everyone Will Know Something Is Alive! Except infants, toddlers and dumb dogs - most will move back instinctively from the moving props.

My vote is: Armed - Spinning Props.

For the Safety and the advancement of this activity we as a community need to do and place advertised Safety features and functions. This consciously shows the FAA and other on lookers that we are aware and working to make our activities/operations, machines and presence a safe one. We need our propellers spinning on an Armed vehicle. This feature should be implemented as 'ON' by default to have the propellers spin. Then, if one wishes to change their own settings disabling the safety feature and to disregard caution it will be their own decision, choice, action and liable risk. This is like Air Bags and Seat belts. Except, here no one is hurt. We are saving each other and there are no age restrictions for this safety.

Brian makes a great point on why to keep it as default. His statement reflects my opinion as well.

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