Trad Heli Attitude controller requirements - Help Requested

Rob, remember my direct drive 600 (that I crashed) that I was experimenting with a DDFP tail on? I built a turntable that the helicopter was strapped down on, and put a digital scale on the tail boom and wound it up in the shop to measure how much thrust I needed to order the motor and prop for it. Then I went to that online eCalc website for calculating multirotor thrust with different motor and prop combos, and figured out what I needed. It flew fine “out of the box” using that simple method to determine thrust, although the code was a little wanked for DDPF at the time.

I just used it again a few weeks ago when I built the experimental DDFP tail for my 500. Worked on that one too, to figure out what I needed.

Maybe that’s not accurate enough for what you guys are trying to do. But it worked for me.

I could build it with a remote BEC powering the servos instead of the main ESC. If the Pixhawk was drawing power from the main ESC, that would be trivial. Then the tail ESC would be a good measurement.

One thing to consider though, is the governor code in the ESC’s are running open loop. They don’t have load feedforward. The ESC is only responding to RPM changes. So there will be a significant lag between the servo output, and the power change.

Actually, I was just having the same thought. Something else I need to build.

OK, well. Do you want some logs from my 500 with the DDFP tail on it? Here’s kind of the deal with that. I tested that tail on the bench and determined that the thrust of the tail prop increases approximately with the square of the speed. So that DDFP logs throttle output on channel 4 to the tail motor esc all the time it’s in flight. Throttle output on a DDFP is proportional to thrust.

It’s likely I might have a flying platform that could measure and log precisely what you need to figure it out.

You are backing out the measurement of tail thrust from the main rotor power. Power = rotor speed*torque and torque = distance tail to cg * tailrotor thrust

I didn’t do my due diligence on the maths behind that one. I have not been able to find sources to corroborate it. I think thrust and steady state rate curves are still part of the answer here.

Olli, we are working on an autopilot system, which is a fundamentally different application than FBL units. Most of the people putting ArduPilot-powered boards in their helicopters are not interested in aerobatics or 3D type flying. We want a system that provides autonomous mission capabilities to reduce the pilot workload so the helicopter can be used for useful things, either in commercial or recreational flying. And ArduPilot does that very, very well.

The open source model does have a lot of advantages. It is not here today, gone tomorrow on the whim of some company like DJI that tries to make things obsolete on a regular basis so they can sell you the “latest and greatest” marketing thing. It has a lot more developers looking at it and improving it all the time, from all over the world. It has dominated the quite prestigious Outback UAV Challenge where the likes of somebody like DJI doesn’t even show their face because they have nothing that can do it.

So please realize that while some of the same algorithms might be used in the code, the ArduPilot community is working on a different type of application, different purpose. And it is currently THE 1 autopilot system on earth and can fly, drive and sail more types of autonomous vehicles than anything else that exists, and runs on a greater variety of hardware than anything else. That flexibility could potentially let an ArduPilot-powered system fly a full-sized helicopter across the country under full autonomous control of the autopilot. Where I wouldn’t trust the highly hyped FBL units to even spool one up and get it off the ground without crashing it.

1 Like

Rob, got back to my shop.

Here is an example plot of yaw vs tail rotor ESC signal on the DDFP. Since the fixed pitch tail throttle signal is related to thrust, it’s kind of interesting. It took quite a bit of fiddling with it to get it to throttle the tail motor at ~50% throttle for hover. This shows the plot of the throttle signal to the tail ESC in a static hover in Loiter, not moving, no yaw changes being made.

Now we’re in dynamic flight with constant heading between some waypoints, and making left and right turns between others. The throttle signal to the tail actually changes very little if you plot the mean of the signal to the ESC. From waypoints 6 to 8 where we were on a southerly heading, then make a 180 degree left hand turn, requiring reduced thrust from the tail rotor, to let the main rotor torque turn the airframe, the change is barely perceptible. And there may have been the effect of a crosswind on this too, I don’t remember on this flight.

