Need Help: TradHeli Direct Drive Variable Pitch Tailrotor

Just looking at the defaults for heli in 3.3 this is what the RC8 settings were
RC8_DZ , 10
RC8_FUNCTION , 0
RC8_MAX , 1900
RC8_MIN , 1100
RC8_REV , 1
RC8_TRIM , 1500

Going to 3.4 we have sort of the same thing except the function is set to 31 (HeliRSC) by default
RC8_DZ , 10
RC8_FUNCTION , 31
RC8_MAX , 1900
RC8_MIN , 1100
RC8_REV , 1
RC8_TRIM , 1500

In 3.3 that function could be left set to zero and HeliRSC still worked. In 3.4 I don’t think it does - must be set to 31.

In 3.5 it was moved to SERVO8
SERVO8_FUNCTION,31
SERVO8_MAX,2000
SERVO8_MIN,1000
SERVO8_REVERSED,0
SERVO8_TRIM,1500

Also in 3.3 and 3.4 the H_SVx params looked like this (using servo 4 as an example)
H_SV4_DZ , 0
H_SV4_MAX , 1900
H_SV4_MIN , 1100
H_SV4_REV , 1
H_SV4_TRIM , 1500

which were moved to this in 3.5 and the H_SVx params are gone, no longer used (NOTE: this is from one of my heli’s with 3.5 so these values are not the defaults)
SERVO4_FUNCTION,36
SERVO4_MAX,1800
SERVO4_MIN,1150
SERVO4_REVERSED,1
SERVO4_TRIM,1550

In 3.5 HeliRSC can be assigned to any SERVO output by assigning the SERVOx_FUNCTION = 31. The same is true with HeliTailRSC by assigning SERVOx_FUNCTION = 32. So my question is, since in 3.5 the SERVOx_ params already carries min/max/rev values as shown above, why were these left behind in H_ params for HeliRSC in 3.5?
H_RSC_PWM_MAX,2000
H_RSC_PWM_MIN,1000
H_RSC_PWM_REV,1

These are the params you got rid of in AP_MotorsHeli_Single.cpp by commenting them out - just a screenshot here because the code probably won’t display correctly. This is from the PR where they are actually removed. In our dev code they are still commented out:

But why were they left there in the first place when the move was made to SERVOx_ outputs in the new library? Just an oversight? Or something we’re missing?

The original rationale was that there was no separation of input channels from output channels. So if you had a channel as both an input and an output then you couldn’t have separate min/max/rev.
Now we do have them fully separated it does make perfect sense to use the SERVOn_MIN/MAX parameter, but we should do an auto-conversion of old parameters to new parameters so that users who upgrade don’t get a surprise. We should also take advantage of the new APIs that allow you to have multiple servo outputs for the one function, which can be useful on some vehicles.
We already have the k_heli_tail_rsc, so much of the work is done:

we just need a bit more cleanup work to remove the PWM values in the motors library and use the servo channel pwm ranges instead by using the SRV_Channels::set_output_scaled() API
Cheers, Tridge

This will be handy for Bill’s EuroCopter X3 with dual thruster props.

It seems to me this was partially done in 3.4 → 3.5. It has been awhile since I upgraded one using that path, but I think it missed one of the cyclic servos (SERVO3 I think) that I had to manually enter. It may have been SERVO4 too, I can’t remember.

At any rate I am going fly our dev code today. I have a few hours of work to do on the heli to get it flight ready. I want to test all the RSC modes, test mapping the RSC output to various SERVO’s, test the Radio Failsafe, and test autorotation using RSC_MODE = 1.

Oh, OK. Now I understand! I browsed the old code a bit and see this now. All along I had assumed the RCn params in the old code were inputs only. So now I understand the reason for the H_RSC_PWM_MIN/MAX/REV providing a separate output value.

How is this done tridge? I see the problem here. Users will have H_RSC_PWM_ params for min/max/rev and those need to be converted to SERVOn_ params for min/max/rev during a firmware upgrade since the H_RSC_PWM_ params will be gone.

It looks like we’re doing an EEPROM dump and if a param was still set to default and no longer used it is just abandoned and defaulted to the new one. If it was not default a conversion is attempted, but how is the conversion defined?

@bnsgeyer and @tridge huge safety issue with allowing reversing of a signal to an ESC, either HeliTailRSC or main_rotor. To duplicate the safety issue, REMOVE THE BLADES FIRST! Power up the heli. It is not necessary to have the RC radio on or connected. FC unarmed, go the SERVOn_REVERSED param, change it to 1 and save to the FC.

Result: the motor instantly starts and goes to 100% power without the FC armed, motor interlock raised, or RC radio even connected. The only way to stop it is to reset the REVERSED parameter, or power down the heli.

Fortunately, I still had the blades off mine when I tested it.

yes, if you set a motor output as reversed but its not reversed then that means the zero output becomes max output.
We can’t just disallow this though, as helis with reversed RSC output do exist. The GX9 that CanberraUAV has with a petrol engine has a reversed throttle, as do many petrol and nitro helis.
Even on electric motors you can have reversed output, especially with reversible motor setups. A friend of mine flies an Optera with a electric motor with a reversible throttle, so he can use reverse thrust to slow down. That isn’t a heli, but the same principle applies to a compound heli, and in the future we will want to support reversible motors on compound helis for forward thrust. You need to be able to flip the reversal in software when doing the setup (otherwise you need to physically change the wiring, which can be a pain)
Whenever we have an output that could be reversed on some vehicles we need to have a parameter to enable that reversal. What we have done recently is to make the parameter value a bit less confusing. It used to be a multipler, so H_RSC_PWM_REV was -1 for reversed and 1 for normal. That could easily lead to confusion.
We’ve gone to using SERVOn_REVERSED as a boolean, where 0 is normal and 1 is reversed, which is much less confusing.

It should require a reboot of the flight controller to take effect. Then the worst thing that happens is that the ESC goes into programming mode. It is not a good idea to have motors starting without the flight controller armed.

With the main rotor ESC having built-in programmable soft-start and ramp time it is not real dramatic. But the tail ESC on my other 600 does not have that. I had just hooked up the rudder linkage and tested it, getting ready for a test flight, and didn’t put the blades on the tail yet. I decided to try reversing that param (although SERVO7_REVERSED in the dev software) and it took me quite by surprise when the tail motor started and instantly went to 100% power with no soft-start or ramp. That could be extremely dangerous if a user didn’t know about it.

Or a person can just use QGroundControl which offers “NORMAL” and “REVERSED” as options, and don’t have to worry about the numeric value. Which is even less confusing :sunglasses:

I made one change to Bill’s code to use the main rotor ramp and runup times for the DDVP tail rotor (the default 2 sec/3sec that is hard-coded is too fast and out of sync with the main rotor). I merged the orginal code into ArduHeli 3.5.3. This is what we are going to fly because it’s safe. It does not start the main or tail rotors by hot-swapping the REVERSED param but still allows hot-swapping the direction of other servos. Reversing the direction of the throttle signals is still allowed - it just requires a reboot of the flight controller to take effect.

https://github.com/ChristopherOlson/ArduHeli/commit/0dd1479bb03c7fd8cf2792787d279a661a2a5c4c

We will have to work thru what the dev team wants to incorporate this into Copter master. But we have commercial users flying our software and we cannot allow a situation where starting the main or tail rotors is possible simply by hot-swapping the throttle signal direction with the flight controller in unarmed state.

@tridge, I agree with @ChrisOlson on the reverse parameter requiring a reboot to take effect. I would like to make that change for the PR to master.

I will look at the set_output_scaled method for the write_rsc method. My only concern on that is ensuring the passthrough feature of RSC mode 1 works when RC8_in min and max are not the same as the servo out min and max. I don’t think that was an issue in 3.3 because the RC_in min and max were used for both input and output to the servo. Now with the in and out separated, I would think the write statement would need to be a pwm method and the statement that reads the RC 8 input would need to be a radio_in method.
Thoughts?

If the change on the ramp time of the tail rotor is used in the final PR, these two lines of code in AP_MotorsHeli_Single.h header file can also be removed after verifying that they are not used any other place in the code

define AP_MOTORS_HELI_SINGLE_DDVPT_RAMP_TIME 2
define AP_MOTORS_HELI_SINGLE_DDVPT_RUNUP_TIME 3

I’m not convinced. There are many parameters that can cause issues like this. The user could change the SERVOn_FUNCTION to be the wrong function and the motor will start. They could change the SERVOn_MIN to the wrong value and the motor will start. Trying to protect against this specific incorrect parameter among a large number of parameters doesn’t make sense to me.
The same thing happens with a traditional flybarless controller setup. If you are setting up your transmitter and reverse a channel then it doesn’t wait till you restart the transmitter to take effect. All RC users need to deal with this.
I also think it could lead to confusion. The users sets up their parameters changing a dozen parameters to get it just right and it all seems to be working. Then they reboot and it no longer works. How do they work out which parameter it is that is the critical one? They have a beeping ESC and no indication of why.
Cheers, Tridge

if you’d like to discuss this on the weekly dev call that may be a good place to go over the pros and cons of special casing reversal of this channel

Well, this goes back a long ways since a user could do this in AC3.3 too.

I guess my question would be, when we having something that is not quite right, why not fix it?
In this case getting a hot start by changing params with no RC connected and FC unarmed, is there a reason to allow hot-swapping the throttle direction and min/max for HeliRSC?

This one, I don’t see applies to heli’s. And this is heli-specific.

