Discussions

Developer

Copter-3.3 beta testing

Posted by Randy on April 11, 2015 at 8:15pm

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

Tags: 33, apm:copter, arducopter, beta, testing
Email me when people reply –
Follow

Replies

            • Andy Piper > Nathaniel Caner September 20, 2015 at 8:55am

              The gyros should both have a mean around 0 and indeed should track each other pretty precisely. Here is a graph from my bad pixhawk where IMU2 has a lot of temperature related drift. You can see that they start in agreement and then IMU2 quickly goes off. This caused me all sorts of problems until a change was made to update the learning rate (can't remember which RC). Yours never agree. I looked at your other log - that doesn't look right either although the EKF looks happy. Seems weird since the gyro calibration should set them up well.

              I also attach a comparison with my AUAV-X2 where you can see the gyros track each other precisely.

              In RC11 you can turn off one or other of the IMUs (INS_USE_0, INS_USE1), I suggest you try turning off IMU 2 and see if that helps.

              All my opinion, so I could be completely wrong :)

              GyroDrift.jpg

              AUAV.jpg

              https://storage.ning.com/topology/rest/1.0/file/get/3702886109?profile=original
  • Andy Piper September 19, 2015 at 11:05am

    Can anyone tell me if the EKF MAG innovations (EKF4->SMX/SMY/SMZ) are a combination of the errors of both compasses or just the primary? If both, is there any way to only use the primary?

  • Kurt September 18, 2015 at 5:45pm

    Question for one of the dev team-  Any issue with running two separate gps units? 

    I have a M8N w/ mag and a CN06 (no mag), running AC 3.3 RC11, the M8N is primary and CN06 is secondary on Serial.  Everything appears to work fine but I'm just wrapping this build and have not test flown it yet.  I also set the GPS mode to 'pedestrian' since this will be a large quad for photography / recon.  Would like to know if i may run into an issue with this setup under 3.3.

    The only error I'm encountering in MP is a constant "bad ahrs", even though hdop / sat / gps lock is all very good as are the EKF monitor readings- everything is well within "green" parameters, EKF text is white on the HUD, so I don't know what would keep popping the bad ahrs message. It does not go away.  BTW i got the bad ahrs message with only the single M8N before i added the CN06. should i ignore the message?

    mag cal / accel cal are fine. i did re-cal several times though just in case that was the cause. no love. thanks in advance, as always I greatly appreciate your hard work.

  • Ivan R September 18, 2015 at 12:54pm

    i think this setting is new to AC3.3, but not sure its very clear......the description is a bit confusing....does it mean that when there is a GPS glitch or no GPS at all that there is a choice to trust DCM more or EKF more? I thought from 3.3 onwards EKF would be the default....not sure how to even test this option....any thoughts?

    2015-09-18_15-04-54.png

  • Will Fellmeth September 18, 2015 at 5:28am

    Hello internet,

    I was wondering if anyone had an update of the arducopter 3.3 feature of outputting NMEA GPS data from the telemetry 2 port on the pixhawk, called a SerialManager function. I found this (https://github.com/diydrones/ardupilot/issues/1774) thread on get hub that has the functionality request but I cant find anymore info on in. I scoured the wiki for info but could find it. Thanks in advance ya'll!

    Cheers,

    Will F

  • Scott W September 17, 2015 at 6:59am

    Hi,
    I made a few posts about GPS drift and other seemingly GPS related issues. 
    I was using an inexpensive RTFQuads m8n.  I got one of the CSGShop ones, and it is actually much better!  I was skeptical, but it definitely drifts less now.   It's also clearly using higher quality components.  Its battery stays charged.  It gets satellites in seconds rather than minutes.. 

    I'm concerned that while I was having GPS issues, copter tried to fly away a couple times.. Copter would not switch in to Loiter mode, etc.  There was nothing in the logs, that I could find, to indicate any issue. (always had over 10 sat's, under 1 HDOP)  But, the GPS was certainly causing some problems.

    • Paul Atkin > Scott W September 17, 2015 at 9:44am

      What is a bit problematic about all this - I get sometimes fine results from any GPS units and sometimes there are obviously some issues, but there is no obvious way to raise any alert or quantify level or GPS correctness that results in the unexpected behavior. RTFQ or CSG or complete no-name unit should not matter that much as long as GPS returns a proper result set, but obviously something else is going on that affects all this.  

      But it is quite obvious now that CSG units seem to be much less problematic than anything else and even if they cost twice more than their competitors, it is probably still a best choice. It is just too bad we cannot figure out how to measure this specific parameter, what makes one unit to work fine and other to produce garbage readings.

      • Scott W > Paul Atkin September 17, 2015 at 9:55am

        I'll be happy to share logs, if anyone is interested. 
        I will gladly plug in both GPS units to either the same pixhawk, or two different ones, and log them sitting next to each other. 

        I've done several tests now, and there is definitely a big difference in performance. 


        The CSG one was 3x the cost, and I'd say from the past two days results, it is 3x better!

        • crayfellow > Scott W September 17, 2015 at 10:01am

          I have no issue paying more for a significantly more effective implementation. It's true all of these have M8N but different antennas, trace/PCB quality, and antennas certainly will make a difference. My question is: what CSG board are you using? Is there one that is either in a case like the 3DR/rctimer/etc. or have you found a case that works? All that I have seen are bare boards. DIY is fine for one-offs but I need something repeatable for research craft.

          Personally all I have ever used is the rctimer M8N and it has seemed fine for me, but I wouldn't mind an improvement if the CSG boards provide that.

          Cheers!

This reply was deleted.

Activity