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 Andy,
Thanks for the reply. It only happens after arming.
My understanding is that the EKF Check routine exits immediately if the USB cable is connected so I can't tell if there would be warnings when connected with USB. I think the code basically sets the Check Threshold to 0 (Disabled) when USB is connected or Throttle at 0 or Not Armed.
Just to be clear, After arming and the EKF Check routine starts I get Yellow/Red LED, No Buzzer warnings and EKF_CHECK-2 in the logs. I get this with or without GPS connected/enabled/Lock.
I can fly in Stabilise and ALTHOLD but GPS modes are locked out. Even with EKF Check disabled. Does this point to GPS issues?
There is no EKF Failsafe being triggered. It happens on all of my machines including my RTF Y6B.
I have tired disconnecting everything one by one to see if there is an interference issue, I have erased and uploaded and run the calibrations.
I know
Thanks for that. Sorry, I did try loading the latest build to see if that made a difference. No flight, just for bench testing.
I just tried reloading rc5, recalibrated etc. Repowered and tried arming with the same result. Flashing Yellow/Red, no buzzer tones.
Downloaded log and it seems that the time column is corrupted (They all have same time). Data is recorded but graphing impossible. I will continue to try and get a usable bench test log.
Thanks for looking, much appreciated. Here is an old bench test log on rc5. No flight, sitting level on bench, no motors running but same error. Not sure if this helps. I can't see what is triggering the warning. On the HUD is see ekvvelv and ekfcompv are below 0.2. I believe this is lower than the check threshold of 0.8.
Thanks again.
2015-06-04 14-36-17 EKF Variance AC3_3rc5.bin
By the way, I am ok flying with 3.2.1 and I realise that rc5 is beta so I am fully expecting that there might be issues.
I do not want to distract anyone simply because I have a problem and I appreciate the work and time spent by all of the Dev's and community in making such an amazing product.
I am just concerned that there might be a hidden issue that is masked in 3.2.1. I realise that this is probably my setup as others have fixed this issue. I am just not sure what to do next or who to ask.
Thanks for the reply. Much appreciated. I am sure that I have the latest MP but I will try updating it again.
My problem is that the warnings are happening on my Pixhawk's. They all flash Yellow/Red but with no buzzer tones and no EKF Failsafe being triggered. Even my RTF Y6B does this.
The problem does not appear to be MP related but in the PH.
I have tried all 3.3rc's with the same results and they all work on 3.2.1. I notice that the latest build addresses EKF reliance on position but this did not fix my issue.
I am starting to lean towards a hardware problem as when I check my logs the only thing I can see that is different from other people's is that Ratio in EKF2 is stuck at 50%. I am probably on the wrong track but I can't see what else is different.
Hi,
Could anybody confirm if there is nothing at all new in 3.3rc5 in regard of how it proceeds with ECSs calibration routine?
Upon first powering up of PX4 with throttle at max it seems to do what expected and wait for a power off - I get 'initializing' repeating message on taranis, FC's light blinks repeatedly, ECSs did a short tone - all seems to be usual.
I power drone off, move throttle to the min, and upon powering up the drone I do not get into a usual ECSs calibration mode - it goes into a regular 'disarmed' mode like nothing happened. I press this safety PX4 button as well, but it does not seem to do anything or alter anything, pressed or not.
All this happens on the new (for me) FC board so I am not sure what to blame, really, It is PX4 AUAV x2 clone, X8R receiver over sbus, mode 4. Radio is calibrated.
Radio calibration was also a bit different from APM - I noticed some channels calibrate to values slightly different from factual slider readings on the screen - can that be the problem?
All same setup was on APM and I just moved it into PX4 and installed 3.3rc5 on it, so not sure what do I miss in this very simple procedure but it does not seem to work as it was.
OT but I've been put off the AUAV x2 by the wiring and mounting since it has no case and most compasses / gps have DF style connectors. Have you made your own wires/connectors? How are you mounting the board?
Andy - The AUAV X2 comes with DF13 to Dupont cable (two of them) that just plug into the board and GPS. No need to make a cable. There is an excellent 3D printed case on Shapeways in Arsov's Shapeway's store that costs $14 plus shipping.
mounting a bit a challenge but for vertical pins format there is this case and I think it will be very usable.
http://www.shapeways.com/product/5Z99YYHWH/auav-x2-case-w-mounting-...
I wish I had my own 3d printer. may be I should buy one...
I dunno, by the time I've spent £15 on a case and made up all my own cables I may as well buy a Fixhawk. Is the weight difference really that much?