[dougkeenan]

Beta5 (2.41M) includes the upper stage which may or may not fire after separation. The LAS jettison happens after core separation as per the new baseball card. The new card has a simpler pitch chart and I want to expose that pitch table to the CONFIG file soon to aid tinkering.

Something is way wrong with the burn time math. The SRB burn happens as predicted but neither core nor upper stage burn is even close. The card says 384 and 610 whereas the model burns out too quickly (360 and 520 or so). The orbits delivered are off as a result.

Early on the SRB's were burning out quickly also. Then I found the thrust-over-time performance curve that lined it up again. I must look for similar curves effecting the other engines, and may fudge it with a time independent "average" thrust for now.

This is buggy code at the moment but it's a good archive point. I need to weed out the scenario folder too. Some of the older ones might not be stable anymore, particularly the J130 ones.

eta: Beta6 includes "averaged" thrusters, a common guidance system for all Jupiter cores, and I fixed up the J130 a bit.

[dougkeenan]

Little progress as I bang my head against the guidance system. I thought I had the upside-down thing understood but clearly don't. (I sure hope that's how the thing is actually intended to fly!) This is what I use to fill the guidance data structure:

 
  gd->roll = GetBank() * DEG ;
  gd->pitch = GetPitch() * DEG ;
  gd->yaw = GetSlipAngle() * DEG ;
  GetAngularVel( gd->Angular_Velocity ) ; 
  gd->pitch_dot = gd->Angular_Velocity.x * DEG ; // get pitch change rate in deg/s
  gd->yaw_dot = gd->Angular_Velocity.y * DEG ; //get yaw change rate in deg/s
  gd->roll_dot = gd->Angular_Velocity.z * DEG ; // get roll change rate in deg/s

