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
Aha! I figured it was something like that. I will go plug the tricopter in and see what that does. Thanks!
Maybe something broke here?
https://github.com/diydrones/ardupilot/commit/b8181b6b90fb2a5b5fbfa...
This is the only mayor rework that happened with the tricopter code since April and has to do with the servo.
Strange, I didn't even have the tricopter yet in April, and I flashed the latest version sometime in early June and that was the version that worked.
The Storm32 serial protocol did not work for me. Is there a special firmware on the storm required?
I tested it with 0.80 and 0.82.
http://diydrones.com/forum/topics/copter-3-3-beta-testing?id=705844...
Folowed the wiki for setup. But I can´t control it neither with MP nor with manual RC control.
I did not get any answer on my request on the bottom of page 160 (link).
There are also some additional requirements:
Passthrough of 2 PWM channels to the storm output lines via serial (control of camera).
Using the Storm link feature as 2. IMU over serial.
Cheers Gregor
Gregmaan,
I've tested the SToRM32 gimbal serial interface with SToRM32 version 0.70 firmware and confirmed that it works. I haven't tested it with 0.80 or 0.82. It's possible the protocol has changed or that something was missed during the configuration.
The additional requests are probably on the to-do list but certainly won't make it into AC3.3.
Hi Randy,
0.70 is a big step behind 0.80 or 0.82e (pan/yaw axis problems).
I will check if 0.70 is running for me (maybe a configuration issue from my side).
Hopefully there is a chance to get the 0.80 and above running with AC 3.3
Please keep us up to date if you can find any improvement with 0.80 or higher. Thx
Randy could you at least take a look at this issue:
https://github.com/diydrones/ardupilot/issues/2426
Seems very serious. I'm sure there will be a lot of people using the Storm32 controller with 3.3 since there is native support for it to some extent, but it would be sad to have a lot of people with burned out gimbal motors or broken cameras from that bug :(
I also would appreciate a working SToRM32 controller with pixhawk via serial!
Tarot 680 pro frame.
13x5.5 cf
blheli damped light esc
3.3 RC7 only pitch and roll autotune.
I can ear motor vibrations from the resulting autotune and hexa is twitchy around middle stick, mostly on the roll. I reduced resulting values 15% afterwards. The high vibs seam to go away (D to high?? or P ?? ) but the middle stick movement gives twitchy result.
My main problem is around middle stick. The very beginning of stick input and the copter is not smooth. On higher angles it does look locked and stable, just not on the very beginning of stick input. Best I can describe is wobbles. Slow and little roll or pitch inputs and the hexa wobbles just a bit.
Any suggestions ? Lower autotune_aggr form 0.1 ? higher than 0.1 ? reduce all autotune values by 25 % ? Does anyone see anything wrong on my log ?
-> Autotune Log -/p>
Thank you
-
352
-
353
-
354
-
355
-
356
of 558 Next