Monthly Archive for December, 2009

Orbital vehicle horizontal ascent profile

I went even further with creating ascent trajectory for the XS Venture (or any other similar transport), and I wrote out several equations that should define the perfect trajectory.

First, here’s raw picture of my whiteboard (it contains mistakes though, look below):
eq

Now describing the equations and how I got them. First of all, what should be solution of our equation? We need to somehow define trajectory itself.

Let’s define x(t) as function that shows distance from launch site at given time, y(t) as function that shows at what altitude we are at at specific moment of time. Therefore we have a parametric trajectory!

A spacecrafts autopilot can command target angle of attack/target vertical speed, but parametric trajectory like that doesn’t suit us, so later we can use our solution to find function y(x), that is how altitude depends on distance from launch site.
And there’s more, we can find alpha(y) (angle of attack) as function from current altitude (which makes us get rid of distance from launch site, and allows us to resume trajectory from any spot, without relation to launch site).

For simplification these equations do not account for curvature of Earth yet.

The following forces act on our spacecraft in our model: aerodynamic force (drag and lift for our 2D case), gravity (obvious), and our engines also produce engine thrust. Our spacecraft will remain constantly flying if all these forces are equal (engine and our current velocity completly compensate gravity).

Aerodynamic force is how much pressure against our surface air creates. We are flying high mach number, therefore we can ignore airfoil lift, and simplify our model big time.
Our vehicle has front area, and wing area (lifting area). It also has side area, but we can simplify our task by only looking at 2-dimensional case, therefore let’s ignore it.

Our aircraft is flying with certain angle of attack (alpha) – that is, angle between airstream and vehicle nose. We can ignore winds, because our vehicle is moving at over 3000 knots, while wind speeds are under 200 knots.

Now, pressure acting on one unit of area is called dynamic pressure, it depends on current airstream velocity. This doesn’t account for effects of compression, etc.
The equation for dynamic pressure is Q = (1/2)*(V^2)*P where V is airstream velocity and P is air pressure.

Our velocity is a vector, consists of velocity on X axis and Y axis, that is derivatives of our functions x(t) and y(t). The final aerodynamic force is area_facing_airstream * dynamic_pressure * velocity.

Our engines are defined by specific function tau – it shows how much thrust we need to apply to keep certain speed, and it limits our speed in this way (the resulting trajectory will have “perfect” speed in each spot).

Here’s corrected set of equations minus initial parameters:
corrected

The result of solving first set will be functions x(t); y(t). These functions will be general solution and depend on several constants. Second set of equations will create some kind of connection between all of these constants, leaving out only one or two.

Then we can solve this for known start/end constrains, and find values of the constants, receiving our x(t), y(t) functions as we want them.



Now by just commanding specific alpha to flight control and tau to engines we will stay on this profile.

The best profile would be when tau never exceeds 70% max engine thrust, that would be safe enough. This equation might return such tau function that it exceeds max engine thrust, that would happen if you set target position and velocity too high or too fast.



Just an example for you, here’s one of possible solutions, but it isn’t real solution, does not fit the equations:
TELEMETRY_dist_nm
x(t)



TELEMETRY_alt_ftmsl
y(t)

XS Venture ascent autopilot

I’ve decided to make an autopilot for horizontal space vehicle launch, and here’s my first prototype. It works, and it runs required sequence (lifting off on atmospheric engines, then switching to rocket engine), and adjusts to current situation (e.g. it’s not programmed to switch over to rocket engines at specific altitude, but rather when it gains specific speed and atmospheric engines come to upper service limit of 20.5 mach).

It doesn’t currently use proper P-I-D stabilization, just P (proportional), so it’s much more curvy than it should be, and can’t keep up to required vertical speed (so the profile shown is below the profile it will fly), just because it overcompensates vertical speed change at some point. And of course a lot of oscillations



Here’s the profile it is currently designed to fly (the profile is altered by altering basic parameters):
sm_TELEMETRY_alt_ftmsl



Fuel consumption from atmospheric engines (you can see thrust sometimes tries to fix overcompensation by how AP controls the ship itself):
sm_TELEMETRY_FF4_lbh
sm_TELEMETRY_FF5_lbh
These are rocket engines burning up, but since it went below flight profile, it started switching between rocket and atmospheric engines constantly, even though they didn’t produce thrust. It’s a bug I should fix (though wouldn’t happen with proper stabilization).



Now here’s the speed profile:
sm_TELEMETRY_Vtrue_ktgs



Vertical speed (you can see overcompensation here, it oscillates a lot):
sm_TELEMETRY_VVI_fpm



And here’s angle jump problem on roll axis, due to how X-Plane handles coordinate system when you cross quadrant. This causes unwanted noise once it moves pretty fast, and every time vehicle crosses the quadrant border:
sm_TELEMETRY_roll_deg



It flies the ship through wanted profile right away – since it’s only specificed by certain limitations, it fillfulls them entirely. The limitations/rules are roughly “keep specific constant dynamic pressure, gain altitude, and gain speed, when you’re over 20 mach switch over to rocket engines and start gaining velocity and altitude, when dynamic pressure drops under 100 psf enable reaction control systems, when pressure drops under 10 psf disable flight control surface, when pressure drops to 0 psf switch to next OPS/operational mode”.

XSAG mission XS10 will be the first one to use automated ascent.

Chaotic functions

Just been playing around with discrete functions, which work on array of bytes (or array of bits). Found a simple obvious function that produces really nice animations (the map starts with single point with energy 0xFF). Source (delphi) attached below.