Anyway, what I learned from experimenting with the DDFP is that the yaw of the tail is changed with the blade pitch in the anti-torque direction with a normal tail in all normal flight conditions. To use reverse tail thrust, it would be the equivalent of throttling the DDFP tail ESC to 1000 and completely shutting down the tail rotor motor because it wanted reverse tail authority. So it never does actually crosses the zero pitch position on the tail rotor on a conventional tail. In all the testing I’ve done with the DDFP I have not seen that yet, and I’ve flown it in 30mph crosswinds without ever having a blowout. The main rotor torque has always been sufficient to yaw left under any conditions I’ve tested it in, by simply reducing the thrust on the tail rotor.

So I think I arrived at the fact that the change in pitch on the tail rotor blades with a normal tail is so minute in UAV type flight that it there’s any binding in the linkage, even backlash in the servo gears, the tail will not be steady.

The power I measured when I figured out the DDFP was 23.5 watts developing 212.3 grams of thrust with a 970mm main rotor turning at 2,100 rpm at 7 degrees of collective pitch (hover). And the length of the arm (tail motor shaft centerline to main rotor shaft centerline) was 585mm. That’s from all my notes when I engineered it to get it to work.

Is that the kind of data you fellows were hoping to measure?

Here’s some additional info I measured on the bench. The power was measured with my Doc Wattson RC power meter to the ESC. Prop rpm was 5700 @ 1510pwm to the ESC @ 212 grams thrust, 222mm diameter, 4" pitch. My rough calculations on static thrust efficiency of the tail prop was that it was producing actual mechanical power of ~18 watts, or about 78% static thrust efficiency. Frame torque 1.216Nm.

Hi, Leonardthall, could you tell me the accuracy of attitude estimation on PIXHAWK, and how to calculate the accuracy.
Thank you very much, waiting for your reply!

attitude accuracy depends on how good your IMU setup is. The best way of seeing what accuracy you are getting is to compare the two attitude solutions that the two different EKF lanes get (we run a separate EKF on each IMU, giving two largely independent different solutions). Check your log and compare NKF1.Roll with NKF6.Roll. The difference between the two gives you a good idea of what accuracy you are probably achieving. Improving your isolation mounting and using a better GPS and a better compass setup will tend to improve accuracy.
Cheers, Tridge

Tradheli users,
I am in the process of implementing a large change in the code that will bring the tradheli code up to speed with the rest of the copter code. The change is called spool logic and the PR is here. I’ve reopened this old discussion because I believe @Leonardthall was asking these questions to implement this change. So Leonard has done some reorganizing in each of the flight modes along with the addition of the trad heli spool logic. I need your help with some aircraft behaviors in some of the aircraft states and spool mode combinations.

I will start off with describing the aircraft states and spool modes.
AIRCRAFT STATES

  • Motors Stopped: Aircraft is disarmed.
  • Landed: Armed and land_complete flag is true
  • Takeoff: mainly used in modes that use altitude hold. triggered by land_complete true and positive climb rate requested.
  • Flying: When aircraft is not motors stopped, landed or takeoff states

SPOOL STATES

  • Shutdown: Disarmed
  • Spin When Armed: Aircraft is armed but motor interlock is disabled (throttle hold)
  • Throttle Unlimited: Aircraft is armed and motor interlock enabled

One difference to note from the current code is that motor interlock disabled in the current code is defined as a motors stopped state but in this change is not a requirement for the motors stopped state.

So my goal is to refine some controller behaviors in specific combinations of Aircraft state and Spool state for a given flight mode. This gets complicated very quickly because for each combination of aircraft state, spool state and flight mode, the four axes of control need to be discussed.
I made a table to help (or confuse you more) with this discussion. I don’t want to go through it all but have pointed questions to pose. Plus I want to be completely transparent about this as it will affect you.

In each block are 6 lines
Line 1 describes what your aileron/elevator stick will command. For loiter, the position controller is active. relax pos ctrl means that your inputs will not affect the response of the aircraft nor will it try to hold position.

Line 2 describes whether the controller is trying to match the ghost aircraft pitch and roll attitude or not.
Line 3 describes the directional control
Line 4 describes whether the controller is trying to match the ghost aircraft heading or not.
Line 5 describes the whether the rate integrator terms are zeroed or released
Line 6 describes the vertical controller. Other than acro and stabilize the vertical control is the altitude controller

