# Lecture 23 - Giving a Demo

## Public Service Annoucements

1. Train Control I demo on Friday, 11 March.
2. The exam will start at 12.30, April 19, 2016 and finish at 15.00, 20 April 2016.
3. By Friday you should be able to drive one train on the track, knowing exactly where it is.
• 'Exactly' means within a tolerance that you know.
Talking to students in the trains lab I have gotten the idea, rightly or wrongly, that many students are not trying to do the easy things first. In class I suggested something like the following order of development:
1. stopping distance,
2. velocity at constant speed,
3. stopping time,
4. short moves, and
5. acceleration and deceleration.
I suggested this order because train calibration seems to work best if you build you intuition slowly, starting with things that are quite simple.
4. Suppose you decided in advance that you want a train to travel at exactly 28 cm/sec.
• It is very unlikely that there is a speed at which the train travels that velocity.
• It is almost certain that there is a closest speed above 28 cm/sec, Sa, and a closest speed below, Sb.
• Obviously you want the train to travel at Sa some of the time and at Sb some of the time. How much of each?
• If the velocity you want is, V, and the calibrated velocities for Sa and Sb are Va and Vb respectively, you might try
(1 - x)*Sa + x*Sb with x = (V - Va) / (Vb - Va).
• Naturally, this will require a little tuning.
• You might try something like the short moves method.
• You might experiment with the granularity of changing from one speed to another.
• Dynamic tuning is also possible.
• Each time you hit a sensor you get a measurement of V.
• From that you can calculate a new value of x, x-new.
• Then update x by x = (1 - a)*x + a*x-new.
A similar approach can be used to have one train follow another at a specific distance.
• There is a relationship between the time required for a sensor poll and the minimum distance at which the leading and following trains never collide.

# Multi-Train Control

By the next milestone you will be able to control two trains at the same time.

To accomplish the first milestone you sorted sensor responses from the train controller into two categories:

1. ones caused by a train, and
2. ones you ignored.
For the next milestone you split the first case into two: ones caused by train 1, and ones caused by train 2. In other words, Which train triggered which sensor?
• As long as the trains are sufficiently far apart this is not too hard.
• What is the meaning of `sufficiently' in practice?
• Sensor attribution must function correctly in the face of single failures,
• of sensors, or
• of turn-outs.

One way of doing this is to plan ahead.

• I expect the train to pass sensor X at time T, with a margin for error of 2\DeltaT.
• T comes from your velocity calibration: T = X/v
• \DeltaT also comes from the noise in my velocity calibration, and may not be symmetrical around T.
• That means that I expect the sensor
• Not to have been triggered before T - \DeltaT
• To have been triggered before T + \DeltaT
• For each of these normal things you should have things ready to do if they don't occur.

#### Communication bandwidth to train controller

This is the scarcest resource.

The symptom that you are trying to use it too much is getting a lot of time-outs for events that actually occurred. Switches switching too late is another symptom.

• The usual cause is buffers filling in a serial server.
• If your programme is requesting sensor reports faster that the train controller can provide them then the time between asking for a report and getting the corresponding report lengthens monotonically. Growing buffers and queues in servers is an early warning of performance problems.

## Route Finding and Following

You need to be able to route in the presence of obstacles. Some obstacles are stationary; others are moving: you should handle both properly. It's normally a good idea to start with stationary obstacles. Blocking one or more sections of track by a keyboard command, then asking for a route is probably the easiest place to start.

You need routes that reverse because they improve the performance of your project.

• As you add trains to your project, each train sees more blocked track when it asks for a route.
• The demo hits a limit when no train can find a route to its destination.
• Thus, more and shorter routes means more success in keeping your trains moving.
Please remember that it's not enough to find a route; you must also be able to drive a train along it. Driving over a route to a destination is not too hard, but it must be very robust because it's a basic capability required for driving two trains at once.

You can try a gradually harder approach.

1. Make sure that you really have the train finding the shortest route using only one train.
2. Make sure that you can route around one or more obstacles by manually removing an edge from the graph.
3. Drive a second train to some point; make sure that you route around it automatically.
4. Let the second train move in a simple way; make sure that you can route around.
5. Make two trains route simultaneously.
When you are testing hand or mentally calculate the shortest route before you start the train moving.

It doesn't matter what shortest-path algorithm you use, with one exception: the Floyd-Warshall algorithm does NOT work.

• Why?

When calculating the length of a path you might want to add some extra distance every time the train has to turn around. That is, you are probably most interested in the time a train takes getting to its destination, and reversing adds significant time.

## How to give a demo.

You are in charge; don't forget it.

#### General: stay in control.

• When nobody has anything to say the conversation has broken down and one feels ill at ease.
• Good manners tell the prof and the TAs to find something to say.
• Most likely they will ask a question, setting the demo in a direction that's not yours
• What's said will be about your demo, but it won't be what you were planning to say.

There are two of you.

• One does the driving, the other does the talking.
• It's not a bad idea to switch.
• What does the talking partner talk about
1. While setting up the next part, the talking partner explains what we are going to see.
2. While the next part is running, the talking partner tells what is happening, and why.
It may be helpful to imagine yourself into the brains of your audience. They haven't had happen to them the thrilling things that have happened to you in the previous two weeks, and are likely not to understand what you're saying if you don't start at the beginning.

Plan what you are going to do and who will do it.

• Think about how long each thing will take.
• Think about what you are going to say.

When you are planning what to say try thinking about these questions.

• What does this part of the demo show?
• Where will the trains go? Where are trains going? Why are they going there?
• What is your partner doing at the terminal? We see partners typing but are not usually told what they are typing, and why they are typing it.
• We often want to look at parts of the terminal display while the demo is running, and can do it more easily if you give us a tour.

Make sure that the things you are going to show actually work.

• Try them out using the train you are planning to use and with it starting where you intend to start it at the demo.
• Keep a copy of a working executable. Test carefully before overwriting it with the current best version.
• If your best version has partial functionality show that to us, say what you were hoping to achieve and what the problems were.
• Keep a copy of an executable that was working before you start the next debugging step. (This can profitably be said more than once!)

• We are not impressed when you ask for time to recompile an older version when the one that worked last night failed.
• Furthermore, the recompiled version is less guaranteed to work than the executable.
• It is common to have one program doing one thing and another program doing another, but have the integrated version not working. If so show us both and explain your plans.

#### How to get back in control

Sorted by amount of force applied, least first.

Inhale loudly.

• That's the sign that you have something to say. (You have never heard it in the past because the rules are burned in; now you will always hear it. In university we change your brain!)
• When the speaker pauses, quickly start speaking about what you will show next.
• Because you have a plan you know what you will show next.

Start setting up the next demo and explaining it.

• Wait for a short pause on the part of the person who is speaking, and start talking immediately. When you listen you hear works and phrases separately from one another. In reality, when we speak the sound is continuous. Most speakers, excepting a small -- if your life is blessed -- subset called bores, leave pauses with no sound now and then, which is an opening into which you can start speaking.
• Different people provide and expect pauses of different length. That's why you sometimes start talking at just the same time as another person. Good guys, a set to which the instructor and the TAs supposedly belong, readily yield when a student wants to speak.

If nothing else work talk over the person who is speaking. I will respond to you.

• "Talking over" means "talking at the same time, but louder". Normally, it's a bad idea to do this to a prof, but it's fine during a demo as long as you don't do it too much.

We exclude other students from your demo to remove one distraction that makes staying in charge harder.