and for the life of me it looks like GetAngularVel returns the roll component inverted (according to Orbiter's left hand rule notation). That is, rolling left gives me increasing roll values but roll_dot keeps coming out negative. What would Spock do? Apply forward thrust?

[tblaxland]

Originally Posted by dougkeenan

 That is, rolling left gives me increasing roll values but roll_dot keeps coming out negative. What would Spock do? Apply forward thrust?

I haven't played with the GetBank function before, but I wonder if it follows a right hand convention (in line with the normal aerospace definition). To test, flying wings level heads up GetBank() should return 0. If you roll right from that attitude, does GetBank return a positive or negative value?

[dougkeenan]

Rolling right produces a negative value. That seems consistent with Orbiter convention.

Is GetAngularVel the same as grabbing the vrot values in the VESSELSTATUS2 structure? I'm looking for something in the local frame and ASSumed GetAngularVel returns that while the vrot values are in the ecliptic frame. Maybe I should test that.

[tblaxland]

Originally Posted by dougkeenan

 Rolling right produces a negative value. That seems consistent with Orbiter convention.

Yes, it should also give a negative angular velocity around the z-axis. Also remember that the bank angle is measured against the local horizon frame, so depending on your pitch angle, yawing can also change your bank angle.

Originally Posted by dougkeenan

 Is GetAngularVel the same as grabbing the vrot values in the VESSELSTATUS2 structure? I'm looking for something in the local frame and ASSumed GetAngularVel returns that while the vrot values are in the ecliptic frame. Maybe I should test that.

Looking at the documentation, I believe they are different but I have not tested it. In any case, GetAngularVel is the one you want because it gives angular velocities that are aligned with your controls.

---------- Post added at 16:00 ---------- Previous post was at 14:46 ----------

I just ran a quick test. It seems that Orbiter uses a right-handed convention for angular velocity. For example, flying wings level heads up, if I bank right I get a positive +z angular velocity. Also, I can confirm that GetAngularVel returns the same values as vrot in the VESSELSTATUSx structure, ie, they are the instantaneous angular velocities about the vessel's principal axes.

[dougkeenan]

Thanks for the testing. Scratching my head here, if the VESSELSTATUS / GetAngularVel roll value is in ecliptic coordinates (per API) then shouldn't the sign of the value flip from say, prograde to retrograde orientation (pick any reference)? If the values were in the local frame, the magnitude and sign should stay the same. That's what I observe. What am I missing here?

[tblaxland]

The angular velocities describe the current instantaneous angular velocity around a set of axes aligned with the orientation of the vessel's principle axes, so the vector returned by GetAngularVel represents the total angular velocity in the local frame.

[dougkeenan]

Correct. Yet VESSELSTATUS vrot is defined in the API reference as "rotation velocity about principal axes in ecliptic frame." So they can't be the same, can they? (Those frames not being equal except by coincidence.) I'm still confused about that, since I measure them the same.

FWIW, the sign correction brought the roll and yaw loops right into lock. I'm still getting a little INC drift at the end of ~90deg azimuths but I think it's the rotation of the earth. A little research to tidy that up and it should be good to go. Then it's back to making them less hideous.

[tblaxland]

Originally Posted by dougkeenan

 Correct. Yet VESSELSTATUS vrot is defined in the API reference as "rotation velocity about principal axes in ecliptic frame." So they can't be the same, can they? (Those frames not being equal except by coincidence.) I'm still confused about that, since I measure them the same.

The rotations are measured against an inertial frame, which is the ecliptic in Orbiter. To give some contrast, the rotations could be measured against some other non-inertial frame such as the current LVLH frame. That is an important destinction for auto-pilots because the reference frame is often rotating. For example, in Attitude MFD's Velocity mode once you have reached the target attitude you want to maintain angular velocities of zero in the velocity frame, but these correspond to non-zero angular velocities in the ecliptic frame.

Also, techincally Orbiter could return a total velocity vector in the ecliptic frame which you could then decompose into axes aligned with your vessel's principle axes but there wouldn't really be any advantage and I don't believe Orbiter internally stores the total ecliptic angular velocity anyway (or ecliptic angular momentum for that matter). It just determines a body's rotation by integrating Euler's equations.

---------- Post added at 16:38 ---------- Previous post was at 09:52 ----------

I just thought of an example that might help you visualise what is going on. Let's say you are flying wings level heads up in a LEO. If you maintain that attitude GetBank, GetPitch, GetSideSlip will all return 0 at each time step, yet GetAngularVel will return {-0.07,0.0,0.0} deg/s (or close to it). That is because GetBank etc is measuring your attitude relative to the LVLH coordinate frame which is itself rotating. Does that help or hinder?

[dougkeenan]

More help than hinder, always. (I appreciate all your comments!) The three Get--- functions returns those values (in one frame) while GetAngularVel returns their derivatives (in another frame).

Consider in that same LEO, put yourself in a steady roll. As I understand it, GetAngularVel should return { -0.07, 0.0, roll_value }. Now orbit around to the other side of the Earth. Your craft is now oriented "backwards" from the original measurement - motion that was clockwise in the ecliptic frame is now counterclockwise. (What was clockwise in the local frame is still clockwise.) Does roll_value get inverted in sign but not magnitude?

eta: Beta 7 (3.2M) features three axis control guidance though the yaw still chatters towards the end. The apoapsis and periapsis values aren't in the ballpark yet but calculating better pitch charts should be an easier job. I hope!

[tblaxland]

Originally Posted by dougkeenan

 Consider in that same LEO, put yourself in a steady roll. As I understand it, GetAngularVel should return { -0.07, 0.0, roll_value }. Now orbit around to the other side of the Earth. Your craft is now oriented "backwards" from the original measurement - motion that was clockwise in the ecliptic frame is now counterclockwise. (What was clockwise in the local frame is still clockwise.) Does roll_value get inverted in sign but not magnitude?

No. The angular velocities returned by GetAngularVel are always measured around a set of axes aligned with the current instantaneous principle vessel axes. So rolling right around the z-axis will always yield a positive angular velocity about that axis.

There is a further complicating issue in your question. Because your vessel no doubt has principle moments of inertia about each axis that are not equal, the vessel will experience polhode motion (that is, a constant change in direction of the angular velocity vector). That is because angular momentum is conserved but, because the moments of inertia vary between axes, angular velocity is not. What this means for you is that the roll and pitch motions will "couple" into the yaw axis and back out again. Try it by putting the result of GetAngularVel into oapiDebugString and watch them change as your vessel rotates.

[dougkeenan]

No. The angular velocities returned by GetAngularVel are always measured around a set of axes aligned with the current instantaneous principle vessel axes. So rolling right around the z-axis will always yield a positive angular velocity about that axis.

I'm with you to here. That's why I thought to use it. What confuses me is what you said here, "Also, I can confirm that GetAngularVel returns the same values as vrot in the VESSELSTATUSx structure, ie, they are the instantaneous angular velocities about the vessel's principal axes."

We've established GetAngularVel returns values in the local vessel frame. Your quote indicates VESSELSTATUS vrot values are the same. But vrot values are defined in the API ref as ecliptic frame. How can they be the same, using different frames?

There is a further complicating issue in your question. Because your vessel no doubt has principle moments of inertia about each axis that are not equal, the vessel will experience polhode motion (that is, a constant change in direction of the angular velocity vector). That is because angular momentum is conserved but, because the moments of inertia vary between axes, angular velocity is not. What this means for you is that the roll and pitch motions will "couple" into the yaw axis and back out again. Try it by putting the result of GetAngularVel into oapiDebugString and watch them change as your vessel rotates.

Yeah I know, I was just simplifying the orbit to make the CW/CCW point. The real math would be lots more messy.

[tblaxland]

Originally Posted by dougkeenan

 We've established GetAngularVel returns values in the local vessel frame.

No, we haven't. Remember earlier we were discussing measuring the angular velocity relative to the rotating LVLH frame and how you could have an angular velocity of zero relative to that frame but still have GetAngularVel return a non-zero value?

Let's say you are flying wings level heads up in a LEO. If you maintain that attitude GetBank, GetPitch, GetSideSlip will all return 0 at each time step, yet GetAngularVel will return {-0.07,0.0,0.0} deg/s (or close to it).

That was because the LVLH itself was rotating with respect to an inertial frame. So is the local vessel frame. Logically, if you measure the angular velocity relative to the local (rotating) frame, you will always get exactly zero. That is the reason for my earlier statement:

The angular velocities describe the current instantaneous angular velocity around a set of axes aligned with the orientation of the vessel's principle axes

That "set of axes" I am referring to there are aligned with the current instantaneous orientation of the vessel's principle axes but are, for the purposes the angular velocity measurement, an inertial (ie, non-rotating) frame. I'll refer to this "set of axes" as the "measurement frame" in my comments below.

Originally Posted by dougkeenan

 Your quote indicates VESSELSTATUS vrot values are the same. But vrot values are defined in the API ref as ecliptic frame. How can they be the same, using different frames?

Take that statement in the API with a grain of salt. The measurement frame for both VESSELSTATUS::vrot and VESSEL::GetAngularVel is the same and is aligned with the vessel principle axes - the testing proves it. I believe Martin's intention there is to convey that the measurement frame is an inertial frame. In the Orbiverse, the ecliptic is THE inertial frame and the measurement frame is related to it by a mere static rotation (for the purposes of instantaneous measurement, anway - the measurement frame is realigned at each time step).

BTW, I have been suspecting that we have a terminology barrier here. TBH, I am struggling to put the same statements into new words whilst still maintaining consistency. Forgive me if that has added to the confusion.

Originally Posted by dougkeenan

 Yeah I know, I was just simplifying the orbit to make the CW/CCW point. The real math would be lots more messy.

Here is something that may help you if you have large attitude errors in your auto-pilot. Attitude MFD does not take polhode motion into account, strictly speaking, but I have developed somewhat of a workaround for it. Since a lot vessels in Orbiter have similar moments of inertia about the pitch and yaw axes (relative to the moment of inertia for the roll axis, anyway) when I have large attitude errors, I simply null the roll rate and just drive the pitch and yaw errors to within a smallish deadband (about 5 deg IIRC) before attempting to null out the roll error. The reason for this is that the similar pitch and yaw moments of inertia tend to limit the amount of coupling into the roll axis to small amounts. That strategy is a bit hackish in Attitude MFD 3.2 but I plan on improving on it for the next version, perhaps even allowing manual selection of the "primary axes" (a tailsitter for example, might be better using pitch/roll as the primary axes). I also have some analytical solutions to polhode motion but I haven't quite convinced myself that the benefits of implementing them into Attitude MFDs control strategy is worth the pain...

[dougkeenan]

Take that statement in the API with a grain of salt. The measurement frame for both VESSELSTATUS::vrot and VESSEL::GetAngularVel is the same and is aligned with the vessel principle axes - the testing proves it.

If it weren't for your help, that API statement would be all I had. It's part terminology and part I'm a bonehead, eager to get things working without figuring out why. There's yet another frame - a static snapshot of a rotating frame, "measurement frame" as you call it - that I've been conflating with the local frame. The measurement frame is not (in general) the ecliptic frame. In that case the details of the MF can be tested, so as long as it's consistent (e.g., roll measured one axis, roll dot measured another - have we checked the other axes?) I'm happy.

[tblaxland]

Originally Posted by dougkeenan

  In that case the details of the MF can be tested, so as long as it's consistent (e.g., roll measured one axis, roll dot measured another - have we checked the other axes?) I'm happy.

Well, let me know what you find (and I will reciprocate when I get to it - I'm getting close to testing of the new Attitude MFD guidance class). BTW, didn't we establish that roll and roll dot were measured about the same axis but with different handedness? Ie, measured about the z-axis and roll is left handed (based on your tests - I have't checked myself) and roll dot is right handed (based on both our tests).