Monthly Archive for July, 2009

X-30 Venture hydraulics systems

Posted on July 30, 2009. 0 Comments

I added new instrument – it shows hydraulic pressure and quantity, also oil & hydraulic temperatures, and hydraulic pump RPM.

Also I wrote complete simulation of hydraulic pump – variable displacement rotating pump is simulated. It takes following parameters as input: friction because of liquid vicosity, motor mechanism friction, motor strength (amp-torque per one amper of input current), voltage (input, and design voltage), liquid flow rate, inertia of hydraulic pump mechanism. Plane angular accelerations on certain axes (in X-30 it is longitude axis) will act upon hydraulic pumps – you can see slight variation in RPM because of effects of non-inertial system.

Soon there will also be heating of the hydraulic fluid – and coolant system to cool it down (or heat it up).

Also I have to override X-Plane default hydraulic stuff – because pressure output of this simulated system constantly varies, and it should provide feedback on aircraft controls. There is a bug in X-Plane that disables RCS when hydraulics are disabled – that should be hacked around too.

hydqty

By the way, there are strict specifications about hydraulic reservoirs, pressures used in system, and exceeding those will result in malfunction. There will be extra control knobs later to adjust hydraulic pumps and all other systems.

And oh yeah, there is only one flaw in simulation so far, right now fluid flow rate is linearly dependant on pump RPM (it is not true, pump does not provide any pressure under about 200 rpm), and there is no hydraulic system valve logic yet (there is high-pressure relief valve though, it will release extra pressure back into reservoir in case pressure levels in hydraulic system start to rise above critical level). Also two pumps are spinning in different directions – clockwise and counter-clockwise. It is instantly noticable, because rolling plane to one side will increase RPM on one pump, but decrease on another – and the other way around.

Tags: , .

X-30 Venture

Posted on July 29, 2009. 0 Comments

Let me share with you this one project I’m working on – a new space shuttle for X-Plane. It is another addition to XSAG (check out, we got a website now!) fleet. What differs it? It is a spaceship. It will have complete simulation of all second-level systems – everything that X-Plane does not simulate. Life support, cryogenic systems, electric system. It will have probably one of most complex spaceship cockpits too – this is no modern spacecraft which can fly to orbit with a single press of button.

A single deviation from checklist will cost you and your aircraft structural integrity. Right now I’m working on instruments and aircraft logic. Yesterday I finished gear state panel (it shows forces acting upon gear or docking mechanism if one is available, also deployement status of gear/docking mechanism), and local navigation panel (it shows spacecraft angles, torque, and angular acceleration).

instrum3

This is how it looks from side right now:
screenshot_12

I’ve been working in detail on every system, right now electric system is more or less complete (8 BA-8180 batteries, that gives total of 7168 watt-hours, it is enough to stay in orbit for about 10-14 days, but the mission length is recommended to be under 8 days).

Next mission, XS8, will be launched in August (20th-27th, somewhere around that), if all goes well. It will be with a team of engineers (if you want to take part, feel free to mail me/leave a comment). Being an engineer is easy – you just monitor stuff, and only in emergency situation your help and assist will be required. Well, I’ll be sure to ask engineers for some more tasks, so it won’t be too boring.

Tags: , .

XNAV

Posted on July 27, 2009. 0 Comments

I rewrote X30NAV system from scratch, now it’s called XSAG monitoring and on-board computer system. It will allow several people to link in to data transmission feed, and see it live on their screens. It also now performs orbital trajectory calculations.

xn1
xn2
xn3
xn4

This system will also provide helper indication for orbit synchronization with another object by given parameters, ability to lock current orbit parameters and force craft autopilot to keep this orbit, have indication screens for all systems and failures of systems in entire spacecraft, will allow remote copies to be launched (and they will receive same data as this one, but they cant influece spacecraft), will have helpers for re-entry.

I’m also currently working with SASL plugin to add life support systems, extended electric system (I’ll be sure to add a whole load of electric units in contour, which can break, and ability to allow you to fiddle with wires, hello apollo 13!), very VERY simple reentry heating, and some misc systems for X-30 (the chassis coolant system using fuel).

With some luck I’ll get SASL to work for 2D cockpit (there’s some problem with button) and add instruments backed up by electric system logic I mentoined before, and with some really extreme luck I could try to create plugin that would put that on-board computer/monitoring thing into cockpit – but don’t really count on this.

Tags: , , .

ESAT ideas on online rezendvous

Posted on July 26, 2009. 0 Comments

The problem of doing rezendvous of two objects (spacecraft) lies in speed of objects (they are both moving at almost 7.8km/sec), and the precision of synchronization (you need 0.1ms precision for an error of 70cm). Regular internet connection delays have a constant delay, plus random fluctuating delay (usually about 5-20 msec).

5 msec is essentially error of about 30 meters – which can’t be tolerated if you are trying to move together (you can’t determine correct position with precision better than 30 meters).

This is what I want to implement to entirely eliminate all possible problems with online docking:

  1. A timer is synchronized on server and all clients. It uses a lot of requests to stabilize timer with precision of (hopefully) more than 1 msec. All key events are timed, and they have timestamp. Clients extrapolate current state of objects based on their state some amount of miliseconds ago (usually hundreds)
  2. Objects which are moving closer than 500m apart from each other are grouped into a single “superobject” (if they are close, and their orbits match) – trajectory is predicted for this superobject
  3. Objects which are moving closer than 500m are using local coordinate system (barycenter of superobject) – their speed relative to this point should be less than 30 kph (else you’re going to miss your rezendvous)
  4. Orbits are defined parametrically (including air drag from planet), and carefully timed using precise timer
  5. Object synchronization in local coordinates can be done peer-to-peer – extensive precision here is not required (or is it? actually it might be requested to specify coordinates with precision of more than only 5 cm.. for precise docking). Superobject coordinates are having priority here – the whole system is rotated and translated in space accoding to movement of superobject

The next XSAG mission (XS8) will determine how precise my model will be (for X-Plane orbitting), and determine air drag at different orbit heights. It will be also a very long mission – I expect 16 hours with 10 circles around Earth.

I will also complete new monitoring system by that time (I hope) – there will be some people helping me (tracking my position and craft state).

Tags: , .

Updated opcode format for ZCODE VM

Posted on July 26, 2009. 0 Comments

Changes from previous version:

  • I removed 128-bit math from specifications – it is potentially a big pain to implement, and adds unneccessary overhead to opcode decoding
  • I removed fixed point math – it’s essentially just using integers and typecasting trancedental functions from floating point to integer.
  • Make scheme nicer
  • Included the fact that you actually need to specify memory operation size (what a waste, the extra field is only 2 bits, I might change this)

Currently opcode decoding is done, and I’m going to add operations to virtual machine now. I might work on some “paperwork” these days, and fix up a lot of documentation on the VM, compiler, and OS.

opcformat_v2
(yeah, it is poster size)

Tags: , , .

HybriC progress

Posted on July 25, 2009. 1 Comment

I’ve been working on HybriC! I added constant expression evaulator, more syntax features (arrays, stuff), and actual code generator now. Right now it just generates code, but soon it will also built optimization tree, simplify it, and then output resulting code. It will compile very fast bytecode.

Some examples of how it compiles stuff right now (I picked ones without obvious optimizations that would be cut down by optimization tree anyway):
R0 = 100;
R1 = 200;
R2 = 300;

zap all; //this will mark all registers as "not important"

R0 = (R0 + R1*R1) * (R1*R1 + R2*R2);
compiles into:
MOV R0,100
MOV R1,200
MOV R2,300
MUL R1,R1
ADD R0,R1
MUL R1,R1
MUL R2,R2
ADD R1,R2
MUL R0,R1

And this:
F0 = 100.0;
F1 = 200.0;
F2 = 300;

R31 = F0 * (R1 + R2);
into this (it preserves F0, F1, F2 – these are registers 0, 1, 2, but they are treated as if they have floating point value. Typecasting is automatic, and done by the VM):
MOV F0,float 100.00
MOV F1,float 200.00
MOV R2,300
MOV R3,R1
ADD R3,R2
MOV F2,F0
MUL F2,R3
MOV R31,F2

Registers can be important and unimportant – value of important register will be preserved at all costs. Registers R0 and F0 are the same physical register, except when you write “F0″ you mean that you want to treat data inside the register as floating point value.

Tags: , , .

ORBITSIM

Posted on July 17, 2009. 1 Comment

Until I finish all physics stuff behind FSIM, I deicided to use it’s rendering engine as a base for a very simple and stupid space simulator – which is also a game engine for one new game for BlackFOX.

I started with just removing landscape, and rendering celestial objects as cubes. The engine is capable of rendering certain amount of bodies, given by a list. Later it will also render static stars (from a list too).
planerender

You can see that I used already written plane rendering, and just specified a space-ship looking object as model. In this version of simulator there’s no air drag, lift, stuff like that, and only basic gravity – it’s very simple, arcade, and visual model doesn’t really make ayn difference.

Later I replaced cubes with two circles, at angle of 90 degrees to each other, so it looked more like a sphere. You can see Earth and Moon here – up to scale, at correct distances.
planerender2
(the moon and earth are aligned on one axis, the ship is looking at them from side, so moon appears nearly behind earth)

Tags: , , , .

Slight Buran update

Posted on July 16, 2009. 0 Comments

I did a slight update to Buran – I added rocket engines, some of extra geometry like OMS and parachute holders, and main fuel tank (it’s not yet perfectly precise). It works well, but I don’t have correct engine settings for Buran right now (thrust and fuel consumption).

These are some screenshots (I’ll start painting it, and making fuselage even more close to real Buran soon):
screenshot_41

screenshot_5

It’s time to start working on on-board computer system and landing autopilot. And yes I know it looks ugly, I will work on making it eye-candy once it flies good.

Tags: , .