CS452 - Real-Time Programming - Spring 2017

Lecture 16 - Trains

Public Service Annoucements

  1. First train control demo is in the trains lab on Thursday 29 June.
  2. PDF documents containing mathematics.


The Train Project

You have been driving one train around the track under manual control. For your project you will drive several trains around the track under program control. Driving the train under manual control you know

The first thing you have to do, and probably the most difficult, is to know where the train is by getting input from the sensors through the train controller.

Terminology

Note. I try to be consistent in distinguishing between two closely related concepts: speed and velocity.

Velocity is controlled by changing the train's speed, BUT, the mapping between speed and velocity is not simple.

Important . Some of these effects matter; some don't. It's part of your task to find out which effects matter and which don't. (If you don't figure out which is which you will spend an unlimited amount of time.)


Note on precision

We are going to be doing arithmetic. Should we do it in fixed point, which requires thought, or floating point, which has the inconvenience of increased state to save, not to mention compiler incompatibilities?

The biggest fixed point number is 2^31. How big is this? 2^10 = 10^3 = 1000, 2^30 = 10^9 = 1 000 000 000, 2^31 = 2 000 000 000.

Suppose that the smallest distance you care about is 0.1 mm. 2*10^9 of them is 200 000 metres or 200 Km, twice the distance to Toronto. At 50 cm/sec, about as fast as a train can go, a train travels about 1 m per minute, 60 m per hour, 1.5 km per day. It will take about 100 days, 30 months to travel 200 Km.

A successful final demo runs for 15 min, 0.25 of an hour, 0.01 of a day. You have a factor of 10 000 before you will start to see round-off error.

Furthermore, things can go wrong, such as

Avoiding such failures, or responding sensibly to them, is possible only if you have a `good enough' velocity calibration. (You get a perfect calibration only in the limit t->infinity, and the train you are calibrating falls over dead long before that.)

Failures like these also pollute your attempt to acquire reliable data for your calibration.


Train Properties

Where is a train?

There are two methods of knowing where you are:

  1. Being at a landmark: "I am at the big tree." I know that's true because I can see the big tree right beside me.
  2. Knowing where you started and how far, in what direction you have travelled: "I am three blocks north of the big tree." Calculating how far you have travelled is usually done by "dead reckoning".
For you project you choose landmarks You then know when the train is at a given landmark, and find a way -- most likely by integrating velocity -- to know how far it is past the landmark at any given time. If so, you need to know each train's velocity.


1. Calibrating Stopping Distance

The simplest objective:

Sequence of events

  1. Train triggers sensor n at t.
  2. Somewhat later, or possibly earlier, you ( = one of your tasks) send a command to the train controller asking it to poll the sensors. The time is t + t1. (t1 could be negative, but not too negative. How negative could it be?)
  3. You receive the reply from the train controller: sensor n has been triggered. The time is t + t1 + t2.
  4. You send the speed zero command. The time is t + t1 + t2 + t3.
  5. The train controller receives the command and forwards it to the train. The time is t + t1 + t2 + t3 + t4.
  6. Train receives the command and starts slowing down. The time is t + t1 + t2 + t3 + t4 + t5.
  7. The train stops at t + t1 + t2 + t3 + t4 + t5 + t6.
This gives you a lot of choice as to which of the possible measurements is the one you actually want. In the next lecture we will analyse this process in more detail.

Fiducial Marks

When you pull out the tape measure to measure y you need to know the two locations between which you are to measure.

You have just chosen a "fiducial mark", a location you can recognize so that you can make a comparable measurement the next time. Some landmarks, switches, for example, also require you to choose fiducial points carefully. (For many terms there were conflicting sets of track measurements because students were not picking fiducial marks consistently.)

Questions you need to answer

Comments

  1. The sequence of events above has a whole lot of small delays that get added together
  2. Knowing where you stop is very important when running the train on routes that require reversing
  3. Clearly, knowing when you stop is equally important.

This is very time-consuming!

Now make a table

Sensor 1 Sensor 2 ...
Speed 6
Speed 8
...

There are enough measurements in each cell of the table that you can estimate the random error. (Check with other groups to make certain that your error is not too big.)

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'. Like most academic dishonesty it simply doesn't work anyway.

Measuring the time to stop

In addition to the stopping distance you will want to know the time it takes to stop. A simple way to do so is

  1. Start a stopwatch when you give the stop command.
  2. Stop the stopwatch when you see that the train is stopped.

This might not be accurate enough for you. When you have calibrated the velocity and can stop anywhere on the track there's a better way.

  1. Give the stop command so that the train will stop with its pickup on a sensor, recording the time you when you give the command.
  2. When the sensor triggers, check the time.


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.

To do this successfully you have to be able to give the stop command anywhere on the track and know how long it will take the train to stop.

Knowing the Current Velocity

An implicit assumption you are making is that the future will closely resemble the past.

  1. You measure the time interval between two adjacent sensor reports.
  2. Knowing the distance between the sensors you calculate the velocity of the train 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.
  3. After many measurements you build a table

Using Resources Effectively

The most scarce resources

The two most plentiful resources

Any time you can use a plentiful resource to eliminate use of a scarce one you have a win. Two examples

  1. Squeeze all the functionality you can from every measurement. Every time you pass a sensor you can use the measurement to improve your velocity calibration.
  2. Use your time with the trains efficiently. There's a lot of setup time each time you start using the train. make as many measurements as you can to economize on set-up time effectively. make it possible to change program parameters from the terminal.

Practical Problems You Have to Solve

  1. The table is too big. (Actually both tables!)
  2. The values you measure vary randomly.

The values you measure vary systematically

3. Calibrating Acceleration and Deceleration

How Long does it Take to Stop?

Try the following exercise.

  1. Choose a sensor.
  2. Put the train on a course that will cross the sensor.
  3. Run the train up to a constant speed.
  4. Give the speed zero command at a location that stops the train with its contact on the sensor
  5. Calculate the time between when you gave the command and when the sensor triggered.
  6. Look for regularities.

Return to: