CS452 F23 Lecture Notes
Lecture 12 - 24 Oct 2023

1. Other Measurement Issues

can work with 64-bit numbers
can represent distance between any two points on the track in mm (or smaller) with no problem
- similarly, no problem representing time in microseconds, which is tick time of RPi system timer
need to avoid floating point
- need to divide distance by time
  - if distances are mm, and times are ms, velocities in mm/ms may be small
    - e.g., 200mm distance, time is 50ms/60ms/70ms
      - velocities are 4, 3, 2 instead of 4, 3.33, 2.86
  - can correct by scaling, e.g. calulate (100*mm)/ms
    - velocities are 400, 333, 286 - more precision
  - essentially a fixed-point representation with implied scale

measurement
- how many speed levels to investigate?
- stopping from lower speed is more accurate
  - but determine minimum speed to avoid getting stuck
how much data can you feasibly collect
need to decide how to capture measurements
and how to incorporate them into your program

train/track behavior may change over time
will probably want to continuously compare predictions to reality
could optionally adjust velocity model on the fly, based on new measurements
how to balance newer and older measurements?
One technique: sliding measurement window
Another technique: Exponentially Weighted Moving Average
- \(c_i\): current estimate, \(n\): new measurement, \(a\): weighting factor
- \(c_{i+1} = c_i*(1-a) + n*a\)
- no need to store a window of samples
- impact of each measurment decays exponentially over time
Can you save dynamically calibrated model for next time??

acceleration is the derivative of velocity
reality of transition from velocity \(v_1\) to velocity \(v_2\)
- acceleration ramps up from zero, then back down to zero
simplified model: constant acceleration
experiment:
- two sensors, far enough apart
- train running at \(v_1\) when it reaches first sensor
- at first sensor, give command to change to velocity \(v_2\)
- measure time (\(t\)) to second sensor, distance \(d\) from first sensor
model:
- constant acceleration for unknown time \(t_x\) until train reaches velocity \(v_2\)
- velocity during the acceleration window is \(v_a = (v_1 + v_2)/2\)
- we know: \(v_a * t_x + v_2 * (t - t_x) = d\)
  - solve this for \(t_x\)
- acceleration is \((v_2 - v_1)/t_x\) - change in velocity per unit time

Option 1:
- send stop command when sensor is triggered
- measure stopping distance manually
Option 2:
- use two sensors
- send stop command after a delay \(t_x\) after triggering first sensor
  - if train passes second sensor, decrease \(t_x\) and try again
  - if train does not pass second sensor, increase \(t_x\) and try again
- Try to find \(t_x\) that causes train to stop right at the sensor
- If \(d\) is distance between sensors, and \(v\) the initial velocity of the train
  - stopping distance is \(d - v * t_x\)

place train a known distance from sensor, set speed, measure time to sensor triggered
special case of acceleration experiment, with \(v_1 = 0\)

course web page links to a directory of track data
track is represented as a graph with sensors, switches, and exits as nodes
each switch/sensor actually corresponds to a pair of nodes, one for each direction
- each node has a “reverse” link which points to its twin
consider track[0] and track[1], which represent the A1/A2 sensor
- after tripping A1, next node is track[103] (MR12), 231mm away
- after tripping A2, next node is track[133],(EX5) 504mm away
consider track[88] (BR5) and track[89] (MR5)
- going straight through BR5 leads to track[34] (C3), 239mm away
- going curve through BR5 leads to track[93] (MR7), 371mm away
- coming into MR5 leads to track[114] (BR18), 155mm away
For TC1, will need to find paths in this graph to route the train
- e.g., use Dijkstra algorithm for shortest path
- for routing, could use a smaller graph with only switches (no sensors)