The Tasks for a good simulator.

The LLC hovering vehicles were fairly simple to model. Fixed local frame of reference, constant air pressure, fixed magnetic dip and declination all in all slow enough that one could basically ignore air drag. One could model the vehicle dynamics using a simple unchanging world in Cartesian coordinates.

I've spent the last 2 years thinking about what it takes to build an orbital vehicle. A very rough first pass can be done with a simple how much delta V do you need. A more refined tradeoff needs a more refined model. Ultimately I'd like a full up hardware in the loop simulator that I can run full missions on. Writing such a simulator is a bit of a daunting task.

Just modeling the complexity of the "World" as you fly around it is non trivial. Starting with what reference frame do you use: Lat Lon altitude? , North East Down? Earth centered fixed. Earth centered Inertial? (Probably ECI what epoch J2000?)

A whole bunch of things that used to be fixed for the LLC simulator now change...

• Gravity,
• Atmospheric pressure.
• Magnetic field strength, direction.
• GPS constellation geometry.
• Earth is not round.
  

One could refine the vehicle model with a simple 2D model of a spherical earth and launched from the equator, Yet there are questions that can't be answered without these details. Just one simple example, I plan to use a MEMS IMU, GPS and Magnetic sensor to keep track of the vehicle position and orientation. MEMS IMU's drift really bad (0.1deg per sec is typical for a mems gyro) A better Laser gyro is much much heavier.

This is correctable if you have a couple of outside references to keep things aligned. In aircraft its common to use gravity and magnetic field to "erect" the gyros keeping then aligned. On a spacecraft under thrust you can do it with GPS velocity an accelerometer and a 3D magnetic filed sensor. The accelerometer measureing thrust direction in a body frame is compared against the GPS measured acceleration in an absolute frame (Say ECF), In reality these two vectors measure the smae thing so these two vectors gives you one absolute orientation vector. The magnetic field gives you another. This will fully define the corrections you need to apply. If some where during your launch the magnetic field vector and the desired thrust vector align too closely then you really only have one reference vector and your orientation is ambiguous in roll around that one vector. You might say that orientation on that axis does not matter, and that would almost be true, but if the orientation changes from the desired trajectory and you want to correct back or close the loop, you must have a full orientation solution to steer the rocket.

So do they ever align? I have absolutely no idea. Does this mean I'm limited to picking only certain orbits? Maybe? When the rocket stops thrusting and coasts I loose my orientation again, can I start thrusting for a circulization burn and learn my orientation quickly or is it more efficent to steer into a direct injection orbit with no circularzation burn.

Doing a direct injection burn has a delta V penalty, is this penalty larger or smaller than the hardware weight cost to have the 3rd stage motor restart? Is the find my orientaion with quick thrusting penalty in delta V greater or less than the mass penalty for a simple sun sensor, or tine CMOS start tracker? Inquiring minds want to know. The whole conceptual rocket has way too many knobs.

Beyond modeling the world you have to model the vehicle and its systems. Tanks, valves, actuators, pressurization systems, rocket motors, thrust vector control, atmosphere drag, aerodynamic moments, areo and solar heating etc.. etc...

Trying to organize this monster project into a modular individually testable coding campaign is quite daunting.