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
:o I had the compass plugged, I even did a compass calibration right before flying and the offsets were good.
What value is telling that there's no compass ?
Try a different GPS module and see how it acts.
I've already tried another 3DR gps +compass (a Ublox 7n) and redo calibration but I get exactly the same results. I also ran compassmot and got just 10% of interference.
what else can be the problem? The loiter pid's? (But they were working fine...they are the default values for the 3DR X4 quad)
I experienced the same as your and couldn't find the solution to the problem, so I decided to try the flight guidance mode (since in that way the input of the transmitter sticks do not affect the functioning of the Quad), then I realized that my radio transmitter Futaba, was sending flashing signals to the receiver, and this caused a drift in a direction , mostly to Loiter and PosHold modes.
I changed my radio futaba potentiometers and the problem disappeared.
Well, maybe you're correct. Because I indeed did change from an old futaba to a more recent one (8J) and thought about that, but didnt had the chance to try the old one again.
May be with the logs there's something that could confirm this ? Any log expert could take a look at both logs and check if it's indeed the radio please ?
EDIT: but if it was a radio problem, wouldnt it happen also in stabilize mode ?
I had no such problem in the stabilized mode, apparently the code ArduPilot accepts some degree of sensitivity in the input of the radio transmitter for Stabilized mode.
Although I'm not entirely sure that's so.
Well, I appreciate your help ! This is something I've thought before, but since stabilize was working fine and I didnt had a chance to try with the old futaba I disregarded this one, and I guess this is the key to solving my problem too. I changed from pixhawk to gps, to another entire quadcopter frame and got the same results everytime, so "of course" it must be something else, the radio DOH :P
Will test the old one and report back ! Thanks once again .
I had my first EKF inconsistency error today. I've been flying 3.3 rc5 for many flights over the past weeks with no errors but this occurred at take off and my quad flew fine in Stab mode but anything using GPS was locked out. I landed and reinitialized and all was well. Let me know if the logs would be of use I'll try and find the flight. I've been fine tuning an upgrade to Alexmos 32 bit on my gimbal so the quad has been on and off several times.
It's interesting that most of the Dev's have been AWOL for the past few days. I assume they are knee deep in sorting out the Solo issues and the EKF errors. I suspect the code is getting petty complex so it will be harder and harder to add new functions and debug. I wonder if QNX which offers a very partitioned operating environment for critical applications would be worth a look or if it can run on the Pix processors.
Hi Randy,
I don't know the proper way to request an enhancement, but I would like to see the default for WP_YAW_BEHAVIOR = 3, which is yaw follows path. This makes for much smoother automated flights, and I think it is the behavior that people would intuitively think it would do. It took me a long time to figure out this was what I needed to set so that it doesn't jerk to point to the next waypoint.
Thanks,
Rick
Another addition might be to add Rate Yaw kI to Ch6 Opt. Is that an oversight, or maybe there is a reason that it is not done? It would be helpful to me, though.
Thanks,
Rick
-
399
-
400
-
401
-
402
-
403
of 558 Next