Developer

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!

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • V3.3 RC10 doesn't let me set the Initial_SetUp\Optional_Hardware\Battery_Monitor\Sensor to "4: 3DR Power Module", it always reverts to "0: Other".

    • I have the same issue.  I'm using attopilot 180's.  One other thing I noticed, even though is reverts back to "other" the current and voltage multipliers are correct for the 180.  If your settings aren't, just write them down under the 3DR option, them change to other and manually enter them under the "other" option.

      • that is MP's issue. as long as the amps-per-volt and volts-per-volt values are consistent all is good. 

      • For me the calculated values didn't match the real used mAh, it was about 1/3 too high. I need to check the A metering with a digital multimeter while the motors are running as the A metering doesn't seem to be correct at low values. I will need to adjust the multipliers a bit.

        Weird as the values in the complete parameter list seem to be correct for the 3DR Power Module, it's only the GUI that is not showing the setting.

        • This is why you look at your motor/prop/cell combo and calculate theoretical hover current at given AUW. Than using something like "Turnigy watt meter" placed between your flight pack and the copter power inlet, throttle up in stab mode to the current calculated earlier (strap your copter to the ground beforehand unless you are looking for a flying blender), compare the current on the turnigy watt meter to the one reported in the MP, than adjust your amps-per-volt to achieve the value reported by the turnigy watt meter. Now, since most of the Chinese amp sensors are not really linear (unlike my favorite attopilot90a and 180a), it is a good idea to take 4-5 more current measurements in 10-15 amp intervals and compare the values, than you should try to approximate the "correct" amp-per-volt value. After this procedure I usually get pretty close total mah used vs total amps recharged value. On my 20Ah hexa this number ranges in about +(200-400)mah  depending on the flight (I use attopilot180a). on some Chinese PMs, which came with **hawks I happen to get, the closest I was able to achieve was about +300ish for 5Ah 6s pack. Also 3DR power module shows similar precision with stock values and I never bothered to calibrate that one. 

        • That reminds me - has anyone found a better method of calibrating the current measurement than running up the motors? That method is impractical for big 15+" prop craft.

          I guess you could use the FrSky hall effect current sensorand make a correlation that way, with it in the air.

          • @ crayfellow +1 I fully agree, hall effects are so much better than measuring the voltage of a shunt resistor.

            insulated quality current sensors. are another kind but very good too.

            Their range of sensors let you choose the "adapted" kind,

            Using these quality current sensors gives reliable and repetitive measurements.

          • Exactly what I do. I use the FrSky current sensor and tweak parameters in MP over several flights till I'm happy with it. I have it setup so that the attopilot sensor is sending back data on one battery and the FrSky sensor is sending back data on the other battery. Even though I am use one batteries consumption to adjust the other batteries current consumption it seems be fine or at least close enough.

  • I'm having some strange issues.  I think it's GPS issues, but I don't see anything wrong in the logs. 
    It tired to fly away in loiter a couple weeks ago, and I've never figured out why.  GPS looked fine at the time.
    Today I was unable to switch to loiter.  I got "err flight_mode-5" in the log, when I tried.   Then, that same flight I was a little lost and flew out of radio range, and it switched to "land" instead of RTL. (It is set to RTL on failsafe) It did land successfully.   I had 3d GPS lock the entire time.

    Could someone look at the log and let me know if you see a reason for the flight mode error, or its inability to RTL?

    I've been flying this copter on 3.3 since about may, and haven't had any issues like these until I updated to rc10 or 11..
    but, I definitely can't say the issue is 3.3 related.   
    Thank you

    2015-09-13 19-09-41.bin

    • I saw something similar on the mission planner app with disarmed Copter:

      The position was about 50 m away from the real position. With the M8N I had fast twitching number of satelites (12 - 18) with HDOP below 1. There was a good view to the sky (outdoor) I leave the copter disarmed for over 5 min but the position was at a more or less same position still wrong. Then I repowered the whole system the problem was instantly gone. I did not have any logs.

This reply was deleted.

Activity