CS452  RealTime Programming  Winter 2015
Lecture 19  Calibration II
Public Service Annoucements

Final exam: 16.00, 14 April, 2015.

First Train Control Demo, Wednesday, 11 March, 2015.

Don't throw away the implementation you did for kernel 4. Use
parts of it to get turnouts into alignment and get the train
going when doing the first train control demo.

Keep reading the sensors as the train slows to a stop, and use
to readings to update your model. You need this

because we will ask you where the train thinks it is when
stopping is complete, and

because the train must know where it is when you give it
the next command to drive.

We expect the train to find itself for milestone 2. But if it
can find itself correctly the tracking software should be able
to follow it as you drive it manually.

When you have your tracking working it should include a prediction
of the time each train expects to trigger the next sensor, and
how big the error is, measured in distance.
Calibration
1. Calibrating Stopping Distance
Questions you need to answer
 If you do this again, same sensor, same speed, will you get the same
answer?
 If you do this again, different sensor, same speed, will you get the
same answer?
 If you do this again, same sensor, different speed, will you get the
same answer?
 If you do this again, different sensor, different speed, will you get
the same answer?
 Or a different train, or different track condition, or ...
Comments
This is very timeconsuming!
 The simplest way to reduce the number of measurements is to eliminate
factors that are unimportant.
 The only way to know that a factor is always unimportant is to measure.
Developing the ability to estimate quickly, and to find the worst case
quickly is the main way of being smart in tasks like this one.
Based on calibrations I have seen in previous terms you will find
substantial variation with speed setting and train, little variation with
sensor.
Group across cells that have the `same' value. Maybe all have the same
value.
Hint. Interacting with other groups is useful to confirm that you are on
track. Of course, simply using another group's calibration, with or without
saying so, is `academic dishonesty'.
In previous terms some groups have given not a tr 0
, but instead
a tr 2
command. Then,

as the train slows they read the times at which they cross sensors,
<\li>

use the times to update the model, and

crawl the last few cm.
Measuring the time to stop
In addition to the stopping distance you will want to know the
time it takes to stop. Why might this be useful?

When you give the
tr 0
your application's model
of the state of the track know where the train will stop, but
does not know how long it will take the train to stop. The
next command should be given only after the train has stopped.
An obvious and simple way to do so is

Start a stopwatch when you give the stop command.

Stop the stopwatch when you see that the train is stopped.
At worst this will give you a worst case upper limit for very
conservative train driving.
A better method is available if you find that the stopping distance is
the same everywhere on the track. If so,

Measure a point one stopping distance before a sensor.

Give the
tr 0
command and measure the time when
the train passes that point.

When the sensor triggers, measure the time. The time difference
is the stopping time.
With a velocity calibration you can do the method above with
better precision.
2. Calibrating Constant Velocity
At this point there are a few places on the track where you can
stop with a precision of a train length or better. However, suppose
you want to stop not sitting on a switch.
 You want to be close to the switch, clear of the switch, and on the
right side of the switch when you stop.
 You want to know when the train has stopped because until then you
cannot give the command to throw the switch.
 You want to know when the switchthrowing is complete because until
then you cannot start the train running in reverse.
To do this successfully you have to be able to give the stop command
anywhere on the track.
An implicit assumption you are making is that the future will
closely resemble the past.

You measure the time interval between two adjacent sensor reports.

Knowing the distance between the sensors you calculate the
velocity of the train

velocity = distance / time interval

measured in cm / sec.
Note that on average the lag mentioned above  waiting for
sensor read, time in train controller, time in your system
before time stamp  is unimportant.

Sensor1 actually hit at t1.

You record (S1, t1 + dt) as the first event.

Sensor2 actually hit at t2

You record (S2, t2 + dt) as the second event

You compute the velocity as
(S2  S1) / (t2 + dt  (t1 + dt)) = (S2  S1) / (t2  t1)

But the variation in dt from measurement to measurement
adds noise to the measurement.

After many measurements you build a table

Use the table to determine the current velocity

Use the time since the last sensor report to calculate
the distance beyond the sensor

distance = velocity * time interval
Using Resources Effectively
The most scarce resources
 Bandwidth to the train controller
 Use of the train itself
The most plentiful resource
Any time you can use a plentiful resource to eliminate use of a
scarce one you have a win.
Practical Problems You Have to Solve
 The table is too big.
 You potentially need a ton of measurements
 The values you measure vary randomly.
 You need to average and estimate error.
The values you measure vary systematically
 For example, each time you measure the velocity estimate is slower,
presumably because the train is moving towards needing oiling.
 You need to make fewer measurements or use the measurement you make
