Copter-4.0.0-rc1 available for beta testing!

Copter-4.0.0-rc1 has just been released for beta testing and should appear in the ground stations’s “Beta Firmwares” link within the next couple of hours. This is just the first release candidate and as such includes a huge number of enhancements over 3.6.11. The most important change are listed in the ReleaseNotes and also copied below.

Changes from 3.6.11

  1. Path Planning for Object Avoidance (aka Bendy Ruler and Dijkstra’s) replaces “Dodge” avoidance
  2. Complex Fence support (aka stay-out zones)
  3. Lua scripting support on the flight controller
  4. New flight controllers:
    a) Hex Cube Orange
    b) Holybro Durandal
  5. Attitude Control changes:
    a) Attitude Control filters on target, Error and D-term (see ATC_RAT_x_FLTT/FLTE/FLTD)
    b) Harmonic notch filter
  6. Flight mode changes:
    a) ZigZag mode (designed for crop spraying)
    b) SystemId for “chirping” attitude controllers to determine vehicle response
    c) StandBy mode for vehicles with multiple flight controllers
    d) SmartRTL provides warnings when buffer is nearly full
    e) Follow mode offsets reset to zero when vehicle leaves follow mode
    f) Upward facing surface tracking using lidar
    g) Circle mode points more accurately towards center
  7. Traditional Heli:
    a) Removed the parameter H_LAND_COL_MIN and functionality now uses H_COL_MID. CAUTION: ensure H_COL_MID is set to collective blade pitch that produces zero thrust
    b) Incorporated a rotor speed governor in rotor speed control (RSC)
    c) Moved all RSC parameters to the RSC library
    d) Converted throttle curve parameters to percent
    e) Converted RSC_CRITICAL, RSC_IDLE, and RSC_SETPOINT to percent
    f) Created swashplate library that has presaved swashplate types for use with Heli_Single and Heli_Dual frames
    g) Motor interlock with passthrough settable through RC option feature
    h) Removed collective too high pre-arm check
    i) Added virtual flybar for Acro flight mode
    j) Fixed H_SV_MAN minimum and maximum settings for Heli_Dual
  8. Frames:
    a) BiCopter support
    b) OctoV mixing improvements
  9. RC input/output changes:
    a) Serial protocols supported on any serial port
    b) IBUS R/C input support
    c) DO_SET_SERVO and manual passthrough can operate on the same channel
  10. Battery improvements:
    a) Up to 10 batteries can be monitored
    b) “Sum” type consolidates monitoring across batteries
    c) Fuel flow battery (for use with gas tanks)
  11. Sensor/Accessory changes:
    a) Robotis servo support
    b) KDECAN ESCs
    c) ToshibaCAN ESCs
    d) BenewakeTF03 lidar
    e) SD Card reliability improvements (if card removed, logging restarts)
    f) Yaw from some GPS (including uBlox RTK GPS with moving baseline)
    g) WS2812 LEDs (aka NeoPixel LEDs)
    h) NTF_BUZZ_VOLUME allows controlling buzzer volume
  12. Landing Gear:
    a) Retracts automatically after Takeoff in Auto completes
    b) Deployed automatically using SRTM database or Lidar
  13. UAVCAN improvements:
    a) dynamic node allocation
    b) SLCAN pass-through
    c) support for UAVCAN rangefinders, buzzers, safety switch, safety LED
  14. Serial and Telemetry:
    a) MAVLink Message-Interval allows reducing telemetry bandwidth requirements
    b) SERIALn_OPTIONS for inversion, half-duplex and swap
  15. Safety Improvements:
    a) Vibration failsafe (switches to vibration resistant estimation and control)
    b) Independent WatchDog gets improved logging
    c) EKF failsafe triggers slightly more quickly

We are pretty confident that the code is solid but because it hasn’t gone through a full beta testing period there are undoubtedly some issues so please be careful during testing and please report any issues you find either in this chat or preferrably open a new topic.

Thanks very much in advance for helping us test and also thanks to the many developers and users that have contributed to this release!

