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

Reply to This

Replies to This Discussion

Hello, just tested it on my quad. I've got e very solid loiter even in mild wing. Rock solid not moving. But when I flicked the switch to guided mode it just tilted forward, sidewards and then it won't stay on the same place like in loiter. I believe guided is like loiter except that you can do the point and click waypoints.

Any parameters I should adjust? And many thanks to the developers. I was really impressed with my loiter!!

Thank you Randy.

Elvin,

     I haven't used guided all that much myself but underneath it uses the same position controller as loiter so it should have similar performance.  Maybe provide a tlog and/or dataflash log.

Palo,

     the vibration levels in your logs are excellent.  Very well done.

     So the issue is you have some very very bad barometer noise.  There are spikes where it's jumping to 300m so the copter will incorrectly think it's climbing and will drop like a stone.  The APM1 baro is not as good as the APM2.x (or PX4's) but it shouldn't be this bad.  You have it covered with a blob of foam?  Light can also affect it although I've never heard of it causing jumps as high as what we see here - i suspect (and hope) it's the lack of foam on your set-up because that's easy to fix.

     The other possibility is I've heard some complaints about APM1 not working well with AC3.0.1 and I've been meaning to test it for 2weeks now but just haven't been able to find the time.

     I see you're on 3.0.0 still instead of 3.0.1.  There's no real reason not to upgrade and I'd highly recommend upgrading if you're going to turn on the failsafe especially the Fence as there was a bad bug in the Fence code in 3.0.0 if you lost GPS.

     you might want to turn off some logging.  Especially the MOT message which is high frequency and it along with IMU can cause performance problems.  best to turn them both off if you don't need them.

I don't 100% understand the request but in AC3.1 there is more checking about whether the copter has a good GPS and can enter RTL.  So in AC3.1 if it can't enter RTL it will always LAND.

Thanks for having a look Randy. I appreciate your perspective. The flight prior and two flights subsequent were just fine so if it's mechanical it's intermittent. . Loiter and AltHold are pretty good, aside from a slight roll twitch that smells like a tuning issue. I don't see the roll twitch in Stable mode. Compassmot is something like 5%.

Ok. Thanks.

I wonder if it's possible that a motor is temporarily stopping.  It's possible that loiter is doing a lot more up-and-down of the motors as it tries to maintain position ... much more than a human would do in stabilize mode.

Have you done the ESC calibration?  Another option is to increase the THR_MIN parameter although the default of 130 is already quite high.  Still, a very small number of users need to make it 150.

OK Randy, will get used now me to the new formulation.

Thanks - Ciao - Giuseppe

JUST A REPORT OF A NICE GEOFENCE TEST FLIGHT & A SUGGESTION:

So this morning I tried the fence for the first time, in a large open field. Had it set for 30 meter radius and paced that off from launch point so I'd know where it was. Launched in stabilize, switched to Alt-hold then Loiter, then a short RTL (aborted over launch point by re-selecting Stabilize), all of that to confirm that everything was working. Then switched back to Stabilze and flew the Hex into the fence. Hex initiated RTL as hoped. Repeated a couple of times.Very, very impressive, it works!!!  A big, big Thank You to all the developers!

No doubt many people will use the fence to help keep out of trouble during aerial photography shoots. The fence will allow more attention to be given the work, and less to the platform. So when filming while flying around manually in Loiter or Stabilize mode it may come as a bit of a surprise when the fence is hit. The first indication is the loss of response from the sticks, as the APM takes over control. As any experienced R/C pilot will tell you, that is very definitely not a pleasant sensation. Today, even though I knew it was coming, it still gave me a few nervous seconds, until it was clear that RTL was indeed underway (I have RTL configured so the Hex stays pointed in its current direction, so no clue there). I don't think that sinking feeling will go away the next times.

In kicking this around with Gary McCray we thought about different ways the pilot could be notified that the fence has been hit. Telemetry, lights on the aircraft, an air horn :=) , whatever. Most methods would require hardware.  An idea that emerged is to have the craft (as an option) do a 360 degree pirouette (yaw) when it hits the fence and then commence the RTL. This might seem silly, but it would be unmistakeable, wouldn't require any hardware,and should be easy to code and not use much of the APM's resources. It would alert the pilot whether he was looking at a camera feed or at the aircraft. Is there a downside I'm not seeing? If not, I think this would be a nifty addition to Mr. APM's bag of tricks.

(Aircraft: DJI Flamewheel Hex ("The Witch"), upsized 900Kv T-motors, Graupner 10X5 balanced carbon props, APM 2.5/3.0.1 on o-ring suspension, 3300 mah 4S X2, 3DR power module, Ublox GPS on stalk, 3DR compass on stalk, JR 9ch Rx w. 2 satellite Rx, GoPro 3 in case in ServoCity servo-based 2-axis gimbal (heavy) independently powered, LED strip nav lights independently powered, JR 12X Tx)

   

IMHO 30m fence is really too small. 75m is probably a good minimum. default is 150m. Using a small fence means you are more likely to hit failsafe unnecessarily. It's like datasheets for electronics. You get the nominal working ranges, then you get the Abs Max values i.e. the values where damage to chip will not occur, but not a normal operating range.

The fence is to keep you out of trouble at the far end of the spectrum of trouble. It's not a hand holding mode (I know you know this Oliver, this is just more detail for others) It's to save you when it really goes bad.

Randy you are right - have no shield on baro sensor. Will upgrade to 3.0.1 ASAP. Anyway I dont use Fence and dont plan to use it. So question is if the bug fix in Fence code is the only major fix and if I have to change SW only because of this fix.

More interesant sounds :

"I've heard some complaints about APM1 not working well with AC3.0.1"

Perhaps there is a problem with IMU sensors on APM1 and 3.0+ code. Well i'll wait some time if you'll find some issue on that.

Thanks Randy for support.

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

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service