CS452 - Real-Time Programming - Fall 2011

Lecture 23 - Calibration II

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.

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

Stage 3. Calibrating Acceleration and Deceleration

Physics of Acceleration and Deceleration

At the core is a relation, (x, t), which is a space-time point. The relation says that as time passes a train takes up successive positions x(t).

Teleportation

The first thing that we rule out is teleportation.

• Why?

A train having infinite velocity is impossible in practice

• Leave to the physicists whether or not it is possible for a train to have infinite velocity in theory.

No teleportation means that x(t) must be continuous.

Constant Velocity

Suppose you have a train at (x1, t1) and you have to get it to (x2, t2).

Two questions:

1. Is it possible? If the maximum velocity is vmax, and vmax < (x2 - x1) / (t2 - t1), then it's impossible.
2. How do you do it? If vmax > (x2 - x1) / (t2 - t1) then you might try
   1. Set v = (x2 - x1) / (t2 - t1) at t1
      • Use your velocity calibration for this!
   2. Set v = 0 at t2.

   Doesn't quite work.

   1. Because of acceleration you arrive at x2 after t2.
   2. Because of deceleration you don't stop until the stopping distance beyond x2.

   You could

   • curse the inadequate train dynamics
   • put xmax down very slow
   • only accept requests for long in the future
   • and be successful because the acceleration and deceleration times are negligible.

   But

   1. It's against the rules, because
   2. Your project would only be interesting to trees, and
   3. You would be unsuccessful because of stalling on curves.

More Fundamental

Infinite acceleration is impossible because the train would be crushed, if not vaporized!

This is true both in theory and in practice.

Constant Acceleration/Deceleration

Intuitively a good idea to minimize acceleration

1. Accelerate at a from t1 to (t2 + t1) / 2
   • Velocity is a*(t-t1)

     Position is x1 + (1/2)*a*(t-t1)^2

2. Decelerate at -a from (t2 + t1) / 2 to t2
   • Velocity is a*(t2-t1) / 2 - a*(t - (t2+t1)/2 )

     Position is ...

3. At t2
   • Velocity is 0
   • Position is x1 + (1/8)*a*(t2 - t1) ^2, which should be x2.
   • Therefore choose a = (8 * (x2 - x1)) / (t2 - t1)^2

But, what happens at t = t1, (t2 + t1) / 2, t2?

• discontinuities in acceleration
• experienced as jerk, in fact, infinite jerk
• And you know from experience that when you jerk things hard enough they break. E.g.,
  • tooth
  • knuckle

Constant Jerk

Third order curve for position, second order for velocity, linear acceleration. We usually go one better, and try to minimize jerk over the whole journey.

Minimize Jerk

Acceleration/Deceleration is continuous

The result is a fourth order curve in position, third order in velocity, which is what you try to achieve when you drive.

Is it Worth Having an Explicit Function?

Benefits

1. You can calculate position explicitly without having to do numerical integration.
   • Euler integration is unstable because of accumulating error.
2. You can calculate the parameters of a function with less measurement. How?
   • Start at x = t = 0, which assumes that you get the same function regrardless of position on the track and time of day.
   • Check deceleration inverse of acceleration?
   • &c.

   The idea is that the person who programmed acceleration/deceleration into the train was lazy, so there's probably one basic function used over and over again

Drawbacks

1. You need to check that the functional form you have is the right one, or a right-enough one.
2. For practical purposes small look-up tables may be perfectly adequate.

Return to:

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