Learning Hub/Getting Started

Getting Started

SwayForm is built around the idea that robotics makes more sense when students can see code turn into physical motion. This page covers what the platform teaches, how students use the hub day to day, and how the files are organized.

What SwayForm Teaches

Programming through robot behavior. Students use Python to define poses, trigger motions, adjust timing, and create behavior sequences — code that moves a physical system, not just a terminal.

ROS 2-style system thinking. The hub introduces nodes, topics, publishers, subscribers, services, launch files, and motion commands through SwayForm examples, not abstract definitions.

Motion and safe control. Robot joints cannot be commanded randomly. Every motion respects safe limits, timing, physical spacing, and the difference between smooth and unsafe movement.

Vision and interaction. SwayForm uses a RealSense camera for demos and labs that connect perception to behavior — simple user detection and target zones, without pretending the robot has perfect human-level understanding.

Debugging real systems. Students learn to read terminal output, check whether a process is running, source a workspace, stop a motion safely, and understand why hardware may not behave exactly as expected.

Key idea

SwayForm teaches robotics as a connected system: code, motion, sensors, timing, safety, and debugging all working together.

How Students Use This Hub

The Learning Hub is meant to be used directly by students. A teacher or club lead introduces the activity, but students should be able to open the hub, follow the steps, and understand what they are changing.

Open the Learning Hub. Students begin here instead of searching through the public website.

Connect to the robot. Students use VS Code and SSH to open the shared robot workspace from their laptop.

Run a provided demo. The first step is usually running a finished demo, such as Wave or Handshake.

Read the walkthrough. Each ready demo includes a code walkthrough explaining what the script does and what hardware is involved.

Modify a small part. Students change one controlled part of the code — a delay value, a target angle, a pose name.

Complete a guided lab. Labs ask students to edit code, test a result, answer a reflection question, and try an extension challenge.

Submit for execution. Finished code goes through the validation queue and instructor approval — see Classroom Workflow.

Important

Students should not be guessing randomly. The hub is designed to move them from running code, to reading code, to editing code, to designing behavior.

File Structure

SwayForm examples are organized so students can tell the difference between official demo programs, editable lab files, and their own project code.

Example demo folder

~/ros2_ws/src/swayform_demos/
├── wave_demo.py
├── handshake_demo.py
├── pick_and_place.py
├── rock_paper_scissors.py
└── interactive_exchange.py

Example lab folder

~/ros2_ws/src/swayform_labs/
├── lab_01_hello_motion.py
├── lab_02_servo_limits.py
├── lab_03_gesture_sequence.py
├── lab_04_head_tracking.py
├── lab_05_button_motion.py
├── lab_06_realsense_detection.py
├── lab_07_hand_pose_timing.py
├── lab_08_base_rotation.py
├── lab_09_motion_locking.py
└── lab_10_mini_demo_challenge.py

Student-authored work lives in a separately named project folder created with the SwayForm project tool — see Student Projects.

Recommended editing rule

Students should not rewrite official demos during the first session. Run the demo first, read the code, then copy the important idea into a lab file or a new student project.

← Hub Home Classroom Workflow →