@Rob_Lefebvre I was not involved in the changes from 3.3.3 to 3.4. That is when your statement was removed and it became the way you see it today in 3.6. We would have to ask Leonard and Randy why they removed that statement. I guess I am wondering why in an unarmed state, this statement is critical. If they want to check their servos, they should go to stabilize and sweep the controls or better yet set servo_test param so the servos do a sweep on boot up.
Please take this in the good humour I intend it to be:
I have got to laugh here as this is all exactly the same as multirotors. We even have settings in place to deal with these issues. We can turn off the learning so it is set constant or we can let it learn but not save at the end of a flight, or we can set it to learn and save. This lets the pilot choose the approach.
So the reason we did this is so that when you switch from Stabilize to Alt_Hold based modes the aircraft doesnât climb or descend. We let it choose between learn and learn+save because at the end of the flight the throttle can be at 1.5 times the take off setting with a full batter (or lower if you really stuff up). On my heavy lift aircraft the throttle can be a factor of 2 or 3 times different with and without load. All the same stuff. (we even get lower current draw in forward flight).
Remember, having a VERY friendly laugh here!!!
I am also not saying the heli users should or should not do anything. Just saying there is some thought and flexibility behind the way we have done it that can be used to accommodate heli users needs. IF you deem it appropriate.
1 Like
No, the two are different. Significantly.
We have one helicopter that we fly at 7000MSL with a bambi bucket on a sling load. It is about at the limitations of the main rotor at that altitude on a hot day if itâs humid. On a cooler day with less humidity itâs not an issue. So the pilot uses the collective as the gauge as to whether to lighten the load or not. It tells him exactly how much pitch heâs pulling to lift it. The second to last tick mark on the collective is 85% and thatâs what we use for the gauge.
In full-size you have a torque gauge (turbine) or manifold pressure gauge (piston) to determine whether a sling load is safe to lift and fly with. Since the power loading is usually much higher in full-size, shaft power is the limiting factor in how much the helicopter can lift. In RC, we typically have higher power to weight ratio than full-size so the limiting factor becomes the main rotor and how much thrust it can produce. We got the power, but we donât have the 650-750fps blade speeds full-size have. So thrust is the limiting factor. The only gauge we got is pitch, and the ground station has no such thing, so collective position becomes the âgaugeâ.
With helicopter there is limitations at maximum payload where itâs safe vs unsafe, and thatâs usually around 85-90% pitch. You can lift the load at 100% and fly with it, but itâs not safe because turbulence or a downdraft can bring the helicopter down before you get it into forward flight and start producing more lift. A multicopter canât fly if youâre using 100% throttle to lift a load. You got no overhead to stabilize it.
Thatâs where I was coming from on that statement.
Further complicating it is that not all pilots are going even set up the collective range the same. Some like considerable negative collective so normal hover range is ~75% stick. Others donât like to use a lot of negative so theyâll set it up with maybe only -2.5 deg. Others like the way full-size is where there is no negative collective so theyâll set the bottom range to zero and enjoy a collective response that is much smoother and easier to fly. So for a pilot that runs -8 to +11 if you mess with the center collective position and make the collective non-linear the pilot is going to be VERY unhappy about it.
@Leonardthall despite my explanation of several reasons I would never use it, this doesnât mean others wonât use it. If their collective pitch range is setup suitably so it can work properly, go ahead and put it in.
Would it adjust the IM_STAB_COLâs? I ask that because for folks that like to run a quite radial 3D pitch range, one of the purposes of the IM_STAB_COLâs is to be able to flatten the pitch curve around hover to make the helicopter easier to fly. When there is 18-19 degrees of pitch range the collective is VERY touchy and hard to hover. Thatâs why those settings exist to tame it down a bit for Stabilize. And they can be moved around a bit to adjust where the machine hovers as far as stick position in the Stabilize flight mode.
Personally I donât use those settings either. I use my Idleupâs instead for varying loads. But Idleups are also not in ArduPilot - for that you need an external governor that supports the feature. If I take off and the collective is too high I simply switch to the next Idleup and bring it down to around 60% before switching to an augmented mode. Which also has the advantage of maintaining fully loaded cruise performance at maximum takeoff weight the same as for empty weight.
But there again, thatâs just one more thing RC helicopters can do that multicopters lack 
Chris you did not disappoint 
My point was not that there are not significant differences in the aerodynamic complexity of collective heli vs simple thrust of a multi.
My point was with multi there is the camp that says âI want to know what the actual throttle setting is because⌠so turn that automatic crap off!â. Then there is the camp that says âI fly all the time in Alt Hold and I donât like it when I have to adjust my throttle position when I switch to Stabilise when hoveringâ.
So from a wider code perspective we have 4 inputs that we use to control the aircraft, roll, pitch, yaw and thrust. From the perspective of the code there is no assumption that hover throttle (or collective) is the same for all types of flight. We do record the throttle in a stationary hover to help remove jumps or twitches when people switch from Alt_Hold to Stabilise in a stationary hover and made sure that it could be disabled to accommodate people like yourself
It maybe worth stating this just in case it isnât obvious.
The general code assumes that the roll, pitch, yaw and thrust settings result in approximately linear response from the aircraft. The motors library should attempt to linearise the âplantâ or aircraft dynamics as much as possible to get the most out of the aircraft. Of course if it isnât perfectly linear that is fine you just need to ensure the PIDS are stable at the highest gain points on the curves.
I do think it could possibly be useful for many people that fly with static loads. I guess I was more curious as to how it would be dynamically adjusted to account for the custom pitch curve that some use with the IM_STAB_COLâs. By setting the two center IM_STAB_COLâs closer together in value this will flatten the pitch curve in the middle for folks that use a lot of pitch range. And can set the IM_STAB_COL_1 to reduce the amount of negative pitch that is set up. This makes the helicopter easier to hover, but it only applies to Stabilize.
Again, I prefer a linear collective response as the engine throttle is connected to the collective percentage with the throttle curve. If the collective out changes, it also changes throttle setting, even if the stick doesnât move. This is all perfectly fine in flight if the throttle curve is properly tuned. But for landing and takeoff in Stabilize if the collective curve is steep at the ends and flatter in the middle it changes the whole spoolup/spooldown profile as to how fast the throttle servo responds vs collective movement. And if the bottom of the collective has been adjusted with IM_STAB_COL_1 it doesnât allow a flight idle position for combustion engines. Since flight idle is the transition between ground idle, engaging the clutch and getting transmissions turning, then used for warmup of engines this has to be pretty smooth. It takes a little manipulation of the throttle for engaging the clutch so as to not get smoke coming out of the clutch from slipping it too much during initial spin-up.
The second stage is bringing engine power up on throttle curve until the governor takes over, which happens at a percentage of governed headspeed and minimum throttle. Then once it engages it takes 10 seconds to ramp to governed speed. It uses the throttle curve for feedforward for faster governor response, and there can be no settings that cause it to drop out in flight.
The point is, there is so many different types of setups in helicopters, some are electric and simple like multicopters, others are quite complex. Itâs hard to make any feature that manipulates throttle or collective fit all. Because on some helicopters youâre also fiddling with the throttle settings if you manipulate collective curve. And the pilot may land and suddenly find out there is no flight idle because the system adjusted the collective position.
I think the majority of our users fly simple electrics, probably work fine. Those who fly more complex and advanced helicopters wouldnât use such a feature.
My point is that I think trying to âlearnâ a hover throttle position on a helicopter is essentially useless. Yes, multirotors have similar effects from translational lift, etc. But the effect is about 10 times stronger in a helicopter. Any attempt to learn is quite likely going to induce oscillation between the physics, the learning code, and the pilot.
And I donât see the point. In my experience working with UAV helis, and training people how to use them, even an accomplished and experienced UAV multirotor pilot, is completely overwhelmed by how âactiveâ the collective pitch is on a heli.
Alt Hold is the âmost manualâ flight mode that we enable on our systems.
Meanwhile, skilled manual helicopter pilots have no problem at all dealing with it, and donât need assistance. I vote for leave well enough alone.
[quote=âbnsgeyer, post:202, topic:18281â] I guess I am wondering why in an unarmed state, this statement is critical. If they want to check their servos, they should go to stabilize and sweep the controls or better yet set servo_test param so the servos do a sweep on boot up
[/quote]
What you suggest makes some sense. However, I received complaints from users. And I have to agree that itâs nice to see those servos moving as you walk the heli over to the launch area. If we compare to how other FBL systems work, are they ever in a state where the servos donât move? No. So it also gets back to âbeing familiar to RC heli usersâ.
And like the auto-descent thing, it all has to be viewed through the lens of âthe least wrong thing to doâ. Letâs say somebody accidentally had a mid-air disarm, for some reason. And I have had that happen twice due to bugs in the landing detection code. With the way things were, at least the helicopter will attempt to stay upright on the way down. In both cases, this limited the damage from the impact.
What is the cost of having that line in there? An extra line of code? We have thousands of lines of code for pet features that nearly nobody uses. You canât even buy an external tail gyro anymore. But we have support for it in there.
I was looking at the way multicopters do this and it is over-simplistic compared to what we already have in heli. What we have doesnât do it automatically, but it adjusts both the curve and hover point. You canât change the hover point without changing the curve, which would turn it into a non-linear setup for one that is set up linear. Which would be really bad.
So Iâm afraid I have to agree. If it is thought this is a useful thing, have at it and see if you can make it work. But at least leave a way to totally disable it because the added complexity of helicopters simply does not lend itself well to things used in simple thrust machines with fixed-pitch. About the same as in the fixed-wing world, going from simple fixed-pitch airplanes to turboprops with constant-speed propellers. Takes a whole new regimen of training for the pilot to fly a complex airplane - and itâs going to take a new training regimen for the autopilot too to adapt this to helicopters.
1 Like
Yep, all I am doing is presenting options based on what we have done in Copter. This is why on all heli specific user interface stuff I defer to the people doing the flying and the work.
And I completly agree, start with the simple uncomplicated stuff and try to only add complexity if it is needed.
My main role here is to make sure you understand the tools the general code provides you, and I understand the tools you need.
You are all doing a great job!!
When we put Robâs descent feature in for low altitude hovering autorotations, hereâs why it works so well. I did some work on the 716 and had to test fly it. So before I brought it in I figured Iâd demo some hovering autos from 12-15 feet or so. This is a fairly heavy helicopter in the 3D world at 14 lbs (about double the weight of a normal 3D machine) running very low headspeed for a 700-class. This is what the autopilot can and canât do when we do this code. Notice how the descent rate is almost linear for a good auto just under the dead manâs curve, but it does use all the collective if done properly.
I honestly donât think ArduPilotâs altitude estimator is all that good (the ground station was showing minus 12-31 feet for most of this, for peteâs sake), and thereâs just no way it can do The Smoothie.
1 Like
It is very interesting seeing the way the energy bleeds off!
Based on what I know it takes to make plane land well, and what I have seen from the altitude estimate and baro measurements (especially in hover and near the ground), I agree you need a lidar to have any hope automatically timing collective input with the landing.
I still think it should be possible with a rpm sensor and lidar to do an auto-rotation automatically to a basic get-it-down-safely level. However I think you should consider it a long term project and focus on making sure the aircraft can be flown safely by pilots who are doing everything right. Then look at what you can do to mitigate risk after that.
Autorotations from hover are very difficult because itâs all about conversion of energy. The vertical component is less than the horizontal component in flight. And converting the horizontal component to lift is quite easy. There is no room for error when there is just the vertical component. So all I see the autopilot being able to do is try to maintain a descent rate from a low altitude hovering profile and try to maintain it until it runs out of lift. And hope the altitude wasnât too high so it runs out before touchdown.
And it seems no two of them are the same. With the same helicopter, if I go to Idle2 at 1,750 rpm itâs fine from 20 feet in a hover entry. If it isnât moving (forward flight) it has to be at 40 feet above that. From 20-40 feet with no airspeed is the âdead manâs curveâ. Canât put it into a dive fast enough to get any more than the vertical component because youâve already lost 10 feet and critical headspeed in the first second in an actual engine-out emergency before you can react. This is where the autopilot can help. It doesnât have to land the helicopter. Let a trained pilot do that. Just assist with the reaction time, and design it so the pilot doesnât have to do anything more than move the sticks to take over manual control (like Pos Hold does).