CS452 - Real-Time Programming - Winter 2017
Lecture 22b - Acceleration
Public Service Annoucements
-
Train Control I demo on Tuesday, 7 March.
-
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.
-
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.
-
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.
-
Make a video of the train accelerating
-
Measure the image timing
-
By putting a clock in the image
-
By counting frames
-
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
Return to: