It is only for the landing detector to disarm. Once it touches the ground and disarms it relaxes the pitch to full bottom with the rotor still spinning at rated speed (although slowing down now after disarm).
The reason for it was people failing to set it, and failing to set it properly. We had one very bad explosion because of it where the helicopter rolled over because it blew the EKF from trying to pull too much negative pitch and never disarmed. It blew the pitch links off, the helicopter launched like a rocket and mowed a 30 foot tree down. If somebody would’ve been in the way their life would’ve been discontinued.
I actually removed it from the ArduHeli builds over a year ago. I finally PR’d the removal to master after it was discussed on the Dev Call as being a safety issue.
You said that dynamic flight code is still active. I wasn’t sure if that had been removed at the same time as Land_Col_Min.
Yes, correct sorry, got the name wrong. Actually, I thought maybe you would go the other way. It’s currently 0-1000. Others have been rescaled 0-100. Seems this one could be as well. Actually this one probably needs less precision than RSC_Setpoint would, so it’s a good candidate for sure.
Not quite, if I understand what you’re asking. Tridge can make these… not sure what they’re called, classes of parameters that don’t even show up in the list until you enable the master. Such as PLND_ENABLED.
Just some of them could be moved. The less commonly used ones, like H_Gov params. It’s a way to reduce the apparent number of parameters for beginners. Just a suggesting.
As I scroll through the massive number of params, I wish it was more common. Such as MNT, LGR, CAM, etc.
Shouldn’t be too bad. You just have to work with Michael Oborne. Before he was full time it took a bit to get his attention, but I think he’s working on MP full time now?
I was talking with Tridge about it. Yeah so Multis can’t either. I think Randy is against it. I was too. But my opinions on this stuff have changed.
Sorry, what do you mean here? When I created it, Land_Col_Min was active the entire time when winding up and down. You never got full negative collective until you were flying Dynamically.
Sorry, I can’t agree with that logic. There are so many things that people can set improperly, that will result in crashes. You just can’t get rid of them all.
ie: somebody could set H_Col_Mid too low. Same effect. Set H_Col_Mid too high, and it will take off into your face uncontrollably. Set ATC_RATE_PITCH_P to be negative, or reverse the AHRS orientation and it will fly backwards at you.
Install a DDFP tail system, but don’t set the parameter. While disarmed on the ground, if you yaw left, then right, it will arm then spin up. I’ve done that one myself!
As it is now with Col_Mid, you will increase the instances of people having mid-air disarms, and it will crash onto their heads. Believe me, it happened to me twice when I set Land_Col_Min too high (ie: not enough negative). With Col_Mid, it will happen even more often. Believe me. I’ve already had this happen once in the sim just playing with it for a couple hours.
Again, you can’t just delete features because somebody got it wrong. There will be nothing left of the code. We had a user with a massive vibration problem on the run-up. MP was screaming at them. They took off anyway. Then they did disarm gesture in the air, heli spun to the right while descending, impacted and exploded.
What feature do you delete to solve that?
It’s a shame to limit functionality for advanced users because some make mistakes.
Despite the fact it has been flown and tested by many users without a single problem, if you don’t like it revert the commit. It’s only a couple lines of code for each frame type and re-instate the param in MotorsHeli.
Hang on, the original function was also flown and tested by many users without a problem. My point is just that removing it solves nothing. Get a parameter wrong, and you get the exact same effect.
The commit is here if you need a guide to revert it. It’s a very simple change.
When you revert it, please provide clear, concise documentation on how to set your param, and make sure to address the issues with pulling negative pitch on the ground with three or more blade non-rigid rotors with droop stops and coning hinges. That was never done and there is now some people flying those, although they are flying my code and not ArduPilot.
Your documentation should note that both COL_MID and COL_MIN must be set to zero thrust pitch with fully-articulated rotors, and LAND_COL must be set to zero.
Clear, concise documentation on HOW to set it was never provided in the past. All it said was: Minimum collective position in PWM microseconds while landed or landing
What does that mean to the user? PWM microseconds, let’s see - geeze my collective is 1000 to 2000 pwm settings. This setting is 0-500? WTF?
Very poorly designed and documented system throwing in different scaling factors that the end user does not understand.
@Rob_Lefebvre I am OK with putting that capability back into the code. But I just had a thought of how to make it easier for set up and require less inputs initially unless the user really needs the capability. Why not make a new parameter that allows the user to set the landing collective but make it relative to the mid collective setting. It would be defaulted to zero so that the mid collective position would be used and if non-zero would indicate a percent from the mid position to the min position. This way users would not have to set this parameter if they don’t need negative collective and would prevent users from getting into ground resonance issues as they would if the land collective min parameter was not set properly. Thoughts?
So would I want the parameter to be a negative percentage to indicate that it’s below mid? Or keep it as a positive percentage described as the percentage below mid?
What can be made to work, vs what’s safe and practical is two different things. There’s a reason some people can get 500 hrs on their piston engine, and others only get 50 hours before it seizes up. In cold weather I run at high idle, clutch engaged and rotors turning for 2-3 minutes sometimes for warmup. In hot weather I’ll run it for the same time at the same speed for cooldown so when I shut it down the temperature doesn’t spike and stick piston rings. Which will score a cylinder and seize it up.
Turbines are even more important for proper warmup and cooldown if you don’t want a $2,000 engine overhaul to due to cracked combustors, or letting an autopilot over-temp it by pushing the ITT over 1000C on spoolup.
Lack of autonomy is not holding helicopters back. Aviation authorities are. Those authorities that do the certification of the aircraft are not impressed with full autonomous features. They are impressed by a Pilot in Command retaining 100% control of the helicopter in all phases of the flight. That’s why drones are so tightly regulated commercially. They don’t trust them because they’re too automatic. That’s why a drone can’t be hired out to DOT for a survey of a U.S. or State highway, but a manned aircraft can be.
A) Your usage of a gas heli, should not preclude somebody else who is flying, say a 249g helicopter in full auto mode.
B) You’ve presented no problems with a programmable system could not be made to handle. Those sorts of situations are, frankly, trivial to solve in software. And in fact, would be more reliable than an operator being left to handle it manually. You even said it yourself, you do it right, and others don’t. I would have loved to have sold a gas powered helicopter, but I won’t go there until all of it can be automated. Right down to oil and fuel injection.
There might be people doing that, but as long as EKF lane changes are a thing, I would not call it safe.
So maybe keep focusing on features that make ardupilot safe, rather than features for toys.
Well, no it’s not. Especially with turbines and there is now a few users flying turbines both commercially and hobby with ArduPilot. For one, you have to be able to initiate the start sequence, which is manual control. The reason it is manual is because even with the most advanced FADEC the engine can experience a hot start with lots of fire, or a hung start where Ng fails to accelerate. Either condition will cause severe damage to the engine. In both full-size aircraft and RC the pilot very carefully guards the fuel cutoff and monitors ITT and Ng rotation until the engine goes self-sustaining and you have a verified good start. Something as simple as wind blowing up the tailpipes during a start can cause a bad start with a turbine. And these engines are VERY expensive to fix if you over-temp one. You’re looking at $150,000 for a hot section on a PT6 if it has a bad start and over-temps. And RC turbines aren’t any cheaper on a scale basis - entry price to most turboshaft RC engines is in the $5,000 range. The larger JetCat engines with dry sump lubrication system and oil cooler are $18,000 and up.
Since the fuel cutoff is a necessary pilot-controlled item for in-flight engine fires, and is used for starting and stopping the engine, it cannot be an autonomous thing. No pilot (that has any experience) is going to fly an aircraft with an autonomous fuel control that falsely detects an engine fire and shuts down in flight without the pilot commanding it.
While not all have it, my piston helicopters have a fuel control as well for the same reasons. If the throttle servo fails or throttle sticks, or in-flight engine fire, the fuel control is used to shut it down and stop the flow of fuel to the fire or kill the engine. Verifying the fuel control works properly is a required pre-flight check during runup.
That has nothing to do whatsoever with the code. Oil injection on two-strokes is mechanical. Fuel injection is electronic, controlled by an engine ECU, pretty much the same as turbines with a FADEC.
It doesn’t preclude such a thing at all. I believe a 249g helicopter is flyable with ArduPilot as is. The code is open source so if somebody wanted to hack a cell-phone controlled helicopter and make a custom build for it that is entirely possible to do (and not even that difficult).
This is a consideration for things like fully automated flight with no RC. It could only be supported for some helicopters, primarily electrics.
For instance, Bill and I discussed adding support in the RSC for starting turbine engines. But we decided against it because they’re not all the same. The basic arming/throttle hold used with the throttle curve works with all of them for engine control. But the start sequence is programmed into the RC.
The only timer used is for max starter time if the starting battery is low or weak and fails to accelerate Ng to self-sustaining before the timer expires. But some require a full throttle signal to initiate the FADEC, then return to ground idle within 2 seconds. Others require:
ignition on - also starts the timer
starter on and hold
monitor Ng - 13-15% turn on the fuel control first stage
monitor for ITT rise and Ng acceleration
first ITT peak (do not exceed 850C), on ITT drop and continued Ng acceleration second stage fuel on
second ITT peak, we have more cooling air flowing thru the engine now so don’t exceed 850C for more than 5 seconds, 1000C for 2 seconds
monitor for ITT drop and continued Ng acceleration, check starter timer
50% Ng release the starter, the engine is now self-sustaining, unplug the DT
release throttle hold (advance to low idle), Ng 63%, temperatures within limits, we have a good start with a stable engine
If during the start sequence any one of these steps or checks fails the start must be aborted and continue to motor the engine to cool it down.
Trying to code this all up to make it “automatic” would be a nightmare. ArduPilot understands nothing coming out of the Data Terminal from the engine’s sensors and thermocouples. There would have to be a new library to support that. Decisions have to be made at every step to continue the start or abort - lots of code logic (assuming ArduPilot would read the output of the DT). It is an inherently dangerous process - since we don’t have onboard fire suppression for engine fires, ground crew must available with a fire extinguisher.
So when you add anything “automatic” and it can’t be supported by all frames and prime movers, it’s not worth putting it in the code. So then the argument can be turbine power is not common, don’t have to support those because can turn the feature off so other users can relax in their lawn chair and watch their helicopter blissfully lift off and fly away into the sunset all by itself. But turbines are popular with high-altitude operators and the fact that they produce tremendous amounts of power with an engine that’s only 16" long and weighs only slightly more than a Zenoah G290. Both are a low user-percentage use-case.
That’s where a custom build applies. Being an open-source system a custom build for non common-use scenarios where only partial support is possible in the code for all types, is the best way to handle it.