CS452 F23 Lecture Notes
Lecture 14 - 07 Nov 2023

1. TC1 Demos

1.1. Basics

  • participants: demo group, instructor, possibly a TA
  • 30 minutes total, divided into two parts of about 15 minutes each
    • not necessary to use the whole time in each part
  • PDF/software submission deadline is the same for all groups (as specified in the assignment), regardless of what time your demo is

1.2. General Advice

  • be there on time, come prepared
  • for teams of two: one presenter, one operator
    • switch roles at some point
  • for each step of the demo
    • before: explain what is going to happen, and why
    • during: point out what to pay attention to
    • after: provide more details, if needed
  • consider your audience
    • instructor knows the assignment and the trains and the RPis
    • instructor does not know about your TC1 project, difficulties, trade-offs

1.3. Part 1 - scripted

  • plan what you are going to do and who will do it
    • know what’s working, and only demo working parts
    • explain what does not work
    • if necessary, show partial functionality using different programs
    • despite your best preparations, things might still go wrong…
  • you are in control \(\rightarrow\) stay in control!
    • get back in control if necessary
  • prepare to explain:
    • what does a particular part of the demo show?
    • where will the train go? why?
    • what is the operator doing at the terminal? show us!
    • what parts of the demo are done automatically vs. manually?
  • increase chances of success
    • dry-run the demo
    • keep copy of working image

1.4. Part 2 - unscripted

  • we might ask questions, such as
    • can you do this with another train?
    • can you do this on the other track?
    • can you do this at a different speed?
    • can the train go to this or that location?
    • can we fake sensor triggers?
  • be prepared to explain and justify your design
  • for teams, both team members should be active answering questions and explaining

2. TC2

  • assignment is available
    • multiple trains traveling to destinations concurrently
  • due date is Wed Nov 22nd, one day earlier than originally listed
  • discuss some issues (robustness, sensor attribution, collision avoidance) next week

3. Final Project

  • Proposals due Nov 16th (week from Thursday)
    • goals:
      • deadline to force thinking about the project
      • lightweight doc
  • Projects need to involve train control - can’t be pure RPi projects
  • Projects can make use of the console
  • Must be do-able in about 2 weeks
    • good to have basic goals and stretch goals
  • Example: luggage loop
    • trains travel around fixed loop
    • try to merge in as many trains as possible while maintaining speed, avoiding collisions
  • Other examples
    • Pursuit games?

4. Routing

4.1. Dijkstra’s Algorithm

  • Algorithm - form of breadth-first search
    • start with origin as the current node
    • update distance to all unvisited neighbors of current node
    • mark current node as visited
    • choose unvisited node with smallest distance as next current node and repeat
  • Idea: node distances are distance of shortest interior path (involving only visited nodes)

  • To route to a specific node, can stop once it is visited

    graph.png

    Figure 1: routing example

4.2. Applying a Routing Algorithm

  • Need to consider train direction:
    • different route lengths in different directions
      • compute two paths, one for each initial direction of train?
      • can also consider direction changes in mid-path
        • e.g, come into merge node on one path, leave on the other
  • nodes are paired in track dataset
    • one node or two when routing?

    • will paths include train reversals?

      TrainGraph.png

      Figure 2: Train Dataset Graph

  • Overlays?
    • choose a suitable representation for routing
    • Example 1: switches are the only choice point, so for routing consider a graph consisting only of switches
      • keep two nodes (branch and merge) for each switch
      • path specifies a direction (straight, curved) for each switch
      • handle mid-path reversals?
        • add path from merge node branch node is it paired with
    • Example 2: sensors are where you detect train, so route in sensor graph
      • edges labeled with switch settings necessary for routing to the next sensor
    • Example 3: sensor-bounded switch sets as nodes
      • incoming and outgoing edge per bounding switch
      • internal routing info tells how to get from any input to any output
      • may place nicely with TC2 (nodes can serve as reservable chunks)
  • Precomputation?
    • about 140 nodes in track graph \(\rightarrow\) about 20K paths (node pairs)
      • potentially less if graph structure is considered
    • flexibility - what if track changes, e.g., some segment is unavailable?
    • partial pre-computation?
    • examples:
      • precompute routes within switchs-set nodes
      • waypoint routing
        • choose waypoint
          • compute routes from everywhere to waypoint, waypoint to everywhere (\(n^2 \rightarrow 2n\))
        • too brittle, too much contention?
          • use more than one waypoint

Author: Ken Salem

Created: 2023-11-06 Mon 15:21