CS452  RealTime Programming  Winter 2017
Lecture 19  Acceleration/deceleration; Anthropomorphic Programming.
Public Service Annoucements

On Friday the 17th we decided that the final exam will start at
12.30 on Thursday 6 April, 12.30 and end on Friday 7 April at
15.00.

You can download data from the terminal, such as the track
graph, by putting a file onto the terminal program's output.

You can upload data to the terminal by sending its input to
a file.

First Train Control Milestone: Tuesday 7 March.

Calibration as a process

We make measurements and we check values we calculated in the
past against those measurements.

We revise as necessary. In some cases we revise our estimate
of the train's location, in others our estimates of its
operating parameters, in most cases both.

Here is a situation that reveals latent bugs in your interaction
with the train controller: reversing the train.

You give a stop command and wait patiently until the train is
completely stopped.

You give a reverse command.

You immediately give a speed command nd the train behaves as
though it didn't receive the reverse command.

What happened?
Calibration I
1. Calibrating Stopping Distance
It is important to know where the train is when it has stopped,
which may not be the same as your estimate. Why? (Hint. The train
will start again at the position where it stopped.) Therefore,
keep reading sensors while the train is stopping.

Once you have thought about acceleration and deceleration you will
have estimates of when you expect to cross those sensors.

Even without those estimates you will know if gross errors are
occurring.
2. Calibrating Constant Velocity
To stop the train at any point on the track you must be able to
give the stop command anywhere on the track. Knowing where you
are when not at a sensor is possible only if you know your velocity.
Calibrating Velocity
An implicit assumption you make 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.
Subtraction removes the systematic error. Calibration document
describes in detail how to analyze random error, concluding that
neglecting random error works just fine.

After many measurements you build a table. At its simplest
this table has speed as its key and velocity as its value. A
more comprehensive table would have a more complex key.

Use the table to determine the current velocity.

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

location = location of previous sensor + velocity * time interval

Correct your position every time you receive a sensor report.
Using Resources Effectively
The scarce resources

Bandwidth to the train controller

Use of the train itself
How to make the most of them. We give you a requirement that you
display on the terminal

the time you expect to hit the next sensor,

the time you actually hit the next sensor and the difference,

the difference converted to distance.
We find these numbers very useful in knowing how well your train is
following its calibration model. You should also use them in the same
way.
Here is a concrete way you can use those numbers, which will make
your demo improve as it runs, especially if your initial calibration
is approximate, which it will be if your favourite train has gone
to train heaven.

Squeeze every piece of information out of each measurement.
For example

You read the sensors to know where a train is by correcting
your dead reckoning.

Each time you detect a sensor you know the time spent
travelling since the previous sensor hit.

You can calculate the velocity and use the result to
update the speed/velocity table.

New velocity entry = a * new measurement + (1a)*old velocity entry
Allow the user (you) to adjust parameter values at the terminal.
For example,

You are likely to have some padding to make certain that
you give switch commands early enough that the train will
pass after switching is complete.

When you are testing to see if you have enough padding
and discover you have too little, you can try different
values without having to go through setting up the train
This is a standard technique used, for example, when tuning games.
Practical Problems You Have to Solve
 The table is too big.
 You potentially need a ton of measurements
 The values you measure vary randomly.
 Sometimes you need to average and estimate error.
How Long does it Take to Stop?
You need to know how long it takes the train to stop. Why? (You usually
assume that the train is at the stopping place before you give the
next command.) 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
pickup 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: short distances.
Trains often travel short distance, starting with the train
stopped, and finishing with it stopped. When doing so the train
spends its whole time either accelerating or decelerating. Your
constant speed calibration is useless because the train doesn't
travel at constant speed. Similarly your measured stopping
distances are not useful.
Creating a perfect calibration of the train's position while it
is accelerating is hard. But there is an easy and precise
calibration that covers most of the moves the train makes where
you need a good calibration. It's the subject of this section.
Most of the your train project can get away with ignoring
acceleration and deceleration. 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 during
the series of commands.
A procedure to calibrate short moves.
Write a small application that performs the following sequence
of actions.
 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
to where it stops.

You how far the train will travel for the chosen values of
n
and t
.
Experiment with different values of t
and n
until you have a reasonable set of distances you can travel.
You now know how far the train moves for a given sequence of
commands.

Position the train that distance ahead of a sensor.

Read the time and give a
speed n
command.

After
t
seconds give a speed 0
command.

When the train triggers the sensor read the time again.
The distance between the two readings is the time it takes to make
that short move.
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 many 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.
This gives the experimental data that we need to approimate
a model.

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?

If the train is changing to a higher speed, then the train
in the model travels more slowly than the accelerating real
train. The real train gets ahead of the train in the model.

When the step change occurs in the model, the train in the
model is travelling faster than the real train. The model
starts to catch up to reality.

The step change in the model is placed so that the train in
the model is at the same position as the real train when the
velocity change is complete.

Is the amount that the train in the model falls behind
acceptable? If it is not you need a more complex model.
How much does the train in the model fall behind the real train?
It depends on what the real train is doing.

Suppose the real train undergoes constant acceleration.

The velocity of the real train increases linearly; the step
in the model occurs at exactly the midpoint of the change.

Before the step, the real train travels faster than the model train by
(t  t0) * (v1  v0) / (t1  t0)

The distance the real train gets ahead is
(t  t0)^2 * (v1  v0) / (2 * (t1  t0))

The step occurs at t = t0 + (t1  t0) / 2 where the real train
is ahead by
(t1  t0) * (v1  v0) / 8

Whether this is good enough for your project depends on what
your project is.
Return to: