Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
Yes, I think you could be OK. I have done this before, dropped a quad right in a lake. Grabbed it out, dried it out, and it all worked, even the fpv camera and transmitter amazingly. I thought for sure the camera would be toast.
The key is to get the power off ASAP, and then get it all dried out ASAP.
Indeed taking the power off was the first thing to do, as one of the motors was starting to smoke-up, I guess the controlling ESC had shorted out...
These are replacements for sure...
place your electronics in a bowl of rice and leave it for a day..
Was doing a test flight the other day and when the battery failsafe kicked in it flew to the location where an EKF error had cleared and just hug there. I was able to reposition the copter to a closer spot but it just hung there in RTL.
Finally the battery went dead and it was no longer able to keep it in the air.
At the point where the EKF error cleared is close to where the HDOP went below 2.
5125.bin
Michael,
Thanks for the report. I think the vehicle was armed and was flying for about 1minute before the home position was captured. I suspet this was the problem. Apologies for showing your flying location (it looks nice!) but it helps clear up what happened... the upper red pin shows where it captured home and it should have tried to RTL to that location. In fact, it came down where the lower red pin is (end yellow line). Maybe it tried to come down at the "home" and you manually repositioned it to the lower red pin?
When running 3.3rc1, I too have noticed that home is where it captures 3d lock and not where it is armed in both takeoff and RTL. When taking off, as it is ascending it is moving over this initial home where 3dr lock occurred. To be safe, I have been applying power and getting 3d lock where I want it to takeoff and land..
That is where it set down and bounced until it landed.
I thought I checked where it set home at. Makes sense that's where it flew too. It must have know there was a tree under it so it didn't land.
Now the problem is knowing where home is. If it just picks a random spot that it got a good GPS signal, home could be anywhere. Also effects where my fenced in area is as well.
Like the new tones though. More positive feed back as to what's happening. Don't like the new failsafe alert though. Wakes up the neighborhood.
Hi
Yesterday I installed AC 3.3 rc1 and today I ran Autotune. The result is not good, there is some overshoot, the yaw jumps.. Adds a log of my flight
best regards
2015-04-15 08-18-41.rar
Hi Lukasz,
I can't seem to download your logs but we have a consistent issue with the change in the way we filter the gyro's has caused an issue with auto tune that will be fixed in the next release.
Ok thanks for the information. Log rar packed because he had more than 17 mega and joined to the previous post ...
-
543
-
544
-
545
-
546
-
547
of 558 Next