- 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!

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.

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.

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

**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'.

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.

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.

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

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.

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

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.

- Why?

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.

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.

- Set v = (x2 - x1) / (t2 - t1) at t1

Infinite acceleration is impossible because the train would be crushed, if not vaporized!

This is true both in theory and in practice.

Intuitively a good idea to minimize acceleration

- Accelerate at a from t1 to (t2 + t1) / 2
- Velocity is a*(t-t1)
Position is x1 + (1/2)*a*(t-t1)^2

- Velocity is a*(t-t1)
- Decelerate at -a from (t2 + t1) / 2 to t2
- Velocity is a*(t2-t1) / 2 - a*(t - (t2+t1)/2 )
Position is ...

- Velocity is a*(t2-t1) / 2 - a*(t - (t2+t1)/2 )
- 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.,
- tooth
- knuckle

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.

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.

- 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

- 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: