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
If you look about 7 posts up, Craig answered this with the following:
The article basically suggests the simplest workaround being to connect a 4k7 resistor on the back of the power module between the 5v vdd output and ground. I will maybe try this when I have the chance to pull my hexa apart (power module is a bit buried on my hexa!)
Hi Paul,
I missed (overlookt) that post thanks for the help!
@ leonard
I agree with them
I agree and I am flying with 3.2.1. It is great! EKF seems to work ok for me on this release.
I just thought it was worth mentioning so that the Dev's and testers were aware and offered my info in the hope of helping with information.
As far as I can see it is probably unlikely to be a hardware issue as I have three different genuine 3DR PH's all doing exactly the same thing. I am not trying to complain and fully accept that 3.3 is still beta. I just thought is better to report a possible issue than waiting and possibly finding it later!
I have found that the support and info from both 3DR,, all of the code warriors here and the DIY community to be fantastic. Although I am still not quite sure what the actual problem is.(I don't know if anyone does) I have a 3DR support ticket in and will let everyone know what I find out. Obviously it does not affect everyone and 3.2.1 is still great.
I have and I am still trying to work it out myself (with my limited knowledge) but please do not think that I am having a go at anyone. Just trying to share in the hope of helping by supplying information.
I like the EKF in theory, but once in a while I hear "EKF Variance" spoken by the GC software I'm using. And about that time the Iris goes a bit "Blazing Saddles" on me and flys off in some totally random direction. I have CH7 set up to toggle EKF on and off. In those cases, I switch it off, wrestle it into submission, and it calms down. So I'm testing it, but I think I would probably be chewing through hardware at a high rate if I wasn't able to turn it off when needed. :-)
Kelly, Interested to know how you turn EKF off? What setting do you assign to Ch7?
There's a setting you can apply to CH7_OPT called "EKF Enable". In 3.2, you can toggle that setting and notice it immediately. My Iris would twitch and change its heading about 5 degrees to the right when I switched it on, and rise about 6cm. Turn it off, it would twitch left, and drop about 6cm. In 3.3, it doesn't do that. I don't know what that means really. Maybe that EKF is now so good, it acts like it's not turned on? :-)
Don't worry Alex,
I don't think anybody is complaining. All I am saying is this code is still a work in progress.
The Devs rely on all the feedback people are giving here to make sure the eventual release is as good as we can make it.
I just don't want people to get too stressed if they see a problem they didn't see with 3.2.1.
Another EKF Variance issue! Running 3.3-rc5
As per many previous posts I also have been having EKF Variance issues - basically the same story, Pre-arm is fine, then arm the craft and get EKF Variance on the Mission Planner HUD screen. I have read many posts on this but finding it hard to understand if this is indeed my setup causing the issue, or is it something in 3.3-rc5. As a result, I have reconfigured the location of all the components on my F550 Hexa to keep the power equipment inside the central body, whilst putting the Pixhawk up on top on its vibration mount. I can not get rid of the EKF Variance issues no matter what I try. I just installed a brand new Pixhawk (HK 'Belize' version v2.4.6 hardware from Banggood), but no improvement with EKF Variance issues (also as an unrelated issue to 3.3 I still have the same regular bad gyro/accel issues as I had on my old Pixhawk, resolvable fr an entire flight by shorting the power module before connecting batteries - few other posts on this IMU2 Vcc filter issue).
OK, for info, it is a F550 hexa with extended arms (pic below). It has Turnigy Multistar 2213-935KV motors (with 1147 carbon props), Hobbywing X-Rotor 20A ESCs, 2x3s 5800mah LiPos connected in parallel. I am using a Crius 6s capable power module with 2 sets of XT60 battery cables soldered on. On the top deck there is the Pixhawk, the FrSky X8R Rx, a PPM->SBus decoder (for the gimbal), the radio telemetry radio (433MHz), and the UBlox M8N GPS/compass on a stick mounted puck. The middle deck has the power module, a voltage converter (for feeding retracts independently with 6v), a PWM operated switch (for switching on/off lights), a Teensy 3.1 (for FrSky telemetry conversion) and a MinimOSD. It will have a 600mw VTx on this level also once I hook it up. The next level down is a battery tray, onto which the retracts will be bolted (currently not fitted due to crash damage). Underneath are carbon tubes for attaching the 3 axis x-cam gimbal (also damaged by crash so not presently fitted). For reference of component placement, here is a pic:
I am desperate for some clues as to what might be causing the EKF Variance issues. I have attached a log file (captured with the log_bitmask 655358). As mentioned I just fitted this Pixhawk tonight and immediately installed 3.3-rc5, restored the settings from my previous Pixhawk and did both compass and accel calibrations - outside were there is less iron to pull the mags off. This log captures me powering on the craft indoors (no props), so no GPS signal; I arm as soon as the pre-arm completes, the props spin up, I rev up the throttle, back to idle and disarm. As I said, as soon as it was armed and motors spinning, the EKF Variance message appeared on the HUD.
Any help/advice would be gratefully received - I'm at a complete loss as to how to now proceed with this copter build.
Cheers, Paul
4.BIN
Hi Paul,
I have been having similar issues. If you set the EKF Failsafe to Land even in Stabilise (I think the param value is 2) do you see the copter arm and then go into Land mode?
-
403
-
404
-
405
-
406
-
407
of 558 Next