Practice FRC Programming Without a Robot: WPILib Simulation

You can practice FRC programming without a robot by using WPILib's built-in simulator, which runs your real robot code on your laptop and shows a virtual robot you can enable, drive, and debug. Everything you write for the actual roboRIO, including command-based structure, subsystems, autonomous routines, and PID loops, runs in the sim with no hardware attached.

That matters because programming is the department most starved for hardware time. The robot is usually half-built, being rewired, or in use by drive practice, and the code team is stuck waiting. Simulation removes that bottleneck. You can iterate on autonomous paths at midnight in December, months before Kickoff, and show up to build season already knowing your tools.

Why simulation is worth your time

The old way to learn FRC code was to wait for a working robot, deploy, watch it do the wrong thing, and repeat with a 30-second deploy cycle and a crowd of people who also need the robot. Simulation flips that. Your test loop drops to a few seconds, you get a debugger, and a broken line of code crashes a window on your screen instead of driving a 120-pound machine into a wall.

There are three honest limits to be clear about. First, physics in sim is approximate, so a mechanism that works in the simulator may still need real-world tuning. Second, you will not catch wiring, CAN bus, or mechanical problems in sim, because there is no wiring. Third, sensor behavior is only as realistic as the model you feed it. None of that makes simulation less useful. It just means sim is for validating your logic and structure, and the real robot is for the final tuning pass.

What you actually need

The requirements are small: a laptop running Windows, macOS, or Linux, and the WPILib release for the current season installed. That single installer gives you a preconfigured VS Code, the WPILib libraries, the build tools, and the simulator. You do not need a roboRIO, a power supply, or any motors. If you have never installed it, walk through our Programming, Controls & Sensors guides — installing the toolchain is covered there step by step — because the sim assumes you already have a project that builds.

Simulation works in all three WPILib languages — Java, C++, and Python — so your language choice doesn't limit you here. If you're still weighing them, our lesson on choosing a language covers the tradeoffs; whichever you pick, make sure a template project builds cleanly before you simulate, because the sim runs your compiled code and cannot fix a project that does not compile.

Running the simulator

You launch it from your robot project in the WPILib VS Code: open the command palette and run the WPILib command to simulate your robot code, or use the Gradle task from the terminal (./gradlew simulateJava for a Java project). The exact command label can shift between seasons, so if the palette entry looks slightly different from a tutorial you are following, trust the current WPILib docs at docs.wpilib.org over an older guide. The first time you run it, WPILib asks which simulation extensions to load; pick the Sim GUI and the driver station extension, and the Sim GUI window that opens is the heart of the whole workflow.

Its Robot State panel is a virtual Driver Station: set the robot to Disabled, Autonomous, Teleoperated, or Test, and flip the Enable control exactly like the real thing. Enable in Teleop and the panels showing your commanded outputs — PWM values, motor controller outputs — move in real time, which alone catches a huge share of "why isn't my motor doing anything" bugs. To drive, plug in a game controller and drag it from the System Joysticks panel into the Joysticks panel so it maps to joystick 0 the way your code expects; now your teleop code is reading a real controller with no robot in the room, but the full input-to-output path is live. Our lesson Simulation: Test Without a Robot walks the full panel tour and each robot state end to end.

Making the virtual robot move

Out of the box, the Sim GUI shows you commanded outputs but not motion, because nothing is modeling the physics of your drivetrain or arm. WPILib ships physics simulation classes for the common FRC mechanisms — a differential (tank) drivetrain, a flywheel, an elevator, a single-jointed arm, and a generic DC motor — and you feed each one the real parameters, such as the gearbox reduction, the motor type and count, and the mass or moment of inertia. Wired in through a simulationPeriodic() method, which the framework calls only when running in simulation, the model turns your commanded voltage into a position and velocity and writes it back into your simulated sensors, such as encoders. Now a closed-loop PID that holds an elevator height will actually settle in the sim, and a badly tuned one will visibly oscillate on screen — that feedback is the entire point, and you got it without a robot or a single risk of stripping a gear. Our lesson on simulation-driven design with WPILib physics models works a full mechanism through from CAD-derived inputs to a settling loop.

You do not have to model everything on day one. A common and productive path is to simulate just the drivetrain so you can develop autonomous routines and odometry, then add mechanism models later as you need them.

Vendor hardware: CTRE and REV in sim

Most modern FRC robots run motors on either CTRE or REV electronics, and both vendors support simulation, so you are not limited to WPILib-native motor controllers. CTRE's Phoenix library exposes a simulation state on its motor controllers, letting you feed a simulated position and velocity into a device like a TalonFX and read realistic encoder and status values back. REV's library similarly provides simulation hooks for its SPARK controllers. The details and the exact API names change with each vendor release, so pull the current version of the vendor's own simulation documentation rather than trusting a two-year-old forum post. The takeaway is that whatever hardware your team standardized on, you can very likely develop against it in sim. If you are still deciding on electronics, our Electrical & Wiring guides cover the tradeoffs on the hardware side.

Seeing your robot on a field

Numbers in a panel are fine for a motor, but for a drivetrain you want to see where the robot is. WPILib provides a Field2d widget: you publish your robot's estimated pose from odometry and the Sim GUI (or the Glass dashboard) draws the robot as an arrow on a top-down field. Drive in teleop and the arrow moves; run an autonomous path and you watch it trace the route. If your odometry math is wrong, the arrow drifts or teleports, and the bug is obvious in a way it never is by staring at code.

Two companion tools go further. Glass is a standalone dashboard that connects to your running sim and gives you richer, more configurable widgets and plots than the basic Sim GUI. AdvantageScope, a widely used community tool, visualizes NetworkTables and log data — including 2D and 3D field views and mechanism animations — and can replay recorded logs after the fact, so teams that log aggressively can reconstruct exactly what the code believed was happening during a match or a sim run. We cover both in depth in a systematic debugging workflow for FRC; here it is enough to know they attach to the same running sim. There is also a growing ecosystem of higher-fidelity physics simulators from the community that add game-piece collisions and more realistic field interaction. If you want to explore that, search for the current season's popular FRC simulation libraries, since the leading options change from year to year.

Test your code, not just your patience

Simulation is not only about the GUI. Because your robot code is ordinary Java, C++, or Python, you can write unit tests that run on your laptop with no robot and no sim window at all. A typical test constructs a subsystem, commands it to do something, steps the physics model forward a few times, and asserts that the encoder ended up where it should. These tests run in seconds as part of your build, so a broken change gets caught before anyone deploys. For a rookie team, even a handful of tests around your drivetrain and your critical autonomous logic pays for itself the first time a refactor would have quietly broken something.

Cheap physical practice: Romi and XRP

If you want the feel of real hardware without a real robot, two small platforms run genuine WPILib code over a wireless connection to your laptop. The Romi is a compact wheeled robot built on a common hobby chassis, and the XRP (Experiential Robotics Platform) is an even cheaper option often in the range of a textbook rather than a robot budget. Both let you write a normal WPILib project, connect through a simulation websocket extension, and drive an actual little robot around a table. They are not a substitute for the competition robot, but they are a fantastic bridge between pure simulation and the real thing, and they are ideal for training new programmers in the offseason. Check the current price and setup steps in the WPILib docs, since both platforms get revised.

A realistic way to start

If you have never touched the simulator, do this in order. Install the current WPILib release and confirm a new project builds. Run the simulator, open the Sim GUI, drag in a controller, and enable a stock template in teleop so you see outputs respond. Add a differential drivetrain physics model and a Field2d widget, and drive your virtual robot around. Then write one unit test. That sequence, which you can do in an afternoon, covers the core skills you will use all season.

Simulation is the single highest-leverage habit a new FRC programmer can build, because it turns "we're blocked on the robot" into "we shipped working code before the robot existed." Ready to go deeper? Work through the full walkthroughs in the LearnFRC Programming department, map out where code fits in the season with our learning paths, and keep the glossary open for any term that trips you up.