Enhance documentation for logging, tuning, simulation, and vision systems#102
Conversation
Project516
changed the title
| | `PM2026` | Practice Machine | Mirrors competition, minor wear-and-tear tweaks. | | ||
| | `XM2026` | Experimental Machine | Off-season prototyping. Encoder offsets and attachment flags vary. | | ||
| | `AM2026` | Alpha Machine | Earlier prototype, used pre-build. | | ||
| | `PHOTON2026` | Photon dev bot | Code-only testing without competition hardware. | |
There was a problem hiding this comment.
NOT for code-only its for Photon
There was a problem hiding this comment.
Fixed in 01353cd — now "Photon's machine — the robot run by Photon, our sister team."
| * Releasing `LB` returns to home. | ||
|
|
||
| ### 2026 Vision (Game REBUILT) | ||
| ### Pilot action |
There was a problem hiding this comment.
also has a lot of 2025 stuff
There was a problem hiding this comment.
Covered by the same rewrite in 01353cd — the intake section and the auto-score diagram were replaced with the real RT/LT intake/launch trigger behavior from RobotStates.
|
|
||
| The plan is to bring back `CANdleLeds.java` (or its successor) as a thin subsystem wrapper around `SpectrumLEDs`, with `LedStates.java` doing what it did before: binding `Trigger`s — auto mode, transition, alliance shift, endgame, "about to shift" — to `setPattern(...)` calls of varying priority. Whoever picks the work back up should: | ||
|
|
||
| 1. Replace the Phoenix 6 `CANdle` instantiation with `new SpectrumLEDs(new SpectrumLEDs.Config("StatusLEDs", 20))` (or however many LEDs the bot ends up with). |
There was a problem hiding this comment.
i'm 99% sure this is NOT part of the plan. integrate? possibly. replace? nooo
There was a problem hiding this comment.
Reworded in 01353cd — the CANdle stays as the hardware driver and the doc now describes SpectrumLEDs as something that may get integrated alongside it, not a replacement. Both the state-of-play note and the revival steps were updated.
|
|
||
| ## A Workflow That Works | ||
|
|
||
| You're looking for gains that hit the target quickly, don't overshoot, don't oscillate, and don't sit short of the setpoint. The order that tends to converge fastest: |
There was a problem hiding this comment.
you should add my docs ;)
There was a problem hiding this comment.
Happy to — I couldn't find your docs in this repo or the org branches. Where do they live? Drop a link and I'll add it to this section.
| * `RB` — fully retract the intake extension. | ||
| * `RT` / `LT` — intake extension manual voltage out (+/−). | ||
| * `Dpad` — same `ShotCalculator` hood/drive offset trims as the pilot. | ||
| * `LB + Y` — reset intake-extension position. |
There was a problem hiding this comment.
not in code at all, where did claude pull this from??
There was a problem hiding this comment.
It's in the code — Operator.java:18 sets fn = leftBumper, Operator.java:44 defines resetIntakeExtensionPos = Y.and(fn) (so LB + Y), and OperatorStates.java:27-28 binds it to IntakeExtensionStates.operatorResetIntakeExtension() with a rumble confirm.
| * Left stick — field-relative translation; right stick — rotation (exponential curves, deadzone in `PilotConfig`). | ||
| * `X` (hold) — `TRACK_TARGET` (launcher + hood aim while driving). | ||
| * `A` (hold) — `UNJAM`. | ||
| * `B` (hold) — slow intake-extension close. |
There was a problem hiding this comment.
can't find this anywhere in code, double check
There was a problem hiding this comment.
It's in the code — Pilot.java:28 defines BButton = B.and(teleop) and PilotStates.java:38 binds it: pilot.BButton.whileTrue(IntakeExtensionStates.slowIntakeCloseCommand()). The command itself is IntakeExtensionStates.java:87 (slowIntakeCloseCommand, named "IntakeExtension.slowIntakeClose").
There was a problem hiding this comment.
nice i didnt notice that
|
Don’t merge it yet
|
No description provided.