Copter-3.3 beta testing

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!

Michael,

Thanks very much for the log. As expected the gyro offsets in this 37.bin log from a good flight are much lower which points towards either a bad gyro calibration or a temporary sensor problem on the bad flight.

Paul, Tridge and I reviewed the earlier log and Paul thinks it's a hardware issue with the 2nd IMU's gyro. He says the gyro bias on the 2nd IMU changes by 14deg/sec during the 1.5min of the flight but ardupilot's EKF can only handle 6 deg/sec per minute of gyro drift. This is why the attitude estimate goes off.

Next steps are:

We wonder if this problem is repeatable on your board. Could you do a bench test (i.e. plug the pixhawk into your computer, no need to plug in the battery), turn on Logging-while-disarmed and then arm the vehicle and raise the throttle for 2min? The logging-while-disarmed can be enabled with a checkbox on the LOG_BITMASK parameter on the Standrad Param page of the latest beta MP.
You might want to replace the board or disable the 2nd IMU by setting INS_USE2 to "0".
On the software side we're going to test some additional pre-arm protection which will involve turning off the 2nd gyro calibration and replacing it with a check that the EKF innovations are good and that the two IMU rates agree with each other.

Replies

Michael Burmeister September 16, 2015 at 3:54am

I just flew my IRIS with 3.3.RC11 and had several EKF errors and crash in Stabilize mode. I think my Pixhawk is going bad but can't fully understand why it became unresponsive.
- Developer
  
  Randy > Michael Burmeister September 16, 2015 at 4:57am
  
  MichaelB,
  
  Thanks for testing and sorry about your crash. It looks like DCM and EKF's pitch estimate diverged slowly over the 1.5min of the flight so that by the end they disagreed by nearly 40degrees. Normally that indicates a bad gyro calibration and it seems like the 2nd IMU's gyro offset was very large (14deg/sec).
  
  Do you have a log from an earlier successful flight so that I can compare the gyro calibration results?
  
  Paul (EKF master) and I will review this again tomorrow. I worry that it's related to the vehicle having taken off without GPS lock. Or maybe we need additional checks around the gyro calibration.
- Michael Burmeister > Michael Burmeister September 16, 2015 at 4:23am
  
  Here is a link to the log of the flight: 39.bin
  - Michael Burmeister > Michael Burmeister September 16, 2015 at 5:51am
    
    Oops, That's not right. Here is the correct log file: 37.bin
    - Developer
      
      Randy > Michael Burmeister September 16, 2015 at 8:43pm
      
      Michael,
      
      Thanks very much for the log. As expected the gyro offsets in this 37.bin log from a good flight are much lower which points towards either a bad gyro calibration or a temporary sensor problem on the bad flight.
      
      Paul, Tridge and I reviewed the earlier log and Paul thinks it's a hardware issue with the 2nd IMU's gyro. He says the gyro bias on the 2nd IMU changes by 14deg/sec during the 1.5min of the flight but ardupilot's EKF can only handle 6 deg/sec per minute of gyro drift. This is why the attitude estimate goes off.
      
      Next steps are:
      
      We wonder if this problem is repeatable on your board. Could you do a bench test (i.e. plug the pixhawk into your computer, no need to plug in the battery), turn on Logging-while-disarmed and then arm the vehicle and raise the throttle for 2min? The logging-while-disarmed can be enabled with a checkbox on the LOG_BITMASK parameter on the Standrad Param page of the latest beta MP.
      
      You might want to replace the board or disable the 2nd IMU by setting INS_USE2 to "0".
      
      On the software side we're going to test some additional pre-arm protection which will involve turning off the 2nd gyro calibration and replacing it with a check that the EKF innovations are good and that the two IMU rates agree with each other.
      - Michael Burmeister > Randy September 17, 2015 at 6:24am
        
        Here are the two logs I got doing the bench test. First one 40 just after turning on logging and the second one, 41 after letting it sit for a while and turning it on.
        
        41.bin 40.bin
  - Michael Burmeister > Michael Burmeister September 16, 2015 at 5:47am
    
    Here is an earlier flight with no issues doing a Circle: 37.bin
    
    Also I have another copter with similar design and it flies just fine.
Richard Kennedy September 15, 2015 at 1:49pm

Just confirming the compass does not need to be recalibrate after 3.3 install just the accelerometers correct?
- Shawn McCracken > Richard Kennedy September 16, 2015 at 7:02am
  
  Did you get confirmation on this? I'm curious too.
  - Richard Kennedy > Shawn McCracken September 16, 2015 at 4:51pm
    
    No... so I guess I'll find out when I update over this coming weekend. I guess not or it would say so. I hope it doesn't because for whatever reason it sometimes takes me MANY tries including the motor compensation before it stops complaining

of 558

This reply was deleted.

Discussions

Copter-3.3 beta testing

Replies

Activity