CS452 - Real-Time Programming - Winter 2016
Lecture 23 - Giving a Demo
Public Service Annoucements
-
Train Control I demo on Friday, 11 March.
-
The exam will start at 12.30, April 19, 2016 and finish at 15.00, 20
April 2016.
-
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:
-
stopping distance,
-
velocity at constant speed,
-
stopping time,
-
short moves, and
-
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.
-
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.
Sensor Attribution
To accomplish the first milestone you sorted sensor responses
from the train controller into two categories:
-
ones caused by a train, and
-
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.
-
Make sure that you really have the train finding the shortest
route using only one train.
-
Make sure that you can route around one or more obstacles by
manually removing an edge from the graph.
-
Drive a second train to some point; make sure that you route
around it automatically.
-
Let the second train move in a simple way; make sure that you
can route around.
-
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.
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.
Don't leave dead air.
-
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
-
While setting up the next part, the talking partner
explains what we are going to see.
-
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 do the train motions say about your calibration progress?
-
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.
Return to: