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

    • Could you post your PARAM file.

       AUTO-tune should create the right values for your copter. If after autotune it feels too aggressive you need to adjust the RC-feel value. in your case lower quite a bit the RC feel, have another flight and adjust accordingly after that.

      Depending on setup you might have to adjust the EXPO-CURVE for throttle but normally this only should be changed if you are way out of the norm range of setups.

  • Can we finally have Copter 3.4?will that ever go out?...or is it 3.5 already?

  • Maybe Randy or someone can answer this. 3.3 works with the Tarot 2d gimbal, does it also work with the Tarot 3DIII, and if not can this be included in 3.4? What I see of the 3DIII so far, it is a good and inexpensive gimbal. Also I am awaiting "boat mode", is there any projected date for 3.4?

  • Hi Guys 
    Is it possible to disable the announcing of the PX4v2 serial number when booting up / connecting to MP But keeping the other announcements still audible ? Its very annoying ..LOl

    Regards R

    • Yes.

      I use the little black knob.

      Works fine ;)

  • Since the latest version 3.3.3 I have a new problem with my hexacopter.
    i'll try to explain, I take off in stabilize mode and try to pass to a constant hover, while doing this, the copter increasingly becomes uncontrollable and starts to rise also if i'm take away throttle. Depending on how the wind influences are, it takes a while until the copter really reduces the speed. like a delay. During this happens the copter is not pilotable and becomes unstable.i already had some crashes because of this so i'm just try to understand whats wrong, is this a known issue of 3.3.3 ?
    it is a F550 Hexa Chassis for the prupose of Acro flying it's very overpowered. i need to set throttle mid to about 200 so you can imagine what power this thing has.i'm little bit scared and hope we can sort this out.
    • Developer

      That's very over-powered so with that low a hover throttle, there's very little room for attitude control.

      A few things that may help:

      1. lower THR_MIN if possible.  You don't want it so low that the motors stop (especially when the battery voltage is getting low) but lower than the default (130) should be possible and will give more room for the controllers to function.

      2. increase MOT_THR_MIX_MAX from 0.5 to 0.7 or maybe even 0.9.  This will allow the controllers to increase the overall throttle in order to maintain attitude control (0.9 will allow overall throttle to climb to 90% of THR_MID).  Need to be careful about this setting though because if you set the THR_MID above the vehicle's actual hover throttle then you might have some periods where the vehicle rises even with the pilot's input throttle near zero because the controllers feel they need to raise the throttle in order to keep the vehicle upright.

      • hi Randy,

        glad to hear from you, thanks for your comment.

        I set THR_MIN to 80 which seems to have a good inpact.I thought in the past this value was lower.

        To the second point i'll need some more time to do some testing. 

    • I have 3.3.3 on my F550 (replica from HK) frame and have none of the issues you describe. Saying this, my motor setup is a little under powered. By the sound of yours, I'd say its producing far too much thrust, especially for the F550 hexacopter frame which are inherently a bit on the flexible side. I have a few multi-rotors running 3.3.3 (and 3.4dev  on one of them) and all of these fly beautifully on 3.3.3 - really dialled in - but I did pay a lot of attention to balance, vibration reduction and good layout design. Like I say, in your case, without more information, my guess would say that its likely due to the combination of the frame flexibility and the overpowered motor/prop setup, which is likely inducing flex and twist into the arms (possibly oscillations) and hence vibration to be picked up by the IMUs which are probably having a tough time to produce accurate measurements, and hence inaccurate info for the FC to go on. In the 3.3 versions of Arducopter there are additional monitoring tools in Mission Planner for checking for any EKF issues, and also vibration monitors - all handy in checking for sensor and vibration issues. Also worth checking how the pixhawk is mounted on the frame - needs to reduce vibration without being too soft to allow the pixhawk to move around on its mount - which would cause false IMU measurements. Finally, check motors and props for vibrations and balance these as best as possible. My best guess though is that the exsessive thrust which is causing most of the issues. For this, you need to reduce thrust - maybe smaller props, or less LiPo cells to reduce the voltage/motor speed. If you want a really powerful copter then you need a very stiff and well balanced setup with minimal vibration. I have a 330mm quad based on Turnigy Talon v2 frame which is very powerful, and that's at the limits of the frame's capabilities and my mid throttle is 300 - yours is even more powerful on a far more flexible frame. For a more accurate analysis you really need to attach a log file. The guys in here are genius at analysing logs so probably your best bet for a more accurate response. Best of luck, Paul

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
yesterday
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Thursday
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Wednesday
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Wednesday
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Wednesday
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident: https://t.co/G1pTxQug6B
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: What a great way to connect why @diyrobocars community is so valuable and important! Have to start somewhere @IndyAChallenge…
Oct 23
More…