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
The problem must be related to the the specific combination of vibration frequencies, filtering frequency and logging frequency.
Rob,
yes, that's pretty interesting. The Acc values in my log are actually pretty low as are the vibes. What is interesting is the RAW data which seems to go crazy - maybe because they are not filtered. So maybe what comes out as the Acc signal depends on how it is filtered. Same is for the vibes. I guess we have to see more logs. But is seems that if the 50Hz or 400Hz signal looks good in the Acc, flying should be fine. If the Acc is high then the vibes should tell if flying is ok.
Adolfo,
The vibe levels are a bit higher than my IRIS on the Z-axis but I don't think it should cause significant problems. Most importantly there's no accel clipping which is really important. By the way, the new VIBE message is better at giving an objective measure of vibration than looking at the IMU values directly.
So we can see that your vehicle's Z is spending a fair bit of time in the middle at 20 which is higher than my IRIS (the example on the Vibration page) is generally down below 15. We don't have enough feedback from people to know when the vibration levels start affecting altitude and position estimates but I suspect you vehicle is ok.
My pixhawk seats on one of those 3d printed anti vibration mounts. Are the "waves" in the graph caused by the mount being too soft?
I would like to understand the waves. If they are dangerous or not since I have acceptable vibe messages and no clipping.
The the waves in the Accel readings are totally normal and expected if flying aggressively. When leaned over, the X and Y show non-zero. For example, if leaned over 45° in roll, you'd expect the AccY to be +/- 7. And the waves in Z is your throttle coming on and off.
Thanks for RC8, seems working pretty good, don't noticed any major problems.
perhaps to consider :
For EKF, i have still some strange behaviour in alt hold, while flying in windy or breeze atmosphere. The Problems are growing when flying without GPS. The Copter suddenly starts rise and i need to take away throttle to compensate, it's very difficult to maintain a constant hover. It's starts beeing dangerous if the state is changing from GPS(Green) or Manually(Blue) to EKF Error (Yellow/Red)
EKF should really be used only in case all sensors are delivering good signals. There should be a kind of logic code which could decide how "much" EKF and how "much" DCM the APM should use for position estimation.
There could be also setting to let user decide what apm should do in case EKF is not good enough for position estimation.
For me it doesn't feel as it have reached the quality needed to be released, but we are close.
Pomaroli,
Thanks for testing and providing the feedback. Instead of backing out to DCM/InertialNav I'd really prefer to get the EKF improved. Can you provide a dataflash log?
Randy, today is open fly day so i would love if apm does what it should. but i will try to force apm to do it wrong on our own fly field the next days.
Pomaroli,
Great, thanks. If it's not too late, could you check the LOG_BITMASK's IMU_FAST bit is checked?
In -rc7 this was forced on but I forgot to apply that change to -rc8. The IMU_FAST is helpful to Paul Riseborough because it gives the 400hz IMU logging so we can run Replay on the log. It's not critical but it would help, thanks!
-
316
-
317
-
318
-
319
-
320
of 558 Next