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
They are not little vibrations - they consistently spike below -5 :) The wiki says they should not go above/below 3/-3 and even that is probably too optimistic.
Nevertheless I'm not sure that is your problem - have a look at EKF4->SV/SP. These show GPS inconsistency and if they spike above 1, GPS will stop being used. You can see that later in your log SP does indeed spike above 1 and that's probably when you get the drift away. You could set
EKF_POS_GATEhigher to avoid this, but might be worth fixing your GPS issues - which I guess could be caused by the TX/RX issues already discussed.EKF4->SV/SP value ? :o that's the kind of stuff we learn when it happens as it doesnt come in the wiki, right ?
I changed the gps module two times already, and it behaves exactly the same way... so what's next? How can I fix the gps issues ?
Today i've tried changing the radio to a Taranis that works fine on my other quadcopter, and the problem persists, so it's not the radio.
Here is the log for today: 2015-06-25 13-26-23.bin
As you can see, today, the EKF4->SV/SP didnt go higher than 0.81, so it continued to use GPS, but the copter still behaved bad in gps modes.
Cant figure this out
You tried to calibrate the compass setting the magnetic declination of your country.
Hi Winston, yes tried that too :( unfortunately it still behaves exactly the same.
I'm kinda lost here, tried everything I could remember of and did everything you guys advised
I was trying to solve this problem for over two months, I made all attempts by changing parameters and anything, then I adjusted the frame and align the engines, changed the radio control potentiometers and disappeared.
I have a frame homemade carbon fiber and is not alienated properly.
Probably in my situation that it was part of the problem already solved.
EKF it seems is directly tied to the GPS and there seems to be issues with oscilations in the XY position estimate
There was a fix added to commit 211760e3e3e5af3ca8c9d0f96368d39d156fbad3 of the PX4 flight stack https://github.com/PX4/Firmware/commit/211760e
"Couldnt understand the GPS issues being related to RX/TX, care to explain ?"
it seems that some RX's and some Telemetry radios generate "noise" that can cause some GPS modules to degrade which can cause less than optimal operations such as low sat count and drop outs.
In my own testing with quite a few m8n modules I have found simply running them at the default 5Hz refresh can cause pretty significant data drop outs even without added noise.
I plan on ordering some "Active" antennas to test on some of the modules I have that use passive antennas to see if the saw filters can better handle the high refresh.
I admit I am no electrical engineer or even very bright so my testing methods are not exactly scientific, but they are repeatable and some modules are worse than others with this one being the worst of the bunch.
http://www.ebay.com/itm/BN-880-Flight-Control-GPS-w-ICHMC5883L-f-AP... [mine had the brand BeStar on the bottom, until the bottom fell off]
@ 5Hz it drops out completely then comes back and then drops over and over to the point that mission planner shows "No GPS" and "3D Lock" over and over.
In U-Center all of my m8n's exhibit some degree of data drops but as I lower the refresh the data drops become fewer and farther between to the point where I get to 2Hz, and other than that BeStar, stop altogether.
I may well be wrong but it seems that the more channels used the more it has issues with higher refresh. Seems that in GPS only mode then 10Hz is doable but with GPS and GLONASS then 5Hz is max as well as GPS + any of the other supported signals.
Much of what I have said and seen may well be conjecture but in my tiny brain it kind of makes sense. And could potentially explain some of the issues with these great little M8N modules
I just uploading a little video I just took of U-Center and a M8N's data drops at high refresh rates.
http://youtu.be/3SLgRYYze2g
How would one flash the latest firmware for Pixhawk FMU ?
Thing is, looking at the logs I dont see significant
drop on sats neither hdop jumps
It's in the wiki - where do you think I got it from :)
What kind of GPS do you have and where in the world are you based?
I'm not sure I'm going to be able to add anything else here - you really need input from Paul Riseborough who wrote the EKF code. The GPS error must be measured against something, so it's possible that that something is the thing that has the problem. I sitll think you should get your vibrations down to see if that clears things up.
I did another short flight again, reduced the vibrations: see log
but problem still happens.
I have a 3DR ublox neo-7n and also a lea-6h, tried both!
My location is Portugal
Thing that is bothering me is that it flew fine one month ago... if it was EFK problems they would had appeared before too, since i'm running same firmware version as before.
also DesVelX and DesVelY look very awkward to me.
-
324
-
325
-
326
-
327
-
328
of 449 Next