× Overview The Robot Learning Hub Curriculum Safety For Schools Contact Sales
Safety

Open student development. Protected physical execution.

Students write and run real code across all 21 degrees of freedom. Every command is validated, queued, and approved by an instructor before it reaches a motor — and a physical emergency stop always sits underneath the software.

Motion Architecture

Every command passes through one protected path.

Student programs never talk to the motors directly. A single protected motion-control node is the only software layer permitted to send final commands to the servo controllers and base motor system.

Student program
Movement request
Validation & queue
Instructor approval
Protected motion-control node
Motor controllers
Robot movement

The motion-control node enforces (or is designed to enforce) joint limits, speed limits, movement-duration limits, safe sequencing, command timeouts, and rejection of malformed or impossible requests, and it respects emergency-stop state and instructor execution control at all times.

Valid joint names & angle limits

Every one of the 21 joints has a bounded safe range enforced before a command reaches a servo.

Speed & duration limits

Requested speeds and command durations are capped so motion stays predictable.

Command timeouts

A stalled or disconnected program cannot leave the robot mid-motion indefinitely.

Malformed request rejection

Out-of-range, impossible, or badly formed requests are rejected before execution.

All 21 programmable degrees of freedom — including the rotating base — are available to student programs. This is open student development with protected physical execution, not unrestricted motor access.

Validation & Queue

Students write real ROS 2 code. SwayForm checks and queues it first.

Before an instructor ever sees a submission, it runs through automated checks. Some are already part of the architecture; others are planned ahead of classroom release.

Python syntax validation
ROS 2 package build checks
Required dependency validation
Valid message structure
Supported node configuration
Valid joint names & angle bounds
Requested speed limits
Command-duration limits
Missing-file detection
Unsupported hardware access
Direct motor-controller access attempts

This is planned architecture for the checks above; it does not claim complete behavioral simulation or a guaranteed-safe program. Full detail on the queue and instructor review flow lives in the Learning Hub's Queue and Classroom Workflow pages.

Physical Safety

Layered safety, not just Ctrl+C.

Software validation is one layer. A classroom also needs a physical layer that works even if a program misbehaves.

Physical emergency stop / servo-power cutoff

Disables motor power without necessarily cutting power to the Raspberry Pi, where practical.

Under validation
Normal software stop

A standard, always-available stop command for ending a running program.

Implemented
Instructor execution control

Instructors can start, stop, and revoke approval for any running or queued program.

Implemented
Protected motion limits, timeouts & queue approval

See Motion Architecture and Validation & Queue above.

Implemented
Clearly marked pinch zones & supervised operation

Physical labeling and classroom supervision practices for finger, elbow, and shoulder pinch points.

Planned before classroom release
Safe startup & shutdown procedures

Documented power-on/power-off sequence to avoid unexpected motion.

Planned before classroom release

SwayForm does not claim a guaranteed-safe system. Robot operation should always be supervised, and instructors should review the full Robot Safety and Acceptable Use Policy before classroom use.

Questions about safety for your program?

Contact Sales