Ask any robotics instructor what the first week of class looks like. Not the exciting part — the part before any robot moves, before any code runs, before any student writes their first rclpy.init(). It's three days of fighting Ubuntu versions, ROS2 distribution mismatches, broken colcon build pipelines, and the particular misery of GPU driver conflicts on Windows machines trying to run a Linux VM.
We've been there. And it's not a small problem.
The real barrier to robotics education isn't the difficulty of ROS2. It's that students spend their first week debugging an environment rather than learning robotics. By the time the setup works, motivation has already eroded.
The Setup Tax
When we surveyed robotics educators and students building their first ROS2 projects, the number one complaint wasn't complex concepts — it was environment setup time. The average reported setup time before writing a single line of robot code was 2.8 days. For some, weeks.
This isn't a failure of documentation or tutorials. It's a structural problem: ROS2 is a deeply Linux-native, hardware-adjacent framework built for professional roboticists. Getting it running requires:
- A correct Ubuntu version (the wrong distro breaks everything quietly)
- Matching ROS2 distribution (Humble, Iron, Jazzy — each with different support windows)
- Gazebo version compatibility (Fortress? Garden? Classic? It matters)
- Graphics driver support for GUI tools like RViz2 and Gazebo's rendering engine
- Proper sourcing of workspace overlay and underlay in the right order
- Environment variables, colcon workspace structure, package dependencies
Each of these is learnable in isolation. Together, on a fresh machine with a deadline, they combine into an obstacle course that filters out motivated people for the wrong reasons.
What We Built — and Why
RoboLab is a browser-native ROS2 simulation environment. You open a URL. You get a fully functional ROS2 workspace, live Gazebo simulation, RViz2 visualiser, and an embedded IDE — all running in isolated Docker containers on our infrastructure, streamed to your browser via WebSocket and KasmVNC.
The key architectural insight is that the development environment doesn't need to be local to be useful. Latency on GUI-heavy tools like Gazebo matters, but for learning, for prototyping, and for most simulation workloads, a well-tuned server-side rendering pipeline over a decent internet connection is completely adequate.
Zero setup. Students click a link, pick a problem, and start writing ROS2 code. The first time they run ros2 run, it works. Every time.
The Technical Architecture
Each user session spins up a dedicated Docker container running Ubuntu 22.04 with ROS2 Humble pre-configured. This container includes:
- Full ROS2 Humble desktop install — all standard packages
- Gazebo Classic 11 with GPU-accelerated rendering (where available) or CPU fallback
- RViz2, PlotJuggler, and rqt running on isolated virtual displays via Xvfb
- Eclipse Theia IDE with ROS2 language support and Python IntelliSense
- KasmVNC for per-tool GUI streaming — each tool gets its own display and stream
Isolation is critical. When one student's Gazebo crashes, it doesn't affect anyone else. When a student corrupts their workspace, they can reset to a clean state in seconds without reinstalling anything. This is genuinely impossible with local setups at scale.
# What a student sees on day one
# Open browser → pick problem → write code
import rclpy
from rclpy.node import Node
from geometry_msgs.msg import Twist
class WallFollower(Node):
def __init__(self):
super().__init__('wall_follower')
self.publisher = self.create_publisher(Twist, '/cmd_vel', 10)
self.timer = self.create_timer(0.1, self.control_loop)
def control_loop(self):
msg = Twist()
msg.linear.x = 0.2
self.publisher.publish(msg)
rclpy.init()
rclpy.spin(WallFollower())The GUI Streaming Problem
Streaming a remote desktop is solved technology. What's harder is streaming multiple independent GUI applications simultaneously — each with different latency tolerances, frame rate needs, and interactivity requirements.
Gazebo needs high frame rate for a fluid simulation view. RViz2 benefits from lower latency for interactive 3D manipulation. PlotJuggler wants smooth real-time data streaming. rqt's interaction model is mostly click-based, so it tolerates higher latency well.
We solved this by assigning each tool its own virtual display (via Xvfb display numbers), its own KasmVNC session, and tuning the streaming parameters per-tool. Students see each tool in its own iframe panel, streamed independently, composited in the browser.
What This Means for Education
The pedagogy changes when setup disappears. Instead of spending week one on the environment, instructors can spend it on core concepts: the publisher-subscriber model, the ROS2 computation graph, how nodes communicate over topics. Students actually run code on day one.
Our structured learning paths take advantage of this. Each problem is self-contained: the environment is pre-configured, the robot is already loaded in simulation, and the student just needs to write the logic. Progress is tracked, so instructors get visibility into where students are stuck.
The setup tax wasn't just time. It was a selection bias: the students who succeeded were often those with the most prior Linux experience, not the most robotics potential. Eliminating setup equalises access.
The Tradeoffs
Browser-based development isn't free of downsides, and we'd rather be honest about them.
Latency is real. For high-frequency control loops running at 1kHz+, the round-trip through the browser isn't suitable. RoboLab is optimised for learning and development — not for deploying real-time controllers to production hardware. For that, you need local tooling.
Offline access is impossible. A student on a plane can't run their simulation. We've heard this feedback and it's a genuine limitation of the model.
Customisation depth is bounded. Students can't install arbitrary system packages or modify the container image. For advanced users with unusual dependencies, this is a friction point.
For the core use case — learning ROS2, building simulation projects, iterating on robot software — these tradeoffs are worth it for the vast majority of users.
What's Next
We're working on two things that address some of these gaps: persistent workspaces (so students don't lose work between sessions) and custom image support (for teams that need specific packages pre-installed). Both are coming in the next platform update.
The longer vision is a seamless pipeline from simulation to real hardware — the same browser interface that runs your Gazebo simulation today routes directly to a physical robot through our Remote Lab when you're ready. No new tooling. No setup. Same workflow, real world.
If you teach robotics, run a university lab, or are just tired of the ROS2 setup ritual — try RoboLab free. The first problem takes about two minutes to get running. That's the point.