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
I also have the CSG large M8N. Bought it t because of the very slow startup of the Lea-6..
Mine drifts several feet in every direction when hovering at five to ten feet in PosHold. I run it with the Lea-6 on a PH.
I had a crash described on the previous page that may be related to concerns expressed in the last several posts. Just before landing it took off sideways at a shallow angle and hit hard on the end of one arm. That motor smoked momentarily sitting on the ground and is fried.
I now wonder if the crash was the result of switching between the two GPS unit with a rapid position adjustment rather than a motor failure? I am unable to sort this out looking at the logs?
I had not experienced anything similar with 3.2.
Log attached.
2015-08-13 19-06-30.bin
Hi Greg,
Really sorry about the crash....
I 'm not very good with logs... only the "basics", but I can’t see anything related with GPS, again ....I’m not a specialist.
By the way... I really recommend for everybody... a good anti-vibration system, I’m using the regular one with small blue shock absorbers , and gel pads to fix the board …. After this implementation “I feel” a hundred times better…..
I’m using this “double cushion” in my olds APMs, Pixhawks and Navio+ boards…..with very good results.
Thanks for the reply Robert. I do could not see any GPS issues either but I am not always sure that I am not overlooking something.
I had a GPS glitch today on rc8, but the EKF GPS glitch filter didn't catch it. I was hovering in the back yard with an M8N with 15 sats, and a fix type of 4, and descended to just below roof height while in Poshold, when the gps dipped to 12 sats, and the copter made a fast correction towards the house before I switched quickly to stab. Fix type changed to 3 soon after this and stayed that way till landing.
I've read the description on http://copter.ardupilot.com/wiki/gps-and-gcs-failsafes/gps-failsafe/ but still can't quite visualise how it would accept the glitched GPS position as valid, while not really having any lateral movement to project a trajectory. The new position it was trying to get to must have been a few metres away.
Is there a strategy for tuning the EKF glitch parameters to make it more resilient to glitches like this? I'd like to make sure these things don't make any unexpected movements when coming into land.
Here's a log.
I'm also using an m8n, and have similar results.. Even with very low hdop, 10-20 satellites, the copter drifts around about 10 meters. I can take a screenshot of mission planner if anyone is interested. Copter sitting stationary on the ground, and mission planner thinks I'm constantly moving ~.5 meters per second, all over my yard.
I have not used this GPS with anything before 3.3, so don't know if it's the cause.
I had a different copter that I sold a few moths ago, with the lea-6 gps and older arducopter firmware, and it moved around a couple of meters, only about .1 meter per second (again, sitting stationary and just looking at mission planner). So, the m8n, while getting many more satellites and lower HDOP, drifts around a lot more.
There seems to be nothing telling it, if its location suddenly jumps over 5 or 10 meters that it must be an error.. The copter tries to go to the new GPS coordinates.
I found threads from a few months ago saying the m8n isn't actually supported yet, so we're all on our own trying it. Arducopter progresses quickly, though, so I'm not sure if it's supposed to be working now....
Should we have good stable results w/ the m8n, or is it still experimental?
I had used M8N for some time.
I had used it on 4 different copter. With APM and AC3.2.1 and with PixHawk and AC 3.3 (rc5,6,7,8).
I never had any problem of drifting.
But I had read that someone have experiences like yours.
I think that a lot can be done by the quality of the GPS.
I have tested personally four different M8N, and I can say that not every build of the GPS is the same.
Where did you buy your M8N?
I had seen that on the market also exist very poor quality M8N. I think that VirtualRobotics M8N and HobbyKing M8N are good. Or at least, in my tests they both performed very good.
But, I admit that I do not have any solution.
I also do not exclude that maybe there is some software error.
So, I really do not know the solutions to your problem, but I felt like to shate my toughts about this.
I also think the following. Maybe it can help:
Maybe if you post the log of your copter with AC3.3 with M8N while is drifting it could be more simple to undestand the cause of your drifting.
So, if you have the log, you can post it maybe.
My one is from drotek, so it's not the cheapest and nastiest, and it's been manually configured for 5hz, airborne 4g. I can just see this as causing serious issues when coming in to land, as often there are trees blocking the view on one side of the copter, and I can't afford it to take a dive into them or something else if the lock degrades slightly as it comes past them. Surely there's a way to tighten the EKF glitch filter to deal with these cases better?
Mine's from Drotek too, I have both the normal size and the XL, although I'm yet to finish my build using the XL. I'd read that the 8 series were sensitive so I've done the whole, copper shielding and earthing. Done the same as you by manually configuring it too.
One of the fields I test in I'm close to a large hedge and some trees and have had very successful RTL's...the only issues I have with landing is the throttle not cutting quickly enough.
I had read that the 8 series works better in Europe than in the US, but whether that's just rumour or provable, I don't know?!
You mind making a copy of your M8N parameters with ublox u-center and share it with me please ?
Cause I've made some changes to my two units, namely SBAS, NAV5, refresh rate settings and now even using the 'reset to default values', makes my quad fly away as soon as I engage any GPS dependant mode (and hdop / num of sats is good and doesnt vary too much)
This setup works very well in my Drotek xl and CSG
-
259
-
260
-
261
-
262
-
263
of 558 Next