Levandor

lightaim Activity Log

6 min read

For Agents

Reverse-chronological session log. Newest entries at top, grouped by date (## YYYY-MM-DD). Each bullet: one piece of work, short summary, wikilinks to docs touched. Updated by obsidian-documenter on every project doc write. Read by historian at bootstrap.

2026-09-03

  • ⭐ “Full speed” is a code constant, not a power limit — and it cancelled a purchase. MAX_RATE_DEG_S = 60.0f in src/main.cpp caps slew at 60 °/s. An MG996R at 6 V does 0.14 s/60° ≈ ~430 °/s, so the rig runs at roughly 1/7 of the servo’s mechanical capability. The XL4015 at 6.0 V has never browned out and no current draw has ever been measured — there is no evidence of a power problem at all. ✅ Cancelled on the strength of this: a UBEC and a 2200 µF bulk capacitor, which were about to be ordered to fix a limitation that lives in a literal. ⛔ PREREQUISITE, not a follow-up: ANGLE_MIN_DEG/ANGLE_MAX_DEG are still at the untouched 0/180 defaults. A servo driven into a hard stop stalls at full current and strips its gears in seconds, and faster slew makes hitting a stop MORE likely — so real mechanical limits must be set before the rate is raised, not after. General lesson: before buying hardware to raise a ceiling, check whether the ceiling is a literal in the source — Full Speed Is a Code Constant, Not a Power Limit
  • ⚠️ Confirmed by exhaustive search: there is NO sender/receiver split in lightaim. It is ONE ESP32-S3, all wired — the joystick is cabin-mounted on a 4-wire run (W9) back to the same board that drives the servo. There is no sender, no receiver and no radio link anywhere in the project. A battery-powered joystick “sender” is a brand-new idea introduced 2026-09-02 with no transport chosen (not WiFi, not ESP-NOW, not BLE, not LoRa) — recorded as a proposal, not as existing architecture. Any note or agent output describing a lightaim “sender” is describing something that does not exist. Relevant prior decision that happens to help: the joystick was put on GPIO1/ADC1 specifically so WiFi could be added later without re-routing a wire — Receiver Split — and a Proposal That Might Add One

2026-09-02

  • Recorded that this project’s Parts Gap — Not Yet Ordered is confirmed against physical stock, in the new vault-level inventory. Two things it settles: (1) the MINI560-5V-5A (100.423.75, 552 Ft) is wanted independently by the KrakenSDR car rig too — the Pi 5 browns out at 5 V/3 A (2026-08-26-krakensdr-field-test-milestone) — so buy at least 2; this is the first cross-project duplicate an inventory has caught. (2) ⚠️ The single XL4015 in the house is currently set to 6.0 V for this bench and is a configured part, not free stock — anything that borrows it must set the pot back or this servo rail is silently wrong next power-up. Also confirmed genuinely absent and therefore blocking the vehicle build: the SMBJ33A TVS, the 2 A fuse and the reverse-polarity part. ⚠️ Soldering is not a blocker — 3 irons are owned (models unknown, undocumented anywhere until now), correcting four earlier agent runs that concluded otherwise — inventory

2026-08-12

  • lightaim is WORKING END TO END ON THE BENCH. Joystick-aimed vehicle light: ESP32-S3-WROOM-1 + CJOY-XYSW (X axis only, GPIO1/ADC1) + MG996R on GPIO5. The load-bearing decision is velocity control, not position control — stick deflection sets the rotation rate and the angle is integrated (angleDeg += n * MAX_RATE_DEG_S * dt), so releasing the stick leaves the light where you aimed it; position control was rejected because it would snap back to centre. Verified centre=2065, ±2 counts rest noise, full sweep raw 0–4095 → x −1.00…+1.00 over 96 clean samples — lightaim
  • Bug found and fixed: SERVO_RES_BITS must be 14, not 16. The ESP32-S3’s LEDC peripheral caps duty resolution at 14 bits (classic ESP32 does 20). At 16, ledcSetup() refuses and ledc_get_duty(745): LEDC is not initialized follows — no servo output at all while the rest of the firmware looks perfectly healthy. 14 bits still gives 1.22 µs resolution on a 20 ms frame. Plus three more reusable gotchas: uvx --from platformio needs --with pip (PlatformIO shells out to pip; also rm -rf ~/.platformio/packages/tool-esptoolpy after a failed run), the S3 bootloader flashes at 0x0 not 0x1000, and only the CH343 UART port (1a86:55d3) can flash a running S3 — the native USB/OTG port (303a:4001) gives No serial data received, the same trap as 2026-08-11-ruview-esp32-csi-real-hardware — 2026-08-12-lightaim-bench-bringup
  • Three hardware hazards documented. ⚠️ The joystick’s +5V silkscreen pad must go to 3V3 — it’s a resistive divider whose wiper rises to whatever feeds it, so 5 V puts 5 V on a 3.3 V ADC pin and damages it. ⚠️ Set ANGLE_MIN/MAX_DEG to the real mechanical limits before bolting anything to the horn — a stalled MG996R strips its gears in seconds. ⚠️ Never power the servo from the board’s 5 V pin (~2.5 A stall browns out the MCU); the split supply is why no bulk cap was needed on the bench. Common ground between rails is mandatory (W4 bench / W10 vehicle) — lightaim
  • Wiring captured in WireViz (wiring/bench.yml + wiring/vehicle.yml → png/svg/html/bom.tsv). Chose WireViz over Fusion Electronics: no Fusion MCP for the electronics workspace, and it’s PCB-oriented EDA needing custom library symbols for the XL4015 / CJOY / MG996R — heavy for six wires. Extends pipeline — lightaim
  • Parts gap logged + one open decision. The HESTORE order has only one buck (100.479.44 XL4015 ×1); the vehicle config needs a second 5 V converter (recommend MINI560-5V-5A, 100.423.75 — fixed output, no pot to mis-set) plus 2 A fuse, SMBJ33A TVS and reverse-polarity protection — do not run both rails off the single XL4015. Automotive 12 V is 13.8–14.4 V running, 6–9 V cranking, 35–40 V+ load dump vs the XL4015’s 38 V ceiling. Open: parked vs moving — at speed, wind load makes the servo fight continuously and wants a worm drive or DS5160; cutting PWM when idle is rejected because an unpowered servo has no holding torque — lightaim
  • Initialized activity log and project folder.

Graph View