CS452 - Real-Time Programming - Fall 2011

Lecture 24 - Calibration III

Public Service Annoucements

1. Information session on graduate studies: Tuesday, 8 November, 2011 at 16.30 in MC 2065
2. First train control demo: 15 November, 2011.
3. Final exam: Friday, 10 December, 2011, 10.30 to Saturday, 11 December, 2011.

Stage 1. Calibrating Stopping Distance

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

This is really a lecture about reverse engineering. Reverse engineering amounts to

• Hypothesize
• Test
• Test again

Making effective hypotheses is the key. How do we do it?

We pull together all the things we know about a system, from all sources. For example,

• Disconuities are what breaks things.
• Discontinuities amount to infinities in derivatives
• A discontinuity in acceleration amounts to a discontinuity in force.
  • When does this occur?
• Programmers created the acceleration function to mimic real trains
  • They will mimic real trains as well as they can,
  • but only provided that it's not too much work.

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