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
Path Planning for Object Avoidance (aka Bendy Ruler and Dijkstra’s) replaces “Dodge” avoidance
Complex Fence support (aka stay-out zones)
Lua scripting support on the flight controller
New flight controllers:
a) Hex Cube Orange
b) Holybro Durandal
Attitude Control changes:
a) Attitude Control filters on target, Error and D-term (see ATC_RAT_x_FLTT/FLTE/FLTD)
b) Harmonic notch filter
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
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
Frames:
a) BiCopter support
b) OctoV mixing improvements
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
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)
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
Landing Gear:
a) Retracts automatically after Takeoff in Auto completes
b) Deployed automatically using SRTM database or Lidar
UAVCAN improvements:
a) dynamic node allocation
b) SLCAN pass-through
c) support for UAVCAN rangefinders, buzzers, safety switch, safety LED
Serial and Telemetry:
a) MAVLink Message-Interval allows reducing telemetry bandwidth requirements
b) SERIALn_OPTIONS for inversion, half-duplex and swap
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!
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.
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?
@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.
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
Try these Loiter settings, or at least compare to you current values:
LOIT_ACC_MAX 600
LOIT_ANG_MAX 0 (uses ANGLE_MAX value, 6000 in my case)
LOIT_BRK_ACCEL 300
LOIT_BRK_DELAY 0.30
LOIT_BRK_JERK 300
LOIT_SPEED 1250
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_ACCEL 100
WPNAV_ACCEL_Z 100
WPNAV_RADIUS 800
WPNAV_RFND_USE 0 (unless you’re using a rangefinder)
WPNAV_SPEED 800
WPNAV_SPEED_DN 150
WPNAV_SPEED_UP 250
WP_NAVALT_MIN 0 (could by a positive value like 1 or 2)
WP_YAW_BEHAVIOR 3
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?
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.
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!
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.