A short introduction to our flight simulation software

A historical perspective

On the 4th of June 1996, the first flight of the European Ariane 5 rocket ended in a catastrophic failure: Around 40 seconds after liftoff, it suddenly veered off course, leading to immense stress on the hull material, which could not withstand the aerodynamic forces for more than a few seconds. The rocket broke up, exploded, and shredded an estimated 370 million euros worth of hardware into pieces.

A few days after the incident, an investigation revealed that the main reason for the failure was an unprotected piece of code which was thought to be completely safe. Unfortunately, this assumption was based on similar flight code written for the smaller Ariane 4 rocket and no further tests were carried out with the predicted trajectory of the Ariane 5 before launch.

Why we need flight simulation software and what it can do

Although we are not building full-scale rockets that cost millions of euros yet, whenever a rocket launch fails, there is a financial loss and a lot of work associated with it. Especially when it is caused by a simple error that was just overlooked during testing, it can be quite unpleasant. But how can errors that would otherwise only occur during a flight be found? Well, just pretend to be flying by simulating the rocket and its surroundings! If you are interested in how the simulation itself works, you can either take a look at the short explanation further down in the article („How it works“) or check out the source code which is available on GitHub (https://github.com/Atmoventus/atmoventus-rocketsim). But first, we would like to show you some of the capabilities that our simulation software has:

Estimating flight parameters

One of the most interesting applications of a trajectory simulation software is knowing our rockets maximum altitude and speed in advance. This helps to choose materials and other flight hardware so that it can sustain the high loads during flight.

Wind simulation

Wind is one of the most important factors during a rocket flight. It causes the rocket to deviate from a perfectly straight flight path and orientation in the first place, and can lead to uncontrollable oscillations, instabilities, a lower apogee, or a rocket being carried away during descent with a parachute. By simulating wind, we can optimize when each parachute should be opened, how fast our stabilization systems should react, and where we should expect the rocket to land. But how does one even get data about wind? Typical weather forecasts only include wind speeds directly above ground, global weather model licenses are oftentimes expensive and only provide wind speeds at less than 5 different altitudes and live data from open weather stations is just too sparse. Luckily, at the end of 2018, the European Space Agency launched a satellite called ADM-Aeolus, named after the Greek god of winds. It uses a lidar sensor that determines wind speeds at up to 30 km altitude using Doppler shift information from moving atmospheric particles reflecting and scattering the laser impulses. We can use this information to generate realistic wind profiles in specific places where we might want to simulate a rocket launch, and we can even adjust the time, to see the effect of different seasons and times of day, provided there is data available for that period.

Testing of stabilization algorithms

To simplify tuning our stabilization algorithms, the simulation can include the exact code that will run on our rocket. This code then accesses simulated sensors and motors and tries to make steering decisions which in turn influence the simulated trajectory. This way, we have a completely closed-loop system where we can test and tweak our software before trying a flight in the real world. We can also try different types of control algorithms, ranging from purely mathematical approaches to feedback loops or even reinforcement learning.

Generating visualizations

As helpful as raw data might be sometimes, it is also always interesting to watch the rocket fly. We can visualize trajectories by exporting flight data from the simulation into a 3d modeling software or even into a game engine to get a closer look at how the rocket behaves.

Emulating inaccurate hardware

The main processor in our rockets relies on a lot of different sensors and actuators to gain insight into its environment and to react to changes: accelerometers, barometers, gyroscopes, radio modules, motors, etc. The simulation software can extract data from the simulation, add a predefined amount of noise, offsets, and inaccuracy, and finally pass this processed data on to our flight software. That way we can make sure that our system can deal with the problems real-world sensors create, so we do not simply (walk into Mordor, wait what?) optimize it to run with perfectly clean values. The same thing is possible for outputs, so motors or radio modules. For example: The simulation could drop random percentages of radio communication, or the motors could run a little slower or faster than intended. This enables us to gather experience and helps us build a robust system that can take on the challenges of the real world.

How it works

To find out what causes a rocket to move the way it does, there are a few basic forces we have to consider: Lift, drag, thrust, and the gravitational force. While some other influences like the Magnus effect or the Coriolis effect also change the way a rocket behaves, they can simply be ignored in our case, especially because of their low magnitude.

Let's start with the gravitational force: It describes the attraction between two masses and can be calculated by using Newton's law of universal gravitation. Three variables influence its magnitude: The first mass, the second mass, and the distance between the centers of the masses. In our case, we only look at the gravitational force between the earth and our rocket because the attraction towards other planets or stars is negligible in comparison. So, the first mass is the approximate mass of the earth, while the second mass is the mass of our rocket, which changes over time as we slowly burn all of our fuel. Getting the distance between the two objects is also quite simple as we can just take the sum of the approximate distance from the earth's core to our launchpad location and the altitude of our rocket during flight.

Next up is thrust: It is generated through one or more rocket motors by ejecting propellant at high speeds to accelerate the rocket. The magnitude of this force can either be calculated or measured, but in our case, the manufacturer of our rocket engines already provides diagrams showing the amount of force generated over time. However, the magnitude is not the only thing that is interesting when it comes to thrust. Because our engines are contained inside of a steerable gimbal, we can change the direction of thrust to actively control our trajectory and orientation. This is possible because we generate a torque around the rocket's center of mass whenever the gimbal is at an angle.

Lift and drag are by far the most interesting forces acting during flight: Drag acts in the direction of airflow relative to the rocket while lift acts perpendicular to drag, and both forces combined cause the rocket to decelerate and turn during the flight (therefore these aerodynamic forces also generate a torque around the center of mass). Their magnitude is calculated by using the drag and lift equation which depends on the airflow velocity, air pressure, and a coefficient specific to the design, angle, and velocity of the rocket. This coefficient is usually determined in a wind tunnel or by simulating one in some kind of fluid dynamics software. Because we currently don't have access to a wind tunnel, we are using the latter approach.

Now we know the most important forces and torques acting on our rocket during flight, but how do we turn those into a position and an orientation? By using the mass and the moment of inertia, we can turn those values into linear and angular acceleration which are the derivatives of linear and angular velocity with respect to time, which in turn are the derivatives of position and orientation with respect to time. So, there is a way of getting from one end to the other, but because all of the forces and torques are tightly coupled and dependent on each other, solving this problem analytically is close to impossible. Luckily, there are plenty of ways to solve these kinds of problems iteratively: We are using the Runge-Kutta fourth-order method for solving the resulting differential equations. This method calculates the position and orientation by simulating small parts of the flight at a time in a specific pattern which leads to the total error of the simulated trajectory being proportional to the used timestep raised to the power of four. What this means in practice is that a result with a timestep size of 0.25s is approximately sixteen times as accurate as a simulation with a timestep of 0.5s, while only taking twice as long to execute.

All in all, this software offers us incredible flexibility while even being fast enough to allow for things like automated parameter tuning if we need it. This way, we can be sure that a lot of the things that can go wrong during flight have already been extensively tested before we even start our motors so that we can develop fast, efficient, and safe flight stabilization systems.

All in all, this software offers us incredible flexibility while even being fast enough to allow for things like automated parameter tuning if we need it. This way, we can be sure that a lot of the things that can go wrong during flight have already been extensively tested before we even start our motors so that we can develop fast, efficient, and safe flight stabilization systems.