Reactive Rules, State Machines, and Behavior Trees

Descriptive transcript — Rules vs FSMs vs Behavior Trees This text-only path includes every spoken paragraph and the essential visual information from the full 2:23 v14 video. It can be read without sound, images, color perception, or video access. “Narrator” marks the actual speech; “Visual,” headings, timestamps, and bracketed notes are added descriptions, not speech. The owner-approved redesign is published on YouTube (https://www.youtube.com/watch?v=H411e_RK6DA). The original animated robot carries a parcel between a charging dock and a delivery bay. Small HumanoidHub branding is consistent throughout. Written status labels accompany colors; captions occupy their own band. Follow the scenes in order, and pause at the prediction before reading the answer. Scene 01 — Who gets control? Scene ID: hook Scene time: 00:00.000–00:09.131 Narrator: A delivery robot has a job to finish. Then its battery turns critical. Who gets control: delivery, or docking? Visual: A parcel-carrying robot travels toward the delivery bay. Its battery indicator changes to CRITICAL. Arrows point toward the parcel bay and toward the charging dock; a question mark marks the unresolved choice. Scene 02 — Same robot. New logic. Scene ID: map Scene time: 00:09.131–00:18.373 Narrator: Three designs can solve this problem: reactive rules, a finite state machine, or a behavior tree. Watch the same robot. Visual: Three choices are introduced one at a time: Rules (condition to response), State machine (mode, event, next mode), and Behavior tree (priority, check, act). The same robot continues along the route beneath them. Scene 03 — Two rules can compete Scene ID: rules Scene time: 00:18.373–00:30.784 Narrator: Rules say: if a parcel is waiting, deliver. If the battery is critical, dock. Both conditions can be true. Add an explicit priority: docking wins. Visual: Two requests appear: parcel waiting requests DELIVER; battery critical requests DOCK. Both feed a priority junction. DOCK WINS appears when the junction resolves the conflict, and the robot turns toward the dock. Scene 04 — Remember the mode Scene ID: fsm Scene time: 00:30.784–00:40.368 Narrator: A finite state machine remembers its current mode. This robot is Delivering. Only the arrows you define are legal transitions. Visual: Three states form a directed loop: Delivering to Docking on critical; Docking to Charging on docked; Charging to Delivering on charged. Delivering is the highlighted current mode while the robot travels toward the parcel bay. No Idle or Fault state appears in this video. Scene 05 — Change mode on purpose Scene ID: event Scene time: 00:40.368–00:51.781 Narrator: The critical-battery event moves it into Docking. Delivery exits; docking takes over. After charging, a defined transition can return it to Delivering. Visual: The event marker follows only the defined transition arrows. The robot stops delivery, turns toward the dock, and reaches the charging side. The battery indicator becomes healthy before the charged transition allows Delivering again. Charging time is compressed, not measured. Scene 06 — Try priorities in order Scene ID: tree Scene time: 00:51.781–01:01.997 Narrator: A behavior tree organizes checks and actions. This reactive selector tries the left, higher-priority branch before the delivery branch. Visual: A Reactive selector sits above a left Sequence and a right Deliver action. The Sequence contains Critical? followed by Dock. Numbered branches and moving tick markers show left-before-right evaluation; arrows carry the tick downward. Scene 07 — Check, then act Scene ID: sequence Scene time: 01:01.997–01:10.280 Narrator: Inside that branch, a sequence checks Battery critical, then runs Dock. A failed check prevents Dock from starting. Visual: Two alternative check outcomes are demonstrated separately. SUCCESS at Critical? permits Dock to return RUNNING. FAILURE at Critical? makes the Sequence fail and leaves Dock SKIPPED. This is a comparison of outcomes, not the battery reversing during a docking operation. Scene 08 — Healthy battery: deliver Scene ID: healthy Scene time: 01:10.280–01:20.416 Narrator: With a healthy battery, that branch fails, so Deliver runs. Yellow means Running: the action has started, but is not finished. Visual: Critical? returns FAILURE because the battery is healthy. Failure passes up the Sequence; the selector then ticks Deliver. Deliver and the selector show RUNNING, and the robot advances toward the parcel bay. The on-screen reminder says Running is not finished. Scene 09 — Critical battery: dock Scene ID: critical Scene time: 01:20.416–01:30.302 Narrator: Now the battery turns critical. On the next tick, the check succeeds. The delivery action must halt, and docking takes control. Visual: The battery becomes CRITICAL. On the next illustrated tick, Critical? reports SUCCESS; Deliver stays RUNNING until the halt is shown. Deliver then becomes HALTED, Dock becomes RUNNING, and the robot pauses and turns toward the dock. Tick propagation is deliberately slowed to make the handoff visible. Scene 10 — Can the action stop? Scene ID: preemption Scene time: 01:30.302–01:42.116 Narrator: That interruption is called preemption. It only works when the action returns control promptly and handles cancellation. A blocking action can freeze reevaluation. Visual: The upper control-flow diagram passes a marker from tick through action to return, representing prompt return and cancellation support. In contrast, a blocking-action bar stops the flow before another check, with the label NO RECHECK. This is execution flow, not a robot path. Scene 11 — Progress is not success Scene ID: recovery Scene time: 01:42.116–01:50.667 Narrator: Running is not Success. And retrying the same blocked route changes nothing; recovery must change something relevant. Visual: A moving robot has not yet reached its goal: RUNNING is not SUCCESS. A fixed obstacle blocks the original route. Repeating that same route is contrasted with a changed route around the obstacle. The example assumes unchanged obstacle and route information. Scene 12 — Different strengths Scene ID: compare Scene time: 01:50.667–02:03.113 Narrator: Which design should you choose? Rules for small responses. State machines for explicit modes. Behavior trees for reusable priorities. None is automatically safe. Visual: Three cards highlight different strengths: rules for small responses, state machines for explicit modes, and behavior trees for reusable priorities. A separate warning says no design is automatically safe. These are introductory choices, not a ranking or an exclusive taxonomy. Scene 13 — What makes it work? Scene ID: question Scene time: 02:03.113–02:13.523 Narrator: Your turn: the battery turns critical while Deliver is running. What two capabilities make this handoff work? Visual: A critical-battery robot is still labeled DELIVER IS RUNNING. Two unanswered boxes ask for the capabilities needed for handoff. After the question, the video pauses silently for 2.4 seconds before revealing the answer. [Silent retrieval pause: 02:11.123–02:13.523; 2.4 seconds.] Scene 14 — Recheck. Halt. Handoff. Scene ID: answer Scene time: 02:13.523–02:23.356 Narrator: Recheck priorities, and halt the running action. Trace those two steps in the EduQuest lab, then test your own design. Visual: Two answers appear in sequence: RECHECK PRIORITIES, then HALT RUNNING ACTION. The robot turns toward the dock. The closing prompt invites the learner to trace and test the mechanism in the EduQuest lab. Interpretation notes — not spoken This is an original mission-level example, not a ROS node lifecycle diagram or a safety-certified controller. The three-state FSM is specific to this video; the separate lesson board is a different worked example. The displayed reactive selector means `ReactiveFallback`, not ordinary `Fallback`. The inner `Sequence` resumes a RUNNING Dock without repeating the earlier successful battery check. Battery stays critical throughout this illustrated docking trace. A failed Dock can fall through to Deliver unless separate guards prevent it. Emergency stops and collision protection remain independent constraints. See Fallbacks (https://www.behaviortree.dev/docs/nodes-library/FallbackNode/), Sequences (https://www.behaviortree.dev/docs/nodes-library/SequenceNode/), and Asynchronous Actions (https://www.behaviortree.dev/docs/guides/asynchronous_nodes/) from BehaviorTree.CPP 4.8, verified September 6, 2026. Times mark scene boundaries rounded to milliseconds, not individual-word timing. The last rendered scene ends at 02:23.356; 30 fps encoding ends at 02:23.367. Status words accompany color: RUNNING is yellow, SUCCESS green, and FAILURE or HALTED red. Related learning Use the Core explanation on this page for the control-flow model and the Practice lab for an executable or paper trace. The Narrator paragraphs above reproduce the spoken narration; Visual paragraphs describe the animation. This format separates speech from added visual explanations following W3C WAI transcript guidance (https://www.w3.org/WAI/media/av/transcripts/); it is not a claim of complete WCAG conformance.