Orbiter-Forum  

Go Back   Orbiter-Forum > Projects > ORBITER: 2010-P1 and newer > Bug
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Lift Vector Rotation Incorrect? Issue Tools
issueid=1394 12-16-2018 07:57 PM
XR2 Ravenstar Commander
Lift Vector Rotation Incorrect?
It appears that the lift vector is possibly being rotated incorrectly.

Hi,

I was experimenting with the SDK, and examining the lift and drag vectors. I was trying to back calculate the bank angle during a reentry.

The scenario I'm looking at is:

Code:
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51983.7885633472
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01
  MODE Cockpit
  FOV 90.00
END_CAMERA

BEGIN_HUD
  TYPE Surface
END_HUD

BEGIN_MFD Left
  TYPE User
  MODE MFD Template
END_MFD

BEGIN_MFD Right
  TYPE Surface
  SPDMODE 1
END_MFD

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Orbiting Earth
  RPOS 5631280.530 3039433.202 -760674.503
  RVEL 1390.2494 -791.5059 7095.6579
  AROT 33.898 -23.997 13.216
  VROT -0.0538 -0.0368 0.0229
  AFCMODE 7
  PRPLEVEL 0:0.028248 1:0.376463
  NAVFREQ 0 0 0 0
  XPDR 0
  HOVERHOLD 0 1 0.0000e+00 0.0000e+00
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

BEGIN_DX9ExtMFD
END

In this case, the flight path angle is approximately zero, the sideslip angle is zero, and the bank angle is 45 degrees, as indicated on Surface MFD. Using the call pV->GetBank() confirms this.

However: extracting the lift and weight vectors (using pV->GetLiftVector() and pV->GetWeightVector()), and taking the inverse cosine of the dot product, shows a bank angle of approximately 37 degrees, not 45 degrees as shown on Surface MFD and pV->GetBank() return. Interestingly, zeroing out the angle of attack fixes the issue, and the divergence seems to get worse at higher angles of attack.

This was run on a clean install of SVN Rev. 84 (and the same behavior exists in version 160828).

To experiment, I added the following code to the MFDTemplate::Update method:

Code:
OBJHANDLE hEarth = oapiGetGbodyByName("Earth");
VESSEL* pV = oapiGetFocusInterface();

double bankAngle = pV->GetBank() * 180 / PI;
double sideslip = pV->GetSlipAngle() * 180 / PI;
VECTOR3 liftVec, gravVec;
pV->GetLiftVector(liftVec);
pV->GetWeightVector(gravVec);
normalise(liftVec);
normalise(gravVec);

double LdotG = dotp(liftVec, gravVec);
double calcBankAngle = 180 - (acos(LdotG) * 180 / PI);

std::string bankAngleStr = "Returned Bank: " + std::to_string(bankAngle);
const char* bankAngleChar = bankAngleStr.c_str();
skp->Text(W / 10, 2 * H / 10, bankAngleChar, bankAngleStr.length());

std::string calcBankAngleStr = "Calculated Bank: " + std::to_string(calcBankAngle);
const char* calcBankAngleChar = calcBankAngleStr.c_str();
skp->Text(W / 10, 3 * H / 10, calcBankAngleChar, calcBankAngleStr.length());

std::string sideslipStr = "Sideslip Angle: " + std::to_string(sideslip);
const char* sideslipChar = sideslipStr.c_str();
skp->Text(W / 10, 4 * H / 10, sideslipChar, sideslipStr.length());

Is Orbiter's flight model doing something where the lift vector is not necessarily perpendicular to the wings at higher angles of attack? I wasn't sure if this was the case, or if it was a bug (or a stupid math error on my part ).
Issue Details
Project ORBITER: 2010-P1 and newer
Status Awaiting Feedback
Priority 5 - Medium
Affected Version Revision denoted in description
Fixed Version (none)
Users able to reproduce bug 0
Users unable to reproduce bug 0
Assigned Users (none)
Tags (none)

12-17-2018 09:17 AM
GLS GLS is offline
Addon Developer
 
I didn't check you math (I have too much math of my own already), but reading your post could this issue be interpreted as "there is a (erroneous) force making the vehicle roll back to 0"?

If so, then I think I have encountered the same issue with SSU, as to keep a left bank it has to keep putting left aileron. Flying with the DG it remains +/- stable at a bank without further aileron inputs, but that was with a very low alpha, which fits your findings. I'll have to check the DG with an higher alpha to see if it makes a difference.
Reply
12-17-2018 03:24 PM
XR2 Ravenstar Commander
 
No, it has nothing to do with a force/torque causing the vehicle to roll, it seems like it's simply a discrepancy between the bank angle and the angle that the lift vector is being rotated. If you could try to run the above scenario and code to try to reproduce it, that would be great (it took me 10 mins to recompile MFD Template and run the scenario).

In your SSU scenario is the sideslip angle zero? That could be doing it. Or, if the lift vector isn't perpendicular to the wings, maybe that's resulting in an imparted roll moment?

When I run my reentry trajectory propagator I'm working on, correcting for the discrepancy, it is extremely accurate, leading me to believe that the potential error in lift vector rotation is real, as opposed to the wrong value being returned by pV->GetLiftVector().
Reply
12-17-2018 03:30 PM
GLS GLS is offline
Addon Developer
 
Quote:
Originally Posted by markl316
 No, it has nothing to do with a force/torque causing the vehicle to roll, it seems like it's simply a discrepancy between the bank angle and the angle that the lift vector is being rotated.
But if the lift force angle is not at the same as the bank, that would mean it has a lateral component, right? The rest of what I see could be the controls reacting...
Anyway, I'll try your scenario/code later today, and the DG at high alpha to see what happens.
Reply
12-17-2018 03:34 PM
XR2 Ravenstar Commander
 
Quote:
Originally Posted by GLS
 But if the lift force angle is not at the same as the bank, that would mean it has a lateral component, right? The rest of what I see could be the controls reacting...
Anyway, I'll try your scenario/code later today, and the DG at high alpha to see what happens.
Hah, literally just thought of that and edited my above post 2 minutes ago. Sounds good on running the DG scenario today, let me know what you find.

The discrepancy seems to be the worst at 45 degrees bank, then get better as you go from 45 to 90 degrees, where it converges to the bank angle in surface MFD. I made some plots but they're at home; I'll post them tonight.
Reply
12-17-2018 10:02 PM
GLS GLS is offline
Addon Developer
 
Flying SSU and looking at the outputs of your code, I don't know what to make of them... sometimes one value is larger, other times it's the other way around. And to top off things, flying leveled, no (or very small) roll inputs, 43kft, alpha 11.5, beta -0.12, and I'm getting -1.95 actual bank and 14.5 calculated bank. *confused*
(yes, the wind is off)

Playing around with the DG in a bank at "high alpha", i.e. ~20, I don't really see a large tendency to roll, but sometimes it seems like it wants to bank more. *more confused*
Reply
12-17-2018 10:25 PM
XR2 Ravenstar Commander
 
Quote:
Originally Posted by GLS
 Flying SSU and looking at the outputs of your code, I don't know what to make of them... sometimes one value is larger, other times it's the other way around. And to top off things, flying leveled, no (or very small) roll inputs, 43kft, alpha 11.5, beta -0.12, and I'm getting -1.95 actual bank and 14.5 calculated bank. *confused*
(yes, the wind is off)
My code assumes zero flight path angle (ie vertical speed equals zero). That 14.5 degrees calculated bank is probably picking up the sum of your flight path angle and bank angle. I assume since you were at 43,000 feet you were testing this on final approach? I can play around with it and write new code to make it work with a nonzero flight path angle.


