You will be concerned with controlling the thrust from a vehicle's rocket motor, so
that it touches ... The fuel burn rate was a constant when at full thrust. Thus by ...
4 & 5 DBT Part B: The Landing Controller 4.1
Introduction
The second part of the Computing Design Build Test is more open-ended, and you will have to make your own design decisions and then implement them. You will be concerned with controlling the thrust from a vehicle’s rocket motor, so that it touches down smoothly on some planet, or can hover above it, as shown in Figure 4.1.
drag
thrust
upwards is +ve
v
h
(a)
mg
(b)
Figure 4.1: (a) The Phoenix approaching Mars. (b) Forces, etc. Upwards is positive. You will design and build two software components • a controller which repeatedly inputs the vehicle’s height, velocity and mass and outputs a sensible thrust to be generated by the rocket motor at that moment; and • a simulator of the vehicle dynamics, which inputs that thrust, along with current height, velocity and mass of the vehicle, and works out how the vehicle’ state changes over the next short time interval. The problem shares much with the rocket launcher problem. There your top level script used Euler’s method like this: % Initialize everything first , then for t =0 : dt : tend Rocket . a = getAcceleration (t , Rocket , ...) Rocket . h = Rocket . h + Rocket . v * dt ; Rocket . v = Rocket . v + Rocket . a * dt ; % store telemetry etc end 49
50
4. & 5 DBT PART B: THE LANDING CONTROLLER
You assumed that the thrust varied in a very simple way with time t — indeed, it was either full thrust or zero thrust. The fuel burn rate was a constant when at full thrust. Thus by supplying t and the Rocket structure to getAcceleration(), (i) you could find the current mass and thrust, (ii) you could work out the drag, and (iii) you could work out and return the acceleration. However, to achieve a smooth landing or to hover, the thrust must varies over time in a more complicated way. If everything was known ahead of time, you could write a differential equation and solve it in advance. However, in reality there are always uncertainties due to unmodelled and unpredictable disturbances — a suddenly down draught in the atmosphere, for example. You need to be able to recompute the required thrust from moment to moment.
4.1.1
Control
This is where automatic control comes in. A controller compares a system’s output with what you desire it to be, and alters the input into the system to correct the error. (Research into control forms is an important area in Information Engineering. You start learning about this seriously next year.) Figure 4.2 illustrates the idea. In a real system, the controller is most likely to be a piece of software running on a computer, but the controlled “plant” (the rocket vehicle) is the physical mechanism itself. The outputs from the mechanism are measured using sensors (altimeters, radar, star fixes, etc). Later in the course you get to control real mechanisms, but here you have to simulate the behaviour of the mechanism. In case this seems disappointing, it is what happens in “real” engineering design too.
Desired Outputs
Error
Controller
Thrust Demand
Rocket Vehicle (Simulator)
Actual Outputs position velocity acceleration fuel
Figure 4.2: The layout of controller and plant. The controller is nowadays almost always computerbased, but here you also simulate the plant in software.
4.2
Where to start?
You have learnt about structures in Matlab. The use of structures not only helps keep the number of parameters passed to functions to a minimum, but also helps us think about the important data entities or “objects” with which one must interact in software. Here three or four stand out, and it seems good practice to initialize them at the top of your top-level script or function.
4.2. WHERE TO START?
4.2.1
51
Vehicle Structure
The Vehicle structure contains some fixed attributes, but others that change over time. For example, % Initialize Vehicle structure Vehicle . fixedmass = 500; % kg Vehicle . fuelrateperN = 0.001; % kg / s / N Vehicle . dragcoeff = 1.0; Vehicle . crosssection = 12.0; % m ˆ2 ... etc ... % These are initial values for those that change Vehicle . fuelmass = 1500; % kg Vehicle . a = 0; % m/s/s Vehicle . v = -300; % m / s Vehicle . h = 3000; % m Vehicle . thrust = 0; % N ... etc ... In a real system, the fixed ones might be found by tests during manufacture, and the ones that change would be returned by sensors.
4.2.2
Simulator Structure
This structure holds quantities more related to the simulation and (perhaps) the simulation environment. Maybe the following is appropriate. % Initialize Simulator structure Simulator . t = 0.0; Simulator . dt = 0.1; Simulator . g = 9.81; % m / s ˆ2 Now you could stick these all these into the Vehicle structure — but now imagine that the Vehicle is replaced by the real mechanism. Quantity dt has no meaning for the real vehicle, so you might argue that it doesn’t belong in the Vehicle structure. Again you might argue you should have another structure Planet to hold g and, say, information about the atmosphere, and so on. Perhaps you could define corresponding information in structures called Earth and Mars, then have statements like Planet = Mars ; to run the simulator for martian conditions rather than earth conditions.
52
4. & 5 DBT PART B: THE LANDING CONTROLLER
4.2.3
The Controller Structure
The controller is sure to require some parameters in its code. Later you will see that one controller suggested has just two. Perhaps we will need different control models? Anyway, for the simple one % Initialize Controller structure Controller . vdesired = -0.5; % m / s downwards ( A Guess !) Controller . gain = 1.0; % ( A Guess !)
4.3
The simulation loop
Having initialized the various structures, you now wish to start a loop that involves advancing time. Something like for t = 0 : dt : tend ?* @ ! %% simulate ... end Unfortunately you do not know how long the landing will take, so the value of tend is a complete mystery! Instead, run the loop for as long as it takes using %% Keep simulating while above the ground while ( Vehicle . h ¿ 0) %% simulate ... end It makes sense for the statements in the body of the loop to follow the chain of actions apparent in feedback loop in Figure 4.2. First, given the existing information on the state of the vehicle, ask the controller to work out a thrust demand. Then allow that thrust to act over the time step, and update the vehicle’s state. while ( Vehicle . h ¿ 0) % ask the controller what would be a good thrust ... thrust = ge tT h ru s tF ro m Co n tr ol l er ( Vehicle , Controller , Simulator ); % imagine that time tstep has passed with that thrust Simulator . t = Simulator . t + Simulator . tstep ; % Update the Vehicle ’ s state using the suggest thrust Vehicle = updateVehicle ( thrust , Vehicle , Simulator ); end
4.3. THE SIMULATION LOOP
4.3.1
53
Something else for the loop: gather telemetry
You need to grow vectors of time, height, and so on, for plotting purposes. Why not have a Telemetry structure, with each member being a vector? After initializing the Vehicle and Simulator structures in the top-level script or function, you could initialize them of as vectors of length 1. For example: Telemetry . t Telemetry . h Telemetry . v Telemetry . thrust ... etc ...
= = = =
[ Simulator . t ]; [ Vehicle . h ]; [ Vehicle . v ]; [ Vehicle . thrust ];
and within the loop grow the vectors as while ( Vehicle . h ¿ 0) thrust = ge tT h ru s tF ro m Co n tr ol l er ( Vehicle , Controller , Simulator ); Simulator . t = Simulator . t + Simulator . tstep ; Vehicle = updateVehicle ( thrust , Vehicle , Simulator ); % Grow telemetry vectors ... Telemetry . t = [ Telemetry .t , Simulator . t ]; Telemetry . h = [ Telemetry .h , Vehicle . h ]; ... etc ... end % Finally , plot the telemetry PlotTelemetry ( Telemetry ); Now you have ideas for the overall design and top level script, it is time to DB&T.
4.4
Building a Simulator: Exercise Set 4a
You will design and write code to simulate the rocket lander vehicle in the vertical direction only. Use UPWARDS AS POSITIVE for displacement, velocity, acceleration, forces, etc, and ensure drag is in the opposite direction to v. REMEMBER that spending time DESIGNING ON PAPER before typing is a real timesaver. You can then type with purpose ... 1. Write your top-level script or function in lander.m, initializing the various structures, writing the while loop and completing the statements to gather telemetry. 2. Write the function thrust=getThrustFromController(...), putting it in its own .m file. Just to get things going, for now have it return some constant positive value, for example, thrust=5000.
54
4. & 5 DBT PART B: THE LANDING CONTROLLER
3. Start writing the updateVehicle() function in its own .m file. function
newV = updateVehicle ( thrust ,V , Sim )
Remember that thrust is the thrust suggested or “demanded” by the controller — your rocket might not be able to deliver it. For example, you might be out of fuel, or your rocket might have a limited thrust (a bit of research might suggest a sensible limit). For example, this snippet sets V.thrust according to a number of tests. function newV = updateVehicle ( thrust ,V , Sim ) %% Step 1: work out actual V . thrust if ( * Some condition involving V . fuelmass * ) V . thrust = 0; elseif ( * Some other condition you might want * ) V . thrust = sign ( thrust )* V . maxthrust ; else %% can do : -) V . thrust = thrust ; end %% Step 2: later ! You might allow the thrust to be both positive (upwards on the vehicle) and negative as there could be an output nozzle on top the vehicle. Or you might want to disallow negative thrust. 4. At this point in updateVehicle() you want to find the acceleration %% Step 2: work out acceleration V . a = getAcceleration (V , Sim ); %% Step 3: later ! Write a function a=getAcceleration(V,Sim) that returns the acceleration given the current values of mass, thrust, velocity and height. Notice that there is no desperate need to write a getMass() function, because it would merely look like function m = getMass ( V ) m = V . fixedmass + V . fuelmass ; but it probably useful to have a getDrag() function. Model the drag using Fd (t) = 0.5ρACd × |v (t)|v (t), but check the signs and chose sensible values for the cross-sectional area, the drag coefficient and atmospheric density. Perhaps allow ρ(h) later? 5. Now assume that V.thrust has been applied to the Vehicle for the last Sim.dt seconds. Use the output from getAcceleration() to update position and so on. %% Step 3: update everything that needs updating V.h = V . h + V . v * Sim . dt ; % and so on ! But don ’ t forget you have used fuel V . fuelmass = ... %% Step 4: later !
4.5. BUILDING THE CONTROLLER
55
6. At the end of updateVehicle(), make sure you write in %% Step 4: provide the return value newV = V ; and be ready to explain why this is required. 7. Last, complete the PlotTelemetry(Telemetry) function, showing Vehicle.a, .h, .v, .fuelmass, .thrust, and whatever you want. 8. Now run, and use the graphical output to check your simulation is behaving as expected. Change the constant thrust from the controller, the drag coefficient, and so on. Indeed you might want to plot the drag force too.
4.5
Building the Controller
You want now to control the velocity of the vehicle. Imagine we had in our mind’s eye that we wanted the vehicle to descend at some desired velocity — call it vd . The simplest thing we could do would be to set the rocket thrust to be proportional to the difference between our actual velocity v and our desired velocity. If the error is large and we want to slow down then we increase the thrust. You might write that the thrust F (t) at time t should be F (t) = k[vd − v (t)]
(4.1)
where k is a suitably chosen “gain” constant to be found by experiment. There is one slight problem here: when the velocity is correct (i.e vd = v ) the engine generates no thrust (F = 0) but the vehicle is still accelerating under gravity causing v to change. Now of course the effect of the weight won’t appear suddenly when vd = v , so the controller would achieve its goal, but it makes the effect of k less obvious. Instead, add constant term to offset the vehicle’s instantaneous weight m(t), as in F (t) = k[vd − v (t)] + m(t) ∗ g .
4.6
(4.2)
Building a Controller: Exercise Set 4b
1. Use equation 4.2 to implement getThrustFromController() which makes the vehicle hover at some positive height (but don’t specify the height yet). When the vehicle runs out of fuel it should crash. (You might need to revisit your updateVehicle code to make sure the requested thrust is only produced while fuel remains!) You’ll need to play around with your choice of the gain k. 2. Plot the velocity and height of the vehicle against time. 3. Plot the thrust verses time curve. Check that while hovering the required thrust continually decreases, and explain why it should.
56
4. & 5 DBT PART B: THE LANDING CONTROLLER
4. Modify the controller so that it brings the vehicle to a gentle landing. You’ll need to consider how to set the desired velocity as a function of vehicle height. 5. Consider the following: • How quickly can you bring the vehicle to the ground? Plot the (braking) acceleration of the vehicle in this case. Would the passengers be liquified? • How could you tuning the controller so that the passengers have the smoothest ride possible? What is the descent time? For both it might be useful to have a top level function which takes in the controller parameters.
4.7
Assessment 3
By early afternoon of your final session you should be ready to be assessed. In the final assessment you demonstrate your working code. Essential items the Demonstrators will expect to see are: 1. a tidy filestore with sensible filenames. 2. to see well commented and well structured code, using sensible variable names, with parameters initialized in one place and not set multiple times deep in the code, and so on. 3. the simulator and controller working together, driven by a top level script or function, to bring the vehicle to a smooth landing. 4. telemetry plotted which shows the vehicle landing without experiencing excessive (deathly) accelerations. Brains break at much more then 6g. Results (bad and good) are shown in Figures 4.3(a) and 4.3(b). 5. evidence that this is your own work. In addition, demonstrators will also look out for ingenuity, invention, and the unexpected.
4.7. ASSESSMENT 3
57
Height (m)
Exercise VI 4000 2000 0
Time to landing 18.00 s 0
2
4
6
8
10
12
14
16
18
0
2
4
6
8
10
12
14
16
18
−1
Vel (ms )
0 −500 −1000
−2
Acc (ms )
5000 0 −5000
Max acceleration 49.96 g 0
2
4
6
8
10
12
14
16
18
0
2
4
6
8
10
12
14
16
18
0
2
4
6
8
10
12
14
16
18
Mass (kg)
2000 1000
Thrust (kN)
0 5000 0 −5000
Time
(a) Height (m)
Exercise VI 4000 2000
Vel (ms−1)
0
Time to landing 32.90 s 0
5
10
15
20
25
30
35
0
5
10
15
20
25
30
35
0 −200
100
−2
Acc (ms )
−400
50 0
Max acceleration 8.19 g 0
5
10
15
20
25
30
35
0
5
10
15
20
25
30
35
0
5
10
15
20
25
30
35
Mass (kg)
2000 1500
Thrust (kN)
1000 200 0 −200
Time
(b) Figure 4.3: (a) A poorly designed landing controller. When the vehicle vehicle gets to within 1km of the surface it sets a desired velocity of 0.8∗hei ght. This causes the thruster to actually accelerate the vehicle. The maximum “g” will mash the inhabitants into the ceiling. (b) A safer landing. Occupants only have to tolerate +8g for a short while.
58
4.8
4. & 5 DBT PART B: THE LANDING CONTROLLER
OPTIONAL: Persistent Variables in Matlab
This section is optional and is not required for what remains of this practical - its put here because some of you may wish to use more advanced features of matlab. One thing to notice is that in the design suggested earlier is that the vehicle simulator takes the current vehicle state as an input and returns the new vehicle state. newVehicle = updateVehicle ( thrust , Vehicle , Simulator ) This is slightly strange because you should not have to tell an object its current state before you act on it. With this in mind it might be attractive to write the simulator such that calls like this worked. newVehicle = updateVehicle ( thrust , Simulator ) Note that you do not pass in the current Vehicle. Is their an advantage to doing this? It could be argued that the simulator is supposed to encapsulate the physics of the system. Thinking of it as a “black box”, it is elegant to have the simulator simply returning velocity , height mass etc with just control parameters as input. This design has what is called an “object oriented” (OO) flavour to it. The simulator is an object which encapsulates both model of the world and its state. A “functional approach” on the other hand (which is also a totally valid approach), might suggest handing previous states back into the simulator at each call. In this case the simulator only has a role of a function which operates on parameters. From an object oriented view point this represents a smearing/bleeding of the details of how the simulator works (i.e by adding small changes to previous values) into other areas of your code. To proceed with an OO bent, what we want is some way to have the simulator remember the state of the vehicle between calls. Matlab provides the perfect mechanism for this via the persistent key word. The example code in Listing 4.1 shows how to do this. The first time GetNewValue is called X is set to the empty matrix []. We check for this condition and set X to zero. It is then incremented and the function returns 1. But because X was declared as persistent the next time GetNewValue is called X = 1 and so the function returns 2 and the initialisation step is skipped. You could use this mechanism to save the vehicle state within the simulator function so it is available for use in successive function calls. Nice, perhaps, but not essential. Listing 4.1: The use of persistent variables in matlab. The value of X is remembered between function calls. In this example repeatedly calling this function will generate the sequence 1, 2, 3, 4etc. function Result = GetNewValue persistent X ; if ( isempty ( X )) X = 0; end ; X = X +1; Result = X ; END OF OPTION ON PERSISTENT VARIABLES DWM September 27, 2011
