Classroom Workflow
Students write real ROS 2 code, but they never send commands straight to the motors. Every submission moves through the same protected path before the robot moves.
1. Lesson intro
→
2–4. Learning Hub + code
→
5–6. SSH + project
→
7–8. Submit + validate
→
9–10. Instructor review
→
11–14. Run + revise
The full sequence
1
The instructor introduces the lesson or objective.
2
Students open the free Learning Hub.
3
Students follow the lesson explanation and examples in a demo or lab.
4
Students connect to the Raspberry Pi through SSH using the shared student environment.
5
Students create a named ROS 2 project using the SwayForm project-creation tool.
6
The tool generates the appropriate folder structure and starter files.
7
Students modify a partially completed lab template, or write their own program.
8
Students submit their program to the SwayForm execution queue.
9
The system performs automated validation — syntax, build, and safety checks.
10
The instructor reviews the program and its source code.
11
The instructor approves or rejects the submission, with feedback if needed.
12
An approved program sends requests through the protected motion-control system.
13
The robot performs the approved behavior.
14
Students observe, debug, revise, and resubmit.
What this is not
A student does not press Run and immediately control the hardware. Nothing reaches a motor without passing through validation, the queue, and instructor approval first — see Safety for the full protected motion-control architecture.
Why the queue exists
Because the review step is real, instructors do not need to watch every keystroke. They review the source once, before it can move the robot, which keeps the classroom open for real experimentation without needing constant supervision of the code itself — physical supervision of the robot is still required, see Safety Notes.