CS452 - Real-Time Programming - Spring 2016
Lecture 17 - Projects, calibration II.
Public Service Annoucements
-
Exam schedule is out; 12.30, Tuesday, 2 August is the date
the registrar gave us. Please bring your exam schedule to
class on Friday, 17 June on which day we will choose the time
for our examination.
-
Final kernel assignment due in class, Friday, 17 June.
-
First Train control milestone, Tuesday, 28 June.
-
PDF documents containing mathematics.
The Train Project
The Ultimate Goal
The goal for your final project is to have several trains driving
continuously on the track, doing something interesting. "Interesting"
is defined to exclude undesirable things like collisions,
derailments and deadlock (no trains moving anywhere).
Three milestones
On your way to this goal you will pass three milestones, for each
of which you are expected to provide a demo to the instructor and
the TAs. All three milestone descriptions will be edited in the
immediate future. (As of today, 12 June, the first edit is
complete.)
-
Stop a train driving at constant speed at any requested point
on the track. Doing so requires a calibration model that knows
the stopping distance of the train, and the velocity it
travels. Both should be known for more than one speed.
-
Know where on the tracks a train is whether it is travelling at
constant velocity, accelerating or decelerating.
-
Drive two trains on the track knowing where both trains are at
all times. It should be possible to give trains independent
destinations at which they can arrive without colliding with
each other.
These demos are expected to get you doing the things that have
to be done for your project in the right order. For example,
there's no point in trying to know the locations of two trains
at once if you are unable to know the location of a single train.
Types of Projects
Most projects over the years have fallen into one of two types.
But about three years ago a third type emerged, which continues
to BE RARE. I am still waiting for a project of the fourth type.
-
Ordinary train projects. The trains are trains, or close
substitutes like busses or taxis, and they do things like moving
freight or passengers from one point to another. One recent
project had trains that "broke down" on the tracks and had to
be brought into a siding to be repaired.
-
Games played on a graph. Many games are played on a graph;
trains move on a graph. Making a game such as Pac-man, played
by trains, is another popular project. If you do such a project
be sure to make the game logic very simple, only complex
enough that the trains must interact. Complex game logic
usually means colliding trains.
-
Trains that do coordinated stunts. You can devise interesting
patterns created by the coordinated motions of trains. Be
certain that you discuss such a project with the instructor,
because it's easy to make a choice that's impossible, or even
worse trivial, to implement.
-
And, of course, anything a train can do, such as this, is
interesting if you can recreate it in the trains lab.
Calibration
Calibration is hard. The essence of its hardness is the inevitability of uncertainty
in
-
how to interpret a sensor reading, and
-
what happens when you issue a command to the train.
Measurements
Getting a sensor report indicating a sensor hit occurs at the end
of a process requiring two sensor readings. On the first reading
the sensor has not yet set; on the second reading the sensor has
set. Here is the sequence in detail
-
Request leaves user code.
-
Final byte of request accepted by train controller.
-
Train controller gets sensor values, sensor bit is unset.
-
Final byte of sensor report arrives at ARM.
-
Sensor report is time-stamped, t0.
-
Sensor report arrives at user code.
-
Second request leaves user code.
-
Final byte of second request accepted by train controller.
-
Train controller gets sensor values, sensor bit is set.
-
Final byte of second sensor report arrives at ARM.
-
Second sensor report is time-stamped, t1.
-
Second sensor report arrives at user code.
The sensor was hit between step 3 and step 9. The application
gets two times, t0 and t1. What should the the application conclude?
We will work this out in class, based on one thing we can measure
fairly precisely and several things we can estimate quite precisely.
Commands
Once we know where a train is and how fast it's travelling we can
calculate when we want things to happen in the train set, such
as a change in a train's speed or the change in direction of a
switch. In doing so we need to take into account transaction lag,
the time between when user code issues the command and the time
when the train or the switch carries out the command. The sequence
is more simple than with sensors.
-
Command leaves user code.
-
Final byte of command accepted by train controller.
-
Command received by train or switch.
Other complications
Velocity is controlled by changing the train's speed, BUT, the
mapping between speed and velocity is not simple.
-
Velocity changes are not instantaneous.
-
After the speed is changed the train's velocity changes gradually:
whether increasing or decreasing.
- `Tricks' that make the train stop instantly are not acceptable
because they wear out the trains.
- The velocity decreases when travelling over turn outs or around curves.
- The smaller the radius of curvature the slower the velocity.
-
Different locomotives travel at different velocities when set to the
same speed.
- Velocity of a given locomotive decreases over time
- As the track gets dirty.
- As the time since the locomotive's last lubrication increases
- As the locomotive gradually wears out
Important
.
Some of these effects matter; some don't. It's part of your task
to find out which effects matter and which don't. (If you don't
figure out which is which you will spend an unlimited amount of
time.)
Furthermore, things can go wrong, such as
-
A turn-out switches while a locomotive is on top of it.
- You need to estimate where the train will be when the turn-out
switches in order to know if it is safe to execute a switch
command
-
Locomotives run off the ends of sidings.
-
You need to know how far a train will travel between when you give
the stop command and when the train stops.
-
Locomotives stall because they pass over difficult parts of the track
too slowly. Why?
-
Friction increases when a train is on curved track.
-
The pickup lifts as the train travels over a sensor.
-
Sensors fail to trigger, or trigger in the absence of a locomotive
- You need to know when you expect the sensor to be triggered if you
are to know that it has not been triggered.
Avoiding such failures, or responding sensibly to them, is possible
only if you have a `good enough' velocity calibration. (You get
a perfect calibration only in the limit t->infinity, and the
train you are calibrating falls over dead long before that.)
Such failures like these also pollute your attempt to acquire
reliable data for your calibration.
1. Calibrating Stopping Distance
Being able to stop the train at a specific point is a very good
warm-up exercise. The easiest case is to stop the train immediately
after getting a sensor report. Here's what happens.
The sensor report reaches user code.
-
The stop command leaves user code.
-
The final byte of the stop command arrives at the train controller.
-
The train receives the stop command, and starts stopping.
-
The train stops.
-
You measure the distance from the sensor to the fiducial mark
you have chosen. The distance you measure is the stopping
distance for that sensor and speed.
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?
- Or a different train, or different track condition, or ...
Comments
-
The sequence of events above has a whole lot of small delays that get
added together
-
Each one has a constant part and a random part. Try to use values
that are differences of measurements to eliminate the constant
parts.
-
Some delays can be eliminated a priori because they are extremely
small compared to other delays. The more you figure this out in
advance the less measurement you have to do.
-
Knowing where you stop is very important when running the train on
routes that require reversing
-
Why are reversing routes important?
-
Clearly, knowing when you stop is equally important.
This is very time-consuming!
Based on calibrations I have seen in previous terms you will find
substantial variation with speed setting and train, little variation
with sensor.
Hint. Interacting with other groups is useful to confirm that you
are on track. Of course, simply using another group's calibration,
with or without saying so, is `academic dishonesty'.
Measuring the time to stop
In addition to the stopping distance you will want to know the time
it takes to stop. A simple way to do so is
- Start a stopwatch when you give the stop command.
- Stop the stopwatch when you see that the train is stopped.
This might not be accurate enough for you. When you have calibrated
the velocity and can stop anywhere on the track there's a better
way.
- Give the stop command so that the train will stop with its
pickup on a sensor, recording the time you when you give the
command.
- When the sensor triggers, check the time.
2. Calibrating Constant Velocity
At this point there are a few places on the track where you can
stop with a precision of a train length or better. However, suppose
you want to stop not sitting on a switch.
- You want to be close to the switch, clear of the switch, and on the
right side of the switch when you stop.
- You want to know when the train has stopped because until then you
cannot give the command to throw the switch.
- You want to know when the switch-throwing is complete because until
then you cannot start the train running in reverse.
To do this successfully you have to be able to give the stop command
anywhere on the track.
Knowing the Current Velocity
An implicit assumption you are making is that the future will closely
resemble the past.
- You measure the time interval between two adjacent sensor reports.
- 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 .
- 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)
- But the variation in dt from measurement to measurement adds noise
to the measurement.
- 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
Using Resources Effectively
The most scarce resources
- Bandwidth to the train controller
-
Use of the train itself.
The two most plentiful resources
-
CPU
-
your problem solving ability.
Any time you can use a plentiful resource to eliminate use of a
scarce one you have a win. Two examples
-
Squeeze all the functionality you can from every measurement.
Every time you pass a sensor you can use the measurement to
improve your velocity calibration.
-
Use your time with the trains efficiently.
There's a lot of setup time each time you start using the train.
make as many measruements as you can to economize on set-up time
effectively. make it possible to change program parameters from
the terminal.
Practical Problems You Have to Solve
-
The table is too big. (Actually both tables!)
- You potentially need a ton of measurements
- 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.
How Long does it Take to Stop?
Try the following exercise.
- Choose a sensor.
- Put the train on a course that will cross the sensor.
- Run the train up to a constant speed.
- Give the speed zero command at a location that stops the train with its
contact on the sensor
- Calculate the time between when you gave the command and when the
sensor triggered.
-
Look for regularities. For example, the time to stop from a random point on the
track should be the same as the time to stop you found when stopping immediately
after a sensor report.
Return to: