CS452 - Real-Time Programming - Spring 2011

Lecture 21 - Calibration

Pubilic Service Announcement

1. Exam: starts 09.00, Friday, 12 August, 2011; ends 11.30, Saturday, 13 August, 2011.
   Note. Correction from Lecture 20.
2. First milestone.
   • Route finding is part of this milestone only so that you can do things that show your calibration to be correct. For milestone 2 you will have to do route finding on track graphs with edges missing, so choose an approach to route finding that generalizes.
   • In the demo you can use your preferred train from among the working ones. But, your favourite train may not be working. In that case we expect you to run your demo using another train. Be prepared!

First Milestone

Simon and I had a long conversation about previous student experience with the first milestone. We propose to eliminate one requirement.

• Your program need not be robust against erroneous sensor reports or erroneous turn-out state.

Why the change?

• In previous terms many students handled these problems with methods that worked well for one train, but which did not generalize to multiple trains, and wasted much time down a dead-end path.
• The essence is that this particular form of robustness, when done for only one train, doesn't need to handle attributing sensor reports to trains, which is part of milestone 2. In the context of correct attribution, achieving robustness against sensor and turn-out errors is easy, and that's the best way to do it for milestone 2.

However, you are still expected to do sensor hit predictions, and that is now explicitly part of milestone 1, not just something we talk about in class.

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 not 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.
   • Turn-out.

Return to:

• Bill Cowan's lecture notes for CS452 in s11
• Bill Cowan's Spring 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page