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

Reply to This

Replies to This Discussion

Hi Leonard,

Better results:

I used AutoTune today again as requested after I have removed the "foam" on top of the APM. It definitely performed better. It now results in a flyable hexacopter after AutoTune (see attached log).

 

So my P.P.S. statement above indeed seems to be the issue, the hysteresis in the errouneous roll position of the APM with reference to the frame is the problem.

 

Note however, that the resulting values are still far from what I would consider optimal.

Manual tuning still yields better results. I use both higher Rate-P values as higher Rate-D values which makes it more direct (e.g. 0.13 v.s. 0.09 for Rate-P and 0.015 v.s. 0.01 forRade-D).

 

Furthermore, as discussed before, a much higher Rate-I value is required for proper tracking (e.g. 1.2).

 

Note that this was with a personal build using the Master code from October 20th (after some bug fixes).

 

Gain Scheduling:

Note that I feel I would like to add gain scheduling to the code. This way we can get it even much more "tight" without getting the control system to start to overshoot or oscillate at higher throttle positions and loosing control at low throttle positions.

 

This could be as simple as adding 2 parameters:

- HighGainFactor (range between e.g. 0.5 and 1.0, default to 1.0)

- LowGainFactor (range between 1.0 and 2.0, default to 1.0)

 

Then at full throttle the PID values are multiplied by the HighGainFactor (<= 1.0) and at low throttle position the PID values are multiplied by the LowGainFactor (>= 1.0).

 

For the positions in between just make a straight interpolation between the "hover gains" (HighGainFactor = 1.0 and LowGainFactor is 1.0) and the "full throttle gain" and the same between the "hover gains" and the "low throttle gain".

 

Tuning would be as follows, start with the deaults and just tune the hexa in hover, get it "tight" with high gain values. Then with much more throttle it will start to oscillate. Now just bring the HighGainFactor down to resolve this issue. Then start to descent, and increase the LowGainFactor until satisfactory control in the descent.

 

It is a bit difficult to explain with plain text, but I hope you get my picture.

 

Would you agree that it would make sense? Most real life control systems in aviation use gain scheduling (more advanced than what I described :-))

 

Let me know what you think.

Do you want me to help?

 

P.S. Note that for most users both the HighGainFactor and LowGainFactor will be left to 1.0 yielding the same performance as we have now and thus avoids additional complexity for those that don't want to go there.

Regards,

 

John.

Attachments:

So an update on the oscillations i had... perhaps it may help someone else as well..


i tried testing everything... and the oscillations where still there...
eventually after testing each motor.. i found one motor that had a slightly different sound ONLY during mid throttle and randomly... whenever this happened the quad used to wobble and oscillate.. but in FFF it was fine since it was above this "hover throttle point"... the MOT logs didnt show any particular corrective action by the APM when the quad was oscillating BUT the APM was doing alot to keep the quad stable...
anyways i swapped the motor out.. balanced it.. and all is well again..
the only problem i am having is in loiter the quad wants to rise...
I have set throttle mid to the value of thrOut but what else can i tune to keep the alt in place?
whether i put throttle mid higher or lower the quad still rises..

I have attached logs  perhaps someone can give me some suggestions?
(the logs have several few seconds flights where i was tuning different values... the first and second of the "flights" in the logs are just a normal hover and  the first test with loiter..  thereafter i was tuning things alt hold, accel_P,thro_accel to get a smoother alt hold.. but i still have that steady climb upwards..

Attachments:

Hi all, I have two questions...

1) with the "hit Rad" set to "0" the copter does a chicken dance trying to find it's spot on about half the points... it's quite dangerous looking. I set the hit rad up to 30 and all is good. I don't want to type in 30 to every line of my mission.. is there somewhere I can set this an forge it?

 

2) the copter seems to want to auto land at the last waypoint. I did not instruct it to do so and I don't recall this happening on previous firmwares... Did something change?

 

Thanks and great work on APM both fixed wing and MR guys.

Steve

1) In the planning window of MP, to the left of "Default Alt" is the "WP Radius" box, which you may want to change from 0 to 30.

2) Interesting if auto termination defaults to land? I have always ended my auto missions with land. So I am not sure if mine would do the same.

SO (File Format)Wikipedia: A file with this extension may be a shared object, dynamically linked library for Unix.

Hi All,

Do you think it is a good idea to tune Rate_P, Rate_I and Rate_D for pitch and roll axis in Alt-Hold than Stabilize mode?

Also, I find that it can also be better than in Loiter mode. Any suggestions on why to only tune it in Stabilize?

Loiter won't work because that adds the nav control layer. If alt hold is behaving well on it's own, then there is no reason to avoid using it for fine PID tuning. Autotune uses alt hold. IMHO it is safest with a fresh new rig to do basic PID tuning in stab mode first, then verifying that alt hold is behaving before using Alt or Autotune for fine PID tuning. Initial tuning in stab mode eliminates many variables that could result in a crash.

There's no serious talk of removing it that I have seen.

That's good. There was a compiled version with auto tune that i tried and after the install my gimbal stopped working. I re installed the MP version and it came back.

Thanks

Joe

What you describe sounds extremely complicated and you would need extensive modifications to the source code to do this, if you want to do it while the copter is already flying the mission.

However, if you want to add a waypoint before you start the mission, this is easy with Mission Planner. In your case, click on WP3 in the list, then click on "Add Below" and you will get a blank space to add a waypoint, so your 3.5 will become 4, and your 4 would bump to 5, 5 moves to 6, and you now have 6 waypoints and can run the mission.

A quick thanks to the dev team!

Here is my onboard video of 3.1rc3 Autotune, followed up by exercises with the new gains. The first 5min shows my unedited Autotune flight, followed by a comparison to my manual gains @5:09. After that, the test flight ensues. Most of the test flight is in stab and alt, but I did some basic acro @8:40:

I like to think I have half way decent manual tuning skills, but I preferred the gains Autotune picked out for me. Stab and Alt felt a bit more sure footed. So I am pretty confident all the auto stuff will work as good or better than it did (it was spot on, but a bit overactive). If anything bad comes up I'll be sure to holler. Acro was way more locked in. It felt a lot like my harakiri mini-h; the extra confidence that gave is inspiring me to take more risks with my APM450. I have no doubt this rig will be attempting a lot more gaps in the future. ;)

unfortunately that WP radius box is not the same. that makes no difference in how it flies on the copter (on the airplane it does)

the only way to make it realise it's reached the waypoint without the funky chicken is to increase the "hit rad" to 30 then it's smooth as silk.

Steve

You're correct. I apologize, it has been months since my last automission. IIRC, on all the missions I have done "hit rad" = 0. I think "WPNAV_RADIUS" controls this behavior, unless maybe something has changed?

While I'm thinking of it, what is the "Grad" field for? It looks like it is maybe the gradient (rise over run) of the flight path between waypoints? When I change altitude on a particular waypoint after entering it, the Grad's do not recalculate until after I either add another waypoint or shift the order of waypoints around. Not sure if that's a bug. Is it used for flight control, or is it just a sanity check for planes?

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