Hands-on session · Saturday, November 21, 2026 · 3:30–6:00 p.m. Mountain Time
First-session goal — Bring up the robot using its documented procedure, verify who controls it and how to stop it, then receive live sensor data in a program your team understands. If time and setup allow, observe one documented built-in action under operator control.
Read the first-session goal above and the operating rule. Bring one question about the robot and one idea for how it could help tell a story or welcome visitors at an Artrageous event.
Programming pair. Bring one tested laptop, its charger, an Ethernet cable, and an adapter if needed. Run the laptop tests and save one successful output line. Everyone else can skip software setup.
Success on Saturday. Save five live orientation readings and notes another student can follow. If the robot or connection is unavailable, rehearse a short welcome on the laptop. Press Go to play a prerecorded line, then verify that Abort clears any queued cues.
| Item | What to know before the session |
|---|---|
| Model | Unitree R1 EDU Standard (U1). Confirm the hardware label and firmware on arrival so you can choose the matching manual and examples. |
| Onboard development | The supplied specs list an expansion dock rated at 40 TOPS. Treat that as a compute rating. Verify the installed module, OS, and access before planning to run code onboard. Start with an external laptop. |
| Perception | A binocular camera is listed. Camera streaming is a separate follow-up after basic connectivity works. |
| Arm payload | The supplied specs list up to 2 kg per arm. Leave the arms unloaded during setup and initial operation. |
Session lead · Confirm with Artrageous before the visit
Operator and spotter · 25 minutes
Programming pair · Laptop setup and tests
Use one laptop with wired Ethernet. Native Ubuntu is the simplest option. A Windows laptop running Ubuntu in WSL 2 or VirtualBox can also work if it passes the wired test below.
python3 example/helloworld/publisher.py in
one and python3 example/helloworld/subscriber.py in the
other. Confirm the subscriber prints messages. This exercise uses sample
messages on your laptop and requires no robot. Stop both with Ctrl+C. DDS
exercise192.168.50.10/24 for the laptop side and 192.168.50.11/24 for the second computer. For WSL, set the laptop address in Windows. For VirtualBox, set it in the Ubuntu guest.
Temporarily disconnect Wi-Fi and VPNs on both computers so the example uses the wired link.python3 example/helloworld/subscriber.py
in the Ubuntu environment you’re testing. On the second computer, run python3 example/helloworld/publisher.py.
The subscriber should print Hello world messages. Unitree’s messaging example| FTC Java concept | R1 equivalent for this session |
|---|---|
| Driver Station and gamepad | The Explore app handles setup tasks. The paired remote is the operator’s control during initial checkout. |
hardwareMap |
The SDK binds to a network interface. DDS matches publishers and subscribers by domain, topic, and message type. |
| Reading an IMU in an OpMode | Subscribe to robot state. A callback receives each new message. IMU roll, pitch, and yaw describe orientation about three axes. |
| Telemetry and logging | Print a few timestamped or rate-limited samples. Treat stale data or a timeout as a failed connection check. |
| Autonomous state machine | A later performance routine can use explicit states such as IDLE, READY, RUNNING, and ABORTED. Rehearse transitions with mock data first. |
Use Python for the first SDK exercise. Your Java experience transfers directly to callbacks, typed messages, state machines, and debugging. If the team later wants a Java cue controller, it can send named cues to a small Python or C++ service that owns the robot connection. The public SDK repositories used here document Python and C++. Python SDK · C++ SDK
Battery plan. Unitree lists about one hour of battery life for the R1 EDU. Do laptop setup with the robot powered off where practical. Check charge at startup and again before telemetry. If time or charge runs low, skip the optional action and keep the 5:30 shutdown and handoff. Unitree R1 specifications
| Mountain time | Activity | Checkpoint |
|---|---|---|
| 3:30–3:50 | Inspect the robot, identify revision and firmware, inventory the remote and support equipment, and clear the operating area. Review the matching stop and shutdown procedures. | Operator and spotter agree on the stop procedure and know where everyone will stand. |
| 3:50–4:20 | Follow the matching startup procedure. Verify app and remote status, battery, and any alerts. With the robot in the documented safe configuration, verify the operator’s stop procedure as directed by the manual. | The operator can explain what the stop mode does and how to recover or shut down. |
| 4:20–5:00 | Check battery charge and connect the laptop using the documented development port and network settings. Run the read-only probe while the operator keeps the robot stationary in the documented safe state. | Save five IMU readings and note the interface, SDK commit, and firmware. |
| 5:00–5:30 | If time and charge allow, the operator can demonstrate one documented built-in action after verifying the controls and clearing the area. Otherwise, rehearse the welcome and Abort cues on the laptop. | Document which capability was demonstrated or what blocked it. |
| 5:30–6:00 | Follow the documented shutdown and packing procedure. Write a handoff with what worked, the exact commands used, and the next test. | Another student can repeat the connection and telemetry check from the notes. |
Operating rule. Keep people outside the robot’s reach and fall area while powered. Use the support setup described in the manual when required. A stop mode can change how the joints support the robot, so verify the correct mode and support procedure before enabling motion. Pause if the stop behavior is unclear, a warning appears, or anyone enters the operating area. Leave firmware updates, calibration, scripted motion, and custom dance sequences for a separately planned session. R1 operation and remote manuals
Use the matching development and debugging tutorial to identify the physical port and wired IP settings.
In native Ubuntu or VirtualBox, apply those settings in Ubuntu. With mirrored WSL 2, apply them to the Windows Ethernet adapter.
In every setup, use ip -br addr in Ubuntu to confirm the address and find the interface name for the script.
Ask the operator to put the robot in the documented stationary setup for the test.
Save the following as read_r1_imu.py. It subscribes to
the R1 example’s rt/lowstate topic using the
unitree_hg message family. It creates only a subscriber and
exits after five fresh observations or a timeout. The upstream R1
low-level example also writes motor commands and switches motion
services. Use it as source reference only during this exercise. R1
message and topic reference
import argparse
import time
from queue import Empty, Queue
from unitree_sdk2py.core.channel import ChannelFactoryInitialize, ChannelSubscriber
from unitree_sdk2py.idl.unitree_hg.msg.dds_ import LowState_
def main():
parser = argparse.ArgumentParser(description="Read five R1 IMU samples.")
parser.add_argument("interface", help="Linux interface connected to the R1")
parser.add_argument("--domain", type=int, default=0, help="DDS domain ID")
args = parser.parse_args()
samples = Queue(maxsize=1)
def on_state(message):
try:
samples.get_nowait()
except Empty:
pass
samples.put_nowait(tuple(message.imu_state.rpy))
ChannelFactoryInitialize(args.domain, args.interface)
subscriber = ChannelSubscriber("rt/lowstate", LowState_)
subscriber.Init(on_state, 1)
for index in range(1, 6):
try:
roll, pitch, yaw = samples.get(timeout=5)
except Empty:
raise SystemExit("No fresh state. Check the interface, DDS domain, and firmware.")
print(f"{index}: roll={roll:.3f} pitch={pitch:.3f} yaw={yaw:.3f}", flush=True)
if index < 5:
time.sleep(0.5)
if __name__ == "__main__":
main()From the folder where you saved the script, activate your SDK environment and run the command below.
Replace enp2s0 with the Ubuntu interface that faces the robot.
Set --domain only if the matching documentation specifies a different DDS domain.
python3 read_r1_imu.py enp2s0Look for five numbered readings. A sample line is 1: roll=0.100 pitch=0.200 yaw=0.300.
Similar values are normal while the robot is stationary. Save the output for the handoff.
| If you see… | Check… |
|---|---|
| Import error | Activate the environment used for the two-terminal exercise. Check which Python is running and review the SDK and Cyclone DDS installation. |
| No link or address | Check the documented port, cable, adapter, interface selection, and laptop IP settings. |
| Network link but no samples | Check the selected interface, subnet, DDS domain and message type against the matching documentation. Check whether a VM, VPN, or firewall is interfering with DDS discovery. A successful ping alone doesn’t establish DDS communication. |
| Warnings or inconsistent behavior | Have the operator follow the manual’s stop or shutdown procedure. Record the alert and firmware version before retrying. |
Handoff to capture — Hardware revision, firmware, confirmed accessories, app and remote status, shutdown outcome, laptop OS and SDK commit, working interface and DDS domain, sample telemetry, and the next test with an owner. Keep account credentials out of the handoff.