ok. I just wanted to verify what I was seeing in the code. It pertains to how I might handle adding the input for the propeller thrust. I will hard code it to channel 7 similar to how the main rotor RSC is hardcoded to CH8. Thanks for the info!
I don’t know if it would have to be hard-coded. Channel 7 (and Channel 6) can already be assigned different functions. Maybe just add a function for propeller thrust control for a EuroCopter style heli.
The RC input channel 7 and 6? I know the servo outs can be assigned functions. I don’t know that you can assign them to the RC input channels.
Yep. They’re call “options” set by the params CHx_OPT for 7 thru 12. These are the current functions or options and there’s already one there, value 32 for motor interlock. So better look at the 3.6-dev code - maybe that’s mappable now and not hard-wired to Channel 8 anymore.
0 Do Nothing
2 Flip
3 Simple Mode
4 RTL
5 Save Trim
7 Save WP
9 Camera Trigger
10 RangeFinder
11 Fence
13 Super Simple Mode
14 Acro Trainer
15 Sprayer
16 Auto
17 AutoTune
18 Land
19 Gripper
21 Parachute Enable
22 Parachute Release
23 Parachute 3pos
24 Auto Mission Reset
25 AttCon Feed Forward
26 AttCon Accel Limits
27 Retract Mount
28 Relay On/Off
34 Relay2 On/Off
35 Relay3 On/Off
36 Relay4 On/Off
29 Landing Gear
30 Lost Copter Sound
31 Motor Emergency Stop
32 Motor Interlock
33 Brake
37 Throw
38 ADSB-Avoidance
39 PrecLoiter
40 Object Avoidance
41 ArmDisarm
42 SmartRTL
43 InvertedFlight
44 Winch Enable
45 WinchControl
That’s right. I forgot about that. I will have to look at this and see if I can put something like the propeller thrust in there. Thanks!
Submitted the PR for this but got some feedback on it. https://github.com/ArduPilot/ardupilot/pull/7199
So I will work on it in the future and look to have it ready for the next release.
V/R,
Bill
Well, the code in the PR works, where the original code didn’t. It may not have ideal integration with the SRV_Channel library. But that’s a separate issue to my way of thinking.
@ChrisOlson I have made the necessary changes to the code to correct the problems that Tridge and Randy identified. I tested it in the SITL and it behaves as you would expect for the servo to be reversed and it doesn’t require a reboot to reset the min or max. I pushed the commit to the DDVP branch of ArduHeli. I also updated the pull request.
Regards,
Bill
Thanks Bill. I will re-test that in my 600 heli.
I made some comments on this on GitHub on the PR. I think we need to get it working as it should in the DDVP branch on ArduHeli, then test it and put it thru the wringer to make sure it functions correctly. That is primary. Once we get a working implementaion that works like it did in AC3.3.3, and I am satisfied it is safe and works right, I can do a build and others with DDVP tail on their heli can test it as well. Then deal with how to implement the fix in a PR to Copter master, fitting in with the anomalies introduced in 3.4 and later with 0 to 1 scaling, reversing the signal, etc…
As I mentioned in the comments on GitHub, reversing the signal results in the tail ESC beeping and going into programming mode. As long as users don’t mess with the REV setting, everything is great. But reversing the signal to a ESC should never be allowed in the first place.
Hate to say it, but the first code you wrote works the best 
Yes it worked well by accident. 
So there is one more thing to address and that is RSC mode 1 where CH8 is passed thru. Since most ESCs work off of pwm then I think I need to read in the pwm rather than how it’s coded now in heli.cpp using get_control_in(). Then I just normalize it to 0-1 signal and then i can hard code the min value for the RSC_write method. Easy fixes. Should have it to you today.
Well, in Mode 1 throttle control is passed thru. But it is still enabled by the motor interlock being raised. I don’t think that should affect the HeliTailRSC where it basically works on governor mode regardless of what the main rotor does? I realize that in theory the main rotor might not be turning once motor interlock is raised in Mode 1, waiting for a signal from the pilot as he/she ramps up the collective pitch, or turns the RSC knob, however it is set up. And meanwhile the tail rotor will ramp up in (I think) 5 seconds. But because it is a variable pitch unit, the blades will be feathered and producing zero yaw thrust.
Not quite sure how to handle that in a situation where the pilot made a throttle/pitch curve in the radio and has the throttle tied to the collective lever position. Which is what a lot of people coming to ArduPilot for the first time tend to want to do, because it is more like traditional helicopter setup when an autopilot is not used.
No, mode 1 is where channel 8 is passed thru. Mode 3 uses the v curve based on the throttle channel. I have never set up mode 3. The changes I am making will definitely affect both the tail and the main rotor. Would a user require being able to reverse the main rotor output servo in a mode 3 set up or would they be able to reverse the settings for the V curve?
I gues I could make the RSC write depend on the mode as to whether it uses the reverse and max/min features? This may cause issues with the tail rsc
EDIT: I just looked and the tail is kept at the set point mode while the main rotor can be any of the three. So if I design the min/max and rev feature iof the write RSC to change based on the RSC mode the. I think that would be best. So in Mode 1 and 2, the user can’t change the min/max or rev and then are hard coded to 1000/2000 and norm. Where in mode 3 the user would be able to affect those parameters using the servo8 params for the main rotor.
Thoughts?
Yeah, Channel 8 passthru is what I meant by throttle.
I use Mode 3 in a heli with no governor. Works good. But no, you can’t really reverse that. It is still a one-way signal. Doesn’t matter if the curve is 900-500-900, 400-400-1000, what have you. It is still percent power * 10 for all three points of the curve. You can’t have a negative power setting.
What would be really nice is to eliminate the separate (hard coded) ramp times for the HeliTailRSC and use whatever the user sets the ramp time to for the main rotor. That way the tail rotor would come up to speed at the same rate as the main, and provide smooth and proportionate yaw authority like a mechanically driven tail. As it is now, where I use a 40 second ramp time for instance (I like the more scale-type takeoffs) the tail rotor comes up to speed very fast and provides a disproportionate amount of yaw authority while the main rotor is still spinning up. That would be in the category of “nice” but not “necessary”.
So for mode 3, the user needs the ability to set the min and max range of the servo and whether it is reversed. Right? If that is the case then I will work toward what I put in the Edit to my previous post. I will see what I can do about the ramp time. I don’t think it would be hard to set that to the main rotor ramp time but let’s make sure that is what we want. I’ll think about any drawbacks but I think you are right with wanting them to ramp at the same rate. It is effectively what a shaft or belt driven tail is doing.
I guess I’m not clear on what you’re asking. These are the current params
H_RSC_POWER_HIGH,700
H_RSC_POWER_LOW,200
H_RSC_POWER_NEGC,700
H_RSC_PWM_MAX,2000
H_RSC_PWM_MIN,1000
H_RSC_PWM_REV,1
I actually think the PWM needs to be hard coded for a RSC system? I cannot think of a valid reason why a different PWM range would be used for an ESC. Every one I’ve seen expects zero throttle on power-up to initialize. So I have never set those to anything else for any reason.
The reverse function, I also don’t understand. That causes the ESC to go into programming or calibration mode. The only reason I can see for it being there is if the radio is putting out a reversed signal for throttle. So you need to reverse it again in the software? I don’t know. That’s another one I’ve never set to anything but the default.
Yes, that is what I saw in the code too. But I don’t see a change necessary for Mode 3 throttle. It is no different from Mode 2 except it has three setpoints instead of one (the high, low and negc values). So the software simply changes the throttle signal to the ESC based on collective pitch input, which compensates (sort of) for having no governor in the ESC. The tail rotor is still independent of this, as the idea is still to maintain a constant headspeed without a governor.
Again, I don’t know what those min/max/rev values are there for for an RSC system. It is a one-way system only with a pre-defined set range of pwm that will make it work.
Yes, I think it would be best to have a synchronized ramp of all the rotors. Not necessary. But since we able to define the ramp time of the main, why not sync the tail with it?
Is mode 3 used for nitro helis? That be the case where I was thinking a rev and min/ max would be needed. I’ve set up nitro Helis but never with a pixhawk.
It can be, but it doesn’t work all that well. More typical is to use a RevLok or GV1 governor with Mode 2 and set the RSC idle for the proper idle speed that doesn’t engage the clutch. That would be a use case for SERVO min/max/rev if the throttle servo horn is not able to be flipped over and doesn’t have enough adjustment holes. Or using a linear throttle servo. But it can be in the SERVOx_MIN/MAX/REV and doesn’t have to have H_ params for it? I think. I don’t know the reason for those. Even in 3.3.3 before RCx params became SERVOx params, why is there heli-specific ones? Did that have something to do with multi-rotor defaults at the time for RCx_, and it’s just been carried over into 3.5?
We have to be careful there to not break something with HeliRSC control where the FC is supposed to have control of the throttle when RC signal is lost.
@bnsgeyer I have the current code in DDVP branch built and testing it. There’s actually no problem with this, I guess. I will have to retract what I said about hard-coding the min/max. It can stay consistent with how the other servos work and it works fine. It can be broken by changing the values, but the default works “out of the box”.
I’m going to try a flight with my Trex 600 DDVP tomorrow with the code as it is, and try all the RSC modes to see if I find any anomalies. I still have the blades off, and ramping up live with the shafts turning, I think it would nicer if the rail and main ramped at the same rate. But otherwise I can’t really find a problem with this on the bench (so far).
Looking at the code again. It does appear that it looks for the rev, min and max for the servo settings to then output the ESC. I haven’t tried it but I can go back to AC 3.3.3 and see what happens with each mode in the old code. Looking at it further, it does appear to account for the Min, max and Rev settings. Like you, I’m unsure how the RCin settings play into this back then. H_ servo settings were definitely for the heli outputs servos but I don’t remember one for the RSC. so it may have used the RCin settings for the RSC.
Let me know what you think of the code the way it is currently. I won’t do anything until I hear from you and have the chance to see how AC 3.3.3 worked.
Regards,
Bill