API Question ShiftCG

[gattispilot]

Thanks. So if the capsule is at 0 pitch then I want to simulate the shift of the center of gravity. The craft should tilt the 20 degrees, right?

void VLiftCoeff(double aoa, double M, double Re, double *cl, double *cm, double *cd, double desired_trim_angle)
{
	static const double step = RAD*15.0;
	static const double istep = 1.0 / step;
	static const int nabsc = 25;
//	static const double CL[nabsc] = { 0.1, 0.17, 0.2, 0.2, 0.17, 0.1, 0, -0.11, -0.24, -0.38, -0.5, -0.5, -0.02, 0.6355, 0.63, 0.46, 0.28, 0.13, 0.0, -0.16, -0.26, -0.29, -0.24, -0.1, 0.1 };
	static const double CL[nabsc] = { 0.1, 0.17, 0.2, 0.2, 0.17, 0.1, 0, -0.11, -0.24, -0.38, -0.5, -0.5, -0.02, 0.6355, 0.63, 0.46, 0.28, 0.13, 0.0, -0.16, -0.26, -0.29, -0.24, -0.1, 0.1 };
	static const double CM[nabsc] =
	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.002, 0.004, 0.0025, 0.0012, 0, -0.0012, -0.0007, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
	// -180, -165, -150, -135, -120, -105,  -90,  -75,  -60,   -45,   -30,    -15,      0,   15,      30,      45,
	
	
	//	static const double CM[nabsc] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.002, 0.004, 0.0025, 0.0012, 0, -0.0012, -0.0007, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
	// lift and moment coefficients from -180 to 180 in 15 degree steps.
	// This uses a documented lift slope of 0.0437/deg, everything else is rather ad-hoc
	aoa -= desired_trim_angle;
	//aoa += PI*2;
	int idx = max(0, min(23, (int)(aoa*istep)));
	double d = aoa*istep - idx;
	*cl = CL[idx] + (CL[idx + 1] - CL[idx])*d;
	*cm = CM[idx] + (CM[idx + 1] - CM[idx])*d;
	*cd = 0.06 + oapiGetInducedDrag(*cl, 2.266, 0.6);
}

and then this:

CreateAirfoil(LIFT_VERTICAL, _V(0, -0.01, -0.1), VLiftCoeffAoA0, 5.5, 0, 1.27);

//CreateAirfoil(LIFT_VERTICAL, _V(0, -0.01, -0.1), VLiftCoeff, 5.5, 0, 1.27);
CreateAirfoil(LIFT_HORIZONTAL, _V(0, 0, 0.01), HLiftCoeff, 5.5, 0, 1.27);

[/CODE]
I get this:
Error 2 error C2065: 'VLiftCoeffAoA0' : undeclared identifier C:\orbiter100830\Orbitersdk\samples\MSLBACKSHELL\MSLBACKSHELL.CPP 133 1 MSLBACKSHELL


I feel like I am missing something.

 

[gattispilot]

Looking at the different images of the MSL. It appears once the Cruise Balance Mass is removed it tilts almost 90 degrees. Then the 20 degree entry angle. And then when the chute deploys and the entry mass is removed is levels off.

Since ShiftCG is a bug. I suppose a powerful RCS could do it.

 

[Urwumpe]

Since ShiftCG is a bug. I suppose a powerful RCS could do it.

Again: Its no bug. Its a feature.

ShiftCG will not, I repeat: not, change the attitude of your spacecraft. It does not even move your spacecraft (only the meshes - the CoG will stay where it is in space without additional accelerations)- any impulse by ejecting the ballast will not be handled by it. And any such impulse by ejecting the ballast will require a second impulse for stopping the rotation, otherwise the conservation of rotational impulse will make sure that your spacecraft keeps on rotating.

All that you can do with it is alter, how aerodynamic forces or thrusters act on your vessel.

And don't put too much faith into a video sequence created by CGI artists, better look for higher quality sources.

 

[gattispilot]

On post 33:
http://www.orbiter-forum.com/showthread.php?t=22907&highlight=Asylum
It mentions it as a bug.

So I guess what I need is change the AOA. So with RCS?
Trying to base off what to do on Altitude. So if Altitude<1600 do something like deploy chute and level ship

 

[Urwumpe]

On post 33:
http://www.orbiter-forum.com/showthread.php?t=22907&highlight=Asylum
It mentions it as a bug.

The bug is in this case in the understanding of the developer, who had been surprised by ShiftCG doing what it should do according to the API reference, instead of doing what he wants it to do.

But that had been finally established already on Post 10.

So I guess what I need is change the AOA. So with RCS?
Trying to base off what to do on Altitude. So if Altitude<1600 do something like deploy chute and level ship

Stop guessing, please. :facepalm:

Understand what you are trying to do before you do it.

As short reference, how I would analyse your problem in form of a short storyboard:

1. Initial Situation: After separation from cruise stage in free-fall towards Mars EI. Rotation axis is normal to flight path.
2. De-spin and activate 3-axis stabilization
3. Jettison ballast.
4. Wait for oscillations to cease
5. Orient to re-entry attitude (Which is not x° AOA, but the global attitude that is parallel to the future attitude of x° AOA at entry interface with expected FPA)
6. About 30 seconds before EI:
7. Activate pre-re-entry guidance
8. On sensing sufficient deceleration (~0.05g):
9. Activate re-entry guidance (control deceleration and landing site by bank angle)
10. Once inertial velocity drops below threshold:
11. Heading alignment
12. Jettison entry ballast
13. Deploy parachute
14. Wait for full and stable parachute deployment, allow fast oscillations to dampen
15. Jettison heat Shield

Starting with this storyboard, I would look for two very basic elements of software development: States and state changes, what happens and which events trigger it? (Note: You are still easily capable of doing this without a computer: Its plain analysis of your problem.)

And then, I would go into the engineering mode: What options of modularity can I identify? Is there any form of hierarchy, like different layers that only interact over defined limited interfaces? Can I re-use something? Is there a problem I have already solved before or what the Orbiter SDK solves?

 

[gattispilot]

ok Thanks. It sounds like it might be beyond me.
on the ballast there are meshes that just appear but they should also effect the craft.

Step1 . just dettach from cruise stage vessel.

 

[Urwumpe]

ok Thanks. It sounds like it might be beyond me.

Welcome to the magical world of R&D. At the start, its always beyond you. Afterwards, it should be too boring easy for you. Been there, done that.

on the ballast there are meshes that just appear but they should also effect the craft.

But there you are back at the earlier question: If they should also effect the craft, how should they effect it? And can this effect be described by known Newtonian physics? (Which Orbiters physics engine understands and can help you. Non-Newtonian effects are harder)

Step1 . just dettach from cruise stage vessel.

Sounds like a good first step. :lol:

And now, for ruining your day: Its a spin stabilized cruise stage.

(Enjoy the accuracy of Orbiter by changing the PMI of the vessel during separation...)

 

[gattispilot]

And now, for ruining your day: Its a spin stabilized cruise stage.

(Enjoy the accuracy of Orbiter by changing the PMI of the vessel during separation...)

Yes. The cruise stage when it leaves the launch rocket towards Mars is spinning. We are thinking not to have it as it makes course correction difficult.

On the ballast. From everything I have seen by removing the ballast it shifts the CofG and thus the ship moves. So when the ballast is removed the other side is heavier and moves towards that side.

 

[Urwumpe]

On the ballast. From everything I have seen by removing the ballast it shifts the CofG and thus the ship moves.

Right. For beginning to move, a force should be acting on it.

Jettisoning the ballast does really create a force because the spacecraft ejects mass - conservation of impulse again. The force of the ballast jettisoned could for example be produced by springs pushing the ballast from the spacecraft.

But then, it is a single force that only exists while the springs still push against the ballast: When the ballast is gone and has no longer contact with the spacecraft, the force is gone.

And now, remember Newton: Without any force acting on it, the spacecraft continues its motion.

If releasing the ballast imparts an impulse that makes the spacecraft spin, this spinning motion does not stop without a new impulse countering it.

So when the ballast is removed the other side is heavier and moves towards that side.

