CS452 - Real-Time Programming - Fall 2009

Lecture 28 - Control

Reminders

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

Feedback Control

Control Concepts

1. System to be controlled
   • Kinematic equation(s)
   • Example: dx/dt = v(t)
2. 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'
3. Control parameters
   • Example: v(t), how fast we are going
   • What if we are not able to change velocity instantaneously?
4. 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'
5. 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

Fundamental Problem is Noise

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?

1. Measure the real position, y(t), as often as we can
2. Modify the velocity to reduce y(t) - x(t), the difference of the desired position from the real one.
3. 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

There is always a Time Lag

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

1. u(t) = d(y(t) - x(t)) / dt = - C(y(t-D) - x(t)). This is pretty intractable.
2. However, we should know the lag, or the average lag, or whatever, and we can solve
3. d(y(t) - x(t)) / dt = - C(y(t-D) - x(t-D))
4. 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.
5. z = C exp( zD ) or log(z) = zD + log(C)
   • What is the solution?
   • Draw a graph of the real part.
6. 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.

The solution is Predictive Control

Change step 3 to

3. 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))

4. 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.

The Transputer: a Second Generation Offshoot

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

• An idea whose time has now come.
• Google

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

Occam 2

Basic idea

1. processes (tasks)
   • may be named, take arguments and return values
2. channels
   • need a protocol (for type safety)
   • must be named
3. time

Combining processes

1. sequential
2. conditional
   • if/then
   • selection by case
3. looping
   • without test/break
   • with test/break
4. parallel
   • initiated when the keyword PAR occurs.
5. alternation
   • guarded alternatives
   • if more than one guard is true then select at random
     • can be prioritized

Channels

1. input

   channel ? variable

   • variable type must match protocol
   • real-world hardware acknowledged by the anarchic protocol
   • blocks when channel is empty
2. 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
3. input & output provide synchronization
   • similar to sockets except for output blocking

Time

• timer returns time as channel input

  clock ? now

• AFTER can be used to combine times

  IF now AFTER yesterday THEN

• AFTER can make timer input blocking

  clock ? AFTER tomorrow

The Result

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:

• Bill Cowan's CS452 lecture note page for Fall 2009
• Bill Cowan's Fall 2009 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page