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
Hi,
I think I finally have something specific to ask about. :)
https://www.dropbox.com/sh/7neu2qpw219c31x/AAAi_1auiWHRrBcDD5tYcxnN...
it is a log of how system reacts when I fly close to my house. it has plenty of open sky, but as it can be seen in GPS and GPS2 data - sats come and go. Still, HDOP stays under 2.4 most of the time.
So, Randy and others - could you please review logic of the 'position hold' mode and figure out what makes drone to wonder around so aggressively with no user controls? I can only assume it is due to GPS signal fluctuations, but, can it be neutralized a bit considering no user inputs were given? I can catch it most of the times, but, it is still less than perfect to have this issue.
at the end of this log drone actually flew right into a bush next to my house, by its own initiative. I would love to know what can be altered, if anything, may be in parameters, to limit this behavior.
when I lfy in the open field I get all 15+ sats and hdop lower than 1.3 and it is never an issue, I guess, because system does not switch from one GPS to another. And it is good that is switches, for safety, it is just would be nice to limit, may be, speed of that correction or do some checks with reading from second GPS to make sure we are in fact still stay in the same spot and there is no need to fly around.
I'm not an expert, but I think this is normal. I was experiencing the same thing, only I never took off.. But, copter sitting in my back yard, looking at mission planner it drifts all over my yard, probably +/- 20 meters.
I spent hours researching it, and keep coming across posts that say between buildings you can expect about +/- 20 meter accuracy, and in the open about +/- 1.5.
When I take off and get above the trees and houses, it stays where I leave it.
-edited, I posted before reading all the replies.. If it matters, I have only 1 gps, m8n. Near trees, behind buildings, hdop of 2.0+, it drifts all over. Up in the air above the trees, hdop 1.? (sorry, not looking at logs now), no problems at all.
Paul,
I assume you have two GPS and at least one is an M8N?
It would be interesting to know if the copter wanders around because the autopilot switches between the two GPS or because of signal fluctuations. I assume it is the because the autopilot switches between them.
Normally I do not fly with a PDOP > 2.2. At least this is my threshold for the arming check. Same as you I usually see a PDOP < 1.3 in open field. But recently I was flying close to a house and some big trees with lots of multipathing effects and the PDOD went below 2.5 (I have to check the exact value). But the copter was pretty stable. Hence I assume it is the switching - which would not be the desired effect of a two GPS setup.
Best regards,
Thorsten
you may look into log I posted in the dropbox link - you can see how hdop jumps up and down.
yes, actually both are m8n units, but different ones, on different chips so one is more sensitive and other one usually grabs less sats but holds to them better,
I think I have it set to a minimum of 2.3 to arm.
Again, to have this functionality to swap between GPS units is critical to have, but can it be something done for those subsequent vehicle maneuvers to be somewhat more intelligent, may be?
So it may be worth a try to test versions with a larger ground plane.
IMHO I am not really sure if the two GPS are critical. There is not much redundancy on a normal system so I am not sure if a second GPS really helps. I think motors, props, batteries and brown outs are more critical. Or do you have some specific requirement for two GPS?
What would be good would be some averaging of the positions or some blending. But in environments with strong multipathing effects it is maybe more secure to use only on GPS.
Can you reproduce the effect? Most probably that's not a good idea / secure to try it again at all... - but if, it would be good to compare it to a single GPS solution.
I d not do this for long time but since April when imstarted flying tests i had 3 gps related incidents, 2 related to connectivity and 1 when battery died mid flght - m8n units act weird when internal battery power is gone. Last time i almost lost a drone as it happened 65m in the air. Additional $30 for a spare gps unit is not much money compared to a complete vehicle loss.
Yes, that's right!
The problem with the bigger modules with larger ground planes is that they are quite heavy. And carrying two of them can add up to 75g in addition.
Back to "beta testing": I am wondering if some of the UBX parameters can be used to detect the failure of a GPS unit (in case of dying batteries etc.) which would allow to permanently switch to the second one.
but, realistically, any unit as secondary would work fine as long as it is capable to pick up at lest 8-9 sats and drop to hdop around 2.0 in 5 min. unfortunately some ebay units cannot even do that.
I experimented a lot with a mount solutions and came to what I used on bot vehicles - see on the photo.
1 inch nylon post has either a carbon fiber or copper plate, right on top of that plate on a small posts is a 45mm unit. this method worked better for me than a tallest 5 inch mast that would be used traditionally. it takes me about of 30sec or minute top to get down to hdop 2 and be ready for position hold mode arming.
And here is also a parameters file, if it helps.
after tune.param
-
345
-
346
-
347
-
348
-
349
of 558 Next