I’m not sure I quite follow this reason. The compound heli uses variable pitch thruster props. They are reversible by changing blade pitch, not motor direction. Most compound (X3 style) heli’s have mechanically driven thrusters, although Bill plans to build one with brushless motor thrusters using the DDVP principle. I have my doubts, due to engineering limitations, that a DDFP could be used for thrusters on a compound, since they are used for yaw control and the precision would be compromised using fixed pitch props. Maybe a small toy model could be build with fixed pitch. But in larger sizes, in my testing, a 500 class is as big as a person can go with a DDFP tail rotor (and probably thrusters on a compound).

Just trying to think up any other reasons hot-swapping the RSC min/max/rev should be a necessary thing.

Yes, I’ll try to make it in there tomorrow evening (evening here).

I flew the code we have in the ArduHeli-3.5.3 branch today for about 30 minutes. It works very nicely in normal flight.

Autorotations was what I was really interested in. I used MODE 1 with a three-position throttle, off/autorotation idle/normal flight power. The heli is an autorotation monster without the main driving the tail. It floats and floats, and can actually hover it for a few seconds in autorotation. That was fun.

I also tried shutting down the throttle signal in flight to see how bad the loss of yaw control is. That was a little more fun as the heli goes into an instant spin in autorotation. But I snapped the switch back on and it ramped up immediately. It skipped the rsc_ramp and rsc_runup times, and regained tail authority right away. The main rotor ESC, however, did not skip its programmed ramp time (built into the ESC programming). So I was still in autorotation even so. I was able to recover it without having to do a full auto. But I was happy with the operation of the tail rotor.

yes, when setting up a nitro or petrol heli it makes life easier as you get immediate changes with parameters, so setup is faster and easier.

If we do the management of the PWM in the RSC code then it is heli specific. If we move the management to use the generic APIs in SRV_Channel then its not heli specific

why couldn’t a compound heli use fixed pitch, variable RPM props?

that really just depends on the scale. It certainly works for multirotors.

I think of it the other way - are there good enough reasons to special case heli RSC as not taking effect immediately. All our other cases do take effect immediately.
We’ve had this on electric planes since the beginning of ArduPilot, and users reversing a motor hasn’t been a problem, even though it takes effect immediately.

I’m assuming that you are suggesting that we remove the write_rsc method? Since the rsc is specifically a heli function, I’m not sure that we need to just use the SRV_Channel functions.

I guess it could done but in a hover the one prop would have to be thrusting in reverse and thus a fixed pitch prop would have to turn in the opposite direction. On a heli with a tail rotor, there is enough torque from the main rotor to provide enough yaw acceleration with out reversing the tail rotor fixed pitch prop and traditional helis accept the tail thrust and managing it with roll attitude. for compound helis, i think the residual thrust from having one prop doing all the anti-torque with the other one idle (if you didn’t use reverse rotation for reverse thrust) would cause the aircraft to have a huge nose up attitude.

I realize users have been managing this risk whether they know it or not for a long time but heli’s in most cases are more expensive and more dangerous. I’m in favor of this only because tradheli does have it’s own code to manage rotor speed control. Wiki’s can be changed or a pop up message added to tell users that they need to reboot for the change to take effect. Just my 2 cents.

Regards,
Bill

For a DDFP tail to work there is a limitation in rotor torque vs how fast the tail motor/prop can throttle too. I tried one on a 600 and it was a disaster. On a 550 @ 5.2kg takeoff weight a DDFP is barely adequate and if there’s wind it doesn’t work. On a 500 @ 4kg takeoff weight it works pretty well.

Comparing to multi-rotors here is not an apples to apples comparison. There is no fixed-pitch drive in existence that can change thrust as fast, or accurately, as variable pitch. So I see fixed-pitch drives as having little to no use for helicopters, except on small models.

The HeliRSC was written in the first place because throttle management for helicopters is a special case, using various methods from traditional throttle/pitch curves to governors. And must be able to work with everything from simple drives like multi-rotors use to turbine engine FADEC controllers.

An example is a governor function - ArduPilot needs it badly. It is standard in most FBL units these days. ArduPilot cannot currently fly my Velos 880 because it is a twin-engine helicopter and requires a governor function in the FBL unit to split the torque evenly from twin drives on a single gearbox. That cannot be handled by standard ESC’s with governor because no two are the same. That functionality can be easily added to the HeliRSC, probably not so easy with the generic API’s in the SRV_Channel library.

Chris,
When I watched your video I could not believe what I was seeing. I believe your way of thinking is the right way and I will support you 100%. Can’t wait to take my y-cables out.

It doesn’t make any difference if the call in the init_servo or write_rsc method. From what I tested here, when the parameter is changed it re-initializes the servo anyway. The reason it worked in the original code is because we could reverse the signal, but it was hard-coded to be one way.