P3: Acquire & automate

Open
  • Is something wrong?
#17 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, data-engineering, devops

Research direction

Start with the p3-log-acquisition OpenSpec change and its acquisition-service requirements, then read the linked roadmap and pitfalls document. The issue says the change is implemented, but lists live-roboRIO throughput and checksum verification, USB testing on Linux and Windows, and Windows service and CI work as pending; check the linked follow-up issues and human verification checklist to find the current entry point. Done means the remaining verification is complete and matches appear unattended within five minutes.

Written by the indexing model from the issue text.

Description

roadmap

Size: S · Depends on: IgniteRobotics/flashpoint-private#68 · OpenSpec: p3-log-acquisition

Status

Update 2026-10-19: the Windows CI job (group 9) is done. What's left is [HUMAN] 11.1–11.4, tracked in IgniteRobotics/flashpoint#13. Windows test gaps: IgniteRobotics/flashpoint#3; owlet flake: IgniteRobotics/flashpoint#4.

Status: implemented; human verification pending (change p3-log-acquisition, on main). Open: the live-roboRIO task (throughput, sha256sum on the rio), a real USB stick on Linux and Windows (macOS passed 2026-10-05), the Windows service, and the Windows CI job (group 9, still pending). The container moved out of P3 (ADR-0009 amended).

  • Follow-up, change acquire-replay-build (2026-10-15): after a successful derive the acquire cycle (watch and one-shot, not a dry run) runs an incremental flashpoint report as its own process, between derive/detect and backup, so a new match reaches Replay without a restart; a running serve lists it after a page reload. A failed or locked build stays owed (persisted as report in the watch status, shown by doctor) and is retried each cycle. flashpoint report now holds meta/report.lock and exits 3 when another build has it. Spec placement: the requirements live in match-reports ("Replay data kept current by the acquire watch", "One Replay build at a time") because acquisition-service exists only in the unarchived p3-log-acquisition change. When P3 archives, add the Replay build step between derive and backup in acquisition-service's "One-shot and watch modes" list. Implemented as PR IgniteRobotics/flashpoint-private#59; archived 2026-10-15 (specs synced: match-reports). Pit check ([HUMAN] 4.3) is open.

Scope

  • SFTP puller (paramiko or asyncssh, [Background]):
    • copies to the inbox, verifies size and hash, and never deletes on the robot by default;
    • is aware of rotation: warn when robot free space is under 100 MB, since WPILib and Phoenix prune at 50 MB (WPILib Developers, 2026b; CTR Electronics, n.d.-a).
  • Removable media: USB sticks (macOS, Linux, Windows) are a pull source next to the robot, read-only and hash-verified. Manual inbox drops still work.
  • Watcher: flashpoint acquire --watch cycles robot, volumes, ingest, derive, the Replay build and backup.
  • Packaging: a systemd user unit with a correct ExecStart (pitfall 7) and a Windows scheduled task. Windows is supported. The container is deferred out of P3.
  • Backup: rclone copy of lake/raw (immutable) and a lake/meta snapshot [Background]. Replaces drive-backup.py.
  • Exit: plug in the robot, and within 5 min its matches show up in the views, unattended.

Moved from the rewrite roadmap on 2026-10-19. That doc keeps the dependency graph, migration, quality gates and risks. Status lives here. Author-year citations are in references.md. pitfall N refers to 03-pitfalls-and-performance.md.

Dominant language
Python
Stars
0
Forks
1
Avg merge
18h 37m
Merged PRs (30d)
15

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IgniteRobotics/flashpoint

All issues in IgniteRobotics/flashpoint

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.