Wrong. Think as counterexample of the opposite situation: If something docks to the ISS, the ISS does not move towards that side, despite that side becoming heavier (The Shuttle for example weights 1/4th of the ISS mass - that's quite significant). The CoG of the station shifts with docking, but the station does not move or rotate towards the docking port.

A really good example of learning what CoG means, especially in space, are tethers and tethered spacecraft.

 

[gattispilot]

Ok. So then when the first ballast is dropped the ship moves and rcs stops/counters the motion?

 

[Urwumpe]

Ok. So then when the first ballast is dropped the ship moves and rcs stops/counters the motion?

First part: Yes.
Second part: Yes, but I am very sure, differently to what you expect right now.


I doubt that jettisoning the weights creates any useful rotation towards the pitch attitude needed. It will very likely only be a small rotation.

As you can see well here, the two ballast weights are mounted outside the aeroshell and separated by a very simple system. But the four RCS modules are mounted on the opposite end of the aeroshell and further away from the CG.

 

[gattispilot]

I thought ( I know don't think) That dropping the ballast altered the pitch.

So I guess Rcs does that. Then why drop the ballast?

 

[Urwumpe]

So I guess Rcs does that. Then why drop the ballast?

For altering the re-entry aerodynamics. I'll draw you something that maybe helps you understand it better.

---------- Post added at 10:17 PM ---------- Previous post was at 06:39 PM ----------

I hope it is understandable... the effect of the offset CG is in Orbiter actually the effect of the offset CP. In this example, I added a fair amount of lift (about 1/4 of the drag force) to document the math. Instead of bombing you with formulas that I don't understand, I simply drew you graphical solutions of the vector math: The torque generated by the sum of lift and drag (Fr) is visualized by the area of the parallelogram spanned by Fr and the reference vector from CG to CP.

Even if you would change the variables in my example, you would still easily see the effect - they had not been absolutely to scale anyway, just good enough for explaining things.

 

[gattispilot]

Thanks. But how to make it do that in Orbiter?

 

[Urwumpe]

Thanks. But how to make it do that in Orbiter?

By using these two:

void VESSEL::ShiftCG (const VECTOR3 & shift);

void VESSEL::EditAirfoil (AIRFOILHANDLE hAirfoil, DWORD flag, const VECTOR3 & ref, AirfoilCoeffFunc cf, double c, double S, double A) const;

 

[gattispilot]

Thanks. But I think we are back to square 1.
ShiftCG moves the vessel/meshes. What values do I need to get from Orbiter?

And the same on the Edit air foil. Are the values calculated or a standard?

 

[Urwumpe]

Thanks. But I think we are back to square 1.
ShiftCG moves the vessel/meshes. What values do I need to get from Orbiter?

And the same on the Edit air foil. Are the values calculated or a standard?

I am one micrometer away from asking you, who you think you are kidding here. So, back to the real square one of Orbiter add-on development:

YOU DEFINE THE PROPERTIES OF YOUR SPACECRAFT.

Not Orbiter, there are no defaults.

Orbiter only presents you the resulting behavior according to the properties of your spacecraft.

 

[N_Molson]

The bug is in this case in the understanding of the developer, who had been surprised by ShiftCG doing what it should do according to the API reference, instead of doing what he wants it to do.

But that had been finally established already on Post 10.

Say what you want, this one isn't all clear. Could be simplified if anything. Also if it wasn't a bug after all, I would have been more than happy to know it back then... and thanks for "in the understanding of the developper" :dry:

Anyway the original post needs another final statement if you're sure of what you say and tested it. A clear one. API "R&D" may be very fun for software engineers, but that kind of things tends to fly a bit above the head of mere mortals like me, and the outcome isn't productive, really. :2cents:

@ Urwumpe :

A) In which cases would you use ShiftCG (two examples) ?
B) In which cases would you use ShiftCentreOfMass (two examples) ?
C) I want to make a Redstone ICBM addon (1 stage, simple case) and I want to feature the fact that the mass distribution shifts as fuel gets burned. Should I use ShiftCG or ShiftCentreOfMass ?
D) I have a single vessel that splits in two parts, creating a new one. I want to reflect the mass distribution change on the first one (Apollo CSM + LM -> Apollo CSM after the LM is jettisoned). Should I use ShiftCG or ShiftCentreOfMass ?

 

[gattispilot]

Ok I guess I am confused on what values I should use for ShiftCG?

 

[Urwumpe]

Say what you want, this one isn't all clear. Could be simplified if anything. Also if it wasn't a bug after all, I would have been more than happy to know it back then... and thanks for "in the understanding of the developper" :dry:

It is pretty clear:

I can confirm right now that the API reference does not diverge from the observed behavior.

What can you expect more?

---------- Post added at 11:50 PM ---------- Previous post was at 11:36 PM ----------

Ok I guess I am confused on what values I should use for ShiftCG?

you could now look for the NASA technical report that contains it. I know for sure that it exists somewhere deep in the NTRS.

Or you could simply recall what some guy named Archimedes already established:

Mass on the left side of the CG is equal to the mass on the right side.

If you drop 2 x 75 kg of ballast from one side, you need to shift the CG until as again as much mass is on one side of the CG as on the other.

Also, you do know that the remaining EDL without any ballast is again neutrally balanced, the CG is below the parachute attachment. This means that you only need to consider three point masses, instead of some complex structure ( at least approximate. Maybe the CG diverges by some mm in reality, but its still good enough for government work)

The complete EDL with all masses weights 2,401 kg.

first ballast: 2 x 75 kg = 150 kg
second ballast: 6 x 25 kg = 150 kg

The diameter of the heatshield is 4.5 m, which you can assume to be approximately the location of the weights for the start (or you measure more accurate values).

2.25 m * 150 kg/2250 kg= 0.15 m

So, the CG shifted approximately by 15 cm towards the first ballast.

---------- Post added 04-08-15 at 12:16 AM ---------- Previous post was 04-07-15 at 11:50 PM ----------

And if you like to check this with the real numbers by NASA:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20130003218.pdf

Remember that NASA uses different X, Y, Z axes than Orbiter.

0.0215 * 4500 mm = 96.75 mm

And the CG is 1350 mm above the bottom of the heat shield.