# Lecture 22b - Acceleration

## Public Service Annoucements

1. Train Control I demo on Tuesday, 7 March.
2. The exam will start at 12.30 on 6 April, 2017, and end at 20 April, 2017.
• The exam will be made available as a pdf on the class web pages.
• The exam answer should be a pdf e-mailed to me before the end time of the exam.
• Questions about the content of the exam may be asked from 12.30 until 15.30 on 6 April, so it's a good idea to read through the exam immediately when it is available.
• Questions may be sent to me by e-mail or posted to the newsgroup, uw.cs.cs452.
• All questions will be answered on the newsgroup so that all students have exactly the same information about the exam.

# Acceleration

Our demos yesterday showed us that most students have noticed that their estimates of position have large errors when trains are accelerating. This lecture describes several approaches to calibrating acceleration and deceleration that go beyond short moves.

The methods are only sketched in and most of the focus is on problems that can occur. That's because you are left pretty much on your own. There's not much commonality in approaches that have worked well in the past.

## Measurement

### On-line

Only one way to do it: using the sensors. The example uses a single group of sensors many times, but it's not the only way.

1. Accelerate the train through a sequence of sensors
• Result is a set of observations (xn, tn).
• Time measured with respect to the start of acceleration.
2. Do it again with an offset, and again, ...
• Result is a set of observations (xn + offset, tn).
• Time measured with respect to the start of acceleration.
Going through sensors while accelerating happens every time the train accelerates, which means every time it changes speed. That should make you think about what you can do dynamically.

### Off-line

Many ways to do it, most using one or more video cameras. You may have noticed that there is a video camera hanging from the ceiling over track A. It is accessible from the PC that provides the terminal window.

1. Make a video of the train accelerating
2. Measure the image timing
• By putting a clock in the image
• By counting frames
3. Measure the image geometry
• By putting a scale in the the image.
• By counting pixels, relying on the camera geometry
Strong possibility that there are systematic (or even random) distortions in the video.
• Camera images, especially ones from inexpensive cameras, undergo extensive image processing prior to being recorded in the camera memory. This image processing is NOT done to enhance precision, but to reduce the number of bytes is the image (lossy compression) while making the image look good to the human visual system, which has many measurement-hostile properties. A student one term succeeded in using three cameras and triangulating to establish position, but left no trace as to how it was done.
• After you get the video from the camera you do things like separating the video into frames for measurement.
• You are mostly clever enough not to "waste" your time measuring by eye, but will use something like OpenCV, which massages images, e.g. edge enhancement, in order to make its feature recognition work.
But there's not much you can do about any of this because all software, except the software you write from scratch, is full of junk you wouldn't put there if you were writing it from scratch.

## Modelling

The measurements are not much use on their own. We need an apparatus by which we can answer questions like, "I gave a speed 12 command so many ticks ago; where is the train now?" The problem is that the measurements, no matter how carefully made, are noisy. How can we reduce noise?

### Empirical

We have no idea why the train behaves the way it does, but we believe it will do now the same thing that it did a while ago. We want to summarise a table of numbers about which we assume only a minimum, such as,

• the underlying reality is monotonic
• the underlying reality is smooth
There are many techniques for averaging, which is the way we treat random error. Is your data worth something complex?

### Theoretical

We have some idea of why the train behaves the way it does, which we allow to influence our interpretation of our measurements. We have two ideas that might influence the model we choose.

• Model trains are meant to resemble physical trains: jerk-free.
• Acceleration was programmed: it's simple.

There are two theoretical models that have been successful in the past

• constant acceleration, linear velocity, quadratic distance travelled
• constant jerk, linear acceleration, quadratic velocity, cubic distance travelled
Please remember that they have also been unsuccessful, so be prepared to massage them with care