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

Reply to This

Replies to This Discussion

Randy,

We already have a nice failsafe builtin.

When the copter is armed, it will disarm automatically after (20 sec default).
The danger of leaving it armed is removed.

And for those first 20 secs of it being armed.
Everyone is already aware the copter is ready to take off.
The pilot will be sure to let everyone know.

Anyway...leaving the autospin off by default is the best option.
Or at the very least, during wizard setup, give the user the option to have it on or off.
Maybe even an indicater in the HUD, showing the motors will spin at startup.
Or an LED flash sequence on the copter for either mode.


nice...the slow mo...lol

Awesome!

 

I respect your point Nick. And I understand that it feels weird or not necessary to have the props spin on arm. And I also believe this is mostly because we all used to have the props NOT spin on arm for a very long time that it because just a habit and now with spinning props it just feels unsafe and awkward.

However, I still believe the prop spin on arm is a much better option as default.

Why?

There is NO danger with this option at all as some of us think. If one thinks that this is a danger because props spin unexpectedly, it must be because the copter has been armed way too early or at an inappropriate location. There is no reason to arm the copter before it is at its take off location or while people are around.

With this feature on, there is no guesswork if the copter is armed or not, one doesn't need to follow and interpret the blinking LED status or give a quick throttle to see if the copter is armed or not. It is so simple and direct: You look at the copter, if the props are spinning, then it is armed, if not, then it is not armed... Period.

Of course, users have all the right to disable this feature and go back to previous state by just changing the parameter. 

But I believe the default should be left at "prop spin on arm" state to let users get used to it. I think developers left it at default for this purpose. Believe me, when I first used this feature, I didn't like it and found unnecessary. But now, it is my default parameter.

I am not a developer but I truly believe that this is the right habit we all need to get used to.

I hope you didn't think that I disrespect your point of view. I understand and respect your comment. I just stated my reasoning why the default should be left the way it is:)

No Power to the Red LED.

I used a multi-meter to check the voltage across the LEDs. The blue shows a voltage ~2+ but, nothing on the RED. So, the LED likely isn't burnt out it is the circuit.

What activates the RED LED? The APM flashes, connects to the MP, HUD works, takes config changes, the copter will arm & disarm, flies, collects logs. I haven't really gotten to do a full flight but, it will fly low and easy around a small area with out any changes. GPS locks too.

Thanks Randy,

I reflashed by the instructions, and  and now work fine,  have tested on my backyard on short fly , before the problem appeared immediately , so I m confident it will work. Logs are normal now.

Even when I have tested many vibration dampening alternatives, logs look always the same , could you tell me what the frequency of this signals, so I can test a more "scientific" approach ?,

Just for the record . Flip does not work correctly under w8, it connects, reads, but doesn't write.

 

Thanks for your help

Regards

Update to no RED LED.

Using Scott Berfield's excellent explanation, here, on how to configure external LEDs and Buzzer I've now what I'd intended to do eventually. This proved that the RED LED APM circuit is still working because the external LED indicates Arm/Disarmed. I just do not have power to the LED.

Software:

I noted that the GPS Blue external LED will not blink coinciding with the Internal LED blinking. This will cause times with no external Blue light. Not a big deal but, a small inconsistency between internal and external indicators. Since my on pcb RED is not working I can not tell if it blinks matching the external for indication or not.

Is there Firmware settings for the on pcb RED LED which some how could have gotten turned off? Like - fuses which somehow may have gotten corrupted or ???  ---- I did erase EEPROM and reflash to firmware 3.0.1 which I had been using successfully.

 Just finish running autotune and I'd like to report that it works perfect for my quad! I think v3.1 now ready for it's official release.

Thanks to Randy, Leonard & members of Devteam!

Brian,

     Thanks for the link to Scott Berfield's blog.  I've added that link to the external leds and buzzer wiki page and maybe someone will transfer over the information to the wiki at some point.

     I'm 99% sure that the issue with your board is hardware related.  Maybe the solder joint on that led is broken.  I can't think of any software configuration issue that could lead to just that single led not working.

Ah, excellent.  There's a fairly big vibration dampening wiki page here which is the collection of many discussions on the forums.  I use 1/4" dubro foam but I hear moongel is better except that it breaks down when it gets hot.

The vibrations come from the motors and if you're using an 880kv motor and 3S battery (i.e. 12V) then the motors will spin at about 10,560rpm at full power which is 176hz (10560/60seconds).  the ArduCopter loops run at 100hz although the accelerometer collection runs at 1khz.

Ok, thanks for the report.  I'll have a look into that.  It's weird though because the mission planner can see the flight mode and they're listening to the same mavlink info.  We've made some unrelated changes to the GCS mavlink messages so perhaps something has gone wrong.

Anybody else tried -rc5 (or one of the earlier release candidates) with a minimOSD?

There's certainly reasons on both sides of this argument and many of the same points as above have been brought up on the drones-discuss list as well where I asked for feedback.  Personally I like them spinning (I didn't use to) but I'm leaning towards turning the feature off by default for the next release.  Mostly because historically that's how it's operated.  We can see how the community goes with it and consider again switching it on by default for AC3.2 release.

Now that I've started playing more with the Pixhawk one thing that I really appreciate is it's tone-alarm and it's LEDs.  That RGB LED actually works on the APM as well in AC3.1 and anybody can connect a piezo buzzer to the APM's A5 pin but not many do yet i think probably partially because 3DR doesn't sell them.

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