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

      • Emin, we will never stop advancing the code.  If you don't like testing, then don't test the RC's and stick with the stable releases.

        • Pfffff...!

      • My thoughts exactly. Couldn't have said it better. I GREATLY appreciate all the efforts from the devs and testers!!! I don't want to criticize... But it would be nice to just fly without issues. I keep getting DCM bad heading in 3.2. I guess 3.3 fixed this but then it seems there's new issues? So I'm not sure what to do. It's not like I have a strange set up it's a standard quad gps and mag on a mast did compass mot 3 times, reinstalled FW, re-did calibrations.. Boy I have done all that a lot :[ It does fly great though. very smooth. poshold is excellent!! But my pulse rate goes up when I hear DCM bad heading then Landing!!! Not complaining though.. just saying ....

        re- third compass +1 !!! I think my DCM bad heading would go away if I had the option to completely ignore the internal mag. Also it would be fantastic if there were two I2C ports so you don't need that splitter thus triples your wires and potential points of failure. 

        • How much did we spend for the software we use?  IMHO it is a small price to pay and part of the fun in the process.  Along the way I have had more stable flights than not and almost every crash as been the result of operator error, either at the controls or the workbench.  I find it staggering that we have the sophistication in product available to us.  A big thanks to all the people that work to make this happen!

          Cheers,

          RB

          • I agree wholeheartedly. I’m just giving a  little input to the process perhaps. I wonder if this would make sense…. when 3.3 came out it fixed a couple issues with 3.2. So maybe it would be wise to go add those patches to 3.2 and then add a note to that thread advising people to update 3.2 again. This way there is always a ‘stable’ release that is being made even better while at the same time working on the next beta. Know what I mean? It seems now the only way to address some issues with 3.2 is to go to 3.3 beta. But then there might be new issues. I don’t know maybe that already happens to some extent and I don’t even know about it. I have a LOT of enjoyment with this and it is utterly amazing when you think about how all this actually works at all!!! It’s come a long way since my first .049 ‘U’ control!! lol 


            I am going to update to 3.3 and see if my issue goes away and will report. Thanks Devs for all your hard work. That old saying no good deed goes unpunished probably applies to your situation :]
            • I don't know, I have been following this tread from the beginning and people are having issues I haven't seen.  I had a couple of problems with altitude and UAVCAN in the first 3.3rc but that is all fixed and I have had no issues on two quads and a medium sized hex.  For general flights I trust 3.3 completely but have not tested the new features that are having issues(Flow, landing gear etc.).  I even uploaded 3.4 Dev. on my quad this morning, did an autotune and it flew remarkably well.  I think these guys are very close to completely stable firmware, especially since the hardware is far from perfect and prone to multiple problems with layout and construction.  If you get GPS noise or glitches in your car nav or smartphone you don't even know, with these things you definitely find out.  All in all this is a great experience and a great positive community.

              Cheers,

              RB 

              • I updated to 3.3. It advises me I need to re-do the accell calibration as expected. I try to do this with APM2 and it won't work. It times out even though I clicked okay. It just won't move on and let me calibrate. I now get multiple weird warnings on my Taranis saying it's armed even though it isn't. It says it's flipping between multiple modes continuously. hmm is this related to Notes 2 above? who knows. I now have different new problems. Probably an APM2 issue?? Very frustrating even though it is free. I'll go back to 3.2 and live with the DCM bad heading for now I guess. 

                • Your taranis issues are down to teensy/lua code that is known to be buggy on 3.3 and has nothing to do with the core apm project.  It's a shortcoming in the teensy code.  apmplanner2 is also not working fully properly with 3.3 yet - the latest master mostly works fine but still has a few small issues.  They both work just fine with stable 3.2 code.  

                  Worth noting that previously the devs did do stable point releases to fix bugs while releasing beta versions of the next branch (eg 3.1.4/3.1.5), I guess in this case though the changes to 3.3 are so extensive and time consuming their focus is just to get it stable and out the door.  There are probably a lot of fixes that just can't be backported to 3.2.

                  • I'm certainly no expert on this issue but I'm using the original teensy code posted by Rolf Blomgren and works just fine with 3.3 and 3.4. Sometimes I have to reboot to get the teensy to pass through. Richard, be sure to set baud rate for Serial2
                • Richard, you installed AC 3.3 rc5 on APM 2?

                  I was thinking that the highest compatible version of AC for APM 2.x is AC 3.2.1

This reply was deleted.

Activity

DIY Robocars via Twitter
May 15
DIY Robocars via Twitter
May 14
DIY Robocars via Twitter
May 13
DIY Robocars via Twitter
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
May 13
DIY Robocars via Twitter
May 11
DIY Robocars via Twitter
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Noticed my car zigzagged in last run. It turned out to be the grass stuck in the wheel and made the odometry less accura…
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Test my car. RTK GPS worked great. Thanks @emlid for their support. https://t.co/EkQ6qmjmWR
May 8
DIY Drones via Twitter
RT @chr1sa: @kane That's @diydrones circa 2009. Still have a box of those Canon cameras that we used to strap into planes, just like this.…
May 3
DIY Robocars via Twitter
RT @chr1sa: Our next @diyrobocars race is going to be outside at a real RC racetrack in Fremont on May 28. Fully autonomous racing, head-to…
Apr 30
DIY Robocars via Twitter
RT @f1tenth: Our Spring 2022 F1TENTH course @PennEngineers is coming to an end with a head-to-head race as a big finale. So proud of our st…
Apr 26
DIY Robocars via Twitter
RT @DanielChiaJH: I wrote a thing! Throughout the development of my @diyrobocars car I've been using @foxglovedev Studio to visualize and d…
Apr 23
DIY Robocars via Twitter
RT @SmallpixelCar: My new car for high speed. Low body, everything ( @NVIDIAEmbedded Jetson Xavier NX, @emlid RTK GPS, IMC) under the deck…
Apr 23
DIY Robocars via Twitter
Apr 21
DIY Robocars via Twitter
RT @f1tenth: F1TENTH Race training setup @PennEngineers for our upcoming ICRA2022 @ieee_ras_icra competition. @OpenRoboticsOrg @IndyAChalle…
Apr 21
DIY Robocars via Twitter
RT @fatcatFABLAB: Proud to be hosting a restarted DIY Robocars NYC Meetup April 26. Come by if you want to talk about and race self-driving…
Apr 17
More…