Tail rotor causing lean myth

[jaylw314]

Originally Posted by extrapilot

Having the TR above the roll CG creates a yaw/roll couple.

The irony in this whole endless series of threads is- what is it that people are trying to ‘fix’? If the airframe were a sphere that landed in a socket, would this debate exist?

What is bizarre is that that FBL is chassis referenced. It doesn’t even know if there is a rotor on the machine. How exactly does an FBL benefit by some 5deg error term between deck angle and rotor tip path plane? It is no different than taking a conventional 3D machine and mounting the FBL on a 5deg wedge. So great, you get more couples (all 3 axes this time).

But they think this has no impact, because the FBL is chasing its tail at 50-100x/sec fixing what it detects as uncommanded motions- which don’t exist at the rotor. It is absurd.

You're right, the FBL only sees the chassis. It just tries to keep the fuselage from rotating in all 3 axes when there is no input from the pilot. The rotor disc becomes tilted because the PILOT is giving cyclic controls.

You're also right, the idea of having the fuselage level is really quite useless for RC flying. It might be useful in real life with passengers who get motion sick, though. Like I said, I suspect the coupling constant with a rigid hub is so high in small scale that it is useless in RC. I can't ever (in my brief experience) recall seeing a hovering RC helicopter whose rotor disc and fuselage are obviously at different angles. I suspect the human eye could distinguish as far down as 2-3 degrees difference.

[extrapilot]

Blades flap- this is why the rotor tip path plane changes in our machines, and in full scale, relative to the main shaft axis.

You would be astounded to see the amount of deviation- just due to bending of blades in flap, bending of grips/feathering shafts, bending of main shaft, etc- even if the dampers are rigid.

[jaylw314]

Originally Posted by extrapilot

Blades flap- this is why the rotor tip path plane changes in our machines, and in full scale, relative to the main shaft axis.

You would be astounded to see the amount of deviation- just due to bending of blades in flap, bending of grips/feathering shafts, bending of main shaft, etc- even if the dampers are rigid.

Structural flexing (either the blades, grips, hub, shafts, etc) and play has to account for all of the blade flapping in a rigid hub, and the torsion constant is not infinite. I'm not sure, but I assume the coupling constant of a semi-rigid/teetering rotor is small, but not zero. Anyone know if this is true? If so, Robinson R22's would have their fuselage sit completely still while the pilot gives full left then right cyclic, which I don't think happens...

My guess that the torsion constant in a rigid hub is very large is based on the OP's photo. Notice that in all 3 craft, the mainshaft and rotor disc axis appear aligned and identical. If the torsion constant was small, you would expect to see different angles between the mainshaft and rotor disc axis. That looks like an mCPX, though and as you scale up, the torsion constant decreases (since objects are proportionately less stiff as size increases). I wonder how large you have to get with a rigid hub before you noticed any such effect, but I admit I have no idea.

[rallyant]

Gedexas is correct,

surprised to see how many have trouble understanding this, especially another Helicopter engineer!
People seem to confuse the moments acting on the air frame (You all seem to have correct .) with having an effect on the aerodynamic requirements for a still in air hover.

Yes, the lower the tail rotor the larger the moment, or if the tail rotor is above the rotor head the direction of the moment will be reversed, and be attempting to bank the heli in the opposite direction. But the ONLY effect these changes in torque have is on the airframe, The reason the bank will NEVER change regardless of tail rotor height is that he swashplate MUST compensate these changes moments.
The lean also causes a small vertical moment from the tail rotor that in theory needs to be compensated with some up elevator.
Just drew up a bad, exaggerated, quick sketch of whats going on with different tail rotor heights.

Originally Posted by flim63

Tail rotor height might not affect, but the longer the boom, the longer the moment and would reduce the amount of thrust required to counter torque and therefore REDUCE the amount of lean required, but never eliminate it.

Spot on, this is the only thing that effects the lean, ( apart from things like more efficient blades that may reduce the torque required to hover) And probably the main reason people think high tail rotors lower the lean, most (all*) helis with a higher tail rotor have a much longer boom (moment arm) in order for the tail blades to clear the main blades.

Originally Posted by kennyd1gital

First and foremost, CG has EVERYTHING to do with it. The tail rotor is directly in line with the longitudinal CG of the helicopter. If it weren't it would produce a rolling moment. For example, if the tail rotor was right or left of the longitudinal CG, the helicopter would roll in the direction of the tail rotor thrust. When the tail rotor is directly on the longitudinal CG, no roll is produced, but instead the thrust of the tail rotor pulls the helicopter in the direction of thrust (translating tendency). The helicopter would still get pulled in the direction of tail rotor thrust if the tail rotor was to the left/right of the longitudinal CG, but it would also produce a roll about the helicopter's longitudinal axis, which in turn would require even more lateral cyclic to compensate.

This is exactly what does happen, get your heli and test the CG hight. almost no rc helicopters have the CG down the boom. the roll caused from yaw accelerations is extremely small compared to the annoying off center roll with cyclic inputs, The optimal place for CG is right in the center of the rotor head!

Next time you hover the heli, smash the cyclic left and right, you will see the roll point is always quite low. now hang a weight below your heli to make sure the CG is well below the boom (or well above the boom if you can) and smash the yaw left and right. tell me if you can pick ANY difference. The FBL unit also works to cancel out this small effect. But there is no way for anything to cancel out the negative effect of the CG below (or above, ie when inverted) the center of the rotor head for cyclic.

Originally Posted by Gedexas

I thought about the CG and the tail rotor height over and over and I think I got it. Whoever said the tail rotor needs to be aligned with the CG for zero roll moment is correct. Sorry for being so stubborn.

That still does nothing for the lean on my helicopter..

True, but do the calcs, its very minor, plus the fly bar or FBL unit compensates for any profound effects this might have.

everyone seems to think its a great idea to have the tail rotor nice and high to cancel the lean, but this puts the tail rotor WAY above the CG, no complaints about the roll that causes?

Claiming the moment from a low tail rotor causes lean is like claiming the moment from the tail also causes Yaw, Both can true, but both are compensated for in a static hover.
The yaw moment is compensated for by torque from the main rotor drag just like the roll moment from the tail is also compensated for by the swash.

[rallyant]

The other way to get rid of the lean is to have a tail boom on the front as well.
Its been done.
Good test would be to have one out the front up high and the one at the back down low in order to give a large roll moment, if its still flat in a hover like this (and it will be), We will have our answer

[R_Lefebvre]

Originally Posted by rallyant

The other way to get rid of the lean is to have a tail boom on the front as well.
Its been done.
Good test would be to have one out the front up high and the one at the back down low in order to give a large roll moment, if its still flat in a hover like this (and it will be), We will have our answer

Even better would be to put the anti-torque rotors to the sides, instead of ahead and behind. Then you could use them to generate propulsion as well as anti-torque.

[R_Lefebvre]

I'd like to change up the discussion a little bit since the mechanical debate has gone stale. Let's talk about electronics and control theory.

I am working on the controls program for Arducopter, and this chassis-tilt thing is a persistent issue that I have not found a solution for. Just to frame the discussion, let's assume we're talking about a "typical" RC heli with a low mounted tail rotor.

In a stationary hover in a windless environment, the frame needs to be tilted ~6 degrees or so to counter the tail rotor thrust. This isn't a big deal when flying in "rate mode" as most flybarless controllers do. The pilot would hardly even know it's happening unless they take photos of their machine so they can argue about the causes on the internet.

However, in our Stabilize mode, it does matter. Stabilize mode attempts to keep the frame level. Or, if a roll input is commanded, it will move and hold the commanded roll angle. Typically full-stick will give you 45° roll and hold.

So when hovering in Stabilize mode, in a windless environment, you actually have to push hold a bit of right roll input to get the frame rolled to the right to generate your thrust. Not a big deal, but slightly annoying.

The other solution, is to modify the program such that the controllers believe that "level" is actually 6° rolled to the right. Now you don't need to hold any roll input in a hover, and all is good. However, it's kind of an ugly trick. When the helicopter is sitting on the ground, the HUD shows a 6° left roll. I just don't like doing this because it's sort of like "lying". I prefer to model things properly, instead of fudging things.

I've thought about putting something in the program such that, if the controller things it's in a hover, automatically roll it to the right 6°. Fairly simple. But exactly when would you remove that input offset? All of a sudden a given speed? Gradually? At what rate?

It's complicated by the fact that you actually still need to compensate for the translation in forward flight. The tail rotor is still generating side thrust. But, in forward flight, you actually have two choices on how to stop the sideways translation. You can either continue to hold the roll angle. Or, you can steer the heli a little to the right, so that it's forward velocity is partially offsetting the translation tendency. I prefer the latter myself. But again it leaves the question about how do you transmission smoothly, and automatically, from hovering condition with a roll angle, to FFF with a heading offset?

Anybody want to jump in?

[rallyant]

Originally Posted by R_Lefebvre

Even better would be to put the anti-torque rotors to the sides, instead of ahead and behind. Then you could use them to generate propulsion as well as anti-torque.

Problem is they propel opposite directions.(Edit: just looked at the pic. I'm guessing thrust only comes from one side until in FFF. Certainly gets rid of the sideways lean would have to tilt backward in a hover instead)
But an even better idea is to hover inverted. The Heli leans to the left instead of the right... Against the moment caused by the tail thrust! IMO proving that moment has no effect on lean.
I can already hear the arguments against that tho

Interesting!
As a 3D Pilot I'm also interested in how FBL units manage negative pitch.
When doing tic tocs or even just smashing the collective up and down in level flight you will see the rotor tilt right, left, right, left as you go -+-+ (also proving the lean is not from tail rotor height. And fbl programmers understand this)
But they don't all seem to compensate the same amount. Skookum vs vbar etc etc.
I'd really like to see this as a programmable variable.
Also, the more pitch you add the more torque and the more thrust from the tail required to compensate for with extra lean. A simple thing I'm sure, but how does the fbl unit know if your running +-10° or -+14° etc.
Then there is the issue of when vertical. The Heli still has the thrust from the tail, but with reduced or 0 thrust from the main rotor, no way to compensate. Not a big issue. But its still interesting to think about..

Not sure of anyway around the 6° lie, (without accelerometers / GPS etc) I think a compensating V curve "lie" with 0° at 0pitch and +-6° at +- hover pitch upto ?° at ?pitch is the only way. So on the ground it would show anywhere from -x° to +x° depending on where the stick is.


___________________________
Sent from phone using Tapatalk typo generator

[extrapilot]

Rob

I guess the first question is- what are you trying to accomplish? Is the goal autonomous waypoint-based flight? Why would you prefer flying nose right to leverage body lift to offset translating tendency vs a roll, which is more efficient?

Regardless, you cannot expect the rules in question to change because an autopilot is in control.

Example, say you find some generic solution to adding a roll bias on departing (skid squat switch or whatever). What happens in a cross-wind? What happens in FF as the rotor becomes more efficient, and the vertical stab offloads the TR (where there is generally a different arm length, altering roll)?

Even just changing headspeed has an effect on lean, due to the change in parasitic drag on the main rotor.

If you are intent on deck angle, about the only way to deal with it is a high-compliance head, where the machine is allowed to pendulum more freely. Wont solve several problems, and adds several more, but it helps with the core problem you defined.

[rallyant]

Oops I didn't read through this thread properly.
You have it all covered pretty well extrapilot! And much more articulate that I could ever manage

___________________________
Sent from phone using Tapatalk typo generator

[desertstalker]

Originally Posted by R_Lefebvre

Anybody want to jump in?

What sensors do you have available?

The exact angle and direction of lean in a hover is rather heavily dependent on external factors (wind, etc.) and heli properties. It should be possible to setup the control without worrying about the angle, just have it correct for the motion of the heli to hold hover. This should be possible with GPS + accelerometers.

The Helicommand levelling has an adjustable offset in the setup software (i think the Brain does too) but they only offer levelling, not full flight control.

[R_Lefebvre]

Ooh great, lots of responses. I'll try to answer this as logically as I can.

I guess the first question is- what are you trying to accomplish?

Great question, I'm not sure I know the answer! Obviously I'm trying to build the best possible UAV flight controller. But that's a cop-out because it doesn't really answer your question. So let's just say this is completely open. I'll do whatever is best, and don't mind making it an option that is selectable by the user (ie: either lean right, or steer right)

Why might a user want one rather than the other? I understand that passenger helicopters, tend to use the steer-right approach, because a constant 6° lean is uncomfortable for passengers. I'm curious what do military chopper do where passenger comfort isn't a factor? Is one flight mode more efficient than the other? When you lean to generate counter-thrust, some of your total main rotor thrust vector is not being used for lifting. So you lose something there. If you steer right, would you lose efficiency because your side-ways component of airspeed means you are actually having to travel through more air? ie: when crabwalking it, you have a sideways component of airspeed which sums onto the forward component. You need more total airspeed to achieve a given forward groundspeed.

Any other issues? Camera gimbals without roll axis. Most specifically, downward facing mapping cameras. One of my goals is for helis to replace airplanes in areas where the take-off/landing of fixed wing is problematic. Helis can still kick the tar out of multirotors in this application.

Is the goal autonomous waypoint-based flight?

That is one aspect.

We've already achieved that in case you missed it:





And "we" is an open source project. I'm the lead heli guy adapting the code to run helicopters.

Example, say you find some generic solution to adding a roll bias on departing (skid squat switch or whatever).

Good question. In the past I have trimmed the controller (electronically) to think that ~6° roll is level. And we don't have a positive ground contact sensor. So this would be a problem because the controller will try to tip the heli over on the ground. But, I've got a little trick that prevents it actually being a problem (more detail available on request).

But lately I've trimmed it flat because I hate lying to the thing about where level is.

I suppose a fairly straightforward solution is to generate a tail-rotor=>roll compensation. I already have collective==>tail-rotor. I could add a programmable tail-rotor=>roll compensation. Assume zero tail rotor pitch is zero thrust, and there would be a variable which multiplies by the TR position to come up with a roll offset, the value of that variable would be simply determined heuristically.

Now, that would work great in a hover. But the question about what to do in FFF still remains. This would probably work fine in FFF too. But it still doesn't give us the option of keeping the frame level.

Anyway, one problem I have with this solution, and it's a big problem, do we really want to do this in highly dynamic flight? This controller can be used for UAV's, but it can also be used by beginners, or people interested in relaxing sport-flight with a helicopter, or scale guys. So I need to cover all the bases. And I see a big problem for example, if you do a pirouette and then stop. To stop the piro you need a big stab of TR thrust, which would then end up trying to roll the helicopter over quite hard. Also, any tail wag would also result in a roll wag. Get's ugly.

I might think a simple solution is a very low frequency low-pass filter on the roll compensation number. It would "take a set" in a hover, but not respond to every little jerk of the tail rotor.

Even just changing headspeed has an effect on lean, due to the change in parasitic drag on the main rotor.

Yeah, absolutely! And one of my things is that I want to have variable headspeeds possible depending on different flight conditions. Then you also have variable payloads, etc. etc.This is why a static offset is just not a good solution. I think this is what the Naza-H does, and nobody seems happy with it. That static roll-offset is wrong more often than it's right.

If you are intent on deck angle, about the only way to deal with it is a high-compliance head, where the machine is allowed to pendulum more freely. Wont solve several problems, and adds several more, but it helps with the core problem you defined.

To what degree of compliance are you talking about? I'm using the softest available dampers on my Trex 550/600. Or do you mean free flapping?

In any case, I want to come up with a solution that is hardware agnostic.

So, I've suggested a strategy to deal with this in a hover, that will also work for FFF where we will accept the cabin lean. We can talk more about ideas for crabwalking algorithms later. Looking forward to any feedback on what I've said so far.

What sensors do you have available?

We have 3 axis gyros of course, 3 axis accelerometers, 3 axis compass, GPS, and baro.

Before launching into this branch of the discussion, I should briefly mention the flight modes. First, we have Acro. The goal with Acro is to have a "competent" FBL controller. I'm not interested in 3D smack, but something that a sport pilot might be happy using. We're pretty close to that already, and I don't think any of this applies at this point anyway. Acro is a simple rate controller, and wouldn't have any roll compensation built in. It does have collective=>TR compensation, and that's working fairly well. I'm still not completely happy with the yaw controller, I can't quite get the performance I'd like, but that's another topic altogether.

Second mode is Stabilize. This is basically your auto-level. Release the stick, it returns to level. Push full forward, and it moves to 45° and holds. But that's about it, it's otherwise full-manual piloting. This is also working really well already. But, this is where the discussion about this roll compensation stems from. If you trim the thing level, you have to hold some right stick to get it to stop drifting to the left.

The exact angle and direction of lean in a hover is rather heavily dependent on external factors (wind, etc.) and heli properties. It should be possible to setup the control without worrying about the angle, just have it correct for the motion of the heli to hold hover. This should be possible with GPS + accelerometers.

And that's where "Loiter" comes in. But it's really GPS/Inertial position control, with pilot commanded groundspeed. This also already works fairly well with no compensation built in at all. At this point, the controller thinks that the tail rotor thrust is just a sidewind. It naturally rolls a little to compensate. Still amazes me how well it works. When flying waypoints, you can even see that it is rolled a little, which is what made it obvious to me that the tail rotor thrust is still a factor even in FFF.

At this point, the controller simply rolls the copter to compensate for TR thrust and/or cross-winds. I'd prefer to have it actually yaw the helicopter into the wind rather than have it roll. Right now if you have a heavy crosswind, it could result in quite a bit of roll trying to counter that and it can look a little silly. But that's one of the problems, is we have NO knowledge of windspeed. Everything is ground-referenced (GPS). This is because it's practically impossible to have an airspeed sensor on a helicopter.

When doing tic tocs or even just smashing the collective up and down in level flight you will see the rotor tilt right, left, right, left as you go -+-+ (also proving the lean is not from tail rotor height. And fbl programmers understand this)

Really? I'd be shocked if this is true. FBL controllers are, as far as I know, simply angular rate controllers. They aren't aware of linear accelerations, so I wouldn't think they would be trying to counter the the TR thrust. The tilt you're seeing must be some other effect?

A simple thing I'm sure, but how does the fbl unit know if your running +-10° or -+14° etc.

This is pretty simple. Well, right now, our controller isn't really aware of it at all. It's only aware of where 0 pitch is, and then it knows the min and max servo angles the user will permit. But it doesn't know what that equates to in actual pitch angles.

Some FBL controllers actually ask the user to tell it what servo angle equals 12° pitch.

I do want to make our controller a little smarter here, as currently we do not do any servo angle trig compensation. For example (on a typical heli like a Trex) if you have the swashplate leaned forward heavily, and then you give a pitch pump, the swash angle will tilt back a bit. This is because the collective pitch increase comes in as an equal PWM number added to each servo output. But that doesn't translate into equal swash ball lift on all 3 balls, because the rear servo horn was already at a high angle.

But again, that's another matter.

Not sure of anyway around the 6° lie, (without accelerometers / GPS etc) I think a compensating V curve "lie" with 0° at 0pitch and +-6° at +- hover pitch upto ?° at ?pitch is the only way. So on the ground it would show anywhere from -x° to +x° depending on where the stick is.

I guess that's possible, but I would prefer to do this compensation on the TR thrust, as it's closer to the the truth. I prefer to always model systems as close as you can to physical reality, as it makes it easier to understand. Just fudging things gets ugly, fast. Especially on nasty helicopters which are completely asymmetric in their operation.

[rallyant]

Originally Posted by R_Lefebvre

Really? I'd be shocked if this is true. FBL controllers are, as far as I know, simply angular rate controllers. They aren't aware of linear accelerations, so I wouldn't think they would be trying to counter the the TR thrust. The tilt you're seeing must be some other effect?

.

Thanks for the detailed response! Lots of musing reading

Maybe I'm just bad with my setups and that's why it does it
But I have done it on every fbl unit I have had as well as asked my mates to do it on their helis so I can sew if it does it for them too . I think I even have some video of it. I'll get some more if I haven't.
The skookum did it much more than the vbar. Or maybe there's another reason for it.. But if I was designing a fbl unit I would build in this compensation and make it tunable. otherwise the Heli will drift off to the left(tail in) as you punch the pitch up and down.... Infact, if you look at the CGY setup video Nick maxwell did he shows the Heli doing exactly this, but with the tail/airframe drag compensation settings. So it was drifting forwards or back as apposed to sideways.
Yes they are angular rate controllers, but I was under the impression they also compensate for this and other things.

My +-10 vs +-14 question was I'm regards to the compensation and my want for it to be tunable since full stick pumps with 14° is going to require more thrust from the tail to negate and therefore more bank from the main rotor than a 10° full stuck pitch pump(at the same rpm)..So its null and void IF FBL units do not have this compensation .
___________________________
Sent from phone using Tapatalk typo generator

[R_Lefebvre]

I'm very open to explore that further.

But another reason I am doubtful that is what is going on is that the time constant of the main rotor response is probably an order of magnitude slower than that of the tail rotor thrust itself. So it could never be made to compensate the tail rotor thrust changes on the timescale you're talking about.

Again, I could be wrong here, so totally open to debate. Do you have a link to this Nick Maxwell video?

[rallyant]

Maybe.
But maybe that's also why different fbl units do it more than others
And probably why its only noticeable with very fast full stick pumps.
I'm guessing there is an acceleration as well as a constant compensation. So fast pumps may see more than slow ones?
If the % of compensation was tied to stick position (center stick or 0° pitch =0° swash tilt - full stick -&+ = X° swash tilt) then it will at least climb vertically the same inverted as right way up. But there will obviously never be a perfect setup. Eg: A full pitch down could not compensate at the same settings as if it were inverted and climbing.

I'll post the link when I get on my laptop tomorrow. But if you YouTube im sure it will be the first one. I think I downloaded it from the futaba website.

___________________________
Sent from phone using Tapatalk typo generator

[extrapilot]

Rob

Are you using the MPU6xxx series? If so, have you done any work with the DMP engine?

Unfortunately, some of your questions are way too complicated to answer in a way most can understand, and they are going to be dependent on context. Example, is it more efficient to cant the rotor or fly crabbed? That depends. If you break out the math, and calculate out the TR thrust in still air for a hover, you will find that the rotor cant angle tends towards 5deg-ish. For a 450, that tilt drops the vertical component of thrust from 1.5lbs to 1.494lbs. It is a tiny fraction. In FF, depending on the head compliance/airframe/tail/etc, you may find that the roll angle neutralizes or even reverses as airspeed increases.

Most machines are designed for cruise speed operation- so they live with the deck angle in hover in trade.

Im not sure I follow your TR->Roll comp idea. If the TR is near the roll axis, changing its thrust magnitude will not tend to generate a roll moment. For raised tails, yes, but few of our machines use that. Do you have a piro-comp mechanism incorporated yet? Maybe you can expand on why you feel this is a concern?

If this is machine agnostic, then you cannot escape the physics of translating tendency. There are no tricks you can apply that will work generically. You require offsetting force, and that can only come from rotor cant. The rotor is coupled to the airframe. End of story.

Using crab angle it just a bit of a challenge, since there will be airspeeds below which it cannot work, or cannot work without excessive yaw. Keep in mind, you may be flying in a 30kt wind, where your ground speed may be defined for 30kt, but your airspeed is zero (or 60kt, or anything in between). How does your system presently work for autonomous flight where the ground track is defined as a circle, and there is significant crosswind? If you are always flying longitudinal axis as nose and tail on the circle, your only mechanism to offset drift is significant roll.

Id contest your assumption that you cannot determine airspeed. You can, with GPS, if you leverage known performance characteristics (i.e. ground speed in a line given some particular control input). You can measure the delta, and get a wind velocity vector, then just apply that to your nav calculations.

Keep in mind, rotor drag can be huge even at 0deg AOA. So it is a bad idea to hard-map anything based on headspeed. If you have a learning system, as with a modern ECU, you may have some luck. But I think you will find you are better off just keeping nav rules simple, and leaving the rate corrections in reactive mode.

[rallyant]

Some dam good points there extra!
I have never put any thought into autonomous flight control.

As for windspeed and direction, Our flight computers for hang gliding work much the same. Do a couple of circles and it works out wind speed and direction quite accuratley . More accurate if using an air speed meter too. It even calculated you mcreedy speeds to fly, maybe use full if you want it to autonomously control a sail plane

___________________________
Sent from phone using Tapatalk typo generator

[desertstalker]

Originally Posted by rallyant

Thanks for the detailed response! Lots of musing reading

Maybe I'm just bad with my setups and that's why it does it
But I have done it on every fbl unit I have had as well as asked my mates to do it on their helis so I can sew if it does it for them too . I think I even have some video of it. I'll get some more if I haven't.
The skookum did it much more than the vbar. Or maybe there's another reason for it.. But if I was designing a fbl unit I would build in this compensation and make it tunable. otherwise the Heli will drift off to the left(tail in) as you punch the pitch up and down.... Infact, if you look at the CGY setup video Nick maxwell did he shows the Heli doing exactly this, but with the tail/airframe drag compensation settings. So it was drifting forwards or back as apposed to sideways.
Yes they are angular rate controllers, but I was under the impression they also compensate for this and other things.

My +-10 vs +-14 question was I'm regards to the compensation and my want for it to be tunable since full stick pumps with 14° is going to require more thrust from the tail to negate and therefore more bank from the main rotor than a 10° full stuck pitch pump(at the same rpm)..So its null and void IF FBL units do not have this compensation .
___________________________
Sent from phone using Tapatalk typo generator

The whole main rotor is canted (not just cyclic input) so an increase in collective pitch will also increase the force countering tail rotor thrust. This force is proportional to the increase in main rotor torque and thus proportional to the increase in tail thrust (roughly). Thus the lean angle of a heli in a vertical climb (or descent) would not differ significantly from one in a stable hover (at least in theory).

The difference is likely how well the FBL compensate for the initial impulse change in forces (the collective thrust change will likley occur slightly before the tail can compensate, or slightly after if pre-comp is enabled). If the forces dont change in sync then the heli will change attitude slightly which would cause the climb to change direction.

[extrapilot]

There is an issue in negative collective. The thrust vector reverses, but the direction of torque does not. So to compensate for translating tendency, the rotor needs to cant the opposite direction. This is at the root of the fallacy of raised tail logic. They forget that the arm, and the direction of torque, does not reverse with the main rotor cant angle, and so what they believe helped them upright, must hurt inverted. But they pretend this is not the case. Geometry seems out of their reach, but they are happy to comment on advanced control algorithms etc lol.

[Iceberg86300]

What is the DMP engine? Right now I'm stuck in the world of the 16 bit Freescale 9s12, although they did come out with a new version with a "core" that makes them much more powerful, but it is still just some extra tech added into a ~2005 piece of hardware.

Rob, I think we need more info regarding exactly what you want to accomplish. You say you have the "aero" mode working well, but I'm confused on one issue, you say the pilot has to "hold" the lean. It has been my understanding that FBL does not reside fully in the "rate" mode that is the basis of all gyros. Rather more of a HH rate mode combo. Essentially if you aren't on the sticks all 3 axis are in HH. Hit the sticks and you command a rate, but release them and the air frame is going to stay in the orientation it was in when the sticks hit zero.

Unless you've programmed things differently. (trying to come up to speed on what your doing)

After that, the question is what do you need to control the lean for? Or I should say dictate the lean. It seems like you want to dictate the lean (or yaw in FF) based on the variables in and outside of the heli. By dictate I mean how you describe having a hard angle of ~6*.

With compensation mentioned I'm guessing you are trying to predict what is needed to go from hover to FF off in a straight line with a minimum of pilot input.

I guess where I'm headed is why not leverage your hardware and software as much as possible to react to all the variables. Change and refine the control loops, likely coupling 2 axis and having a general precomp that is adjusted in settings, or even adjusted on the fly based on sensor input.

You can do the same thing with your control loops by having dynamic terms based on ground speed from the GPS, wind conditions that c can be generalized based on gps and gyro data.

Of course this creates some quite complex control programming, but not impossible, and could be heli independent with the use of variables adjusted in the settings interface.

Something to think about, or dismiss if I'm off base and let me know where I'm off.

Regards,

Steve