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

Reply to This

Replies to This Discussion

Thank you for appreciation and sorry for delay in my reply. The Do_SET_ROI command works until next WP is executed. So it needs to be copy-pasted after each WP. I observed that DO_Jump command does not work , as i would like to make many circles around me without the need to restart mission.

Luciano did this ROI together with Circle command, like in its video http://www.youtube.com/watch?v=QncNOSfOn18

And one more thing, the OSD shows from time to time "Waiting for Mavlink data..." on Arducopter 3.1 RC4

Any thoughts on adding camera trigger based on distance Randy?

Programming a typical mission with individual waypoints so that I can trigger my camera at each would mean a mission with 500-1000 waypoints for me and this is just not practical.

Is there some way to steal that chunk of code from ardu plane and add that feature to arducopter?

They just recently added this in ardu plane a few months ago.

Steve

Right... I think i understand..its the thr out value.. at stick 50%.. .hence its not enough to hover at 50% i have to move my stick to (possibly outside the dead band) to get it to hover..

when i move to alt hold the stick is outside the dead band and therefore asks for an increase in alt... (wouldnt matter if it was in the dead band)?

I am just going through the code quickly... I dont understand it fully (i have only spent around 30 mins on it..) but it seems at least these two functions play a part in alt hold/loiter etc:

get_initial_alt_hold - this takes in to account climb_rate_cms - which helps set target_alt. so if I am climbing at a good rate (depending on my alt_hold.kP) it will "project" a new target_alt..  this could be quite high? (i dont see an upper bound or normalisation vector - except the casting to int32)?

 

 

and get_throttle_althold

has the call ; get_throttle_rate(desired_rate);

is where the functionality you are describing is encoded?

 

I havent read enough of the code to find the controlling functions yet.. would be good if you could let me know :)

 

 

 

Looking good Thorsten.  Are those flight times with a payload?  And what was the windspeed in that test? 

GPSGLICH_RADIUS refers at max deviation in 1/5 seconds interval?  (5hz GPS refresh)

anybody?? I thought dev team wanted feed back on autotune problems

Robert, yes with payload: a small Canon camera. AUW is currently 2980g using two 6500 mAh 4S batteries. The tests were with 3040-3100g. So I expect slightly longer flight times now. There are some similar but lighter arms available each saving about 15g. So there is either potential for longer flight times or more payload. I am pretty happy with this setup especially because I had no problems so far with APM at all: no crashes, no nothing. 

I am not sure about wind speed in that test. But normally I would not fly under such conditions. 4bft maybe. Under 2-3bft it is no problem to go on a waypoint mission. 

Well that's a really great duration with a useful payload then.  Nice work.  I'm not a fan of "duration specials" that can't carry any weight, but doing 30+ minutes while carrying a real camera is a very useful machine.  

So, what was the cause of the yaw problem?  I see you fixed it, but couldn't clearly see what the cause was.  You tilted the motors a bit?  But what was the root cause?

Steve,

     Leonard and I spent a couple of hours looking at your logs and the code.  We can clearly see that the angle boost number (used to increase the throttle to compensate for the tilt of the copter) is becoming very large and negative (-7557 to be precise) but we haven't yet found a possible cause.

     Could you try going into the mission planner's Terminal screen and doing the "setup", "reset", "Y" and re-doing your copter's set-up?  It's best if you don't save/load any parameters from your current configuration, do the whole copter setup (rc, compass, accels, etc) from scratch.

     Also which receiver are you using?

     Thanks and we've actually never seen this before.

Re RTL, yes, we can fix it so it doesn't turn on the intial climb.  txs!

Most people take 5 to 8 minutes to do the autotune but it depends on how far your starting parameters are from the final autotune parameters and how much time you spend re-positioning the copter.

It is all in the get_pilot_desired_throttle for stabilize that does the scaling we are talking about.

The Alt_Hold uses get_pilot_desired_climb_rate and your stick at half throttle is zero change in altitude and it puts a dead band around half stick.

Yes it is a useful machine - and definitely not for (too much) fun ;-) 

It seems the root cause are the arms which are twisted a little systematically. I am still waiting for a reply from the manufacturer.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service