CS452 - Real-Time Programming - Winter 2018

Lecture 19 - Acceleration/deceleration; Anthropomorphic Programming.

Public Service Annoucements

  1. Our exam has been provisionally scheduled for 09h00, Monday, 23 April. When the final exam schedule comes out we will select a date and time in class. I hope that will be Friday, 2 March, so come to class with your exam schedule that day.
  2. You can download data from the terminal, such as the track graph, by putting a file onto the terminal program's output.
  3. You can upload data to the terminal by sending its input to a file.
  4. First Train Control Milestone: Thursday 8 March.
  5. Calibration as a process
  6. Here is a situation that reveals latent bugs in your interaction with the train controller: reversing the train.
    1. You give a stop command and wait patiently until the train is completely stopped.
    2. You give a reverse command.
    3. You immediately give a speed command and the train behaves as though it didn't receive the reverse command.
    4. 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.

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.

Using Resources Effectively

The scarce resources

  1. Bandwidth to the train controller
  2. Use of the train itself

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

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.

  1. Squeeze every piece of information out of each measurement. For example
  • Allow the user (you) to adjust parameter values at the terminal. For example, This is a standard technique used, for example, when tuning games.

  • 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.

    1. Place the train on the track in the sort of location where you expect to make short moves.
    2. Give the train a speed n command, where n is big enough to get the train moving reliably.
    3. Wait t seconds.
    4. Give the train a speed 0 command.
    5. Measure how far the train travelled from its initial location to where it stops.
    6. 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.

    1. Position the train that distance ahead of a sensor.
    2. Read the time and give a speed n command.
    3. After t seconds give a speed 0 command.
    4. 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 pre-determined 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 qualitatively how the velocity changes.

    1. slowly at first
    2. increasing
    3. reaching a maximum, possibly for a non-zero time
    4. decreasing
    5. more and more slowly as the new velocity is approached

    How should we model the process of speed changes?

    The simplest possible model is a step change from the initial velocity to the final velocity. When should the change occur?

    How much does the train in the model fall behind the real train? It depends on what the real train is doing.

    Anthropomorphic Programming

    We all, even most programmers (!), have effective intuitions about human relations

    Tasks are independent entities

    Servers and Attendant Tasks

    Why do servers need attendant tasks?

    1. Proprietor with a Notifier

    Proprietor `owns' a service, which usually means a resource.


    1. Notifier is usually of higher priority than server
    2. The server buffers both clients and data from the notifier. In this implementation client and data buffering are duals of each other. Our server code should

    2. Using a Courier

    We can handle two interrupts coming very close together using a courier. Simplest is best, so we shouldn't go beyond a courier unless we expect more than two.

    Transmit Notifier Code

    Transmit Courier Code

    Transmit Proprietor Code


    This gets you through a bottleneck where at most than two events come too fast.

    Remember that all the calls provide error returns. You can/should use them for error recovery

    Another possible arrangement for task creation

    Another possible arrangement for initialization

    Distributed gating

    I am showing you collections of tasks implemented together because sets of related tasks is a level of organization above the individual task.

    E.g., the decision to add a courier requires revision of code within the group, but not outside it.

    Return to: