RoboOps

Operator console for an AMR/AGV integrated remote fleet-control platform — 30 interactive screens rendered as a navigable React app, driven entirely by design-data JSON committed in this repository.

About · Screens · Getting Started · Paper · Data Layout · Refresh · Deployment · Roadmap · Sponsor · License

---

What is RoboOps?

RoboOps is a local, fully client-side operator console for an AMR/AGV remote fleet-control platform. The entire UI — 30 screens, 8 user flows, navigation, and modal dialogs — is rendered at runtime from Manyfast wireframe JSON stored under src/data/, alongside the exported feature specs (8 requirements · 25 features · 51 specs).

That makes the repository three things at once:

• a running operator console you can click through end-to-end (npm run dev),
• a living design document — the PRD, feature specs, and user flows ship as data next to the code,
• a wireframe renderer (src/wireframe/) that turns page-tree JSON into React components, wiring navigate / open-modal / close actions between screens.

Honest scope — every number, robot ID, and chart you see is wireframe placeholder data. There is no live robot, telemetry, or backend connection yet; that adapter layer is on the roadmap.

Screens

30 screens across seven functional groups (sidebar order):

Group	Screens
인증 (Auth)	로그인 화면 · 역할 선택/인증
관제 (Monitoring)	통합 관제 대시보드 · 로봇 목록/그리드 · 지도 기반 실시간 뷰 · 로봇 상세 상태 패널
알람·장애 (Alarms & Faults)	알람·장애 관리 · 실시간 알람 수신 · 알람/장애 이력 조회 · 장애 티켓 상세 · 센서 데이터 수집
원격 제어 (Remote Control)	원격 제어 · 비상/일반 정지 · 재시작 제어 · 수동 조이스틱 제어 · 미션 개입
맵 관리 (Map Management)	맵 관리 · 맵 목록 · 맵 생성/가져오기 · 맵 편집기 · 맵 버전/배포 관리 · 경로/목적지 설정
시스템 관리 (System Admin)	시스템 관리 · 사용자 계정 관리 · 역할/권한(RBAC) 설정 · 로봇 등록/수정 · 현장·구역 관리 · 연동 헬스체크
분석 (Analytics)	KPI 분석 대시보드 · 감사 로그 조회

지도 기반 실시간 뷰	원격 제어
KPI 분석 대시보드

All values shown are wireframe placeholder data rendered from the committed JSON — not live fleet telemetry.

Getting Started

Requires Node.js 22, the version the paper's benchmark and CI use. The first-round benchmark also reproduces the committed records under Node.js 20.20 and 24.21 (checked on the development host).

npm ci          # or: npm install
npm run dev

Open in your browser:

URL	Screen
http://localhost:5173/page/n2	로그인 화면 (default entry)
http://localhost:5173/pages	Index of all 30 screens
http://localhost:5173/page/n6	통합 관제 대시보드

/ redirects to /page/n2. Use the /page/ prefix — /n2 alone will not work.

Buttons with navigate actions move between screens; open-modal / close toggle overlay dialogs.

Production build:

npm run build
npm run preview      # serves dist/ (default http://localhost:4173)

FMS algorithm module (src/fms/)

Framework-free TypeScript implementing a lifelong fleet manager, exercised in the console at /fms (sidebar → 시뮬레이션):

Path	Contents
src/fms/map/	4-connected grid model, ASCII loader, benchmark layouts (small, warehouse, narrow with one-lane aisles, and console, generated from the zone/line/dock vocabulary of the wireframes via npm run extract:console-site)
src/fms/alloc/	Hungarian (rectangular, infeasible pairs) and greedy assignment; static, congestion-proxy and path-aware cost models with a battery term
src/fms/mapf/	windowed space-time A*, reservation table with holds, prioritized planning with hold cascade, windowed CBS, conflict checks, and the unwindowed token table of the token-passing baselines (TP, TPTS)
src/fms/charging/	two-threshold battery policy, per-slot charger capacity
src/fms/sim/	seeded discrete-time lifelong simulator (Poisson task stream, rolling-horizon replanning, endpoint capacities, dwell, stall detector), token-passing baselines, metrics, and the independent trajectory auditor (audit.ts)
scripts/bench-fms.ts	benchmark driver → paper/experiments/results/ (JSON + CSV, committed)
scripts/regenerate.sh, scripts/measure-timing.sh	regenerate all results at the current commit; measure the reported wall-clock numbers on a quiet host
scripts/check-paper.ts, scripts/check-results.ts	number guard for the paper; field-by-field comparison of a re-run with the committed records
paper/arxiv/	the paper describing and evaluating the module

npm test              # vitest: Hungarian vs brute force, MAPF property tests, CBS vs exhaustive, token passing, auditor, determinism
npm run check:paper   # number guard: every table and every number in the paper against the committed results

Run one simulation from the command line (prints the metrics of the run as JSON):

npx tsx -e "import { runSimulation } from './src/fms/index'; console.log(runSimulation({ layout: 'warehouse', fleetSize: 16, numTasks: 50, alloc: 'pact', seed: 1 }))"

Paper

paper/arxiv/ holds the manuscript PACT: A Conflict-Free Lifelong Fleet Manager for Warehouse AMRs and a Controlled Study of Reservation-Aware Pickup Costs (Jungmo Kang, 2026; preprint, not peer reviewed). It describes src/fms/ and evaluates it in simulation only: there is no real robot and no fleet connection anywhere in this repository. The study's main result is negative and weak: the reservation-aware pickup cost did not measurably change throughput in the tested settings, and recorded counters show that it changed the task matching in only 1–14 % of the allocations. The default charging policy strands robots under doubled battery drain. Both are reported in the paper.

Reproduce the results (Node.js 22; durations measured on a 6-core Ryzen 5 5500GT):

npm ci
npm test
npm run bench:fms -- main planner scaling ablation battery --out /tmp/pact-rerun   # 420 runs, one process, about 2 min
npm run check:results -- /tmp/pact-rerun   # field-by-field comparison with the committed records
npm run check:paper                        # tables, figure data and every number in the text

• All ten sweeps: npm run bench:fms -- --jobs 8 --out /tmp/pact-rerun (7,200 runs, about 20 minutes with 8 worker processes), then check:results as above.
• Without --out, bench:fms overwrites paper/experiments/results/.
• Every field of a run is deterministic given its seed except the four wall-clock fields (wallMs, plannerMs, allocMs, plannerMsPerTick), which check:results leaves out. CI repeats the 420-run comparison on GitHub's runners under Node.js 20, 22 and 24.
• The committed records were written by bash scripts/regenerate.sh 8 at commit 63a2db7. The script re-runs all ten sweeps at the current commit, refuses to replace the committed records if any field that existed before differs, and then replaces them (paper/experiments/repro/regeneration.json holds the comparison).
• Planner times in the paper do not come from those records. bash scripts/measure-timing.sh measures them (planner, scaling and ablation sweeps, one process, three repeats, about 5 minutes). It starts a repeat only when the 1-minute load average is at most 0.50, records the load and the top CPU consumers before and after each repeat in paper/experiments/timing/, and marks a repeat invalid when the host was busy.
• npm run check:paper -- --update-pins rewrites paper/experiments/guard/pins.json after a reviewed change to a formula or to a number written as a word.
• npm run paper:data rewrites paper/arxiv/tables/*.tex and figures/data/*.csv from paper/experiments/results/. paper/arxiv/NUMBERS.md maps each number in the paper to its source field.
• Build the PDF with pdflatex main && pdflatex main && pdflatex main in paper/arxiv/ (the .bbl is committed; a TeX Live with pgfplots and algorithm2e is needed).

To cite the software or the paper, see CITATION.cff.

Data Layout

Path	Contents
src/data/manifest.json	Export metadata (timestamps, counts, project/version IDs)
src/data/summary.json	Wireframe page index (30 screens)
src/data/project-full.json	Full Manyfast project blob (read_project)
src/data/project-meta.json	PRD summary markdown + stats (read_project_meta)
src/data/feature-specs/	기능명세서 — requirements, features, specs, PRD overview, hierarchy index
src/data/pages/*.json	Per-page wireframe trees from Manyfast
src/data/user-flows/	유저플로우 — list.json + 8 flow detail exports

Refreshing the design data

The design data is exported through the Manyfast MCP server (auth is session-bound to an MCP-connected editor session — standalone scripts get HTTP 401). From such a session:

1. Re-fetch project: read_project → project-full.json; extract feature-specs/ (requirements, features, specs, index)
2. Re-fetch meta: read_project_meta → project-meta.json
3. Re-fetch wireframes: read_wireframe scope summary + scope page for each page in summary.json
4. Re-fetch user flows: read_user_flow mode list + mode detail for each version → user-flows/
5. Update manifest.json with exportedAt and manyfastUpdatedAt

Project and wireframe-version IDs live in src/data/manifest.json.

Deployment

RoboOps is a plain static web build — the same dist/ runs on Linux and Windows; only the delivery differs by audience.

• Internal URL — npm run build output in dist/ served by nginx, IIS, or any static host; users open a link in Chrome/Edge.
• Portable folder — zip with pre-built dist/ plus a small start.bat / start.sh that opens the default browser (no install, but not a native .exe).
• Desktop installer — planned (see roadmap); the app today is browser-only.

Roadmap

• 30 wireframe screens navigable end-to-end (navigate / modal actions wired)
• Feature specs, PRD summary, and 8 user flows shipped as data alongside the UI
• Desktop packaging — Tauri or Electron wrapping the dist/ build, shipped via GitHub Releases
• Fleet-management algorithms (allocation, MAPF, charging) with an in-console simulator (/fms)
• Live telemetry adapter — replace placeholder data with a real fleet API
• English UI locale (screens are currently Korean-first)

Sponsor

If RoboOps saves you time, consider sponsoring. Sponsorship funds maintenance, new features, and faster issue response. 💛

License

Apache License 2.0 — see LICENSE. This covers the code and the data in this repository; the manuscript in paper/arxiv/ is by the same author and will carry its own licence where it is posted.

Acknowledgements

The screen structure, feature specs, and user flows were designed in Manyfast and exported to JSON; the renderer in this repository turns those exports into a navigable console.