animanim2
(click them, they are animated)

And here’s the source code (change constants A and B for different patterns, must be integers):
Continue reading ‘Chaotic functions’

ZX Spectrum update

I’ve brought my spectrum to university today, they held a sort of computer technology history lecture there, it wasn’t really a lecture, but it was pretty interestring. There were 10″ floppies, and huge disk plantterns (used for data storage), and various old computer parts.

Anyway, I added an extra resistor to speakers, which made volume twice smaller, and now it doesn’t sound-rape your ears. I’ve showed it on small black & white TV I have, and the setup roughly looked like this (plus a laptop acting as cassette player to load from tapes):
IMG_1406

And here’s a small video, which has sound:

Oh yeah, I tried copying games from tapes to diskettes, but it seems they need to use altered game loader, which I didn’t start writing (but it should be fairly simple, most games just require to load their binary by specific address, and that’s all, in fact, most of the time it’s offset 32768, at least that’s valid for original JSW). The tape-to-disk copier looks like this:
IMG_1411

XS9B

I finished first space flight since XS8 (and that was back in September) using XS Venture. It was a short orbital flight, with 2 orbits around Earth, starting and ending at Edwards AFB. It’s primary mission was to test RCS (reaction control system), and it was a success.

I posted about reaction control system before, and during this flight I tested that, and also I want to use telemetry data obtained from this for determining where exactly X-Plane fucks up the orbit, which makes my orbit calculations be wrong (even with right world constants).

Also I wrote a new instrument, which takes telemetry data in format X-Plane outputs it in, and converts it into set of graphs/visualizations. This way I can provide you these graphs (they are not very good yet, but they are more than enough for general indication):

TELEMETRY_Vtrue_mphgs
Ground speed, in MPH

TELEMETRY_VVI_fpm
Vertical speed, feet per minute (you can see adjustements in vertical speed as I was adjusting my orbit).

TELEMETRY_alt_ftmsl
Altitude, feet

TELEMETRY_lon_deg
Longitude, degrees (showing that I actually orbitted Earth two times!)

Some pictures:
Continue reading ‘XS9B’

XS Venture X-Plane update

I updated X-Plane version of it too, primary change is that new RCS system. Now central computer controls set of 14 thruster groups, it can send them commands to fire or not. Every direction of movement fires specific set of thrusters, just like on real spacecraft. The RCS thruster groups are layed out as following:
rcs_beta

Here’s software display with reaction control system information (now it’s actually split into three screens):
displays_rcs

It displays when thruster groups are fired, when specific thruster sets are fired, what are commands that guidance computer software gets, and what kind of thruster sets it wants to activate. It’s all pretty neat, although you can’t see or hear thruster jets yet – no rendering for that yet.

Also command entry now works, and vehicle is ready for tomorrows XS9B short orbital flight – which aims to test some systems, and will be only 4 hours long. Although there will be live telemetry and picture feed available, as usual.

XS Venture update

Here is the new general model for the XS Venture (the new official name). This model is now more correct, because it’s pretty much close to current concept, and it also accounts for various problems with being actually built (previous model had some weird joints in some places).

Here are the pictures. Boxy thing under it’s belly – scramjet chamber, and also part of structure which holds turbofan engines (they are partially buried into cargo bay):
xs_venture_a

xs_venture_b

Here are some results of aerodynamic testing in a CFD:
result000003_IT=1161
result000004_IT=1161
result000005_IT=1161

OpenGTA2 networking prototype #3

Been working more on networking – now on clientside extrapolation. It means that after internet packet has arrived, and during small time until next one arrives (in my current networking model) the game will try to guess how it should run until next frame arrives.

This is actually only important for high-latency games, as it makes game much smoother (although not much more playable), for example here I recorded video at 1000 – 1200 msec latency (round-trip time). Green crosses show where players are located on client, red crosses show where players were located in last networking packet to arrive. Red lines are connecting these two points:

You can see that as long as it only involves AI pedestrians and player himself, the error is very small, and you can walk around – although once you try to shoot someone or iteract with players, it goes very wrong.

I’m thinking of adding two networking modes of a sort – one is when world update frames are sent at some low number, for example 10 times a second, and clients will use this data for checking sync state, resyncing – extrapolation takes more here. The other mode is when server sends state updates to clients every tick, and clients simply interpolate between last two received update frames.

The second way is much more precise, but it uses more traffic (and it’s more precise visually). Actually the only real difference between these two approaches is how quickly packets are sent from server – and this all relates only to client visualization. Client inputs are send to server, which calculates clients and their movement, and does all the bullet hit checking and lag corrections – therefore two modes only affect how players see it, and how enjoyable their game is.

The code difference between two modes is small, but I guess for best perfomance they would differ by this: in second mode the client adds extra interpolation between two frames, and the world state lags behind current state for about 100-200 msec (which means you need no more than 100-200 msec latency to play the game). E.g. the last received world frame is pushed by 100 msec into future.

In the first mode there is no interpolation between two received frames (because larger visual delays would be really annoying to user), but instead it entirely relies on extrapolation from last frame – because last frame is always late by more than 300 msec.

In fact, both of these modes can be interchanged in realtime, from users point of view this only requires setting a kind of net_clientrate console variable – making server send data faster or slower. Within one world frame data is compressed using delta compression, and AI pedestrians use their own way of synchronizing (full position resync frames, and AI updates, which carry changed AI states).