CS452 - Real-Time Programming - Spring 2012
Lecture 18 - Projects, Calibration III, Projects
Public Service Annoucements
- Exam: 9.00, August 8
- 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 and your preferred
track, but only if they are working, and either may not be working.
In that case we expect you to run your demo using another train
and/or another track. Be prepared!
Projects
1. Train style
Give trains roles and objectives. For example,
- Passenger train travels on a repetitive route meeting a schedule.
- Freight train travels to random destinations as fast as possible.
- Objective is to deliver as much freight as possible while keeping a
passenger train on time.
Another example,
- Trains are taxis.
- When a load appears they race to see if they can get it.
Another example,
- Trains are buses, which travel long routes from one place on the track
to another.
- At the end of the route is a scheduled trip to a different
location.
- When a bus is late arriving, the dispatcher must find another, unused
bus to leave at the scheduled leaving time.
2. Game style: AI
The track is a graph.
- Several different ways to choose vertices and edges
Many games are played on graphs
- Checkers, snakes & ladders, maze games, etc.
- Implement a graph game played on the track graph.
For example, watchmen and bandit.
- One train is the bandit, which tries to move from one hide-out to
another.
- The other trains are watchmen, who try to prevent the bandit from
getting to a hide-out once he is out in the open.
Another example, PAC man
- One train tries to cover as much track as possible.
- Other trains try to trap him so that he can't get reservations that
would allow him to keep moving.
3. Game style: interactive
In the games you play for pleasure, the user normally controls one or more
of the game entities.
- the bandit
- the trapping trains
Students often want to make an interactive project. It has been done
successfully in the past, but constructing a usable interface is a real
challenge
Calibration
1. Calibrating Stopping Distance
Hint. Interacting with other groups is useful to confirm
that you are on track. Of course, simply using another group's calibration
without saying so is `academic dishonesty'.
2. Calibrating Constant Velocity
At this point there are a few places on the track where you can stop with
a precision of a trainlength or better. However, suppose you want to reverse
direction at 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 start moving again.
How Much Time 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. (You know the stopping distance.).
- Calculate the time between when you gave the command and when the
sensor triggered.
- Look for regularities.
How Long does it Take the Train to Get up to Speed?
We call the time the train takes to get up to speed the acceleration
time. Finding the acceleration time is left as an exercise for the
reader.
Hint. The distance travelled from a standing start,
graphed as a function of time, is a straight line after the train reaches a
constant speed
Stage 3. Calibrating Acceleration and Deceleration
Thinking again about the problem of following a route that has
reverses.
- Reverses always occur in order to go a different direction at a
turn-out.
- You want to move as little beyond the switch as possible.
- Much of this manoeuvering is done at non-constant velocities.
Physics of Acceleration and Deceleration
Suppose a train is at x1=x(t1) with velocity v1=v(t1) at time t1, and we
want to get it go x2=x(t2) with velocity v2=v(t2) at time t2, and we want to
do it without exceeding any of the physical limits of the train.
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).
Velocity is deduced as the time derivative of x(t).
Our task is to create a physically possible path x(t) obeying such
constraints. To do so we must know how the train's velocity varies when its
speed is changed.
Our task is simplified because the velocity change function is
artificial,
- created by programmers just like us, and
- intended to imitate real trains.
We try to get into the programmer/designer's head and think their
thoughts
Teleportation
The simplest way of moving the train from one place to another.
- At time t teleport the train to x=x2, v=0.
- At time t2 increase the velocity to v2.
The first thing that we rule out is teleportation.
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:
- Is it possible? If the maximum velocity is vmax, and vmax < (x2 -
x1) / (t2 - t1), then it's impossible.
- How do you do it? If vmax > (x2 - x1) / (t2 - t1) then you might try
- Set v = (x2 - x1) / (t2 - t1) at t1
- Use your velocity calibration for this!
- Set v = 0 at t2.
Doesn't quite work.
- Because of acceleration you arrive at x2 after t2.
- Because of deceleration you don't stop until the stopping distance
beyond x2.
You could
- curse the inadequate train dynamics
- constrain vmax to be very small
- only accept requests for long in the future and be successful
because the acceleration and deceleration times are negligible.
But
- It's against the rules.
- You would be unsuccessful because of stalling on curves.
- Your project would only be interesting to trees and other
long-lived creatures.
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
- Accelerate at a from t1 to (t2 + t1) / 2
- Decelerate at -a from (t2 + t1) / 2 to t2
- Velocity is a*(t2-t1) / 2 - a*(t - (t2+t1)/2 )
Position is ...
- 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.,
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
- You can calculate position explicitly without having to do numerical
integration.
- Euler integration is unstable because of accumulating error.
- 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
- You need to check that the functional form you have is the right one,
or a right-enough one.
- For practical purposes small look-up tables may be perfectly
adequate.
Return to: