Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations IDS on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Basic Aircraft sim not producing desired results. 2

Status
Not open for further replies.

ra1024

Electrical
Jan 30, 2012
8
I'm in dire need of assistance in fixing an aircraft sim. I was a Math/Physics major before switching to electrical engineering so I have a good background in the area but could use a true ae to help with some of the areas that are not quite right.

If I adjust the rudder parameter for example to make it turn well, it messes up the behavior for when the plane falls backwards after flying straight up. This makes me believe I'm not doing something right like not modeling the forces on the control surfaces correctly.

I have about 12 steps in my sim process and model about 11 main forces so it's not a very detailed simulation. If anyone has time to help, it would be greatly appreciated. I would be willing to pay for someone's time if that would be appropriate. I'm including a summary of what I do below but let me know what else I should provide.

Thanks,
Reggie

Vector Setup - I don't suspect any problems here, I deal a lot with vectors and these should be correct.

Rotation Slowdown - I reduce any rotation velocities across all 3 axis here to simulate the wind resistance that would slow down a rotating aircraft that was spinning fast. Here's the calc for each axis.

f1 = angularVelocityX * angularVelocityX * 90 // 90 is an arbitrary constant that gave good results. The faster it's spinning, the greater the slowdown torque
// f1 is now checked to make sure it's not big enough to cause a rotation in the opposite direction, ie it can only slow down the current rotation to 0
torqueX = torqueX - Math.Sign(angularVelocityX) * f1

// Repeat for X & Y axis


Elevator Effect - I add in rotation velocity due to the effect of the elevator. I could have set a torque but decided instead to just directly affect the rotation.

velocityUp = plane's velocity perpendicular to the elevator
curTime = 0.001 // I used fixed time steps of 0.001 seconds
signFactor = 1 or -1 depending on the direction of velocityUp
f4 = dot product of velocity with planes forward vector

f4 = Math.Sign(f4) * (1.0f - Math.Abs(f4)) // If velocity is parallel to elevator, f4 is 0. As velocity approaches completely perpendicular to elevator, f4 goes to 1
angularVelocityX += signFactor * velocityUp * velocityUp * f4 * 0.025f * curTime // 0.025 is a scaling factor


Lifting Force from Wings - If the plane's velocity is forwards, I calculate lift and drag forces for each wing so as to take into account the dihedral angle.

velocityF = plane's velocity with side component removed ( only forwards/upwards velocity components remain )
drag = Get_Point_2D_Float_Graph(angleOfAttack, 0) // look up the drag from a lift/drag curve

totalDrag = drag * wingDragFactor * velocityF * velocityF * 0.5f; // Divide by two since this is just half of the wing

forceX -= totalDrag * xForward // Add in drag forces for each axis due to wing drag
forceY -= totalDrag * yForward
forceZ -= totalDrag * zForward


signFactor = 1 or -1 depending on the direction of the angle of attack
lift = Get_Point_2D_Float_Graph(angleOfAttack, 1) // look up the lift from a lift/drag curve
totalLiftRightWing = lift * wingLiftFactor * velocityF * velocityF

forceX += totalLift * signFactor * wingVectorUpX
forceY += totalLift * signFactor * wingVectorUpY
forceZ += totalLift * signFactor * wingVectorUpZ

// Repeat for second wing


Dihedral Torque - I add in torque produced by the wings dihedral angle.

torqueY -= mainVelocity * (totalLiftLeftWing - totalLiftRightWing) * 0.000000005 // Last number is a constant that produced a good result


Rudder

velocityRight = velocity component parallel to the plane's right vector ( as seen from pilot's viewpont )
torqueZ -= Math.Sign(velocityRight) * velocityRight * velocityRight * 0.075f



Engine

forceX += xForward * engineThrust
forceY += yForward * engineThrust
forceZ += zForward * engineThrust

Wind Resistance

f2 = velocityForward * velocityForward * flatPlateArea;
forceX -= f2 * xForward
forceY -= f2 * yForward
forceZ -= f2 * zForward

Force Against Wings - This would come more into play if the plane were dropped with zero velocity

f1 = velocityUp * velocityUp * areaWing;
forceX -= f1 * xUp;
forceY -= f1 * yUp;
forceZ -= f1 * zUp;


Gravity

forceZ += DefinesClass.GRAVITY * mass

Controls Input

// rotZ = rudder input
// rotY = aileron input
// rotX = elevator input

torqueZ -= rotZ * 0.001f * velocityForwards // 0.001f is a scaling factor for the input parameter
torqueY += rotY * 0.00045 * fuselageVelocitySquared // 0.00045 is just a scaling factor for the input parameter
torqueX += rotX * 0.00012 * fuselageVelocitySquared // 0.00012 is just a scaling factor for the input parameter