Here is where I need input.
As the first note states for loiter and althold modes in the shutdown/motors stopped state, the current logic has the climb rate set to land_speed. My thought on this is that regardless of whether the aircraft is disarmed (motors stopped) or armed with interlock disabled (landed or flying in spin when armed) then the altitude controller should be relaxed. Which means the collective goes to H_LAND_COL_MIN. Users should not be switching motors interlock disabled (throttle hold) in Althold or loiter.

The next thing I want help with deals with tail rotor and swashplate behavior which was addressed earlier in this discussion. I don’t want to change the behavior but looking to base it on different triggers that would be universal of heli or multi. Currently there is a heli flag called init_targets_on_arming. This flag is used to initialize the target heading (all modes) and target attitude (acro only) to the current value on the first instance of motors interlock enabled after arming. Therefore if you land and go motors interlock disabled and move your heli like turn it 90 deg and then hit motors interlock enabled. the heli might try to spin back toward the heading when you landed previously. So I would like to remove this unique heli flag and reset these targets based on spin when armed and land_complete flag true. The only time this may adversely affect your aircraft is if you were conducting autos and by chance it thought you were landed which I think is pretty unlikely. Acro would probably be the most biggest issue because of resetting the attitude targets. for the land_complete flag to be true, there are several criteria that need to be met
accelerations less than 1 m/s/s
descent rate less than 1 m/s
collective below H_LAND_COL_MIN
These three criteria need to be true for 1 second for it to declare a land_complete true.

Looking for feedback specifically on the two items above but if you have any comments or questions, feel free to post.

Regards,
Bill

Will this be true also for Auto-Rotation ? Or Motors stopped should be rotor stopped ?

@LuisVale The autorotation state is still considered to be an aircraft flying state. However the spool state will be spin when armed which is effectively a throttle hold state. Motors stopped is the aircraft state for all motors and the rotor to be static. It is not guaranteed that rotors will be stopped like it is with multi’s but it is assumed that a user would never disarm while rotors are turning. For multi’s the motor state can almost always be linked to the motor state. the spin when armed state for mult’s is very closely represents the thottle hold state for helicopters. the difference is for multi’s the motors and propellers are turning at a slow speed and used mainly as a safety feature to indicate to users the aircraft is armed which for them means if you raise the throttle stick then the aircraft will spin up and fly. For heli’s, thottle hold is a state for starting an ICE and running it at idle which is really not needed for electric powered heli’s. Where autorotation lies is between spin when armed and throttle unlimited states There is a spool down state in the motors class which is not seen by the copter code. The spool down state is the motors going from throttle unlimited to spin when armed. It is in this area where autorotation would be. Currently the switch from thottle unlimited to spin when armed is instantaneous and in the future could have some logic that held the aircraft from going from throttle unllimited to spin when armed until the rotors stopped if the aircraft was on the ground and if it was flying, put the motors state (really the RSC) in an autorotation. So you can see that it gets a little messy trying to align the states between multi’s and heli’s but we will get this implemented and then work with @Leonardthall to make improvements where needed.

I’m not sure this is a good idea? I know pilots shouldn’t be going to throttle hold in Loiter or Alt Hold, but I’ve done it before by accident. And so has my wife. The fact that the helicopter “hangs” until the pilot realizes her mistake and hits the throttle hold switch again prevents a crash.

I think there’s several things to consider

  1. it is possible to get an accidental disarm in flight with helicopters using stick arming. I’ve had it happen several times doing basic sport aerobatics. Stick arming comes from the drone world - should’ve never been in helicopters

  2. it is possible to go to throttle hold in flight by accident, or on purpose in any flight mode

  3. helicopters can be flown and safely landed with the controller in disarmed state

So, since we have these safeguards already in heli - machine fully flyable and controllable in disarmed state, can fly in armed state with throttle hold on, why are we not automatically reverting to a flight mode where the helicopter can be flown in these states, which is not Alt Hold, Loiter, Pos Hold, Auto, RTL, or Land?

