- Train tracking 2: deadline reminder
- Train tracking 2: demos
- Final exam

- System to be controlled
- Kinematic equation(s)
- Example: dx/dt = v(t)

- Time-dependent variables to be controlled
- Example: x(t), where we are at any moment
- x(t) = x(0) + \int_0^t v(t') dt'

- Control parameters
- Example: v(t), how fast we are going
- What if we are not able to change velocity instantaneously?

- Objectives (goals)
- Example: x(t) = v(t) = 0 at t = t0
- Commonly there is another objective such as minimizing the action: A = \int_0^t0 a(t')^2 dt'

- Control algorithm
- Example: v(t) = B(t-t0), with B chosen to realise the objective.
- x(t) = x(0) - B t (t-2 t0) / 2
- x(t0) = 0 => B = 2 x(0) / t0^2

- This solves the control problem, in theory

- Example: v(t) = B(t-t0), with B chosen to realise the objective.

We try to set the velocity as we wish,

- But, really v(t) = B(t - t0) + e(t)
- e(t) certainly is not known, and is often stochastic

How do we tame noise?

- Measure the real position, y(t), as often as we can
- Modify the velocity to reduce y(t) - x(t), the difference of the desired position from the real one.
- Example: v(t) = B(t-t0) - C(y(t) - x(t))

Suppose we can measure continuously and instantaneously. Then

- Set v(t) to calculated v(t) plus u(t), where
- u(t) = d(y(t) - x(t)) / dt = - C(y(t) - x(t))
- y(t) - x(t) ~ exp( -Ct ), and the difference is always being reduced.
- ( This equation was solved by hypothesizing a solution of the form exp( -at ) and solving for a.)

This looks pretty good, BUT

At time t, we really know y(t-D), where D is an inevitable time lag. Now what happens?

- u(t) = d(y(t) - x(t)) / dt = - C(y(t-D) - x(t)). This is pretty intractable.
- However, we should know the lag, or the average lag, or whatever, and we can solve
- d(y(t) - x(t)) / dt = - C(y(t-D) - x(t-D))
- Hypothesize a solution of the form exp( -zt ) and solve for z
- We use z because the solution might be complex
- If complex, the imaginary part oscillates and the real part is exponential.

- z = C exp( zD ) or log(z) = zD + log(C)
- What is the solution?
- Draw a graph of the real part.

- Sometimes there is no real solution
- We can always find a real solution by making C close enough to zero.
- You have experienced this in user interfaces, and
- sometimes you just can't slow down enough for the experience to be tolerable.

Change step 3 to

- d(y(t) - x(t)) / dt = - C(y(t-D) + Dv(t) - x(t)), which is close to
d(y(t) - x(t)) / dt = - C(y(t) - x(t))

- And we are back to a solution we like.

There are whole textbooks about different ways of doing predictive control; there are whole journals with articles describing new ways of doing predictive control.

Using predictive a little loosely, predictive control is what you are doing.

Use many co-operating, medium capability microCPUs to do a big job.

- An idea whose time has now come.

Problem is communication

- Big granularity (thick client: MS, Google)
- minimizes communication
- maximizes replicated data
- The Google approach: a problem nobody thought about.

- Small granularity
- minimizes replicated data
- maximizes communication
- Your system, like threading solutions, relies on shared memory for
communication
- The return of the FORTRAN common block
- How would you handle caching?

Comminication requires either

- a common bus, star topology
- system bus,
- LAN
- internet

- passing messages along
- emphasizes the switches

The transputer was an early, now vanished, example of the latter

- CPU, memory, switch on one chip
- chips connected in an array
- presumably a run-time system decides where tasks will go in order to
- maximize CPU throughput
- minimize communication overhead

- processes (tasks)
- may be named, take arguments and return values

- channels
- need a protocol (for type safety)
- must be named

- time

- sequential
- conditional
- if/then
- selection by case

- looping
- without test/break
- with test/break

- parallel
- initiated when the keyword PAR occurs.

- alternation
- guarded alternatives
- if more than one guard is true then select at random
- can be prioritized

- input
channel ? variable

- variable type must match protocol
- real-world hardware acknowledged by the anarchic protocol
- blocks when channel is empty

- output
channel ! value // the value of a variable or the result of an procedure

- variable type must match protocol
- blocks until an input process accepts the data

- input & output provide synchronization
- similar to sockets except for output blocking

- timer returns time as channel input
clock ? now

`AFTER`

can be used to combine timesIF now AFTER yesterday THEN

`AFTER`

can make timer input blockingclock ? AFTER tomorrow

You can write a type-safe server, BUT

- all possible clients must be known at compile time.

Program structure is more static than is allowed in your system.

This might be a good thing.

Return to: