


12172018 03:24 PM  


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(). 
12172018 03:30 PM  


Quote:
Anyway, I'll try your scenario/code later today, and the DG at high alpha to see what happens. 
12172018 03:34 PM  


Quote:
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. 
12172018 10:02 PM  


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* 
12172018 10:25 PM  


Quote:
Quote:

12172018 11:50 PM  


Quote:
Quote:

12182018 03:23 PM  


Quote:

12232018 03:25 AM  


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. 
03032019 08:56 PM  


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 
03112019 03:20 AM  


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 xaxis of the plots are the bank angle returned by pV>GetBank(), while the yaxes 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 
03112019 09:37 AM  


Quote:

03112019 12:21 PM  


Ok, I think I understand the problem now. Here is the most likely explanation:
The Deltaglider defines two separate airfoils: one with vertical lift component (I.e. from the wings and liftingbody 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 xcomponent 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. 
03142019 03:03 AM  


Quote:
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 < nabsc1 && 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:

Issue Tools 

Subscribe to this issue 
Quick Links  Need Help? 