From 365d694a582d5059f14b87b13f10acb34440f25a Mon Sep 17 00:00:00 2001 From: loehub Date: Mon, 5 Oct 2026 20:30:47 +0200 Subject: [PATCH] docs: remove the outdated roadmap docs/roadmap.rst no longer reflects where the project is going, so drop it rather than leave stale plans in the published docs. Remove it from the Architecture table of contents and drop the README link. Nothing else in the docs or the selfpatch repositories links to it. --- README.md | 1 - docs/index.rst | 1 - docs/roadmap.rst | 175 ----------------------------------------------- 3 files changed, 177 deletions(-) delete mode 100644 docs/roadmap.rst diff --git a/README.md b/README.md index 2747ee580..182ffcdf3 100644 --- a/README.md +++ b/README.md @@ -183,7 +183,6 @@ ros2_medkit builds on them. It reads `/diagnostics` too, so keep your `diagnosti - [Documentation](https://selfpatch.github.io/ros2_medkit/) and the [step-by-step tutorial](https://selfpatch.github.io/ros2_medkit/getting_started.html) - [REST API reference](https://selfpatch.github.io/ros2_medkit/api/rest.html) and the [Postman collection](postman/) -- [Roadmap](https://selfpatch.github.io/ros2_medkit/roadmap.html) ## Contributing diff --git a/docs/index.rst b/docs/index.rst index 1adf85ec5..a09389dcb 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -98,7 +98,6 @@ Community :caption: Architecture design/index - roadmap .. toctree:: :maxdepth: 2 diff --git a/docs/roadmap.rst b/docs/roadmap.rst deleted file mode 100644 index d17bee1ee..000000000 --- a/docs/roadmap.rst +++ /dev/null @@ -1,175 +0,0 @@ -Roadmap -======= - -This document outlines the proposed development roadmap for ros2_medkit. -The plan is subject to change based on community feedback and project priorities. - -For the latest status, see the `GitHub Milestones `_. - -Strategy --------- - -**Developer-first, then system-wide.** - -The project follows a phased approach that prioritizes developer experience: - -1. **Start with Apps (ROS 2 nodes)** - The level closest to developers. Provide tooling - that makes their daily work easier: discovering nodes, reading data, checking faults. - -2. **Expand to full system** - Once app-level features are solid, extend coverage to - Components, Areas, and system-wide operations. - -3. **API coverage first, quality later** - The initial goal is to cover the entire - standard API surface using available ROS 2 capabilities. This enables early integration - with real projects and compliance validation. Code hardening and production-ready - implementations will follow in later phases. - -Milestones ----------- - -MS1: Full Discovery & Data Access - Complete -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**Goal:** Provide a complete view of the ROS 2 system and enable basic data operations. - -Developers can discover all running nodes, explore the entity hierarchy, and read/write -diagnostic data. This milestone establishes the foundation for all subsequent features. - -**Standard API coverage:** - -- [x] Discovery (11 endpoints) - version info, entity collections, hierarchy navigation -- [x] Data (5 endpoints) - data categories, groups, read/write operations - -`MS1 on GitHub `_ - -MS2: App Observability - Complete -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**Goal:** Enable developers to monitor application health and diagnose issues. - -With observability features, developers can check fault codes, browse logs, and monitor -the lifecycle state of their nodes - essential for debugging and troubleshooting. - -**Standard API coverage:** - -- [x] Faults (4 endpoints) - list, inspect, and clear diagnostic faults -- [x] Logs (5 endpoints) - browse and configure application logs -- [ ] Lifecycle (6 endpoints) - status, start, restart, shutdown operations - -`MS2 on GitHub `_ - -MS3: Configuration & Control - Complete -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**Goal:** Allow developers to configure and control running applications. - -This milestone brings configuration management (backed by ROS 2 parameters) and -operation execution, giving developers runtime control over their nodes. - -**Standard API coverage:** - -- [x] Configuration (5 endpoints) - read/write configuration values -- [x] Operations (7 endpoints) - define, execute, and monitor operations -- [ ] Modes (3 endpoints) - entity operating modes - -`MS3 on GitHub `_ - -MS4: Automation & Subscriptions - In Progress -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**Goal:** Enable automated workflows and reactive data collection. - -Developers can set up scripts for automated diagnostics, subscribe to data changes, -and define triggers for event-driven workflows. - -**Standard API coverage:** - -- [x] Scripts (8 endpoints) - upload, execute, and manage diagnostic scripts -- [x] Cyclic Subscriptions (6 endpoints) - periodic push-based resource delivery via SSE -- [x] Triggers (6 endpoints) - condition-based push notifications with hierarchy matching -- [ ] Datasets (4 endpoints) - dynamic data lists for subscription - -`MS4 on GitHub `_ - -MS5: Fleet & Advanced Features - In Progress -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**Goal:** Complete SOVD API coverage with fleet-oriented and advanced features. - -The final milestone adds capabilities for fleet management, bulk data transfer, -software updates, and authentication - completing the standard specification coverage. - -**Standard API coverage:** - -- [x] Bulk Data (5 endpoints) - large data transfers (upload, download, delete) -- [x] Updates (8 endpoints) - software update management via plugin framework -- [x] Auth (3 endpoints) - authorization, token refresh, and revocation -- [x] Locking (4 endpoints) - SOVD resource locking with scoped access control -- [ ] Communication Logs (5 endpoints) - protocol-level logging -- [ ] Clear Data (5 endpoints) - cache and learned data management - -`MS5 on GitHub `_ - -MS6: Fault Management System - Complete -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**Goal:** Add fault management to ros2_medkit with fault reporting, two-level filtering -(local + central), persistent storage, lifecycle management, and REST API access. - -This milestone introduces a complete fault management architecture that allows ROS 2 -nodes to report faults through a simple client library, with intelligent filtering -and central aggregation. - -**Key features:** - -- [x] **Two-level filtering**: FaultReporter (local) + FaultManager (central) -- [x] **Multi-source aggregation**: Same fault code from multiple sources combined into single entry -- [x] **Persistent storage**: Fault state survives restarts -- [x] **REST API + SSE**: Real-time fault monitoring via HTTP -- [x] **Backwards compatibility**: Integration with ``diagnostic_updater`` - -See :doc:`design/ros2_medkit_fault_manager/index` and :doc:`design/ros2_medkit_fault_reporter/index` -for detailed architecture documentation. - -`MS6 on GitHub `_ - -Beyond Milestones -~~~~~~~~~~~~~~~~~ - -The following features were added outside the original milestone plan: - -- [x] **Plugin Framework** - Load custom functionality from shared libraries with provider - interfaces (UpdateProvider, IntrospectionProvider, LogProvider, ScriptProvider) -- [x] **OpenAPI / Swagger UI** - Auto-generated ``/docs`` endpoint with interactive API explorer -- [x] **Vendor Extensions** - procfs, systemd, container, topic-beacon, and parameter-beacon - introspection plugins -- [x] **Rate Limiting** - Token-bucket-based per-client and per-endpoint rate limiting -- [x] **Graph Provider** - Function-scoped topology snapshots with per-topic metrics - -Future Directions ------------------ - -With most of the SOVD API surface covered, the project is shifting focus toward -production readiness and ecosystem integration: - -**Remaining SOVD Coverage** - Complete the remaining specification endpoints: communication logs, - clear data, datasets, lifecycle management, and entity operating modes. - -**Code Hardening** - Replace initial implementations with production-ready code. Remove workarounds - and refactor into smaller, well-tested packages. - -**Ecosystem Integration** - Deepen integration with ROS 2 tooling (Foxglove, MCP-based LLM workflows) - and commercial extensions (fleet gateway, fault correlation engine, OTA updates). - -**Additional Diagnostic Protocols** - Extend support to other diagnostic standards relevant to robotics and embedded - systems. - -**Transport Protocols** - Add support for alternative transport mechanisms beyond HTTP/REST. - -We welcome community input on prioritization. Feel free to open an issue or -join the discussion on `Discord `_!