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

    • Developer

      Hi Pomaroli,

      I have not been happy with the aggressiveness of Yaw after Autotune. I have worked out why and the next release will result in much sharper Yaw response after Autotune.

      The problem was I was not using the full throttle range for the yaw test and backing off the acceleration as well. The new Autotune will still back the acceleration for roll and pitch off to 90% and Yaw to 75%. So you can increase both of these a little before getting to the limit. I chose these numbers to give sharp performance without any overshoot. For fpv racing you may want to increase these until you see a little bounceback after big inputs.

      For racing though I tend to find that lower rates and accelerations help with smooth flying provided it doesn't get too slow. The lower accelerations only tend to be a problem if you want to do those really fast flips and rolls. Then you need to push the acceleration to the absolute limit.

  • After i got sorted a few mechanical things out the copter now works pretty well.

    i have only the problem that i can't setup THR_MID as needed. my copter is build for acro and it's very very powerfull, THR_MID should be set to round about 230 but when i try to make this change in mission planner after save and reload of the settings, the value returns to be @min value of 300.

    I'm using rc5, could this please be changed for rc6 ?

    • Developer

      hi Pomaroli,

      I set it in the parameter tree. It doesn't reset there. But it seems you tried to do that. Maybe you need to look at it there too.

      • On the tree it shows 250 and on the list 300 so not sure which value is active and will be writen to the controller.

        • Developer

          Hi Pomaroli,

          Save the parameter file and see what it says there.

    • Peter,

      mainly i use it for Acro and FPV and rare also for auto flight and all the other cool stuff i don't want to miss.

    • Acro with the pixhawk, is it as good as the naze32 with cleanflight or baseflight?

      And what are your specs of the acro machine with pixhawk?

      • Developer

        Hi Peter,

        That is a hard question to answer. I has some advantages in the basic ACRO performance and probably some disadvantages.

        Some of our advantages is our throttle linearisation is much better than TPA. We have a variable Yaw mix that lets you tune the point at which your copter spins out rather than roll roll or pitch (very extreme flight here). Depending on the controller and pid choice you have the pixhawk will provide significantly better stability at maximum and minimum throttle. The other big difference between Arducopter and some of the other autopilots in ACRO is we use a stabilized acro controller. That means that when you are going through extreme maneuvers (fpv racing), the copter may cavitate and drop a prop but it will bounce back to your last position.

        All this is heavily dependent on how well you set up the controller and this setup wouldn't be practical if Autotune didn't do most of the work for you. We are also working hard to ensure we can squeeze every last bit of performance out of a given frame.

        The other point I want to highlight: There is great work being done in all of these autopilots and they are achieving fantastic performance, the points I made above may not apply to all other autopilots. Arducopter is a little behind in some small areas and way ahead in others. Because we aspire to be the best across the board it is hard to push the development of ACRO as fast as I would like to.

        What I can confidently say is that the pilot will be the biggest limiting factor given a well setup and manufactured copter.

        I would say the biggest disadvantage arducopter has in this space is the size of the controller. I am hoping we can get a next generation micro pixhawk in the formfactor of the naze32 / multi wii boards.

        Still to be implemented is full quertonion stabilization (currently use euler angles). We want to do an update of the code to run the rate loops with the gyro read and bypass the io chip. This will ensure we have the absolute minimum latency and jitter. To improve acro further we will need new ideas.

        • For smaller Copters i would go for a multiwii just because of the missing room for bigger Controllers and the fact that there are good Community support.

          It would be really nice to see a Pixhawk mini from 3DR.

          @Craig i've seen such coming from China, but there are still a lot of adaption to do.

          Did you see some fully compatible ?

          • Other than the wires they are fully compatible. They are "full" pixhawks as far as the firmware/GCS is concerned. 

            2 issues I have with them are [and now there is a V2 that fixes one of them] all the leads are wired backward, so the PM has to be re-wired and it has no speaker or battery.

            But it's 1/2 the size and weight and now you can even get them in a case :)

This reply was deleted.

Activity

T-MOTOR liked T-MOTOR's profile
14 hours ago
DIY Robocars via Twitter
RT @gclue_akira: 柏の葉で走行させてるjetracerの中身 #instantNeRF #jetracer https://t.co/giVvuE4hP7
Jul 4
DIY Robocars via Twitter
Cool web-based self-driving simulator. Click save when the AI does the right thing https://github.com/pncsoares/self-driving-car
Jul 4
DIY Robocars via Twitter
RT @donkey_car: Human-scale Donkey Car! Hope this makes it to a @diyrobocars race https://www.youtube.com/watch?v=ZMaf031U8jg
Jun 25
DIY Robocars via Twitter
Jun 25
DIY Robocars via Twitter
Jun 16
DIY Robocars via Twitter
RT @GrantEMoe: I won my first @diyrobocars @donkey_car virtual race! Many thanks to @chr1sa @EllerbachMaxime @tawnkramer and everyone who m…
Jun 13
DIY Robocars via Twitter
RT @gclue_akira: JetRacerで自動走行したコースを、InstantNeRFで再構築。データセットは別々に収集 #jetracer #instantNeRT https://t.co/T8zjg3MFyO
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: SPC 3.0 Now the motor also works. This car is doable. I just need to design a deck to mount my compute and sensors. http…
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: My new car SPC 3.0. https://t.co/CKtkZOxeNQ
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: High speed at @diyrobocars thanks @EdwardM26321707 for sharing the video https://t.co/o4317Y2U1S
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: Today at @RAMS_RC_Club for @diyrobocars. Used @emlid RTK GPS and @adafruit @BoschGlobal IMU. Lap time 28s https://t.co/R…
May 28
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
More…