By the way, there are 4 known changes that we will include in a follow-up release. If you’re really interested in the details these 4 items can be seen here in the “PRs” column.

We’ve done a little better than usual in getting the wiki up-to-date (thanks to @hwurzburg and @brunoolivieri) but we still have some updates still to do to explain how to use some of the new features.


This is awesome news!

Thanks to Randy and the ardupilot team! Also thanks to Sid, JC, Michael and the full CubePilot team!

Cube Orange has a first “non master” firmware!

Remember that this is Beta till Randy says otherwise!

Another PR that’s urgently needed for this is the CAN compass ordering from Sid that’s either already done or very close to done!


What an impressive list !

1 Like

Is there a way to change or set the altitude speed/reaction in loiter and altitude hold? It is really slow. It looks like the copter has not enough power. When I set in stabilize mode the reaction is good. Would it be possible to make a line where we can change this reaction?

@rmackay9 Thanks for this great release!!!
Does this handle high precision float waypoints by any chance?



@Koenvrints1, yes the PILOT_SPEED_UP and PILOT_SPEED_DN control the maximum climb and descent rates.

@Corrado_Steri, no I don’t think so. The most detailed mission items we support are using long integers which gives us cm level accuracy. These were already supported in Copter-3.6.x though.

Thanks, i read about long integers but i just can’t get them to work in my program, still do not understand how to implement them.

Fantastic news outstanding work as always guys.

As a community we all massively benefit from the work you guys do.


Great News!

Some info needed on some of the new features included. Any kind of information will be helpful and appreciated.

a) The new object avoidance scheme is completely onboard the FCU? Even the Dijkstra?

b) How to interface the WS2812 LEDs ? I couldn’t find any docs describing the process.
Also is the support right now only for 1 LED?

We will start testing these out once this info is available.

Thanks in advance!

But the reaction is slow. We already have that parameters on max. Moment you give an imput on you stick the reaction is slow after a while you get the max speed but not like all the other imputs

Hey Ian -

Nice to see you over here!

1 Like

Try these Loiter settings, or at least compare to you current values:

LOIT_ANG_MAX 0 (uses ANGLE_MAX value, 6000 in my case)

This should give you a “sporty” loiter but retaining the advantages of loiter over just Pos Hold.
If yours were messed up, probably check these too for good measure:

WPNAV_RFND_USE 0 (unless you’re using a rangefinder)
WP_NAVALT_MIN 0 (could by a positive value like 1 or 2)

Excellent! Copter 4 is a big jump in features and functionality! Copter 4.0 is also the first release version fully compatible with all Solo copters and included with Open Solo 4 now.

@rmackay9 can you add the slew rate limiting to the change list and release notes?

1 Like

@Koenvrints1, Increasing PILOT_ACCEL_Z may also help with the vertical acceleration.


Re using long integers for commands. I think you’ll see some mavlink messages that have _INT at the end. These are the ones to use. For example COMMAND_INT is the equivalent of COMMAND_LONG but uses long integers (instead of floats) for the lat and lon. MISSION_ITEM_INT is the equivalent of MISSION_ITEM.


Yes, BendyRuler and Dijkstra’s are done onboard the flight controller. There are large differences in the two algorithms but the biggest difference is perhaps that BendyRuler can avoid obstacles sensed by lidar (and fences) while Dijkstra’s can’t be used with Lidar but it is much better at getting around complex fences and stay-out zones.

Thanks for the info!

So Bendy Ruler will be more effective with a 2D Lidar as compared to when using a 1D Lidar right?

And having Dijkstra dodging no fly zones …if these (no fly zones) are known before hand couldn’t we just plan the auto mission accordingly? Please provide your insights I think I don’t know the whole picture here.

Also found the instructions for interfacing WS2812 in the Copter wiki - great!

Will get straight to testing!


Yes, that’s right on all counts. BendyRuler will work better with a 2D lidar. Dijkstra’s should work better than BendyRuler if the situation allows the user to define the places to avoid by setting up no-fly zones.

Great that you found the neopixel wiki.

Great! Thanks for the help.