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
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!
I had a flight about a month ago on AC3.3 rc8 in which I had an EKF triggered failsafe as well as a later NO-RC Receiver failsafe. Up until this point (and immediately after changing modes) everything has been fine, and seemed fine at the time. I'm hoping someone can review the log and give me an idea what caused the EKF failsafe and how to prevent it in the future. I think it is compass related and not sure if there is an indication I need to re-calibrate the compass, or if it's something else entirely.
As to the RC Receiver signal I'm stumped. The RSSI was about 97 right before the failsafe then dropped to 0 for about 1/3 sec. the failsafe was triggered then it was back to 97.
The short clip below shows the various screenshots of the tlog replay with VIBE and EKF scopes open (love these by the way).
Attached are copies of the above video clip, and a copy of the tlog.
Here is a link to the BIN file for this flight on my Google Drive.
I haven't had any time to fly since this flight and want to upgrade to AC3.3 rc11 before my next flight, but I want to understand what's going on here first.
Something is weird here. I used to get these a lot and they were indeed badly calibrated compass. But your's is different. At the time the failsafe triggers everything spikes - the MAG innovations, GPS innovations, Baro innovations, all the motors blip as well. I can't see an obvious cause, vibrations look good. I just wonder if it was some kind of mechanical knock that set everything off. There's also a sudden drop in voltage, both on the battery and FC - so I suppose brown-out is possible, but maybe these are just reflecting the sudden power surge when all the motors blip.
The other weird thing is the learned gyro offsets for Y (EKF1->GY) & Z (EKF1->GZ). They both get quite large and then suddenly reset to 0. There is also a weird blip in Y at the time of the failsafe.
Maybe just chalk it up to experience and install rc11 :)
Do you have the log for the RC failsafe? I've been having some of these which I've been blaming lemon for, followed by bluetooth - but today I went way out with bluetooth on and no issues, so I wonder if there is a software fault. Again this was with rc8 or so, rc11 now much better so I should try it.
The RC Reciver failsafe is in the same log. I don't know where it is in the BIN but its 3:44 into the flight on the tlog (79.79% of the file).
I think the X and Y vibes look pretty good but I think I can get the Z better if I remove some of the play in the motor bell housing on one or two of the motors.
I've done the Mag/Current Compasmot and a Compass Calibration (with the original setup but not since). Not only do I want to fix whatever is causing this, I want to understand what's happening. I suspect it's vibration related, but I don;t see the evidence of that.
When the EKF failsafe kicked in I switched modes from Loiter to something else and back again to stop the landing (from my viewpoint it looked like I was over trees). Immediately everything returned to normal. I have my Loiter speed set fairly high compared to the default, not sure if that has anything to do with it. I know some people say Loiter isn't a "Flight Mode" but it works for me and I like the convenience of just being able to stop and take a break to look around without having to switch modes when recording.
1st of all I would thank whole dev team for awesome work on 3.3.
2ndly,Today I have been doing some test flights with version rc10 and had a crash.
At the end of the flight my copter has suddenly bounced up in the air, I took throttle down and the copter started to fall like a stone. I tried to add throttle not to hit the ground but I crashed anyway.
Can someone please take a look at my logs and see if there is anything suspicious?
Also I seem to have issues with auto-tune (I did it on rc9) where after auto-tuning whole platform was wobbling in Pitch and Roll.
I had to decrease P and D for about 30% in order to have the platform more stable.
Still it doesn't fly as I would like it - maybe someone looking at the log could give me a hint what's wrong.
here is the log file:
Tonight my test quad flew a 3.7 mile mission perfectly on 3.3 rc11, and landed on a dime. This copter uses a RTFQ 55mm M8N with standard GPS scipts, no second GPS, and AUAV-X2 FC. No warnings or surprises.
I used Tower with the EKF monitor; excellent feature.
The only problem now is the logs won't download from the USB.
I´m using the CSG M8N since 2014 when the first big one with 35/4mm taoglas patch came out and they still perform great and the DroTek XL (not the XXL) with the 35/6mm taoglas patch which is great as well and I´m using either a GLB Flight Controller Housing or 2 pcs. 45/50mm glass fiber board, which looks a lot better.
I tried several cheapo boards with M8N, but some of them performed even worse than the good old 3DR LEA V1.1,V1.2...so won´t use them for expensive rigs . But for those who even use the PX Lite on a low cost setup they maybe even good enough .
Hi Nathaniel, I took another look at this. I see the RC error in the RC input, but I don't see the failsafe.
Anyway, take a look at GYR1/GY2->GyrX - I think this is your problem, the gyros don't agree with each other and eventually the EKF gives up, resets itself and this results in the twitch you get. Maybe the copter was moved while the gyros were calibrating? I would do another flight and check that the gyros agree with each other. If they don't maybe its an issue with the board?
Thanks again for taking a look. Can you explain or even better post a screen capture of the GyrX comparison that looks like they disagree. I took a look and I admit I'm not really sure what I'm looking at, but it looks like they follow the same mean however one has greater amplitude in it's plot than the other. I just want to better understand what I'm seeing.
As far as moving while calibrating, I'm very careful about that, but anythings possible; perhaps a breeze.
I don't understand why the BIN file doesn't appear to show the No-RC Receiver with an RTL failsafe. The tlog clearly shows it and it definitely happened. The BIN file does show the low (968) throttle that triggered it on ch3 RCIN. That's strange.
I'm going to update to AC3.3 rc11 and take another flight as soon as the wind co-operates!
I've posted another BIN file here from another earlier flight for comparison. If you get an opportunity, could you take a look and see what you think about those gyro values?
The gyros should both have a mean around 0 and indeed should track each other pretty precisely. Here is a graph from my bad pixhawk where IMU2 has a lot of temperature related drift. You can see that they start in agreement and then IMU2 quickly goes off. This caused me all sorts of problems until a change was made to update the learning rate (can't remember which RC). Yours never agree. I looked at your other log - that doesn't look right either although the EKF looks happy. Seems weird since the gyro calibration should set them up well.
I also attach a comparison with my AUAV-X2 where you can see the gyros track each other precisely.
In RC11 you can turn off one or other of the IMUs (INS_USE_0, INS_USE1), I suggest you try turning off IMU 2 and see if that helps.
All my opinion, so I could be completely wrong :)
Final update on this. I redid roll with the filter settings set properly this time and it resulted in a much more stable copter! My CG is quite high and it was a bit wobbly originally, now its really solid but very responsive at the same time. Good job!
- I too encounter the "autotune won't engage" issue that others have mentioned. I seem to have to flip in and out of autotune a couple of times before the copter starts doing anything.
- RATE_RLL_IMAX has been set to 10000 by the tune, but the parameter docs say that 4500 is the maximum. It also says the units are 10x% max motor output, but that doesn't seem right either - I'm pretty sure my motors would blow up at 1000% output!
In the end I didn't use these because they were very different to other settings I'd seen and my starting point. That said, what I finally ended up with wasn't a million miles from here - so sorry for not picking up on this!