Practice, on your terms.

Start a teleop match

Choose your match type, robot and match size on setup, then click Start match. Public matchmaking opens a waiting room; Cancel wait returns to setup. When two drivers connect in 1:1 or four in 2:2, everyone enters play automatically. Solo practice starts immediately. Private rooms show a code to share and let the host start early as unranked practice. In 2:2, empty slots contain stationary robots. In 1:1, the unused robots are removed. No AI opponents are provided.

Drive with W/A/S/D or the left stick; turn with Q/E or the right stick. Intake starts on; toggle it with I or RB. Press Space, controller A, or the on-screen Shoot button once per ball; the configured shot delay defaults to zero. Up/down arrows or LT/LB change pitch; brackets change power. Release the drive controls to stop moving. On the Controls page, click beside a command and press a key or controller button to assign it. Changes save automatically; Back returns to setup. Saved mappings also update the play hints. Touch controls support holding drive, pitch and power while tapping Shoot. Text editing, focus loss and network timeouts stop your robot.

To test with four tabs in one browser, enter a guest driver name in each guest tab and join the same teleop room. Guest tabs get separate slots. Signed-in tabs share one account; click New guest in this tab to drive an additional practice robot. Autonomous practice rooms always wait for the host to click Start private match after pairing adapters.

Submit a robot

The garage accepts a data-only profile: a box body, tank/mecanum drive, front intake, up to four stored elements and one shared shooter or separate pollen and nectar shooters. Declare a muzzle position, fixed yaw, pitch range/slew, maximum ball launch speed (power scales linearly), trigger delay and feed timing. Turn adjustable pitch/power on if you want drivers to control them during the game. Arbitrary arms, claws and custom code uploads are not supported.

Standard: 1.5 m/s driving, 150°/s turning, 9 m/s shooting. Custom caps: 2 m/s, 180°/s, 20 m/s. The garage has parameter fields, profile import/export, shot delay (default 0) and optional dual shooters. The next loaded ball selects its shooter automatically. Solo practice includes curves, sliders, descending-arc search and Flight profile. Sign in to save a profile and optionally upload a colored, static GLB model up to 5 MB. Appearance is scaled inside the declared collision box. Models are visible and downloadable by other players. Textures, external resources, extensions and animations are excluded from this beta. Brands are unrestricted. Custom robots are approved automatically when their profile and model pass the simulator limits; signed-in players can use them in ranked matches.

Understand beta scores

Scoring values: tips 20, AUTO leave 3, park 5, raised-cell elements 2, garden elements 1, owned-flower elements 2 and bottom-nectar bonus 5. Early flower nectar adds a 20-point penalty to the opponent. Live scores are provisional until final settling.

Physics, hive load/rotation and flower stacking are approximations. Referee judgments such as pinning, strategic fouls and deliberate ejection are not fully modeled; out-of-field balls are removed. There is no official ranking-point system. This simulator does not certify a real robot as legal. A JSON speed limit is a platform limit, not an official competition rule.

Leaderboard and data

Only completed public teleop games with a full room of distinct signed-in players and approved robots can rank. Disconnects, server scheduling delays, local Java and settling failures invalidate ranking. Highest alliance score ranks each signed-in account, separately by match size, with average score breaking ties. Server authority prevents invented client scores, but does not prove human input or prevent collusion.

Hosted login uses your provider identity and verified-email status. Passwords stay with the login provider. Your signed-in account is used automatically. Your display name appears in rooms and eligible leaderboard results. Models are public; replays are downloadable by match participants. Ask the site operator about retention and account removal before submitting confidential or personal information.

Use your local Java autonomous code

Your code runs on your computer. The adapter sends drive and shooter commands to a private arena and receives simulated sensors. No source upload or router port forwarding is needed. Local Java games are unranked.

1. Install a JDK 17 or newer. In a terminal, check both java -version and javac -version. A JRE alone is not enough.
2. Download and extract the adapter autonomous-adapter.zip. Open a terminal in the extracted folder, where run.sh and run.cmd are located.
3. On the front page, choose your robot, then click Start solo Java practice in the separate Autonomous practice section. This creates a solo autonomous practice room and waits only for your Java adapter. No matchmaking, teammates or opponents are required.
4. The room automatically shows a one-use pairing key. Use Copy room code and Copy token to copy the values. The command below runs the bundled DemoAuto connection example. To run your own routine, first follow Select your local controller below and replace DemoAuto with your controller class name. Replace ROOM_CODE with your room's ten-character code, then paste the one-use token at the terminal prompt; it expires in five minutes.

./run.sh https://robotarena.org ROOM_CODE DemoAuto

If macOS/Linux reports “Permission denied”, run chmod +x run.sh once, then retry. If the compiler is missing, install a JDK and add its bin directory to PATH.

5. Wait for Paired in the terminal and Java adapter connected on the website. The Start solo practice button appears only after Java connects; click it when ready. The included DemoAuto drives briefly and shoots; it is only a connection example.
6. Java controls the 30-second AUTO period. The private test then ends after the balls settle; there is no teleop period. Pressing drive controls during AUTO revokes Java control. Use Leave match or Ctrl+C to stop. Create a new room and token for another autonomous run.

Select your local controller

The adapter does not discover your robot repository or connect to an already running Java program. The launcher compiles local Java files and loads the controller class named in its third argument. Your controller and autonomous logic then run together in the same Java process on your computer; only sensors and commands cross the network.

1. Put your hardware-independent autonomous Java files and their dependencies inside the extracted adapter's src/ folder. Preserve package folders: a class declared in package myteam.auto; belongs under src/myteam/auto/. Files in subfolders are compiled too. Android OpModes and hardware drivers cannot run directly in this desktop adapter.
2. Start with the included src/MyAuto.java bridge, without a package declaration, that implements RobotIO.Controller and has a public no-argument constructor. Its update(RobotIO.Sensors) method translates sensor readings into the inputs your existing routine expects, advances that routine once, and returns RobotIO.Commands from its motor outputs. Use TeamMapping.java for unit and drivetrain conversions. Open START_HERE.md in the ZIP for numbered adaptation steps and a file map. The included src/example/team/ExampleAuto.java makes MyAuto runnable immediately: it drives 12 inches from measured pose, then stops. Replace that example with your routine. A complete existing-controller bridge is also included at examples/quantumstorm/QuantumStormAuto.java, with its own README; that example requires your local team sources.
3. From the extracted adapter folder, run the command below. MyAuto is the bridge class name, without .java or a file path; it is not the underlying state machine's name unless that class itself implements RobotIO.Controller. Without the third argument, the downloaded adapter runs DemoAuto.

./run.sh https://robotarena.org ROOM_CODE MyAuto

Paste the pairing token, wait for Paired, then start the private match in the browser. After editing your local code, stop the adapter, create a new practice room and token, and run the launcher again to recompile. If you already have an adapter folder in your robot repository, follow its README: its launcher may compile the shared sources directly so you do not need to copy them into the downloaded adapter.

How sensor data is mapped

During autonomous practice, the server sends simulated sensor readings to the adapter on your computer. The adapter translates them into the units and conventions your Java code expects, so your code can use simulated readings in place of physical robot sensors. It does not read your real robot's hardware or upload your source code.

• Position and movement: simulator positions use meters from the field center and heading uses counterclockwise radians from +X. The mapping can convert these to inches, clockwise degrees, or encoder ticks using your wheel size, gearing and encoder resolution. Check axis directions and motor signs against your robot.
• Ball sensors: simulated storage occupancy and ball count replace the readings your code would get from beam-break or other inventory sensors. Use these readings to confirm pickups and shots, rather than assuming they succeeded after a delay.
• Vision and sensor health: the adapter passes target IDs, angles, tag heights, pipeline, capture time and validity to your code. Preserve timestamps and camera/odometry health; missing or stale data must remain unavailable. Simulated vision is an approximation of camera observations.
• Commands back to the arena: the adapter converts your controller's motor outputs to normalized forward, sideways and turning commands, plus intake, feeder, shooter power and angle settings. The server applies your selected robot's speed and mechanism limits.

These mappings must match your robot; they are not detected automatically. Edit the mapping layer supplied in the ZIP, using its README and examples. Your autonomous logic needs to run independently of Android hardware drivers. Use simulation time for timers and return commands promptly; the server stops stale commands after 300 ms without a fresh valid command.