Conversation
lsy3
force-pushed
the
docs/initial-design-proposal
branch
from
84ecd9e to
df9de93
Compare
Three founding documents for the rosgraph project: - MANIFESTO.md: project direction (why, what, how) - ROSGRAPH.md: full technical proposal (schema, architecture, phasing) - FAQ.md: audience-organized FAQ covering 9 perspectives Signed-off-by: Luke Sy <sylukewicent@gmail.com>
lsy3
force-pushed
the
docs/initial-design-proposal
branch
from
df9de93 to
0450557
Compare
- FAQ: reduce from 880 to ~360 lines, add General section with cross-cutting questions, keep 2-3 essential per audience - FAQ: fix all PROPOSAL.md cross-references to ROSGRAPH.md - FAQ: add launch file / param config convergence question - ROSGRAPH §3.2: add "Toward a single source of truth" note on system.yaml replacing launch files and parameter configs - ROSGRAPH §12: remove resolved questions section (internal notes) Signed-off-by: Luke Sy <sylukewicent@gmail.com>
|
|
||
| ## Why | ||
|
|
||
| Robotics engineers spend too much time on ROS plumbing — writing boilerplate, debugging invisible wiring, and keeping launch files in sync with code — instead of building their application. |
There was a problem hiding this comment.
as systems get larger, they become harder to reason about. The lack of a "well defined" interface (topic, service, action) contracts makes this even harder. It also excludes any ability to have automated tools to give leverage over this problem
emersonknapp
left a comment
emersonknapp
left a comment
There was a problem hiding this comment.
Some comments from our discussion today.
|
|
||
| ## Why | ||
|
|
||
| Robotics engineers spend too much time on ROS plumbing — writing boilerplate, debugging invisible wiring, and keeping launch files in sync with code — instead of building their application. |
There was a problem hiding this comment.
Want to call out that the main interfaces of ROS systems (topics, parameters, services) are by default undocumented and don't have a story for how to do so easily and consistently. Code APIs can be generated but aren't how most users interact with most ROS packages
|
|
||
| ## What | ||
|
|
||
| A declarative, observable ROS graph. Engineers declare what their system should be; tooling generates the code and verifies the running system matches the spec. |
There was a problem hiding this comment.
code and entities as needed
| covering the four goals of the ROSGraph Working Group: | ||
|
|
||
| ``` | ||
| rosgraph |
There was a problem hiding this comment.
Seeing this more as specific components that may or may not be wrapped by user interfaces like a CLI:
- Node spec
- Code generation
- Runtime discovery
- Node-level unit testing
- Graph analysis & comparison (integration-level testing)
- Documentation generation
There was a problem hiding this comment.
Call out order of importance:
- Node Spec (NoDL) most core part of the whole thing.
- Then, code generation and runtime discovery are the equal-importance next key components to making that NoDL useful.
nodl-generator takes NoDL input and outputs code for a ROS Client Library.
rclcpprclpyrclrs??
Open question: implementation language for the generator tooling?
Hard requirement: nodl-generator is installable as part of a ROS distro (apt-get install, etc)
There was a problem hiding this comment.
Architecture requirement for codegen, sidechannel plugin for other language client libraries - rcljava or whatever
3 participants
Summary
Founding design documents for the rosgraph project:
docs/MANIFESTO.md— project direction: why, what, how (short)docs/ROSGRAPH.md— full technical proposal: schema, architecture, phasing, prior art, 51 features across 7 subcommandsdocs/FAQ.md— audience-organized FAQ covering 9 perspectives (new ROS dev, AI-assisted dev, eng lead, safety engineer, nav2/MoveIt user, skeptic, package maintainer, educator, embedded dev)Context
These documents are the starting point for WG discussion. The PR serves as the review and acceptance process — please comment inline.
Key sections in ROSGRAPH.md