You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Writing an autonomous routine? You need two of these pages.Chassis is the facade every routine is written against, and Routine is the fluent recipe layer on top of it. Everything else on this page is the machinery underneath — real, documented, and safe to ignore until you want it.
Every public entity in every shipped header — 1,632 of them across 115 headers: types and their members, nested types, free functions, namespace-scope constants and type aliases. Extracted from the headers, so it cannot fall behind the code: anything added to a shipped header appears here the next time the tool runs, and the host test build fails if it has not.
A public entity with no documentation comment fails the build, naming itself and its file and line. That gate is what makes "generated" mean "complete" rather than "generated from whatever someone remembered to write".
What is not here, and why. Four exclusions, all deliberate:
include/shulib/sim/ — the host simulator. Test-only, and not by convention: a CI guard fails the build if anything outside sim/ includes it, so no robot binary can reach it.
hal/fake/ and localization/fake/ — the test doubles the suite drives the real seams with. Public by file placement, test fixtures by charter; test/README.md is their documentation.
Preprocessor macros (SHULIB_PRECONDITION, SHULIB_TRACE). A macro has no signature, no access and no type, so there is nothing for an extractor to render without inventing it. Each is explained at length in its own header's design commentary, which every page below reproduces in full — so they are on the site, in prose, but not in the member lists or the index.
protected members — one section in the tree, in motion/move_to_pose.hpp. This reference documents the surface you call; the surface you subclass is guide chapter 13's subject.
Being on this page does not freeze anything. Most of what follows is unfrozen and expected to move. The Freeze Register in the roadmap is the only place a contract is locked, and it is enforced by compile-time signature pins, not by this page: changing a frozen signature fails a C++ test that names the register row, while changing anything else here costs one /// edit and a regeneration. Those are different mechanisms and only the first is a promise.
What the gate does not check. It proves every entity has a documentation comment. It has no opinion about whether that comment says anything — /// Sets the voltage. on setVoltage passes. Only a reader catches that, which is why the headers are written to be read and why each page below ends with the header's own design commentary rather than a bare list of signatures.
Prose about how to think about the API lives in the user guide — chapter 10 is the API as prose, and deliberately does not restate signatures. Worked recipes live in the cookbook. This page answers "what exactly exists, and what is its exact spelling".
RunReporter — the glue that makes a run LEGIBLE end to end (WS13, chunk C5): session header (§18.5) → per-motion result lines (§18.3/§18.4) → run summary (§18.3).
Feedforward — the kS/kV/kA motor feedforward (master plan §M2): the open-loop voltage to achieve a target velocity + acceleration, so the PID only has to correct the residual.
hDrive() — the H-drive (tank base + one transverse strafe wheel), as a MatrixKinematics preset (chunk C3; the hybrid backend §13 #15: a holonomic LINEAR drive is a coefficient table, exactly as xDrive() is).
The bounded mechanism operation (chunk F1, WS7/M4): IMechanismOp + the two season-free operations every scoring verb decomposes into — run a motor mechanism until something confirms (RunUntilConfirmed) and fire a discrete actuator, wait for it to physically…
BlackboxReader — THE DECODER. It ships in the same chunk as the encoder, because a format nothing can read is not a record: the first time a blackbox genuinely matters is a competition afternoon, and a file that cannot be opened that afternoon is worth exac…
Angle — a heading on SE(2). The one type that owns angle wrapping, so the "degrees into cos/sin" and "359° vs -1°" bug classes are impossible by construction.
User-defined literals for shulib units. Each converts to CANONICAL units at the point of writing, so the rest of the code never sees a raw unit again: distance = 24_in; field = 1_tile; dt = 20_ms; v = 12_volt;.
Controller canonical conversions — the ONE place the V5 controller's raw stick range becomes shulib's canonical [-1, 1] (§7: "convert exactly once, at the edge").
Distance-sensor canonical conversions — the ONE place the V5 distance sensor's millimeters become shulib's canonical inches and its raw 0–63 confidence becomes [0, 1] (§7: "convert exactly once, at the edge").
IGps — the VEX GPS behind the HAL, reporting in shulib's CANONICAL frame (the VEX meters / clockwise-from-North convention is converted away in the hal/pros adapter via gps_conversion.hpp).
IImu — the inertial sensor behind the HAL, reporting in shulib's CANONICAL frame (the V5's clockwise/degrees convention is converted away in the hal/pros adapter via imu_conversion.hpp, so everything above this line is CCW-positive radians).
The mechanism device seam (chunk F1, WS7/M4): IMechanism + the two concrete compositions every VEX mechanism reduces to at the device level — a group of motors on one shaft (MotorMechanism) and a set of digital lines switching one pneumatic circuit (Pneumat…
Optical-sensor canonical conversions — the ONE place the V5 optical sensor's raw channels become shulib's canonical ranges (§7: "convert exactly once, at the edge").
Rotation-sensor canonical conversions — the ONE place the V5 rotation sensor's centidegrees become shulib's canonical radians (§7: "convert exactly once, at the edge").
vision_conversion.hpp — the ONE place raw AprilTag image corners become shulib's canonical robot-relative tag pose (§7: convert exactly once, at the edge).
ProsCharSink — ICharSink over the V5's USB serial (chunk R1a): where TermSink's diagnostic bytes physically go on the robot (pros terminal displays them).
ProsTickPacer — motion::ITickPacer over pros::Task::delay_until (chunk R1a): the ONLY seam that regains control mid-motion on the robot, replacing main.cpp's V5DelayPacer (which had to hand-advance a FakeClock).
The shulib API version — the mechanism behind the Freeze Register's promise.
Every public entity, alphabetically
The alphabetical index lists all 1,632 of them with a link to each. Nested types appear under their qualified name (BlackboxReader::Frame::type), so a member of a nested type is findable by the name you would actually write.
Where the other documents fit
The user guide teaches the ideas in order, and chapter 10 is the API as prose — when to reach for a verb, what it does when things go wrong, which gotchas bite. It deliberately does not restate signatures; this reference owns those.
The cookbook answers "how do I write the routine I am writing right now", with compiled recipes.
This reference answers "what exactly exists, and what is its exact spelling".