API Question ShiftCG

[gattispilot]

Thanks downloading now.
But since the 1st ballast is in the y direction.
I get this:

ShiftCG(BALLASTDISTANCE);

where

const VECTOR3 BALLASTDISTANCE = { 0.0, -.15, 0 };

 

[Urwumpe]

Thanks downloading now.
But since the 1st ballast is in the y direction.
I get this:

ShiftCG(BALLASTDISTANCE);

where

const VECTOR3 BALLASTDISTANCE = { 0.0, -.15, 0 };

Make it -0.096 then... its more accurate to the real values.

 

[gattispilot]

Thanks. I now have this. Press a key and the first ballast is dropped.

if (key == OAPI_KEY_3)//drop cruise ballast
{
	ShiftCG(BALLASTDISTANCE);
	
	return 1;
}

const VECTOR3 BALLASTDISTANCE = { 0.0, -0.096, 0 };

But to get the entry angle I guess I use RCS?

 

[Urwumpe]

But to get the entry angle I guess I use RCS?

Again: Yes.

And to prevent that your key press is capable of jettisoning the ballast multiple times, implement a proper state machine for this transition.

 

[gattispilot]

Thanks. Yes I will add that state so one can only do that once.

What about the airfoil definition?

Then I guess use RCs to level the capsule once chute deployed.

I think I may uses Transx to get the capsule to where it needs to start the edl.

 

[Urwumpe]

What about the airfoil definition?

Use simply one and the same function for both vertical and horizontal lift, since the capsule is axis symmetric...

In one NASA document, there are test results of the simulations and subscale tests (by shooting a subscale model with an artillery gun through a hall) and AFAIR also a formula that can be used for calculating lift and drag.

 

[gattispilot]

Thanks. Looking at some documents.
adjusts mass based off attachments. I allowed 390 for rcs on the backshell.475 heatshield and 2065 for skycraneand rover

if (GetAttachmentStatus(HEATSHIELD))//HEAT SHIELD IS ATTACHED
	{

		SetEmptyMass(1000 + 475);
	}
	else SetEmptyMass(1000);

	if (GetAttachmentStatus(HEATSHIELD) && (GetAttachmentStatus(SKYCRANE)))//HEAT SHIELD AND SKYCRANE ATTACHED
	{

		SetEmptyMass(1000 + 475+2065);
	}

	else SetEmptyMass(1000);

if (key == OAPI_KEY_3)//drop cruise ballast
{
	if (cruiseballastStatus == YES){
	ShiftCG(BALLASTDISTANCE);
	SetMeshVisibilityMode(CRUISEBALLAST, MESHVIS_ALWAYS);
}
	return 1;

 

[Urwumpe]

Your code for the key handling will not work - cruiseballastStatus will never be reset and you also miss a } at the end.

Much better solution: Create a new function to call from the key handler "void JettisonCruiseBallast(void)"

In that function, you check if cruiseBallastStatus is still YES ( I would have used a simple bool and reduced the code to "if(cruiseBallastStatus) {" ), you separate it, make the ballast mesh INVISIBLE ... AND then reset cruiseBallastStatus to NO (or false)

Much better would be using a simple integer to define the structural state of the EDL:

Stage# | Logical stage
0|After EDL SEP
1|After Cruise Ballast SEP
2|After Parachute deployment
3|After Heatshield SEP
4|After Entry Ballast SEP
5|Etc.

Since you can't transition between every stage and possible configuration, that's much more failsafe. Especially if you still use only special transition functions like "JettCruiseBallast" to modify the logical stage.

 

[gattispilot]

Thanks. I think this doc has the lift/drag:
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100026017.pdf

So so use that function for the stages for the whole edl? So that states which stage it is in?

 

[Urwumpe]

So so use that function for the stages for the whole edl? So that states which stage it is in?

No... think about it like you are talking to your add-on.

When you say "JettisonCruiseBallast();" and your add-on can do that transition, it should do that and transition to the new state.

(If the state transition is illegal, like from state 1 to state 3, you should at least log it into the log file, its a runtime error and should be handled)

After re-entry, you say "DeployParachute();", again, with the same checks and transitions.

Etc.

The important detail there is, that you are always knowing in your code that you trigger an action, that has the goal of a state transition. Your code gets much easier to read.

Also, you can further split those transition functions in two parts:

A group of statements that leaves the old state (The ballast is jettisoned) and a short part that just calls another function that defines the new state (new dry mass).

This way, you can easily reuse the code for the "clbkLoadStateEx" transition: When the scenario is loaded, you of course want to get directly to the correct configuration and not jettison another set of ballast weights, etc. In that case, you just have something like "JumpToState2();" (or better with a more descriptive name, you will only call it once in the source code and just need a good name for finding it again), which does the fast transition from stage 0 to stage 2 and calls the definition of the state 2.

 

[gattispilot]

So something like:
Press 3 to deploy ballast. this goes to deploy cruiseballast if stage =0
// ballast not deployed

void JettisonCruiseBallast(void){
ShiftCG(BALLASTDISTANCE);
SetMeshVisibilityMode(CRUISEBALLAST, MESHVIS_ALWAYS);
SetEmptyMass(backshellmass + heatshieldmass-cruiseballastmass);
Stage=1;
}

 

[Urwumpe]

Yes, but as I recommend, also do something like that:

enum EDL_STAGE {
	EDL_STAGE_POSTCRUISE,
	EDL_STAGE_ENTRY
};

//... In your class declaration:

EDL_STAGE edl_stage;

//... In your class implementation:

void JettisonCruiseBallast(void)
{
	if(edl_stage == EDL_STAGE_POSTCRUISE) 
	{
		ShiftCG(BALLASTDISTANCE);
		DefineEntryConfiguration();
	} 
	else
	{
		oapiWriteLog("(MSL) ERROR: Illegal stage transition in JettisonCruiseBallast!");
	}
} 

void DefineEntryConfiguration() 
{
	SetMeshVisibilityMode(CRUISEBALLAST, MESHVIS_ALWAYS);
	SetEmptyMass(backshellmass + heatshieldmass-cruiseballastmass);
	edl_stage = EDL_STAGE_ENTRY;
}

Also, you should really adopt a source code formatting style and a consistent naming convention. you are about to enter a world of pain by that chaos.

 

[gattispilot]

Thanks. I saw I made a mistake.
SetMeshVisibilityMode(CRUISEBALLAST, MESHVIS_ALWAYS);should be
SetMeshVisibilityMode(CRUISEBALLAST, MESHVIS_NEVER);

Then the next step would be to let rcs move the craft to the entry angle of 18 degrees.

 

[Urwumpe]

Then the next step would be to let rcs move the craft to the entry angle of 18 degrees.

Yes. Best for that would be defining an autopilot that you can reuse for all phases, by being modular.

 

[gattispilot]

Great.
Thanks. I thought so.
Since I have never done an auto pilot. I am up a creek without a paddle.
Wouldn't know where to begin?

I suppose the user could do that. Still looking for info on the airfoil. I found a lot that say l/d ratio of .24

 

[Urwumpe]

Great.
Thanks. I thought so.
Since I have never done an auto pilot. I am up a creek without a paddle.
Wouldn't know where to begin?

How about some theory first? Not too much, you are not planning to do your PhD in it... but some key concepts and key words should be helpful.

Like this article for example:

[ame="http://en.wikipedia.org/wiki/Control_system"]Control system - Wikipedia, the free encyclopedia[/ame]


Basically you can vertically structure your autopilot code already around the letters of the TLA GNC: Guidance, Navigation and Control.

You have a navigation layer, that establishes where your spacecraft is currently pointing at (and maybe where it will be pointing at in the future, which is often also interesting). You have a guidance layer, that uses the navigation for telling where it should be pointing and how you could orient your spacecraft in that direction. And you have a control layer, that does the actual motion, for example by using the RCS.

If you look closer at the three layers, you can also maybe see, that its possible to interchange different kinds of navigation, guidance and control modules: If you have a new sensor available (like radar), you can include it into the navigation. if other thrusters are available, you can use a new control function.

Now the trick question is: Where do you start? Maybe you should start simple at the most basic problem you will get: Three-axis stabilization.

Important is for example: Which coordinate system do you use for navigation? Many spacecraft actually use multiple coordinate systems, depending on which guidance task they are actually doing. For example, for the MSL, you could use a Mars relative coordinate system, that has its origin in the landing site. Or you use the Entry Interface as reference. Or both.

 

[gattispilot]

Thanks Ok. Three axis Stabilization. I like the Mars relative coordinate system. So now what.

 

[Urwumpe]

Step one: Get the navigation.

 

[gattispilot]

So get where I am and where I am going to?

 

[Urwumpe]

So get where I am and where I am going to?

Exactly. Especially the first part means: Find a format that you can handle.

If you use three angles, remember that three angles have gimbal lock. Maybe no problem, maybe it is a problem. Get the coordinates and attitude data from orbiter and convert it reliable in the best format that you can use.