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

Reply to This

Replies to This Discussion

Hi Randy,

I was looking at the 3.1.0-rc2 code, to see how GPS glitch were handled, and I notice several things :
 - gps_hdop_good is not check when entering in a mode that need GPS
 - when copter is already in a mode that need GPS, where's no check about gps_hdop_good, so gps glitch problem can still occurs
 - to handle previous point, we can configure GPS failsafe, but this mode only LAND the copter, there's no other option, like ALT_HOLD, and gps_hdop_good is not handled.

I was wondering about modifying those files to test gps_hdop_good before entering in a mode that need GPS
- Adding gps_hdop_good to system.pde method GPS_ok()

    g_gps != NULL && ap.home_is_set && g_gps->status() == GPS::GPS_OK_FIX_3D && g_gps->hdop <= g.gps_hdop_good
    
- Impact on motors.pde, method arm_checks :
    
    mode_requires_GPS(control_mode) && !GPS_ok()

But to handle gps glitch when copter is already in mode that need GPS, I've modified control_modes.pde method read_control_switch(), but I'me not sure it's the right place

Sorry to keep spamming, but Rob's issue is caused by a faulty GPS config.  It's only updating at 1hz when it should be 5hz.  First time I've ever seen that!  (it's not a 3DR GPS by the way).

HDOP does not change fast enough for it to be useful to qualify the GPS position.  It will change many position updates after the glitch occurs.

But remember this happens even with the 3DR gps. :D

I don't understand, are you saying that looking at HDOP value is not a good strategy to detect if a gps glitch occurs and if a GPS position is reliable or not? What do you suggest ?

Hi  airmamaf,

Is it possible to hold it's position first and run a sequence of gps status(glitch) before it will execute the LAND procedure?

I think you mean "Altitude Hold" and not "Hold position" which require GPS. It could be nice to set a delay before landing, so if a GPS glitch occurs, you first stay at the same level (Alt Hold) and after a configurable time (maybe 30s to recover from GPS glitch or change to a mode that don't need GPS) you start landing => Randy is it possible ?

That way if you got a Glitch during Auto mission, your drone won't drift and land a kilometer from you :)

yes, that's what I like to point out (Alt Hold).

Do you think LAND is the best way to do it? What if I'm flying over the water? Is it possible to switch back to STABILIZED then you take control of the landing? BUT the user must know if its having this GPS glitch already.

Is the HDOP value realtime? If not, how often (in seconds) it updates?

HDOP (Horizontal Dilution of Precision) is an error estimation, and while I haven't looked at the uBlox stream, other GPSs have been very slow/filtered in updating it.  It may not be trustworthy as a dis-qualifier either, since position could jump with the same HDOP.

One source of GPS 'glitches' and jumps in position is when a different set of satellites is used for a solution than the set before.  A new bird comes into view, an obstruction blocks two or more from view, or decreasing altitude cuts off ones near the horizon (the ones that provide the best HDOP).  Then your position 'jumps' as your solution uses fewer or different satellites.

This is why the SV count is interesting to see as well.  It may be the APM code should 'discount' the GPS position briefly if the SVs or satellites-used change by some amount?  This has more negative effects, of course.

The sequence is that the rms error on the position solution increases and then the position jumps and then the HDOP value increases. i.e. hdop increases after the error has occurred. 

I got a gps cn-06 v2 from a clone company (rctimer) and had problems with loiter and RTL

After upgrading the gps with the 3dr script it seems much beter, script removes unnecessary data and updates the transfer  rate.

But the feeling with the glitches stays in my head, any sign when we can we test the gps fix version?

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service