Quote:
Playing around with the DG in a bank at "high alpha", i.e. ~20, I don't really see a large tendency to roll, but sometimes it seems like it wants to bank more. *more confused*
How are you differentiating roll versus bank (I think they're the same)? What was your flight path angle here?
Reply
12-17-2018 11:50 PM
GLS GLS is offline
Addon Developer
 
Quote:
Originally Posted by markl316
 My code assumes zero flight path angle (ie vertical speed equals zero). That 14.5 degrees calculated bank is probably picking up the sum of your flight path angle and bank angle. I assume since you were at 43,000 feet you were testing this on final approach? I can play around with it and write new code to make it work with a nonzero flight path angle.
Yes, gamma affects your calculations... sorry, I should have read the instructions with more attention.



Quote:
Originally Posted by markl316
 How are you differentiating roll versus bank (I think they're the same)? What was your flight path angle here?
Hmmm, the angle wings make with the horizon?
Reply
12-18-2018 03:23 PM
XR2 Ravenstar Commander
 
Quote:
Originally Posted by GLS
 
Hmmm, the angle wings make with the horizon?
Whoops I misread, I thought you said they meant two different things, my mistake. I couldn't find those plots last night so I'll recreate my "experiment" in the next few days. We're you able to reproduce this with SSU flying with zero vertical speed?
Reply
12-23-2018 03:25 AM
XR2 Ravenstar Commander
 
Ok. I ran through several test cases, at the following flight conditions:
Ground Speed: 7063 m/s
Altitude: 71.2 km
Vertical Speed: +/- 20 m/s
Mach ~24
AOA: 40 degrees
Sideslip: 0 degrees
Swept bank angle from 0 degrees to 90 degrees right bank





The blue points are from test cases I ran, and the orange point is from a test case GLS ran at similar flight conditions. It looks like it's able to be reproduced.
Reply
03-03-2019 08:56 PM
Orbiter Founder
 
My definition of the lift vector direction is not fixed to the wing, but is always perpendicular to the relative wind [1], (and therefore to the drag vector), so

L = [0, v_rel.z, -v_rel.y] * scale

where v_rel is the relative wind vector in the vessel frame,

scale = alpha * (v_rel.z^2 + v_rel.y^2)^(-1/2)

and alpha is the lift magnitude.

So yes, the lift in this definition is not perpendicular to the wing for nonzero AOA. Does this explain the discrepancy you are observing?

[1] J. D. Anderson, Jr., Introduction to flight, 4th edition, McGraw Hill, pg. 230
Reply
03-11-2019 03:20 AM
XR2 Ravenstar Commander
 
Thanks for looking into this Dr. Schweiger.

Definitely agreed that the lift vector should be perpendicular to the drag vector/local wind regardless of the angle of attack (and I can confirm this is the case through my testing). However, the behavior Kuddel and I were seeing looked like there was a bit of horizontal component at nonzero bank angles.

Here are a couple annotated screenshots of a Delta glider at a 0 degree flight path angle, 40 degree angle of attack, and ~35 degree left bank, with zero sideslip. Velocity vector, drag, and body axes are self explanatory. The blue lift vector is a vector that is both perpendicular to the drag vector and the +X body axis, while it looks like Orbiter is returning the orange lift vector (still perpendicular to the drag vector & local wind as Anderson says, but not quite rotated all the way). In Figure 1, blue and orange vectors are the same magnitude, but orange is rotated about the drag vector out of the page slightly.

The angle between the blue and orange vectors in Figure 2 is what I plotted in my previous post on 12/22/18. In that post, the x-axis of the plots are the bank angle returned by pV->GetBank(), while the y-axes of those plots are the computed bank angle from the lift and gravity vector, which would be the supplementary angle of the angle between the yellow and orange arrows in Figure 2. It looks like the discrepancy is worst at 45 degrees of bank. Let me know if that clears it up?






Thanks!
Mark
Reply
03-11-2019 09:37 AM
Donator
 
Quote:
Originally Posted by markl316
 [...]However, the behavior Kuddel and I were seeing[...]
Me? I don't saw anything
Reply
03-11-2019 12:21 PM
Orbiter Founder
 
Ok, I think I understand the problem now. Here is the most likely explanation:

The Delta-glider defines two separate airfoils: one with vertical lift component (I.e. from the wings and lifting-body fuselage), the other one with a horizontal lift component (essentially from the fuselage and the wingtip stabilizers). This second lift component will kick in when there is a slip angle (i.e. horizontal component of the relative wind in the vessel frame), which is likely to occur during a bank.

The vector returned by GetLiftVector(), and the vector displayed, are the sum of the lift components from all airfoils, hence you get that horizontal component.

You can test that by modifying the DeltaGlider.cpp sources, either removing the second airfoil altogether, or having HLiftCoeff(...) return 0 for cl. This should remove the x-component of the lift vector.

Whether the relative magnitude of the horizontal lift component is realistic, given the DG geometry, is another question. I tried to guestimate the aerodynamic characteristics from shape, cross sections, etc. but I'm not an aerospace engineer, so this might be far off the mark. I'm grateful for any suggestions.

One way to reduce confusion would be to display lift and drag forces for each airfoil individually, but it could make the vector display rather busy, and could create more confusion than it solves.
Reply
03-14-2019 03:03 AM
XR2 Ravenstar Commander
 
Quote:
Originally Posted by martins
 The Delta-glider defines two separate airfoils: one with vertical lift component (I.e. from the wings and lifting-body fuselage), the other one with a horizontal lift component (essentially from the fuselage and the wingtip stabilizers). This second lift component will kick in when there is a slip angle (i.e. horizontal component of the relative wind in the vessel frame), which is likely to occur during a bank.
I had actually seen that tracing through the Delta Glider source code, so when running all of the tests on this thread, I had my zero-sideslip autopilot running, so sideslip was held to within a tenth of a degree or so.

Just to make absolute sure that this wasn't it, I reran the scenario from my original post with a clean install of the beta rev 87, with the following changes to DeltaGlider.cpp:

Zeroing out the lift coefficient of the tail:

Code:
void HLiftCoeff (VESSEL *v, double beta, double M, double Re, void *context, double *cl, double *cm, double *cd)
{
	int i;
	const int nabsc = 8;
	static const double BETA[nabsc] = {-180*RAD,-135*RAD,-90*RAD,-45*RAD,45*RAD,90*RAD,135*RAD,180*RAD};
	static const double CL[nabsc]   = {       0,       0,      0,      0,     0,     0,      0,      0};
	for (i = 0; i < nabsc-1 && BETA[i+1] < beta; i++);
...

I also set dCl in the rudder creation function to 0 to make the rudders ineffective, just to be on the safe side:
Code:
CreateControlSurface3 (AIRCTRL_RUDDER,       0.8, 0.0, _V(   0,0,-7.2), AIRCTRL_AXIS_YPOS, 1.0, anim_rudder);

Then I went into the MFDTemplate source code and modified the MFDTemplate::Update function:

Code:
bool MFDTemplate::Update (oapi::Sketchpad *skp)
{

	double tsim = oapiGetSimTime();
	if (tsim < 0.02) {
		return true;
	}

	VECTOR3 liftVec, dragVec, weightVec, forceVec;
	double thLinRCS_MinusX, thLinRCS_PlusX, lift, drag, bank, AOA, slip;
	VESSEL* pV = oapiGetFocusInterface();

	// Verifying the linear RCS thrusters
	thLinRCS_MinusX = pV->GetThrusterGroupLevel(THGROUP_ATT_LEFT);
	thLinRCS_PlusX = pV->GetThrusterGroupLevel(THGROUP_ATT_RIGHT);

	// Get the force vectors
	pV->GetLiftVector(liftVec);
	pV->GetDragVector(dragVec);
	pV->GetWeightVector(weightVec);
	pV->GetForceVector(forceVec);

	// Get the force scalars
	lift = pV->GetLift();
	drag = pV->GetDrag();

	// Get vessel flight parameters
	slip = pV->GetSlipAngle() * 180 / PI;
	AOA = pV->GetAOA() * 180 / PI;
	bank = pV->GetBank() * 180 / PI;

	return true;


}

Note, the initial "if tsim < 0.02" statement is just for convenience so I can get a debugging breakpoint during the second frame of the simulation, letting it run the first frame to be sure to initialize the force vectors correctly.


I show the following for the scalars:
tsim = 0.115103997
thLinRCS_MinusX = 0.00000000
thLinRCS_PlusX = 0.00000000
slip = -0.295212661 << Note, has been converted to degrees
AOA = 39.667364
bank = 44.73935273 << Note, obtained from pV->GetBank()
lift = 50983.69802
drag = 27090.71264

And the vectors (in the body frame):
liftVec = [0, 39245.37841, 32544.39641]
||liftVec|| = 50983.69802
dragVec = [-107.4460346, 17292.66395, -20853.27169]
||dragVec|| = 27090.71264
weightVec = [-67451.63591, -68237.37386, -56373.18279]
||weightVec|| = 111283.4135
forceVec = [-67559.30128, -11700.49806, -44676.42112]
||forceVec|| = 81836.0767


So it looks like the lift and drag magnitudes are lining up nicely. Also, I didn't calculate it in the code, but the vertical speed is about 4 m/s, so the flight path angle is acos(4/6843) ~= 0.3. And, the cosine losses from 0.3 from the flightpath angle and sideslip should be in the noise for the purposes of this.

Taking the angles of the vectors (via MATLAB for me):
>> acos(dot(dragVec, weightVec)/norm(dragVec)/norm(weightVec))*180/pi
returns 89.946 (as it should, drag should be perpendicular to gravity for zero flight path angle)

But...
>> 180 - (acos(dot(liftVec, weightVec)/norm(liftVec)/norm(weightVec))*180/pi)
returns 37.31, which is about 7.5 off of the value returned by pV->GetBank();

And the 7.5 error lines right up with the plot here that I made a few months ago:



I'm not sure what else could be doing this...any way you could run this code to see if you can reproduce it? Much appreciated! If you need the Delta Glider position and velocity vectors in the ECI frame, let me know, I have functions for that.


Quote:
Originally Posted by martins
 I tried to guestimate the aerodynamic characteristics from shape, cross sections, etc. but I'm not an aerospace engineer, so this might be far off the mark. I'm grateful for any suggestions.
I'm definitely happy to dig through my old aerodynamic textbooks this weekend and see what I can come up with. Since the DG is a supersonic/hypersonic vehicle, it's going to have a diamond airfoil or something, so I think the symmetry of the (horizontal) lift coefficient is a good assumption. I think I had to analyze a diamond airfoil through Mach 15 or so for homework once; I'll see if I can find that. Unfortunately, if there's one thing that I learned from aerodynamics, especially hypersonic aerodynamics, it's that your guesses are a crapshoot until you test it
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT. The time now is 02:45 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.