ROS 2 Learning Path Architecture v0.1 — 14 programs benchmarked, zero competency models: a skill tree and gap map for discussion

[NemanjaGalic]

TL;DR: Of 14 robotics programs I benchmarked, none defines a competency model, none offers a branched progression, and none gives an open learner criterion-referenced assessment. Below is a proposed ROS 2 learning path architecture — a v0.1 discussion draft for the people who teach and learn ROS to shape. It is not a course, not a product, and nothing is for sale.

Every structured ROS 2 curriculum I could find is a linear sequence: Phase 1→5, Week 0→6, Course 1→6. That looks reasonable — it is how books and MOOCs have always been organized, and course-level learning outcomes are an academic norm (Northwestern states them per course; TU Delft’s MOOC has five testable “What you’ll learn” statements).

What nobody defines is the layer above: what a ROS 2 developer at a given stage can demonstrably do, independent of any one course. Curricula, competency models, and assessments are my day job in learning and development; in the ROS ecosystem I am an active community member and open-source builder rather than a core maintainer. Over the past few weeks I mapped the ROS 2 learning landscape the way I would for any curriculum project — benchmarking 14 programs from their own primary sources, mining learner threads, sampling job postings. The community has asked for this structure for years: the skill-tree thread (36382) asks for a curated progression so newcomers don’t bite off more than they can chew, and ROSCon UK 2025 educators concluded that “Great reference material isn’t always great teaching material” (50587). So here is a v0.1 to argue with. Everything below is desk research, and every claim carries its source.

The market has a hole where the architecture should be

Across 14 programs benchmarked from provider primary sources (retrieved 2026-07-13 to 2026-07-15), the four structural findings all score zero — while universities withdraw from the open segment. Open, current, university-grade ROS 2 teaching is effectively unavailable, which leaves the structured segment to commercial providers.

The retreat has a structural reading: the retired offerings were project-funded — TU Delft’s MOOC was built under the EU ROSIN grant — and nothing in university incentives pays for maintaining open materials against ROS’s release cadence. If that holds, no single institution will carry an open learning layer for long. The architecture below is therefore designed to be community-maintained and contribution-based — the same model that keeps the ROS documentation itself alive — rather than handed to any one provider.

On the demand side, I sampled 11 job postings (7 from /c/jobs, 4 from Indeed; small sample — calibration, not statistics): 10/11 ask for production-level ROS 2, 8/11 for C++ and Python, 5/11 name navigation/SLAM, 5/11 real-time or embedded experience. The most useful short definition of the target level: “you know ROS 2 well enough to have opinions about it” (55337). All of this sits beyond the official tutorials, which describe themselves as “not meant to be comprehensive documentation”.

1. Competency model: define stages by observable work, not course completion

The model is designed backward from that employability threshold, not forward from a tutorial table of contents. Four stages, loosely following the Dreyfus model of skill acquisition; the fifth Dreyfus stage, expert, is intentionally out of scope — expertise beyond the employability threshold grows in production practice, not in a curriculum. Every outcome is a “can …” statement that an assessor, a peer reviewer, or the learner can verify by observing work.

The complete v0.1 outcome set, each verifiable by observing work rather than by checking completion. Two of the Stage 4 outcomes are safety-related by design — an extension beyond what the job sample asks for by name; the safety slot below argues why.

2. Skill tree: encode which skills unlock which — not teaching order

Everything enters through CLI-based introspection against a provided, containerized running example: reading a running system before writing code for one. The first system is provided, not built, because instructors report losing large parts of their teaching time to setup alone (32588) and containerized environments can cut setup from weeks to minutes (50587). From there, the client libraries — rclpy and rclcpp side by side, since 8 of 11 postings ask for both languages — carry the workspace tooling (package creation, colcon builds, overlay sourcing), and the tree branches:

tf2 + URDF is the backbone: Nav2 and MoveIt 2 both consume the TF tree, and simulation consumes the robot description, so weakness in either surfaces as mysterious failure everywhere downstream. Prerequisite order is not teaching order — the three syllabi I analyzed in depth (Udacity, The Construct, TU Delft) all independently open with visible robot behavior before any API systematics.

Nav2, MoveIt 2, and Gazebo are docking points, not curriculum members: those stacks have their own documentation and communities, and the tree only defines what a learner must carry to the interface. Two omissions are knowingly open in v0.1 — ros2_control, which every real bring-up crosses, and perception/sensor fusion, named in 4 of 11 postings — both are questions for this thread (full list below).

3. Gap map: five places the evidence shows learners falling out

Each gap is tied to a journey phase and a public source. The transfer gap is where the job-market threshold (Nav2/SLAM named, CI/CD, both languages) lies beyond the official tutorials’ self-declared scope — the reference-vs-teaching distinction ROSCon UK educators drew directly.

One design answer belongs in text: the feedback gap. 1:1 mentoring does not scale, so the default mechanism here is structured peer review against rubrics, with reviewers calibrated on worked exemplars before their first review — the condition the peer-assessment literature ties to reliability (Falchikov & Goldfinch 2000). That turns the community’s existing strength, reviewing each other’s work, into the learning mechanism the benchmark found missing everywhere. One boundary stated plainly: structured peer review is a feedback mechanism, not a summative assessment — for open learners, the assessment gap stays open in v0.1.

4. Safety & HRI literacy: a slot, not a stage

