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

Reply to This

Replies to This Discussion

It is already implemented in the beta versions

Ah!  See, I just bought some new square aluminum tube to rebuild my Octo, and I noticed that the aluminum twisted as it was extruded!  Not cool. 

I'll get you a log today Leonard.  I'm travelling tonight through next weekend, but will get you that log as well as an Autotune log with -rc5 in the next little bit to review.

Good to know Randy, thanks.  I saw a test recently on youtube (I thought it may have been yours?) where the terminal was displaying feedback from the ESCs and the FC was using that feedback to determine motor/esc failure, and can see the vision here that if this works, it'll take not only failure-handling, but autotune and stability and everything else with the platform to a whole new place.  Pretty exciting potential!

awesome thanks!!!

Ok Leonard, Successfully got Autotune to run, and have attached that dataflash log as well as the motor log.  The Autotune log is +IMU, as well.

 

First attempt at Autotune actually stalled, so I landed, disarmed, re-armed, re-positioned, and re-engaged, and it completed successfully.  Having the message on the vhud of MP was awesome!  I've flown it around a bit and I do like it and I think it solved some of the problems I was having.  I knew my tuning needed work but I didn't want to spend too much time on it because I wanted let Autotune do its magic.

 

Here are the results, I really hope this formats correctly:

 

PARM Before After
RATE_PIT_D 0.0055 0.001
RATE_PIT_I 0.05 0.1
RATE_PIT_IMAX 500 500
RATE_PIT_P 0.12 0.1
RATE_RLL_D 0.004 0.004
RATE_RLL_I 0.035 0.03
RATE_RLL_IMAX 500 500
RATE_RLL_P 0.08 0.03
STB_PIT_I 0 0
STB_PIT_IMAX 0 0
STB_PIT_P 3.8 6.6
STB_RLL_I 0 0
STB_RLL_IMAX 0 0
STB_RLL_P 3.6 6.6

 

Interesting changes, but so far I'm happy with them.  I'm hoping I can go make a quick FPV run later but time is tight with my flight out this evening, so we'll see.

Attached are the two logs as well, for both Autotune (+IMU) and ACRO vs STAB (+MOTORS).  The condition is still present with the current MP version of -rc5 and I switched back and forth 3 times for a total of 6 mode changes (maybe 7 but I think it was 6)

Attachments:

No. especially if sold for a frame commercially. For sure it gets worse with bigger props but...

Leonard, 

I have had a problem with the quad performing in Alt-hold under sonar.

The quad seems to drift within a zone of about 2m and then suddenly overreacts as it tries to correct.  This progresses into an uncontrolled oscillation.  

I have tried changing the PI parameters on THR_RATE on ALTITUDE.

It looks to me like there is logic error/bug in the code.  I say this very tentatively as I am not an expert at these things.

This is my take on what is happening:

  1. in update_throttle_mode - case THROTTLE_HOLD the function 

    get_throttle_surface_tracking(pilot_climb_rate) is called.  pilot_climb_rate is the value from the Tx stick.

  2. in get_throttle_surface_tracking the target_sonar_alt is modified (if there is stick input outside of the "dead band") and a distance_error is calculated - (distance_error = target_sonar_alt-sonar_alt;)
  3. from this the velocity_correction is calculated (velocity_correction = distance_error * g.sonar_gain)
  4. This velocity error is then passed to the function get_throttle_rate_stabilized(target_rate + velocity_correction)
  5. (I am not sure why target_rate is added to the velocity correction - I believe this to be unnecessary but this is not the main thrust of my observation)
  6. In get_throttle_rate_stabilized()  target_rate + velocity_correction from above become the new target_rate
  7. This is used to increase controller_desired_alt and this is then passed to get_throttle_althold(controller_desired_alt)
  8. In this function the alt_error is calculated (again! - we had it from the sonar function get_throttle_surface_tracking) and we (again) calculate an alt_error which is then transformed into the desired_rate by multiplying by P.
  9. desired_rate value is then passed to get_throttle_rate()

Why do we go through 2 iterations of calculating a distance error, does the second iteration not nullify the first calculation based on the sonar readings?

My suggestion for terrain following would be to:

  1. Calculate the distance error, multiply this with sonar_gain to get desired velocity
  2. Pass this desired velocity to the get_throttle_rate() function.

Am I stupid?

Hi Guys. I'm hoping someone here can help me out. I just had a crash today using arducopter 3.0.1. I was flying in loiter, then when I switched to stabilise all motors stopped and the quad crashed. I can see from the logs that my throttle input was about 50% however throttle out decreased to almost zero when I switched to stabilise mode.

Logs and more info is available here: http://diydrones.com/forum/topics/crash-switch-to-stabilise-cut-all... .

Here is throttle in and out. Any help will be greatly appreciated:)!

Have a great day:)!

Well after so many years of tinkering it will be my first bug find. I seriously thought it couldn't be in the code. I even had a battery cable (+) that got hit by a propeller and cut through about half of the wires. I continued using it since I'm under the amp draws anyway but then suspected that was it so repaired it. Then I saw all my batteries doing it so started looking else were on the wiring. It all seems good.

I'm using 2 receivers and a repeater. ezUHF on the copter, connected via ppm. It's Tx is connected to the repeater that is connected to my 9ch spektrum rx for my JR9ch. This way the ezUHF isnt' hanging off the Tx and the ezUHF Tx can be put high up on a pole. I have the same setup for other copters like my octo and planes and haven't seen this so I don't suspect it's a problem.

I will do the reset and post back. I just did 3 flights now and didn't see the problem at all. It's like that sometimes coming in groups and then not doing it for a few flights.

The reason for this is the delay in the measurement used for alt hold is very small compared to the sonar. So we can make very accurate and fast controller based on the altitude but we can only make a very soft and slow controller based on the sonar.

So we look at the sonar error and then use that to do a slow control of the altitude but then use the measured altitude to control the actual height. This lets us get the most out of the controller.

So if you have a good Alt Hold and a poor terrain following then the sonar gain is the problem, not the Alt Hold gains.

Finally the velocity term you said we didn't need. You are right we don't but having it allows us to react much faster. This technique is known as feed forward.

Yeh, this is a strange one. Had Randy and I scratching our heads for about 2 hours with no luck!

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service