Moving collective to H_COL_LAND just sets it up for an autorotation profile in flight and preserves headspeed, but in a mode it can’t be autorotated in. So if this happens in the dead man’s curve the pilot doesn’t have time to switch flight modes if the collective goes to H_COL_LAND - it just drops like a rock in a mode you can do nothing with because you have no collective control.

I would propose that helicopters in disarmed state, or armed state with throttle hold, should not be allowed to be in any other flight modes other than Acro or Stabilize. To take off in Loiter, Alt Hold, etc. would require arming, throttle hold off, then you can switch modes after the runup timer completes. This would also fix the problem for folks that land in say Loiter, go to throttle hold and you have a fully flyable helicopter sitting on the ground that can be jumped off the ground in autorotation, but the pilot has no control over the thing.

It would prevent this - this was a test land in Loiter, throttle hold on at touchdown, and the Loiter controller tried to tip it over during spooldown due to a “GPS Glitch”. I had to flip it to Acro and hunt around with the cyclic a bit to find the “ghost” to get it back on its feet. This was Copter 3.6.

In lieu of automatic switching to a manual flight mode, it sounds like I should keep it as it was where it will command Land_speed for the vertical axis. would we want to make that altitude based? Altitude greater than 50 meters, use H_COL_LAND_MIN and less than that set land_speed? typically this is something the pilot should realize, right? then take corrective action. the vertical speed setting in throttle hold is just giving the pilot time to react?

I understand your desire but I want to table this until I get spool logic implemented. Maybe write an issue against tradheli so we can further evaluate this and how we would implement this idea. spool logic is hurting my head as it is.

I think the way it is now works good enough. I can’t really see the logic to putting an altitude on it. The height-velocity curve for different helicopters will be so different it is almost impossible for the autopilot to make that decision. Only a trained pilot is going to know what to do. Say you go to throttle hold in an altitude mode, switch back to flight power, the engine has to go from ground idle to WFO so it coughs and dies. Now what? Unless you get into Stabilize or Acro pronto, you are flying a paperweight. Stabilize or Acro, it’s not even mildly hair-raising because you got collective control.

On landing, however, I can see the reasoning behind it. So it is a two-edged sword.

I thought perhaps something like this might be able to be designed into the spool logic. But we’ll have to bolt it on later. Little thought has been historically given to helicopters and their autorotation capabilities in ArduPilot’s design.

I vote for leaving the autopilot’s collective management the way it is now. And then later we can deal with all the special cases where helicopters have capabilities that multi-rotor drones don’t.

Great work and thanks!!!

Keep the discussion going!!!

:slight_smile:

I worked on it some last night. I propose that in motors stopped state (disarmed) for all non-manual throttle flight modes, the altitude controller is relaxed (set to H_COL_LAND_MIN). the reason I say this is because the current code has the altitude controller relaxed for the landed state. Disarming in any non-manual throttle modes requires the land_complete flag to be true. So for years now trad heli users have been flying with the collective being set to H_COL_LAND_MIN in the landed state. I haven’t heard of any users accidentally getting into the landed state while they were still flying. I think it is reasonable to say that it is highly unlikely that they could disarm the aircraft because it not only requires the throttle stick to be held back and to the left for 3 seconds but also the land_complete flag must be true. I tried disarming the aircraft in Althold in realflight last night and it wouldn’t do it while I was flying. I think the set up would have to be pretty bad for this to happen.

I would still keep the altitude hold set to land_speed if flying and the motors interlock is disabled.

I’m going to change this in the code I fly because I use arming switch. The current implementation of the code disables the arming switch if stick arming is used. But if arming switch is used it does not disable stick arming.

So do you disagree with the proposed change? Do we need to check this functionality with the arming switch (i.e. that it won’t disarm with land_complete flag false)? Or should we push a PR that disables stick arming with use of an arming switch? I just want to understand why you will make an independent change and whether it needs to be resolved differently. It sounds like you still don’t trust that the system will remained armed while flying in a non-manual throttle mode.