CS452 - Real-Time Programming - Spring 2012

Lecture 18 - Projects, Calibration III, Projects

Public Service Annoucements

  1. Exam: 9.00, August 8
  2. First milestone.

Projects

1. Train style

Give trains roles and objectives. For example,

Another example,

Another example,

2. Game style: AI

The track is a graph.

Many games are played on graphs

For example, watchmen and bandit.

Another example, PAC man

3. Game style: interactive

In the games you play for pleasure, the user normally controls one or more of the game entities.

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.

How Much Time does it Take to Stop?

Try the following exercise.

  1. Choose a sensor.
  2. Put the train on a course that will cross the sensor.
  3. Run the train up to a constant speed.
  4. Give the speed zero command at a location that stops the train with its contact on the sensor. (You know the stopping distance.).
  5. Calculate the time between when you gave the command and when the sensor triggered.
  6. 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.

  1. Reverses always occur in order to go a different direction at a turn-out.
  2. You want to move as little beyond the switch as possible.
  3. 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,

  1. created by programmers just like us, and
  2. 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.

  1. At time t teleport the train to x=x2, v=0.
  2. 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

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:

  1. Is it possible? If the maximum velocity is vmax, and vmax < (x2 - x1) / (t2 - t1), then it's impossible.
  2. How do you do it? If vmax > (x2 - x1) / (t2 - t1) then you might try
    1. Set v = (x2 - x1) / (t2 - t1) at t1
      • Use your velocity calibration for this!
    2. Set v = 0 at t2.

    Doesn't quite work.

    You could

    1. curse the inadequate train dynamics
    2. constrain vmax to be very small
    3. only accept requests for long in the future and be successful because the acceleration and deceleration times are negligible.

    But

    1. It's against the rules.
    2. You would be unsuccessful because of stalling on curves.
    3. 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

  1. Accelerate at a from t1 to (t2 + t1) / 2
  2. Decelerate at -a from (t2 + t1) / 2 to t2
  3. At t2

But, what happens at t = t1, (t2 + t1) / 2, t2?

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

  1. You can calculate position explicitly without having to do numerical integration.
  2. You can calculate the parameters of a function with less measurement. How?

    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

  1. You need to check that the functional form you have is the right one, or a right-enough one.
  2. For practical purposes small look-up tables may be perfectly adequate.

Return to: