THE GLOSSARY.

The steering geometry on real cars: the inner wheel turns more sharply than the outer one to track around a shared center of rotation. NeoRacer uses Ackermann, not skid-steer.

A standard ROS 2 algorithm that estimates the car's pose on a known map by matching live LiDAR scans against the map.

NVIDIA's kernel + driver bundle for the Jetson. The NeoRacer OS image is built on top of the Jetson Linux BSP plus Ubuntu 22.04.

The encoder's resolution. One full wheel turn produces this many tick edges. Higher CPR means finer odometry but more interrupts on the MCU (microcontroller unit).

The flat T-shaped power plug on the battery. If the car won't power on, a firm reseat is usually the first thing to try. When the two halves rotate freely against each other, the connector is worn and worth replacing.

The big red button on the chassis. A press cuts power instantly, and a twist brings it back. Every student program also treats the left bumper on the controller as a software e-stop.

Takes a low-power PWM signal in, drives the motor with regulated power out. Has a built-in voltage cutoff so a flat LiPo can't damage the battery.

The MIT-originated autonomous racing competition NeoRacer is API-compatible with. F1TENTH scripts run on NeoRacer with no code changes.

The ROS 2 string that names a coordinate frame. Every sensor message carries one. The LiDAR frame is lidar_link, the IMU is imu_link, the car body is base_link.

A planning algorithm that picks the largest free arc in the LiDAR scan and steers toward it. The foundational F1TENTH-style behaviour.

A chip that fuses an accelerometer and a gyroscope so you get linear acceleration plus angular velocity. The NeoRacer IMU also publishes a fused orientation estimate.

The Linux host on the car. NVIDIA single-board computer with a 67 TOPS AI accelerator, runs Ubuntu and ROS 2.

NVIDIA's software bundle for the Jetson family (Linux kernel, drivers, CUDA, the AI runtime). The NeoRacer image ships JetPack 6.2 on Ubuntu 22.04.5 with ROS 2 Humble on top.

A spinning laser scanner that measures distance to whatever the beam hits. The NeoRacer LiDAR gives your code 720 samples per revolution at 30 Hz.

The battery chemistry used in NeoRacer and most RC cars. High power density, but needs careful charging through a balance charger and a flat-storage routine.

The Richbeam LakiBeam1, the 2D lidar mounted up front. It talks to the Jetson as a UDP sensor on its own subnet (host 192.168.8.1, sensor 192.168.8.2), and the lakibeam1 node publishes scans to /scan.

The real-time chip the Jetson talks to over USB. Owns the motor, servo, and IMU loops because the Jetson can't hit microsecond deadlines under Python.

In practice, the top-speed cap (max_speed_mps + max_forward) you set in the driver YAML so set_speed_angle scales to a speed you chose. The motor neutral itself lives in the ESP32 firmware, so a creep at zero is usually the ESC neutral or drivetrain drag, not a value you tune here.

The mux_node in the driver, the arbiter that decides whether the autonomy channel (/drive) or the teleop channel (/gamepad_drive) reaches the motor. The Flysky switch arms manual or autonomy; mux only forwards when one of the two modes is armed.

A pose estimate built from wheel encoders and the IMU. Useful for short-horizon dead reckoning, drifts over distance because of slip.

The custom Neobotics board in the chassis. ESP32-S3 robot controller that takes the LiPo in, fans out 5 V and 3.3 V rails, reads the onboard IMU, and runs the ESC + servo PWM. It is the board the driver talks to over USB-CDC.

The Seeed Studio robot platform the NeoRacer chassis builds on, and the name the udev rules pin to. The Jetson sees the OSCORE board as /dev/osrbot_base, the USB webcam as /dev/osrbot_usb_cam, and the dot-matrix display as /dev/osrbot_led_matrix.

A WebAssembly build of CPython that runs in the browser. Lets the NeoRacer Playground execute the same Python student code the car runs.

The Python module every student writes against. The rc.* namespace it exposes is identical on the browser sim and the physical car.

The racecar object every program drives the car through. You create it with rc = racecar_core.create_racecar(), then call rc.drive, rc.lidar, rc.camera, and the rest. The same object works in the browser sim and on the physical car.

The middleware running on the Jetson. Sensors publish topics, your code subscribes, your code publishes drive commands, the actuators subscribe.

A shell wrapper the driver installs into the racecar user's bashrc. Common entry points: racecar teleop (full stack), racecar status (USB symlinks + running nodes), racecar setup networking (AP + Ethernet + lidar subnet), racecar service install/start, racecar selftest.

The car is its own Wi-Fi access point, broadcasting the network neoracer-[Car ID] (password neobotics). Once you join it, the car answers at the fixed address 192.168.1.[100 + Car ID] (Car 1 = 192.168.1.101), hostname neoracer, as user racecar. There is no DNS server and no name to resolve.

A few degrees of trim, set as steering_trim_deg in config/controller.yaml, that points the front wheels dead ahead when your steering command is zero. Pinned per car because the steering linkage has a little slop.

Building a map of an unknown space while tracking the car's pose inside it.

A named channel in ROS 2 (/scan, /imu, /drive). Publishers don't know who's reading. Subscribers don't know who's writing. The middleware does the routing.

A node supervisor in the driver. It tracks every node teleop brings up (controller, throttle, mux, gamepad, lidar, camera), restarts a dead one, and flags /imu or /scan if they go stale. The web dashboard at http://neoracer.local:8080 surfaces what it sees.