I have worked on the autopilot, and added the built-in quaternion support. There is just one command right now – keep desired attitude and heading. This is the implementation of the command:
local attitudeCommand = QuaternionMath.Divide(State.Attitude,Params.Attitude)
local headingCommand = QuaternionMath.Divide(State.Attitude,Params.Heading)
local eulerAttitudeCommand = QuaternionMath.GetEulerAngles(attitudeCommand)
local eulerHeadingCommand = QuaternionMath.GetEulerAngles(headingCommand)
local currentYaw = Math.AsDegrees(eulerHeadingCommand[3])
-- Input = Target - Current
Input.Pitch = 0-Math.AsDegrees(eulerAttitudeCommand[2])
Input.Yaw = 0-currentYaw
Input.Roll = 0-(Math.AsDegrees(eulerAttitudeCommand[1])+Clamp(4*currentYaw,-30,30))
The XGDC OS DAP will attempt to match all inputs to the target value of zero. The result is a command output for the control surfaces, which attempts to match the corresponding Input variable to zero.
I will explain that much better later. Also it uses two quaternions for a separate attitude and heading orientation – that is, the airplane is interested in keeping it’s current attitude (roll and pitch) separately from the yaw angle (because to change yaw angle the plane has to change it’s roll/bank angle). The direct yaw command is currently ignored.
There is one small problem right now – there’s a noticable jump when you reboot the computer, that is, when the autopilot comes online and starts commanding a conflicting command at first. I will fix this by adding a smooth-out delay, which smoothes out the commands during the initial startup. But this solution doesn’t work for when commands are interchanged (control goes to the next command) – they must be by definition seamless. But if you use the PID controller, there is a slight delay before PID controller “comes online”. I’m sure there’s a working solution for that.
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:
There is an automatic throttle down to keep the spacecraft under the structural limits.
The separation and the entire ascent are fully automated.
The Ares rocket has a natural +9 degrees nozzle pitch.
The MFD picture is a direct video output draw by the XGDC OS.
There’s no scenery to have launch pads yet, so it starts from mid-air in the video
It uses euler angles right now, so there’s a certain limitation in manuevers during initial ascent… will be fixed later with quaternions.
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.
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:
This update concerned the guidance computers of the SV-302. I have completly redid the software part, or rather the envrionment the operating system runs in. Previously it had to use global object “GDC” as own memory, but now the operating system runs in a dedicated envrionment, and it also uses a different standard functions library (not the Lua one, but most of functions are simply renamed ones).
This actually only means replacing GDC.Event with Event, and things like string.sub with StringLibrary.Substring. This makes code much more readable, and therefore much easier to track down early errors.
The XGDC operating system was updated with the new digital autopilot system, which I will tell you about later. The GDC control panel also has changed, this is how it looks like now:
Added a prototype of a map-based navigation system, so you could use charts/maps, and display them full-screen on airplanes MFD. Right now it’s very blurry because I’m using just one texture for an entire region, but later I’ll break it down into blocks of smaller size, will improve quality a lot:
I need to find some charts in a good format to work with. JPEG preferred, and cylindric projection preferred, maybe anyone knows websites where to get these?
Added database subsystem to XGDC. Now you can have a database (like a database of airports), and easily load it/process it in background (it doesn’t lag the OS/simulator). No pictures, because it’s an internal change, but here’s a neat random picture:
Been working more on the synth, now it uses only sine and white noise as sound sources (although I should use a wind sound instead of white noise, or somehow alter it). Still doesn’t sound right, can’t get FMOD to do what I want to: http://brain.wireos.com/wp-content/uploads/1xplanesnd.wav
Added WAPI – window API. It’s a set of controls you can place on the MFD, and they will properly work (controls like buttons, list boxes, etc). I’ve rebuilt the FMC with them, and slightly altered the layout to be more sane:
Started also working on creating an engine sound synth for X-Plane – a set of utils that allow one to build engine sound synth. Right now it only uses pre-recorded samples, here’s how it sounds like (not very good right now): http://brain.wireos.com/wp-content/uploads/0xplanesnd.wav
Recent comments