CS 452/652 Winter 2026 - Lecture 16

TC1 Demo Preparation

Mar 05, 2026 prev next

Design Suggestions

• build small independent control "circuits"
• localized location estimate vs. route-based location estimate
• deadlock avoidance
  • avoid circular send
  • avoid circular receive
  • do not mix Send() & Receive() in same task!
  • notwithstanding exception in proprietor pattern
• higher concurrency through more smaller tasks
• modularity → lower complexity through more smaller tasks?
• possible reference design: one design idea - not necessarily perfect!
  • early paper (accessible from UW IP addresses or via library proxy):
    Message passing between sequential processes: The reply primitive and the administrator concept

Demo

Basics

• participants: demo group, instructor, (teaching assistant)
• 20 minutes, 2 parts: not strictly necessary to use the whole time
• PDF/software submission deadline is the same for all groups, regardless of demo time
• technical robustness - anticipate failures
  • use headlights for direction, deadspot detection, etc!
  • use timeouts in software to detect problems
    • recover, halt, reset

Advice

• be on time, come prepared
• two students: 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 necessary
• consider your audience
  • instructor knows the assignment and the trains and the RPis
  • instructor does not know about your TC1 details, difficulties, trade-offs

Part 1 - scripted

• plan what you are going to do and who will do it
  • know what's working, and primarily 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 - 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?
• we want to understand:
  • setup/positioning of trains
  • tracking & stopping accuracy
  • possible destinations
  • flexibility and robustness of software
• increase chances of success
  • dry-run the demo
  • keep copy of working image

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 we fake sensor triggers?
  • can the train go to this or that location?
• be prepared to explain and justify your design
• all team members should be active answering questions and explaining

Part 3 - discussion & code review (optional, offline)

• be prepared to explain and justify your design and coding decisions

Next Steps

• TC2: multiple trains
• final project
  • proposal deadline to force thinking about the project: lightweight doc
  • projects need to involve train control - not just 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