Calcuatle Position, Velocity, and Rotations - After summing up the forces and torques, I have a basic physics routine that calucates the new state of the aircraft. This is pretty straightforward and I don't believe I have any issues here.

get_Planes_Position(airCraftData, curTime)






















 
Replies continue below

Recommended for you

I got involved in a similar problem many years ago, i.e. electrical/physics major analyzing a mechanical system. The one big flaw which I remember was that the older Boeing expert was not taking into account that different parts of the aircraft were subjected to a different angle of attack due to pitch rotation. He kept putting into his formula the same AOA for the elevator and the wings, even though the wings were almost 100 ft away from the elevator. I could not, through sketches, plastic model in my hand, equations, you name it, I could not get him to realize that the rotation causes a different AOA on different parts of the airplane. At near stall speed this was critical to the issue we were analyzing.
This rant probably was way off your question but, that's my 2 cents. You are very correct to mention rotation and take its effect into account.
 
Student posting is not allowed

TTFN
faq731-376
7ofakss
 
Thanks hgldr for the info. That's one piece to consider.

@IRstuff, I haven't been a student since 1990 when I graduated from GT.
 
i don't see you calc the lift on the horizontal tail, balancing the lift on the wing ?

i think IR was mislead (as i nearly was) by "was a Math/Physics major before switching to electrical engineering" ... the time meaning of "was" could be a month or a decade ...
 
Hey Rb, thanks for the reply. I suspect my modeling of the elevator and rudder may be where my problems are coming from. For the elevator, I don't do the balance you were referring to as I just assume the wing lift is above the CG and causes no rotation. I can then just treat the elevator as causing rotation. Is this simplification going to cause the simulation to break in certain conditions and produce unrealistic behavior? I don't need extremely accurate results, just pretty close to real world behavior.

Here's a breakdown of my force/torque model. For a moderately realistic simulation, should these be sufficient?

Thanks again,
Reggie

Forces
wing lift, gravity, wing drag, fuselage drag, engine thrust, force against wings from perpendicular (up/down) velocity component

Torques
wind resistance to spinning about an axis, rudder torque, elevator torque, torque due to dihedral, torque due to controller inputs

 
i suspect your problem is ignoring the horizontal stabilizer. i think you need the two sufaces to balance control inputs and upsets (if you allow upsets in your sim). You could say you're modelling a tail-less (delta wing) plane (like a Mirage III) but then you'll need different control inputs and additional wing reactions (pitch moment for one).
 
If I take the force due to lift on the wings and calculate the torque from that and do the same for the elevator, and add a translational force for the elevator, would that correct the problem?

Also, do I need to continue adding a second force for velocity perpendicular to the elevator? If the plane had no velocity or thrust and was dropped, I needed to simulate the torque that would push on the tail and point the plane downwards. I wasn't sure if I should just do as you say and calculate lift but this would be a case of lift with an AOA of 90 deg.

Thanks,
Reggie
 
You're not very clear about what your simulation does or does not do that it shouldn't or should. Something about wrong behavior in vertical orientation? Specifically related to rudder control inputs only?

How do you store your orientation? It needs to be a quaternion or matrix. Three euler angles won't do it as they will produce funny behavior (for instance) when you go straight up. (Gimbal lock).

If you don't get answers here, you might want to try Gamedev.net's Math&Physics forum. They are very well versed at this kind of simulation.
 
What the current simulation does is provide a fairly convincing simulation of an airplane. What it doesn't do is provide accurate results for certain scenarios. (orientation is stored in a quaternion ).

In thinking about what rb1957 said, I realized one of the problem situations is caused by the lack of a h-stab lift component. One thing I noticed was if the plane took off with no elevator applied, as it began to lift off the nose would tip up and the plane would continue to rotate up and slowly go into a loop. I realized that in my model this was correct because as the wings lift raised the plane, this caused a downward force on the elevator causing the nose to rise slightly. If I had treated the elevator as a wing as rb1957 indicated, the elevator's lift would have created a counter torque and kept the plane level.

I guess what I really need to understand is if any of my modeling assumptions are wrong as was the case with the elevator.

I'm going to modify the elevator but one thing I'm not sure of is whether I still need to add in a force caused by velocity perpendicular to the elevator or whether to treat it solely as a wing type surface. If the plane is falling straight down, I need the elevator to push the nose down (I think). I've tended to think of a plane behaving much like an arrow and perhaps this is a big part of the problem.

Thanks,
Reggie
 
consider the elevator as a wing ... it might make sense for elevator lift to be +ve down.
 
Sorry but I'm not clear on that last part. Are you saying that I should take the lift produced by the elevator and then add in a force created by velocity perpendicular to it?

So should I use the same model for the rudder as well?

Thanks,
Reggie
 
I think what RB is saying is that the force on the elevator needs to be in a downward direction.

In most aircraft, the machine is balanced so that in the absence of an elevator/stabilizer, the aircraft would rotate to a nose down position. the downward acting force on the elevator counteracts that.
B.E.

The good engineer does not need to memorize every formula; he just needs to know where he can find them when he needs them. Old professor
 
i'm not sure how you're using velocity perpendicular to the surface (or how you're determining it).

i'd treat all the surfaces as lifting surfaces (same as the wing) and not as "barn doors". flying straight and level the wings generate enough lift to react weight (and the balancing lift of the stabilizer), so somehow you have a Cl table ... the airplane flies straight and level at different speeds. so flying straight and level you want lift from the wing and down lift from the elevator. add some elevator force, the nose tips up the wing creates more lift, the airplane rises ...
 
@berkshire Ok, I was under the impression they were balanced the opposite way for some reason and thought the elevator would provide upward force to balance. That makes sense now.

@rb1957 I'm going to modify the program to do treat the elevator and rudder as lifting surfaces and that all makes sense. The one scenario I'm still unclear on is what happens if the airplane is dropped from a state of no velocity and no thrust. I thought a real aircraft would behave similar to an arrow. I thought air would push on the elevator and tip the nose down. That's why I calculated a velocity component perpendicular to the elevator and applied a torque. I see that during normal flight, this force is negligible compared to the lifting force but in the case of negligible forward velocity, should this force be considered?

I really appreciate everyone's input, it's really helping me understand the flaws in my original model.

Reggie
 
"if the airplane is dropped from a state of no velocity and no thrust" ... then the plane pretends it's a rock !

actaully what should happen, after the airplane stalls, is it should nose over, with or without control input (through the elevator), enter a dive (control inputs to prevent it getting too steep), to create airflow over the wings, and lift, and then the plane sheds it's rock persona and becomes a right-thinking plane again.
 
Ok, that's what I thought would happen. In my previous model I had the main lift vector over the CG and just took into account wind pushing the nose down due to the elevator. I now understand the CG is in front of the main lift vector so in a falling condition, I would have a force on the wings and a force on the elevator creating torque in the same direction to push the nose down.

For the purpose of my simulation, I think I will take the flat plate area of the wings and of the elevator and calculate a force using the same drag equations I used for drag on the fuselage. I'll then use these 2 forces for a translational force on the fuselage and a torque component.

So for modeling the wings and elevator, I'll have a lifting force and torque created by airflow over the surfaces and a force/torque created by airflow perpendicular to the surface.

Would this be a reasonable approach?

Thanks,
Reggie
 
rb1957 said:

'"if the airplane is dropped from a state of no velocity and no thrust" ... then the plane pretends it's a rock !

actaully what should happen, after the airplane stalls, is it should nose over, with or without control input (through the elevator), enter a dive (control inputs to prevent it getting too steep), to create airflow over the wings, and lift, and then the plane sheds it's rock persona and becomes a right-thinking plane again.'

Based on what rb1957 said above, I agree that is preferred behavior. With regard to real aircraft, I believe the phenomenon you are trying to avoid is the "flat spin" where the aircraft is falling like a rock (possibly rotating about its vertical axis, thus the term spin). But in such a condition the force of the air through which it is falling pushes up against both the wing and the horizontal stabilizer, maintaining the aircraft in a pitch-level orientation.

I am NOT aerospace so please forgive me if I am missing other important factors here, but it would seem that your horizontal stabilizer would not help in a "flat spin" scenario because it cannot generate lift due to no airflow across it due to no forward velocity.

So it would seem one way to avoid the flat spin scenario would be to have the CG so far off that the air pushing up against the horizontal stabilizer overpowers the force of the air pushing up against the wings and creates a torque about the CG that will cause the tail to rotate upwards about the CG. Such an off center CG may not be acceptable for normal flight, however.

For a non-aerospace person I probably screwed up all the terms and forces, but am I any where close to realistic behavior of an aircraft?
 
debodine,
Flat spin behavior only occurs in most sensibly designed aircraft when the CG is too far aft.
For the most part it occurs when the horizontal stabilizor is lifting or has minimal download.
It gets to be problematic in certain aircraft, because an aircraft is most efficient, when the lift of the wing does not have to counter the download of the tail, so people tend to load the aircraft that way.
The symptoms of an aircraft that is tail heavy are overly sensitive elevator, or reversed control feel i.e. having to push on the control column to maintain speed. None of which are good.
B.E.

The good engineer does not need to memorize every formula; he just needs to know where he can find them when he needs them. Old professor
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor