Photocopy Application

I’m using photocopying a lot during the university – to copy various books, publications, schedules, etc. I’ve wrote a simple application that helps me to convert the resulting photos into more or less acceptable picture.

This application will also attempt to fix the basic distortions in the picture, although it only does a rectangle into rectangle transformation at the moment.

I started with this picture as the initial test case:

The first result was a bit wrong because of a small mistake I made:

I’ve fixed the glitch, although the picture is still distorted due to non-linear distortions this simple approach cannot fix:

This is an example of a very good case, when lighting was more or less uniform, and there were no non-linear distortions:

SV-201 Flight Simulator

I did not have access to the X-Plane flight simulator, so I wrote my own, to adjust all the parameters of the spacecraft properly, and to further develop the on-board software.

Right now the simulator does not support the aerodynamic data, and there is only a basic drag model. This works fine for a shuttle launch like this though, because the orbiter leaves the atmosphere pretty quickly. It is a very simple simulator, and there’s nothing much more than just linear and angular moments here. I’ve attached the source code to this post.

I will try to describe how it works though. First of all, this is what is defined as input parameters:

  • Spacecraft fuel tanks and fuel weights (no center of gravity shift yet)
  • Spacecraft moments of inertia (calculated as moments of inertia for a cube)
  • Empty and cargo weight
  • Location and direction/magnitude of all the forces that act on the body (engines and control surfaces)
  • Thrust deflection angles (for some of the forces that relate to the engines)

First of all, there are two coordinate systems: the global coordinate system, with point of origin in center of the earth, the Z axis going up through the north pole, and the X axis going to the point of 0 latitude, 0 longitude. The local vehicle coordinate system center is in the vehicle center of mass (center of mass of the primary vehicle body). The positive X axis goes to the nose of the plane, the positive Z axis goes up, following the vertical tail, and the positive Y axis goes to the right wing.

For every force that acts on the spacecraft the change in linear and angular moments are calculated:
\frac{dL}{dt} = F (linear moment, only affected by direction of the force)

\frac{dM}{dt} = F \times r (where r is a point in the local vehicle coordinates where the force is applied to – angular moment, affected by direction and position where the force is applied).

The vector of momentum changes are then rotated into the global coordinate system, and the state of the vehicle is updated accordingly. That’s all for now – it doesn’t calculate center of gravity change yet, but there is all the code you need to do so.

This is the screenshot of how it looks like (pretty boring):

Here’s the sourcecode (had to attach it as a text file, did not want to get into the post for some reason):
Continue reading ‘SV-201 Flight Simulator’

SV-201 cockpit

Here’s the cockpit I’m working on for the SV-201. It comes in both the russian and the english versions:

Everything works as expected – there’s less systems to play around though (compared to SV-302). There’s still a lot of different switches and controls here, and for a reason.

There’s a certain russian touch as you see – the Buran cockpit is built in a different way than the space shuttle cockpit (and therefore the SV-302 cockpit, since it draws inspiration from that one).

This shuttle, just as the Buran space shuttle is capable of completly autonomous flight – which is why most controls are buttons, whose state can be controlled in software. There is no need for human iteraction for some specific controls.

SV-201 Digital Autopilot Test

This is the digital autopilot test. It runs the only program it’s programmed to follow right now – the automatic ascent program. Few notes about the video though:

  1. There is an automatic throttle down to keep the spacecraft under the structural limits.
  2. The separation and the entire ascent are fully automated.
  3. The Ares rocket has a natural +9 degrees nozzle pitch.
  4. The MFD picture is a direct video output draw by the XGDC OS.
  5. There’s no scenery to have launch pads yet, so it starts from mid-air in the video
  6. It uses euler angles right now, so there’s a certain limitation in manuevers during initial ascent… will be fixed later with quaternions.

SV-201 Ultra Heavy Lifting Space Shuttle

This is a new vehicle in the XSAG space fleet. It’s a design offspring of the Buran space shuttle. The changes include the extra canards for more control (design input by Mr. Scott), and the use of a different Ares-based booster for more lifting capability. It has a much higher cargo lift than the space shuttle, partially because of it’s launch site at the Baikonur space center, which provides a lower launch lattitude (and more assistance from the rotation of the Earth).

The ascent is very similar to the Buran space shuttle, and I’m currently working on making it run on the XGDC operating system (it’s primary goal is to test autopilot, and serve as a backup/secondary vehicle for XSAG missions, with a higher service time).

It is a three stage vehicle – first stage are the four Zenit boosters, second stage is a single Ares booster, and the third last stage is the orbiter vehicle itself.

XGDC DAP

Time to describe the digital autopilot features provided by the XGDC OS. The autopilot support provides an easy framework for building own autopilots based on different controllers.

The DAP has several channels, each channel has commands. All the commands in the parallel channels are executed simultanously. The commands can be grouped into programs, which are blocks of commands which can replace current command queue when required.

Every command has four functions – data input (function that generates the state vector for the controller), data output (function that turns controller command into real actuator deflections), the controller which performs actual state to command space transform, and the condition function, which tells DAP when to end the command execution and move on to the next command.

This is the rough scheme of how the command works:

Every command has a code name it is referenced by, and also every program has a code name as well. The programs will redefine one, or some of the current command channels.

This is an example of how a single command can be defined:

DAP.AddCommand("EARLY_ANGLE_HOLD",
  function(Input,Parameters) -- Data input
    local decreaseInAngle = (1/650) * (State.ElevationMSL-312)
    Input.Pitch = (84.60 - decreaseInAngle) - State.Pitch
    Input.Roll  = 0 - State.Roll
  end,
  function(Output,Parameters) -- Data output
    FCS.VectorThrustCommand.Pitch = FCS.VectorThrustCommand.Pitch
      + Clamp(Output.Pitch,-0.9,0.9)
    FCS.VectorThrustCommand.Roll  = FCS.VectorThrustCommand.Roll
      + Clamp(Output.Roll, -0.2,0.2)
  end,
  DAP.Controller.PID,
  DAP.Condition.EARLY_PHASE_END
)

Creating the SV-302 re-entry profile 1

I’m working on the new strictly defined re-entry profile for the SV-302. In this post I will only outline my current plans though, I didn’t start doing the actual work yet (because I need to finish the wind tunnel script for the X-Plane).

The re-entry profile should bring the vehicle down from 7.8 km/sec velocity and 100 km altitude to full stop at the end of runway. First of all, there is a simple assumption we can make – the heating flux is roughly proportional to the G-load during the atmospheric braking part of the re-entry.

I want to try and perform these steps:

  1. Determine attitudes for sustaining constant different g-loads
  2. Determine attitudes for sustaining constant rate of descent (vertical speed)
  3. Pick 1.0 g or 1.5 g as deacceleration rate, and calculate required rate of descent commands based on the fact that vehicle should hold nearly-constant and not-too-high dynamic pressure (under or roughly equal to 300 KPa)
  4. Smooth out the profile, because the vehicle has reactive properties when keeping the vertical velocity

I made a simple C program that outputs table of maximum velocity at given altitude to sustain specific dynamic pressure. Here’s an example of output for the Q of 300 KPa:

Vind=360.00 KEAS  Vind=690m/s(EAS) Q=300 KPa

V0= 110 m/s  H=    0 m/     0 ft
V0= 150 m/s  H= 5000 m/ 15000 ft
V0= 210 m/s  H=10000 m/ 30000 ft
V0= 290 m/s  H=15000 m/ 45000 ft
V0= 400 m/s  H=20000 m/ 60000 ft
V0= 560 m/s  H=25000 m/ 75000 ft
V0= 760 m/s  H=30000 m/ 90000 ft
V0=1050 m/s  H=35000 m/105000 ft
V0=1440 m/s  H=40000 m/120000 ft
V0=1980 m/s  H=45000 m/135000 ft
V0=2720 m/s  H=50000 m/150000 ft
V0=3730 m/s  H=55000 m/165000 ft
V0=5120 m/s  H=60000 m/180000 ft
V0=7030 m/s  H=65000 m/195000 ft

This is the sourcecode, and also full table attached (it works for any spacecraft, it doesn’t have to do anything with spacecraft itself, but with the atmosphere parameters):
Continue reading ‘Creating the SV-302 re-entry profile 1′

SV-302 documentation

You might have seen some illustrations from the SV-302 documentation earlier. I’m still working on it, and it actually consists of several different “books”:

  • Engineering Reference Guide – information about various SV-30x vehicle components, systems, and avionics
  • Checklists and Contingency Procedures
  • Flight Crew Reference – information about avionics systems and vehicle components, systems, etc.
  • Vehicle Operation Guidelines – vehicle operation limits and rules of thumb
  • XGDC Avionics Operating System – XGDC OS programming and architecture information

All of these are included in the operations handbook (although not all of them should be). You can download the current draft here: xsvdoc.pdf