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!

Views: 374811

Reply to This

Replies to This Discussion

Thank you Randy

If I'm not able to 'save' my GPS unit by loading these parameters from another unit, what's the next step ? 

I mean, I've only changed a few parameters within ublox ucenter software, how can that make a gps useless :|

Randy, Leonard,

After finally be able to download RC9, due to very bad internet connections at my current holiday location, yesterday I had the first flight with this firmware.

In the meantime read the Blog post of Leonard, about the Motor Bel Play, and the feedback from Wes which basically delivered the proof that this should bring down the Z Axis Vibrations, I removed the play on all 6 Motors (power usage is going up a little (2 amps)), as I did have quite some up and down movement on the 4114 I am using.

After taking it up, the motors already sounded much more monotone without the occasionally quick ramping up like they did in RC8, so it did fly much better as before...

In the logs however I do find clipping, but it's not going up as high as before...

Vibrations seems to be lower as well, in comparison with the previous logs I looked at

Looks like the latest changes in RC9 are working out.

Thanks Devs !

Logfile : https://drive.google.com/file/d/0BwKkz56PHqS0U1lra1BZNzBNSW8/view?u...

P.S By looking at the previous log of RC8, it seemed I did have an unhealthy barometer value as well, as somewhere just 

before the uncontrolled altitude gain, the Baro switched 2 meters within 100ms, which is hardly something you can trigger by flying I guess....

I would have expected a small tweak to the EKF parameter to make the Barometer less important, but don't see the change there...? , so I guess it's done somewhere in the EKF code ?

Hi Randy,

Thanks for the feedback. I can confirm, that my followme-box works now with RC9 with the correct coordinate frame SET_POSITION_TARGET_GLOBAL_INT.

I have also done more flights with Tower in followme mode and it worked without problems. Now I was quicker in sending take off from Tower, so that I did not have to re-arm the copter a second time, which has caused the strange immediate take off (without any second take-off command in Tower) and the crash 30s later.

Yeah, I think this and the EKF viewer are really going to help people diagnose issues with their copters before they lead to a crash or flyaway.

The next step RobL and I have been discussing is a real-time "control" display.  So this would give an objective warning and measurement of how good/bad the vehicle's attitude control is.  So when the vehicle is dutifully maintaining it's desired roll, pitch, yaw (and perhaps position) this display would be all green but if it starts to lose control in one (or more) axis the display would go orange and then red.  This fits in well wit how we diagnose bad copter behaviour - normally the first question we try to answer is, "was it an attitude estimation problem or was it a control/tuning problem?".

Anyway, this idea won't make it into AC3.3 but maybe AC3.4.

I don't suppose those nice features will be in APM Planner for Mac's will they? Is a lot of what's needed for that with the GCS software itself too right? aka Bill would need to work with you guys on that for APM Planner? Sounds like a great visual way to get an idea what's going on! 

Richard,

They should go in for AP2 as well.   I've certainly raised issues for the EKF and vibe monitors to Bill Bonney and I know he was looking at them.

Excellent thank you!

AC3.3-rc10 is available for beta testing.  I've updated the main section with the changes.

The changes vs –rc9 are mostly of bug fixes and safety improvements.  This is hopefully the last release candidate before the official Copter-3.3 release.

The new EKF compass variance pre-arm check (3a) may require another release candidate because if the EKF stops using the compass there’s currently no way for it to recovery without rebooting the flight controller.  Solo-master has a solution for this that we may need to import if too many people find they can never get past the “EKF compass variance” pre-arm check but let's see!

Hi all.
With 3.3 RC9 firmware I have problems getting storm32 (firmware v80)to work while connected to pixhawk serial 4/5.
I have used following user guide to setup both strom32 and pixhawk:
http://copter.ardupilot.com/wiki/common-optional-hardware/common-ca...
Below are detailed settings I applied to pixhawk:
SERIAL4_BAUD = "115"
SERIAL4_PROTOCOL = "1"
MNT_TYPE = "4"
MNT_RC_IN_TILT = "6"
On storm32 side I have only enabled emit heartbeat.
Above settings should allow me to control gimbal pitch with rc channel 6, but nothing happens when I use channel 6 knob on my rc transmitter.
Can you let me know if by the chance this issue is resolved in lates RC10 beta?
Or maybe there is some configuration I have missed?
Can anyone confirm that communication between storm32 and pixhawk serial 4/5 is actually working?
Both telemetry ports on my controller are used so serial 4/5 is the only I have.

Hi,

I don't have a STORM32 board, but, in case you missed it, there is a bug fix in 3.3 rc10 for STORM32 serial protocol driver.

I just upgraded from -rc9 to -rc10 and noticed that my motors no longer spun up when armed. I had to change the MOT_SPIN_ARMED parameter to 75 from the default 70 to get them to spin as they did before. I hope this is the correct method.

Updated from 3.3-rc1 to rc9 yesterday on a TBS Discovery Pro.

Autotune results were fantastic, the end result was a lot less twitchy than those on previous versions. Very smooth flying. 

In addition, landings used to be very bouncy and the landing detector wouldn't trigger unless I switched from Loiter/Poshold to Stabilise, where I then was able to throttle down a lot more. 

Now the landings are much smoother - it still takes around two seconds for the landing detector to trigger while landing with Loiter/Poshold, but it's a lot better than before. Very happy about this. 

I did observe something strange, namely that the GPS HDOP value was at 99, despite having over 13 satellites. The position in the map looked stable as well, so I set "GPS_HDOP_GOOD" to 10000 and took off. It flew and hovered fine, so I'm not sure if: 

a) The GPS (CSGShop u-blox NEO-M8N) is defective

b) GPS reception was bad after all

c) It's maybe a bug introduced by a change in rc7 that affected HDOP/PDOP reporting

Log attached. 

Attachments:

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service