Normative safety content is nearly absent across the field; the single exception is instructive — MIT xPRO carries a dedicated Human–Robot Interaction module behind a $2,700 fee, with no ROS anywhere in its published module list. The slot grows with each stage, in three strands: risk-assessment vocabulary (hazard, harm, risk reduction — and the principle that safety functions are engineered and certified rather than emergent from application code); a standards map at “know it exists and when it applies” depth, not legal depth (ISO 10218, ISO 13482, ISO 13849, VDA 5050, ANSI/ITSDF B56.5 — the last two already appear verbatim in one integrator posting, 55229); and human-robot signaling as a design discipline, taught from the existing research base rather than invented — expressive light signals (Baraka et al. 2016; Cha et al. 2018), eHMI taxonomies from the autonomous-vehicle field (Dey et al. 2020), and open draft proposals in this space (for example the Luminae Signal Expression Protocol (LSEP), an MIT-licensed draft spec for robot state signaling that I maintain) — all of them objects of study for comparison, none of them settled standards.

5. A contribution template where the energy already flows

The docs repo is where community energy already goes: ros2_documentation has accumulated 6,399 pull requests, roughly 2.8 times the count of rclcpp (checked 2026-07-21), and an open issue asks for exactly the missing beginner coverage (#6827). Proposal: a small, optional header for tutorial-type documentation PRs that aligns each page with a learning outcome.

<!-- Learning-contribution header (optional, tutorial pages only) -->
Outcome:   After this page, the reader can <verb + object + condition>.
Stage:     2 (Builder)        <!-- 1 Explorer | 2 Builder | 3 Integrator | 4 Production developer -->
Requires:  tf2 + URDF         <!-- prerequisite nodes from the skill tree -->
Verify:    <the command or behavior the reader runs to confirm success>
Tested on: <date>             <!-- distro is already implied by the docs branch -->

The cost is one comment block per page. The payoff: pages become findable by stage, gaps become visible, and version rot becomes explicit through the “Tested on” line. This is designed to be compatible with the ongoing 3di overhaul (53682), not parallel to it — the header is metadata, not restructuring.

What I would most value from people who teach or maintain

Three questions first:

1. Where do students actually stall in your courses? Does the Builder→Integrator boundary (single nodes → integrated system) match what you see, or does the wall sit somewhere else?
2. Which of the Stage 2–4 outcomes do you already assess today, and with what instruments? I would rather collect existing rubrics than invent new ones.
3. If this turns out to be useful, where should it live — a revived Education WG, the docs repo, or a standalone community repo?

All nine questions

1. Stage boundaries: In your courses, where do students actually stall? Does the Builder→Integrator boundary match what you see?
2. Prerequisite edges: The competency model places QoS at Stage 2, before Stage-3 Nav2 bring-up, but the prerequisite graph encodes no QoS → Nav2 edge. Should it, or is QoS better learned as debugging vocabulary after the first failure?
3. Existing rubrics: Which of the Stage 2–4 outcomes do you already assess today, and with what instruments?
4. The PR header: For documentation maintainers — useful metadata, or contribution friction?
5. The backbone claim: Is tf2/URDF over-weighted or under-weighted as the central prerequisite node?
6. Language sequencing: Do you introduce rclpy and rclcpp in parallel or staggered, and at what cost?
7. Perception: The job sample names perception/sensor fusion 4 times out of 11, yet the tree has no perception node. Where should it dock? The same question applies to ros2_control, which every real bring-up crosses but the tree currently omits.
8. A home: A revived Education WG, the docs repo, or a standalone community repo? The university-retreat pattern above is my argument for a community-carried home; if you read that pattern differently, say so.
9. Open assessment: Can rubric-based peer review be hardened into trustworthy open assessment (calibration, moderation, multiple reviewers), or does open assessment need a different instrument altogether?

Method and limitations, plainly stated

• Desk research only: no interviews, no learner observation. The quotes reflect what people chose to post publicly. (Reddit blocks direct programmatic access, so r/ROS quotes were verified through the public pullpush.io archive against their original permalinks.)
• The job sample is n=11 from two channels at one moment in time. Calibration, not representativeness.
• The benchmark relies on provider self-descriptions, not course audits from the inside. Several benchmarked programs teach robotics with little or no ROS 2 (the MIT OCW courses build on Drake, CS223A is ROS-free, Udacity nd209 and TU Delft’s MOOC are ROS 1-era); they are included because they are what a searching learner actually finds — and the split is itself a finding.
• The four-stage, Dreyfus-adjacent structure is a design decision, not an empirical finding. The stage boundaries are hypotheses.
• The Education WG appears dormant per the public record (32588, 39577; no documented meetings since late 2023). If that is wrong, I would like to be corrected, because it changes where this work should live.
• The path assumes a Linux shell, Git, and Python/C++ basics. It does not yet serve the hobbyists for whom the prerequisites themselves are the wall (“too complicated a subject, too diversified domain for a hobbyist”, 35900). A pre-Explorer on-ramp is out of scope for v0.1 by choice.

Conclusion

The architecture defines stages, not hours: the same competency model can run as a semester course, as part-time sprints, or as a self-paced path — and it accredits nothing and certifies no one. What it needs now is the judgment of people who actually teach ROS.

Would you use or adapt this architecture with your learners?

• Yes — I would adapt at least one component for my course or materials
• Maybe — it depends on how the open questions above resolve
• No — and a reply saying why helps me most

If this thread surfaces real interest, I will develop v0.2 in the open — assessment criteria attached to each stage outcome, collected from existing course rubrics rather than invented — incorporating whatever this thread surfaces. Disagreement with the architecture itself is as useful to me as refinement of it.