ESA's GOCE satellite - © ESA
In this post I’m going to talk about the rational behind the approach taken to develop the control algorithm for the QinetiQ GOCE T5 ion thrusters (shown in an ESA representation to the left)
I (Micky Corbett) helped develop these thrusters to meet the mission needs…and in the process learned a lot about good engineering and science practice…and how you don’t just need common sense to succeed but an Engineering Common Sense.
The control of the ion thrusters on the GOCE satellite was an interesting challenge to say the least…
Each thruster had to operate in a thrust range of 1 to 20 mN (or the weight of a few sheets of A4 paper)…and within this range the system had to meet EACH and EVERY thrust step command that was issued…
And they were issued at 10 times a second…
For a minimum mission life of 18 months!
Not only was every thrust step to be met within 12 micro-Newtons (µN)…or to 0.063% of the full thrust range…but there were time and performance requirements on the trains of steps themselves…
In fact the only “easy part” if you could call it that was that the thruster just had to concern itself with 10 goes at meeting a thrust step and each step only needed to be within the range 12 to 250 µN.
Which means the engine control was running at 100 times a second…faster than most if not all jet engines!
Now I admit that if you aren’t a technical person, reading those last paragraphs will seem like complete Greek to you. I wrote them for the benefit of anyone who has some engineering leanings or experience…and I could have gone on and on!
The reason I wrote them is that this type of “rocket science” is very complicated, I must admit…and I wanted to demonstrate this…
But the irony is that the solutions to a lot of the challenges come when you learn to SIMPLIFY…
And simplify not only your thinking, but your design, your testing and your egotistical dreams!
Originally the idea for controlling the thruster was to primarily use one of the main inputs – the magnet current – that controlled the magnetic field in the plasma inside the thruster (BTW if you don’t know how ion thrusters work you can go check this page out about electric propulsion)
The idea was that the other inputs (gas flow and anode current) would be controlled at a much slower rate…so that effectively you throttle the engine with only one input…a bit like drving a car in a fixed gear in a fixed direction with nothing to change but speed by pressing or lifting your foot off the accelerator pedal…
This is a great idea in principle…but the mission needs soon morphed as happens in space projects, to be something more complicated.
When you add in that the original idea for controlling the thruster used equations and mathematical functions, the task of doing something MORE COMPLEX was starting to get far too costly and unachievable.
A simpler solution was needed
Before I joined QinetiQ I used to work on jet engine software. I’ll freely admit I was no aeronautical engineer so all the aerodynamic equations looked new to me.
But one lesson I learned was that for complex control it is often more effective (and takes less valuable computer processing time) to simplify as much as you can to literally, simple adding and substracting and “linear interpolation”. Or the maths used in straight lines.
The skill was to get enough real measurements of performance and distill this down into Look-Up Tables. These could be simple lists or huge arrays of data.
You used the data to approximate a complicated function, like a power law, and you did this by essentially linearly scaling the differences between data points.
Now what’s a linear scaling?
Well here’s an example:
Say I have a point in my look-up table made of 2 numbers. One number refers to an input the other an output.
So if the system reads in say airspeed, in the case of jet engines, I have a look-up table full of different airspeed points that come from test or theory…or both.
Each point has “reference” airspeed that has an associated output value…this could be an estimated parameter or simply a number used in a calculation that is itself only a step. It doesn’t really matter. The important factor is that you have these references.
So say point 1 is [airspeed = 10 m/s, output = 20 (some units)] and the next point along is [airspeed = 20 m/s, output = 40 (some units)].
That’s a simple look up table.
Okay the system measures an airspeed of 14 m/s…so what is the output?
Well you scale the difference between the output values by using the airspeed values and the actual airspeed. So in this case the output is the 1st point’s output value + 0.4 times the difference between output 1 and 2…or 20 + 0.4 * (40 – 20).
Which is 28.
Why 0.4 times?…well this is the ratio of (actual airspeed – airspeed 1) to the difference (airspeed 2 – airspeed 1).
If you draw it out on a graph you see that the maths is actually what you do to work out values of a point along the line between the reference points. Hence “linear interpolation”.
What is great about this method is that you can set up a whole series of logic tests to make sure that the data points you want are as close as possible to the conditions you need. So that when you interpolate, your error from theory or even real data is as small as you can reasonably make it.
Now…the interesting thing about look-up tables and linear interpolation is that it is almost TOO simple a method.
It’s ugly and simple…at least to the scientific or engineering eye used to grand sweeping functions with clusters of symbols, swirls and squiggles.
But sometimes ugly and simple can be POWERFUL and EFFECTIVE if you do it just right!
And ugly look up tables and simple linear interpolation came to be so effective for the GOCE thrusters that now I wouldn’t have it any other way when designing control systems…
The moral of this post is that it pays to forget the complicated intricate smart-looking maths for simpler functions and rules.
And with that I’ll leave you for now with the story about the GOCE ion thruster control! More to follow soon!