@Rob_Lefebvre@ChrisOlson and the rest of the Trad Heli Users,
I am doing some maintenance on the motors library for trad heli which was started by Tridge to complete the conversion of the trad heli motors library over to using the SRV_channel library. here is Tridge’s PR which I am modifying. My modifications are Here
So I wanted to check to make sure no one has any heartache over changing the external gyro that is a tail type option to being a PWM output type. This feature allows you to use an external tail gyro for yaw axis. The changes will include fixing the servo endpoints to 1000 and 2000. If you try changing servo max and min, they will automaticlly change back. And the ext gyro gain parameters, H_EXT_GAIN and H_EXT_GAIN_ACRO, are the actual PWM outputs -1000 which was the original implementation back in Copter 3.3. Currently it scales the output based on the servo min and max values.
Please let me know if there is some reason for not reverting the handling of the gyro gain output to what it was in Copter 3.3.
Thanks,
Bill
So I have learned a little more on the SRV_Channel library. You can set up servo scaling for either an angle type which is +/- from the servo trim which is set by the user in the SERVOX_TRIM parameter. however with this set up if the TRIM parameter is not centered on the range of Min to Max then you will have a larger gradient for throw in one direction than the other. The other scaling type is Range, which is what the EXT GYRO was set for. In this case, the value is scaled proportionally between Min and Max. So I felt the desired output to the EXT GYRO is ultimately PWM for set up. So getting rid of the scaling type servo output will reduce confusion of what users need to set for the Servo min and max parameters.
On another note, I would really like to do something similar to this for the RSC outputs when controlling ESCs. If ESCs are expecting 1000 to 2000 output in PWM, then I would like to fix that to a PWM output when the Set point option is selected. This would only apply to that option because I know for the throttle curve option, users need to set the enpoints of their throttle servo and the throttle curve points are percent x 10 for the range of servo min to max. Just a thought to reduce confusion.
Well yes, as we discussed with Leonard some time back it would be nice to get these settings in a more consistent scaling for user-friendliness. One that is human understandable. Our users are not computer programmers. So they think of servo outputs in pwm from 1000 to 2000. And they think of throttle outputs in terms of percent throttle or power from 0 to 100.
So when it comes to power settings, like the RSC_SETPOINT or throttle curve settings, it makes it non-user friendly when 70% throttle is displayed as 700 in the settings with an explanation that it’s percent x 10, or pwm microseconds from 0 to 1000. The common response is, “who the heck thought this up?” In setup of any other FBL unit, RC radio, etc., throttle is percent power from 0 to 100 and a five-point throttle curve is described as a 25-35-50-65-100 (or whatever) and anybody that has even touched a RC helicopter immediately knows what that means.
Why did ArduPilot have to make it so “techie” and difficult to understand? These conversions are trivial to do in the code where it’s transparent to the end user. We can use whatever scaling we want to use in the code. But I feel the actual setting the user sets has to eventually be what end users understand, and what follows industry convention in ease of setup.
To answer the question, why was it made so difficult understand: You have to understand the genesis of the project, and we were doing a HELL of a lot in a slow little 8-bit processor that took 100 cycles to do a single Float calc…
So everything we did was to reduce calculation horsepower, which meant ugly parameters.
After we got the STM32, this all changed. But then we were fighting against some people’s very firm belief that A) No old features should ever be broken and B) Nobody should ever have to go and “retune” anything after a firmware update.
I don’t agree with either, but have given up on that debate.
Now, to answer the specific technical question, I don’t care what happens to the Tail servo code. Actually, IMO, I think it should simply be removed. It’s an anachronism. You can’t even buy a single axis gyro anymore. I’d also gut external FBL support as well.
For the RSC outputs, I’m not sure I understood completely what you were saying. I think that what’s coming out of the Ch8 port should be scaled according to the Servo 8 Min and Max parameters, which could default to 1000-2000. And I think the RSC settings should be a percent of that, like 70%. But I do think we should be able to change the Servo 8 Min and Max to something other than 1000-2000. 1100-1900 is common.
What would be fantastic, is if we got an easy-to-use ESC calibration proceedure. Something like what the multirotor guys have, where you set a param to trigger it, reboot, and it automatically feeds Maximum, then Minimum to the ESC.
No, you can’t buy a single axis tail gyro anymore, but a lot of people are still using it with downstream FBL units.
Downstream FBL “support” does not really exist in the code. It’s just a matter of settings to turn off the rate controller, turn up the feedforward, use H1, and use flybar mode.
The key is that downstream FBL is an option that some people want - and there’s no code overhead if people want to use that option. It provides the redundancy and fun of a flybar helicopter, which a lot of people like. Frankly, ArduPilot’s Acro mode is not as good as a straight flybar or 3-axis FBL unit. Acro in ArduPilot has somewhat of a robotic feel to it and it’s not near as smooth. So I see nothing wrong with folks that are more discerning pilots that demand their helicopter fly the way Igor Sikorsky intended them to that want to use that option.
ArduPilot is, after all, an autopilot system, which by its very nature is a robotic system. The fact that it can play nice with flybars or downstream FBL with some simple settings makes it more flexible. If we attempted to lock out use of downstream FBL it would basically cripple flybar as well because the settings are pretty much the same.
I think it’s all anachronistic (including flybars) and does create extra code to maintain. But since it’s not me doing it anymore, fill yer boots.
What I do not like however, is what it did to Ardupilot’s reputation. I have seen many comments that “Ardupilot is a cheap/crappy/amateur autopilot system, you have to use a hobby gyro to make it fly.”
Since it is a feature a significant number of our users use, and that part of the code is virtually zero maintenance, we’re going to leave it as-is.
The only people I have heard claim ArduPilot is “crappy” is from the 3D or F3C crowd. Which it is in their world. ArduPilot, nor its hardware, is in no way shape or form a match for a FBL unit with a professional pilot on the sticks in competition aerobatics. It was never designed to be. It is an autopilot system designed primarily for flying autonomous missions with many different aircraft types. And it does what it is designed for very well.
Acro in ArduPilot is kind of a misnomer. Number 1 it is limited in what it can do with a helicopter. Number 2 experienced pilots don’t like Acro because it is too robotic and not smooth. So these pilots want a downstream FBL unit, or like I do now - I turn on flybar mode with no FBL unit in all my heli’s except one. And have the flight mode switch flip in my own custom rate and expo in the radio when I switch. I love how stable, smooth and responsive the helicopter is in Acro when there is no attitude controller messing with it.
So it remains a quite valuable feature for many of our users, regardless of how it is used.
