CS452 - Real-Time Programming - Fall 2011

Lecture 22 - Trains

Public Service Annoucements

1. Saturday November 5, 11.00 to 13.00. Open house for high school students.
2. Information session on graduate studies: Tuesday, 8 November, 2011 at 16.30 in MC 2065
3. First train control demo: 15 November, 2011.
4. Final exam: Friday, 10 December, 2011, 10.30 to Saturday, 11 December, 2011.

Train Properties

A locomotive travels on the track at a given speed following the path created by directions of turn outs.

• As it travels it triggers sensors that give you feedback as to where it is.
• Actually, not quite where it is. There is a time lag.
  • Train triggers sensor at t: x(t) = Sn + 0 cm
  • Report of sensor is recorded (time-stamped) at t + dt. dt includes
    • interval between time of triggering and next sensor query
    • time for train controller to process query and return result
    • time in your application between receiving bytes from train controller and packaging bytes into a time stamped event

    You should be able to estimate each of these time intervals

  • At t + dt: x(t + dt) = Sn + dx
  • dx = \int_t^t+dt v(t') dt' ~= v(t) dt
  • In the event time-stamped at t + dt the train appears to be at Sn, but it is actually at Sn + v(t) dt
  • Does this matter?
    • How fast do trains go? Estimate 20 cm/sec.
    • If dt is 100 msec you are off by 2 cm.
    • Is 100 msec reasonable?

How do you know where the locomotive is?

• intermittently, at a sensor
• between sensors, dead reckoning, which means you need to know the train's velocity

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

• Velocity changes are not instantaneous.
  • After the speed is changed the train speeds up and slows down gradually.
  • `Tricks' that make the train stop instantly are not acceptable because they wear out the trains.
• The velocity decreases when travelling over turn outs or around curves.
  • The smaller the radius of curvature the slower the velocity.
• Different locomotives travel at different velocities when set to the same speed.
• Velocity of a given locomotive decreases over time
  • As the track gets dirty.
  • As the time since the locomotive's last lubrication increases

Important. Some of these effects matter; some don't. It's part of your task to find out which is which.

You will see things go wrong as you test your application. For example,

• A turn out switches while a locomotive is on top of it.
  • You need to estimate where the train will be when the switch changes in order to know if it is safe to throw the switch
• Locomotives run off the ends of sidings.
  • You need to know how far a train will travel between when you give the stop command and when the train stops.
• Locomotives stall because they pass over difficult parts of the track too slowly.
  • Why? Friction increases when a train is on curved track.
• Sensors fail to trigger, or trigger in the absence of a locomotive
  • You need to know when you expect the sensor to be triggered if you are to know that it has not been triggered.

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. Failures like these also pollute your attempt to acquire reliable data for your calibration. )

Factors that might effect a calibration.

In general the velocity of a locomotive may be a function of many variables

1. which locomotive it is
2. which speed is set
3. time since the last speed change
4. the velocity at which it was travelling before the last speed change
5. where it is on the track
   • possibly on what type of track it is on
6. how long since the track was cleaned
7. how long since the locomotive was lubricated

Important. Some of these effects are matter; some don't. It's part of your task to find out which is which.

Stage 1. Calibrating Stopping Distance

The simplest objective:

• know where the train stops when you give it a command to stop
• restrict the stop commands to just after the train passes a sensor
• only one train moving

Sequence of events

1. Train triggers sensor at t
   • train at Sn + 0 cm
2. Application receives report at t + dt1
3. You give command at t + dt1 + dt2
4. Train receives and executes command at t + dt1 + dt2 + dt3
5. Train slows and stops at t + dt1 + dt2 + dt3 + dt4
   • train at Sn + y cm
   • (You measure y with a tape measure.)

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?
• And all the other important ones in the list above. (Not all are important.)

This is very time-consuming!

• The only 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 it repeatedly. 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.

Now make a table

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 without saying so is `academic dishonesty'.

The Essence of Calibration

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
   • 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), which is the correct answer.
   • But the variation in dt from measurement to measurement adds noise to the measurement.
     • Variations are bigger when the processor is heavily loaded.
3. 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

The Problems You Have to Solve

1. The table is too big.
   • You need a ton of measurements
2. 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.

Stage 2. Calibrating Constant Velocity

An implicitly accepted fact about the world that is essential for calibration.

• The future will be like the past, which is obviously true. It will get light tomorrow morning. It will rain tomorrow.

As long as the future is sufficiently like the past, which it almost always is, calibrations work just fine.

But when it isn't, all bets are off. You need something different disaster recovery. There are two rules of disaster recovery.

1. Do no further harm.
2. Start from the beginning.

Back to Calibration

If the future is like the past, then knowing the future is easy: understand the past. Understanding the past is easy in theory, but hard work in practice.

In Theory

1. Measure
2. Measure
3. Measure
4. ...
5. Compile data into a useful form

In Practice

You need to figure out what to measure, and how much measurement to do.

1. Estimate the calibration precision required by your task. E.g., stop within one train length
   • Train length ~10 cm
   • Typical speed ~20 cm/sec: At least 0.5 sec precision needed for stop command issue
   • Estimate times to receive a sensor reading, issue a stop command, and have the train receive the command. Count only times greater than 0.05 seconds.
2. Estimate the error in typical measurements. E.g.
   • measurement of position versus measurement of velocity
3. Make some measurements to test your estimates.
4. As you make measurements continuously update the calibration.
   • A human you be looking continuously at the ongoing progress of the calibration, intervening to subtract and add measurements as his quantitative knowledge of train/track properties improves.

You need to figure out the best way to structure measurement results so that they can be efficiently applied in doing the task.

1. The set of tasks that provide calibration must
   • Accept new measurements
   • Update the calibration
   • Provide estimates based on the calibration
2. How much of this should be done on-line? How much off-line?
   • Is statistical learning using simulated annealing a good idea?
   • Static versus dynamic calibration

Where the Steel Hits the Rail

These comments are essentially random.

1. Measurement is costly.
   • The most congested resource, the train, generates at best one measurement every few seconds.
   • If your fellow students, not to mention the TAs and me, can tolerate five minutes of calibration you still get only about 100 measurements per train. (It's actually rare for students to calibrate more than one train at a time.)

   Therefore, you should never throw any data away.

   • You make measurement whenever you are driving trains on the track, regardless of the purpose of driving.
   • Note that, for milestone 1, we require you to have on the console screen, the estimate of the time when the most recent sensor would be triggered compared to the actual time that it was triggered. (This could just as easily, and probably more usefully
2. You are likely to use floating point.
   • However, it's not necessary. E.g.
     • Make distance measurements in 0.1 millimetre units. 2^32 times 0.1 mm = 400,000 metres.
     • Make time measurements in 10 millisecond units. 2^32 times 10 milliseconds = 40,000,000 seconds = 600,000 minutes = 10,000 hours = 400 days = 1 year.
   • There is a floating point co-processor, but
     • compiler maybes
     • context switch costs versus inter-task communication costs
   • Floating point is provided by the math library you were given using software
     • How does it's speed compare to the speed of the co-processor?
3. Each landmark requires a well-defined origin and clearances with respect to that origin. E.g.
   • E.g. turn-out

Return to:

• Bill Cowan's Fall 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page