more effectively.
How much time does it take to stop?
Try the following exercise.
 Choose a sensor.
 Put the train on a course that will cross the sensor.
 Run the train up to a constant speed.
 Give the speed zero command at a location that stops the train with its
contact on the sensor
 Calculate the time between when you gave the command and when the
sensor triggered.
 Look for regularities.
3. Calibrating Acceleration and Deceleration
How Long does it Take to Start and then Stop a Train? How Far does it go?
Most of the your train project can get away with ignoring
acceleration and decelleration. The one place you can't is when you
are doing a short move, giving a speed command followed by a stop
command before it gets up to speed. How far will the train go? How
long will it be before the train is fully stopped?
Short moves are common when the train is changing direction, which
you need to increase the number of possible paths from one point
to another.
The general idea is to give the train a carefully timed series
of commands knowing how far and for how long the train moves for
that series of commands.
Procedure to calibrate short moves.
 Place the train on the track in the sort of location where
you expect to make short moves.
 Give the train a "speed n" command, where n is big enough to
get the train moving reliably.
 Wait t seconds.
 Give the train a "speed 0" command.
 Measure how far the train travelled from its initial
location.
 Repeat for a range of times.
 Build a table that tells you how far the train will travel
for a given t.
 Build an inverse table given the time needed for a move of a
known distance.
Now that you know how far the train moves for a sequence of
commands you can start the train that distance short of a sensor
and measure the time between the first command and the triggering
of the sensor.
Together with knowing when and where the train will stop if given
the speed 0 command when running at a constant velocity, this
will provide most projects with all the calibration they need.
But you can do better.
4. Calibrating Acceleration and Deceleration: Doing Better
At this point you can do most of the things you will want to do
for your project. But some things can only be done from a standing
stop. It's more elegant to keep the train moving, speeding up
and slowing down as required. To do so it's necessary fully to
calibrate velocity during the act of accelerating and decelerating.
Keeping a train at a predetermined velocity, for example, requires
changing from one speed to another frequently.
To explain velocity changes we must introduce models. On the track
the train has a real location, so mant cm past sensor S. In your
program the train has a position, so many cm past sensor S'. The
model is linked to the real train by the calibration. Neither the
number of cm nor even the sensor is necessarily the same in the
model and in reality because no calibration is perfect. The performance
of a project, such as whether trains collide or not, depends on the
difference between the model and reality. The remainder of this
section is based on minimizing different measures of discrepancies
beteen a model and reality.
Back to real trains. When you give the train a command to change
speed, we know roughly how the velocity changes.
 slowly at first
 increasing
 reaching a maximum, possibly for a nonzero time
 decreasing
 more and more slowly as the new velocity is approached
How should we model the process of speed changes?

One might carefully measure the function that gives velocity
as a function of time or distance after the command is given.
How could one measure the instantaneous velocity?

Video the train driving beside a tape measure, calculating
mm/frame by differencing the positions in successive
frames.

Measure the time it takes for the train to travel at
constant speed from one sensor to another. Then give the
change speed command at varying distances before the
sensor and measure the differences in time to the sensor
trigger. Then construct a linear approximation.

Start with the crudest possible approximation, and improve
it as you require more precision. An example is below.
The simplest possible model is a step change from the initial
velocity to the final velocity. When should the change occur?
 When the velocity change begins? The model gets ahead of the train.
 When the velocity change ends? The model falls behind the train.

Somewhere in between? There is a time when the train gets
ahead of the model for a while, then falls behind exactly the
same amount so that at the end of the speed change the model
exactly matches the train position.
You can improve this by constructing a linear velocity change
model, a bilinear velocity change model, a quadratic velocity
change model, or whatever. Oral comments in class give possibly
helpful, possibly extraneous suggestions.
When you drive a train there are four things you care about, all
of which are functions of time. Particularly you care about the
effects of discontinuities in them.
 Location on the track, specified by x(t), usually anchored at the
previous sensor.
 A discontinuity is teleportation, which requires infinite
velocity.
 Trains do not provide infinite velocity (teleportation)
 Velocity along the track, specified by v(t) = x'(t).
 A discontinuity is an instantaneous change in velocity, which
requires an infinite force.
 Trains do not provide infinite force
 Acceleration, specified as a(t) = v'(t) = x''(t).
 A discontinuity in acceleration, which feels like a jerk. Think of
what it feels like when you are tied to a rope that is being pulled.
First the rope exerts no force on you, then suddenly there is a jerk
and you feel a force. Not nice.
 Do trains provide infinite jerk?
 Jerk, specified as j(t) = a'(t) = v''(t) = x'''(t)
 We can avoid discontinuities in acceleration by keeping jerk
constant.
 Thus, j'(t) = x''''(t) = 0.
Return to: