Copter-3.6 and Rover-3.3 have entered beta testing and can be downloaded using the Mission Planner’s beta firmwares link. Rover-3.3’s changes were announced a couple of days ago in the Rover discuss forums here.
Copter-3.6.0-rc1’s changes are in the Release Notes and also copied below.
ChibiOS support including F4BY, OpenPilot Revo Mini, TauLabs Sparky2 boards. Note: default for Pixhawk family of boards is still NuttX. Upload instructions are here.
Flight mode changes:
a) New Loiter with faster roll and pitch response, braking
b) SmartRTL (returns home using outgoing path)
c) Follow mode (allows following without relying on ground station commands)
d) FlowHold (position hold with optical flow without lidar)
Battery failsafe allows two stages of actions and monitoring of multiple batteries
New sensors/drivers:
a) Marvelmind for Non-GPS navigation
b) RPLidarA2/A3 for object avoidance
c) Winch for lowering packages without landing
d) Septentrio GPS driver robustness improved
New frames:
a) dodeca-hexa copter (12 motors on 6 arms)
b) Variable pitch quadcopter support (aka HeliQuad)
c) multicopters with vertical boosting motor (see MOT_BOOST_SCALE parameter)
Miscellaneous changes and enhancements:
a) Auxiliary switch to enable/disable RC overrides from ground station joystick
b) Barometer temperature calibration learning (see TCAL_ENABLED parameter)
c) Camera triggering by distance only in Auto mode if CAM_AUTO_ONLY set to 1
d) Compass noise rejection using COMPASS_FLTR_RNG parameter
e) Compass interference compensation for up to 4 motors (see COMPASS_PMOT parameters)
f) Command Line Interface (aka CLI) removed to reduce firmware size
g) Flight mode channel can be changed using FLTMODE_CH parameter
h) IMU notch filter to ignore specific frequencies (use INS_NOTCH_ENABLE parameter)
i) LAND_ALT_LOW parameter allows setting altitude at which vehicle slows to LAND_SPEED in Land and RTL modes
j) Mission cleared automatically on each reboot if MIS_OPTIONS parameter set to 1
k) Object avoidance configurable to “stick” to barriers (previously would always slide past)
l) PILOT_SPEED_UP, PILOT_SPEED_DN allow different max climb and descent rates in AltHold, Loiter, PosHold
m) Safety switch configurable (i.e. only allow arming but not disarming via switch)
n) Servo output rate configurable (see SERVO_RATE parameter)
o) Vehicle rotation rate limits (see ATC_RATE_P/R/Y_MAX parameters)
p) SI units in parameters, mavlink messages and dataflash logs
TradHeli improvements:
a) H3-135/140 swashplate support
b) Reversed collective option for leading/trailing edge control
c) AltHold angle limiter fix
d) Five point spline-smoothed throttle curve
parameter and log message name changes:
a) ACCEL_Z_ renamed to PSC_ACCZ_
b) ACC_ parameters renamed to PSC_ACC
c) POS_ parameters renamed to PSC_POS
d) VEL_ parameters renamed to PSC_VEL
e) FS_BATT_ renamed to BATT_FS_
f) BATT_AMP_PERVOLT renamed to BATT_AMP_PERVLT
g) PILOT_VELZ_MAX to PILOT_SPEED_UP (and PILOT_SPEED_DN)
h) RC_FEEL_RP replaced with ATC_INPUT_TC (functionality is same, scaling is different)
i) WPNAV_LOIT_ params renamed to LOIT_
j) NTUN dataflash message renamed to PSC
If you give it a try, please provide feedback in the Copter-3.6 discuss category. Thanks very much in advance to our beta testers!
TradHeli users please note that if you are employing the mode 3 three point v-curve for the rotor speed control, this mode has been changed to a 5 point spline-smoothed throttle curve. The parameters for the 3 point v-curve, H_RSC_POWER_HIGH, H_RSC_POWER_LOW and H_RSC_POWER_NEGC, were replaced with the parameters to define the 5 point curve, H_RSC_THRCRV_0, H_RSC_THRCRV_25, H_RSC_THRCRV_50, H_RSC_THRCRV_75, and H_RSC_THRCRV_100. The default parameter values are set up for a normal flight mode NOT a 3D flight mode. The defaults settings will get you close for piston heli with a collective range of roughly -2 deg to 10 deg. You will need to retune your heli rotor speed control.
The TradHeli wiki has ground school videos here that discuss how to set up the new mode 3 five point throttle curve. @ChrisOlson please post your latest excel spreadsheet that allows users to plug in the 5 points to give a graphical representation of the throttle curve. If users have any questions on the new throttle curve, don’t hesitate to contact Chris or myself.
Oh, sorry. I was not aware that Leonard and Randy had incorporated nav controller changes into the New Loiter. I have flown the New Loiter with helicopter, but not in Auto yet with 3.6. So can’t really say yet how the changes in the position controller work.
I have flown the old nav controller at 40-45 m/s with no issues once WPNAV_ACCEL was increased enough to hit waypoints.
Just installed Tradheli 3.6rc1 and I’m getting a ‘throttle radio trim below failsafe’ warning and it wont arm.
Straight update from 3.5.4
Parameter file protosv01.param (13.8 KB)
Jakob,
It is mostly like that your throttle radio trim, RC3_TRIM, is too low. I think any time the RC3_TRIM or RC3_MIN is within 10 PWM of the Throttle Failsafe value then you will get this error. Your throttle Failsafe is 975 and the RC3_TRIM is 983. Suggest recalibrating your RC transmitter or looking at status page in mission planner to see what the low value of channel 3 is and set your RC3_TRIM and RC3_MIN to that value.
Jakob also be aware the old ACCEL_Z_P has been moved to the position controller settings
PSC_ACCZ_P,0.32
For some reason my old setting was a little too sensitive in 3.6 and I had to reduce it a bit from what I used in 3.5, or the heli would collective-hop as soon as I switched to Alt Hold. I was at 0.3 and ended up reducing it to 0.25. The other settings seemed to be pretty good (so far).
There’s a new param you can set, PSC_ANGLE_MAX, that sets the frame max angle when the position controller is active. Otherwise it will use ANGLE_MAX. There is also LOIT_ANG_MAX you can set for max frame angle in Loiter. As well as the braking settings for Loiter that you can set now.
I was pretty happy with the defaults for the Loiter controller - seems to provide the smooth acceleration and braking I was used to with Old Loiter. The default for the braking delay is 1 second and if it seems to drift more than you like after moving it in Loiter and centering the stick you can set that like to 0.5 or something to make the brakes come on quicker.
Haven’t tried it in auto yet, but Randy and Leonard improved this quite a bit from the alpha that I tested a few months ago.
@lketh I looked thru the changes in the code and it appears the length of the “leash” between the actual aircraft and “ghost” aircraft is still calculated from speed, acceleration limits and position x,y. So it will still be necessary to set the WPNAV_ACCEL to a value that will provide adequate horizontal acceleration to have a suitably short “leash” to prevent the nav controller from deviating significantly from waypoints in high speed flight.
The way this works is that the aircraft flies the GPS course at a desired speed. There is a “ghost” aircraft that flies the course ahead of the real aircraft. The code calculates the length of a “leash”, or virtual “tow line”, between the real aircraft and the “ghost”. The length of this virtual tow line depends on the interaction of speed, what you are allowing for horizontal acceleration (with the WPNAV_ACCEL setting), and the position x,y estimate. To shorten this virtual “tow line” you must either decrease speed or increase the WPNAV_ACCEL.
What happens in a turn at a waypoint is that with a long “tow line” the ghost is significantly far in front of the real aircraft. So the “ghost” goes around the turn first and it pulls the real aircraft in an arc with the virtual “tow line”. This arc traveled by the real aircraft is a little different than actual path of the “ghost”.
The limits that can be set for WPNAV_ACCEL is advertised as being up to 500 (cm/sec^2) which is about a 1/2 G. With helicopters I have forced-set this to as high as 980 (1 G) to try to get a heli to bank at 75-80 degrees in high speed flight to reduce under-run on turns and pull more G’s in the turn. But there is other limits that have traditionally prevented it as it seems to cut off at about 45 degrees or so of bank no matter what, even though I have plenty of power and collective in reserve in a high speed turn.
Maybe @rmackay9 or @Leonardthall can comment further for you on the improvements made to this system in 3.6. As I have not had a chance to test it yet in high speed flight.
lol This “ghost” navigation sounds like what is generally referred to in aviation as ARINC or Airway steering which creates waypoint guidance based on “great circle” calculations from start to finish.
There are other steering types, used in various situations, like Point to Point, P2P with desired overfly, DeMocko steering (also referred to as Hard Steer),
Anyways, I was going to point out that this is a great visual explanation of airway steering
The next rewrite of the navigation controller will enable a specific path to be flown independent of the velocity and acceleration settings. This is a very large job though and will take time.
For now you need to trade off your velocity and acceleration parameters against the turn radius for a given corner, just as you described.
What I’m using the higher speeds for is limiting the flight angle to say 30° and commanding 50 m/s. This forces the craft to maintain that 30° since it can achieve only about 20 m/s at that angle. This keeps power consumption in the sweet spot and improves efficiency by over 20% in my tests. If I use a lower target ground speed, such as 20 m/s, then the craft will not utilize tailwinds and the efficiency is lost.
I’ve suggested a watt-based speed control before, or to make it simpler, a flight angle target during missions failsafed with a minimum ground speed so that if ground speed drops below your inputed minimum speed, the pilot is allowed to tilt beyond the target flight angle. This feature would catapult the power of ArduPilot because the efficiency increases are significant in winds over 10 mph.
Yes, I can see where that scheme would possibly work. Unfortunately I don’t have much experience with that. I fly section surveys where I have to cover one pass per minute so I fly at 27 m/s and the heli must maintain that within +/- 1 m/s on the COG. But I am using piston power so it is a bit different.
You do learn how to set the waypoints to not get too much over-run or under-run on turns for passes. And line up on the next pass right on target speed. At one point I thought the L1 Nav Controller from Plane would be better. But I think I like Leonard’s idea of eventually going to a more position based Nav Controller. But I can’t say the current system is all that bad - once you learn how to lay out waypoints to make it work. And with splines set one about every 200 meters or so. Or even closer if there is altitude changes required to follow terrain. It has worked pretty good for me, overall. I’m actually happy this change was not made in 3.6, as it will allow an easier transition from 3.5 with less testing.
It’s not a scheme that might possibly work. Using ground speed in place of airspeed is terrible for efficiency because you can’t set the most efficient airspeed with ground speed unless you manually change the speed throughout the flight based on current weather conditions. Most multirotors don’t have airspeed gauges, but you can use something even better than an airspeed gauge, and that is the angle of the craft. An angle will always be a certain airspeed.