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
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.
Hey Andy,
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.
Regards,
Nathaniel ~KD2DEY
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?
Andy,
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?
Best Regards,
Nathaniel ~KD2DEY
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 :)
GyroDrift.jpg
AUAV.jpg
Can anyone tell me if the EKF MAG innovations (EKF4->SMX/SMY/SMZ) are a combination of the errors of both compasses or just the primary? If both, is there any way to only use the primary?
i think this setting is new to AC3.3, but not sure its very clear......the description is a bit confusing....does it mean that when there is a GPS glitch or no GPS at all that there is a choice to trust DCM more or EKF more? I thought from 3.3 onwards EKF would be the default....not sure how to even test this option....any thoughts?
2015-09-18_15-04-54.png
Hello internet,
I was wondering if anyone had an update of the arducopter 3.3 feature of outputting NMEA GPS data from the telemetry 2 port on the pixhawk, called a SerialManager function. I found this (https://github.com/diydrones/ardupilot/issues/1774) thread on get hub that has the functionality request but I cant find anymore info on in. I scoured the wiki for info but could find it. Thanks in advance ya'll!
Cheers,
Will F
Hi,
I made a few posts about GPS drift and other seemingly GPS related issues.
I was using an inexpensive RTFQuads m8n. I got one of the CSGShop ones, and it is actually much better! I was skeptical, but it definitely drifts less now. It's also clearly using higher quality components. Its battery stays charged. It gets satellites in seconds rather than minutes..
I'm concerned that while I was having GPS issues, copter tried to fly away a couple times.. Copter would not switch in to Loiter mode, etc. There was nothing in the logs, that I could find, to indicate any issue. (always had over 10 sat's, under 1 HDOP) But, the GPS was certainly causing some problems.
What is a bit problematic about all this - I get sometimes fine results from any GPS units and sometimes there are obviously some issues, but there is no obvious way to raise any alert or quantify level or GPS correctness that results in the unexpected behavior. RTFQ or CSG or complete no-name unit should not matter that much as long as GPS returns a proper result set, but obviously something else is going on that affects all this.
But it is quite obvious now that CSG units seem to be much less problematic than anything else and even if they cost twice more than their competitors, it is probably still a best choice. It is just too bad we cannot figure out how to measure this specific parameter, what makes one unit to work fine and other to produce garbage readings.
-
138
-
139
-
140
-
141
-
142
of 449 Next