Ideas for a ROS skill tree

A thread to discuss ideas and implementation for a ROS Skill tree to give an accurate understanding for a beginner, “so they don’t bite off more they can chew”.

To give some context why this post was made.

Here is a version already made by @Katherine_Scott:

Again, ideas are welcome here

4 Likes

[A Repost to consolidate all ideas]
A suggestion would be to add a horizontal band (like the arrow that showed how advanced each topic is - from the example @Katherine_Scott had provided) demarcating a place on the skill tree. Showing the reader that “you have learned just enough and now the scale of your projects actually warrants the use of ROS”.

That is, you actually have multiple sensors, motors and actually need to relay data for computation or decision-making process or both. Which does require the benefits of a middle-ware such as ROS.

Most times (at least from I am from) beginners, such as myself, started to use ROS just to use ROS and that makes a simple problem that would take 2 days into a 2-month problem, because now you are more busy with project structure and builds rather than the project itself.
Complexity with none of the benefits (As a beginner, you have no idea what you need). As a beginner, this leads to quick burnout.

Here are bunch of my ideas:

  1. I think that in such skill tree there should be a split for 2 sub-trees to master manipulation and navigation stacks. On the highest levels these leafs should merge for even more complexity.

  2. For the starters I think the start of the tree should focus on steps to describe a robot. Starting learning about frames of reference and transforms between them (with tf2) is easier than throwing whole DH notation and the concept of DoFs.

  3. For me, having skills to understand and write URDFs sounds like a level comparable to basic experience with CAD modelling and 3D printing parts for a robot. An essential skill n the side of electronics would be an ability to connect cables on bread board with a MCU to read some sensors’ data with serial terminal.

  4. Maybe it should make sense to group absolute minimal, basic knowledge about electronics/mechanics/programming/networking as separate mini-trees, which should be at the beginning of the whole tree.

1 Like

So using @macale ideas of combining leaves and complexities with multiple sub-trees.

I PRESENT.

SOFTWARE STACK

ROS 2 Programming Skill Tree
|
└─── [A] ROS 2 Basics
     ├─── Level 1: Install ROS 2 and run demo nodes
     ├─── Level 2: Create a publisher and subscriber
     └─── Level 3: Use ROS 2 CLI tools for inspection and debugging
|
└─── [B] Robot Simulation (Prerequisite: [A])
     ├─── Level 1: Introduction to Gazebo and RViz for ROS 2
     ├─── Level 2: Create and manage simulated robots
     └─── Level 3: Advanced simulation and custom sensor integration
|
└─── [C] Navigation and Perception (Prerequisite: [B])
     ├─── Level 1: Implement obstacle avoidance using lidar
     ├─── Level 2: Utilize ROS 2 navigation stack
     └─── Level 3: Integrate SLAM for mapping and localization
|
└─── [D] Robot Control Systems (Prerequisite: [C])
     ├─── Level 1: Understand ROS 2 control frameworks and controllers
     ├─── Level 2: Design and integrate custom controllers
     └─── Level 3: Implement advanced control strategies and real-time processing
|
└─── [E] Real Robot Integration (Prerequisite: [D])
     ├─── Level 1: Basic hardware interfacing and robot setup
     ├─── Level 2: Implement autonomous behaviors and safety systems
     └─── Level 3: Complex system integration and multi-robot systems
|
└─── [F] ROS 2 Best Practices (Prerequisite: [E])
     ├─── Level 1: Code organization, package management, and build systems
     ├─── Level 2: Unit testing and continuous integration
     └─── Level 3: Documentation, community involvement, and open-source contribution

HARDWARE STACK

Robotics Hardware Skill Tree
|
└─── [A] Basic Electronics
     ├─── Level 1: Build a circuit on a breadboard that lights up an LED
     ├─── Level 2: Create a circuit with a sensor controlling an actuator
     └─── Level 3: Program a microcontroller for sensor input and actuator control
|
└─── [B] Mechanical Design (Prerequisite: [A])
     ├─── Level 1: Assemble a simple gear train
     ├─── Level 2: Design a mechanism for motion conversion
     └─── Level 3: Design a simple robotic arm and calculate its reach
|
└─── [C] Advanced Electronics and Control (Prerequisite: [A])
     ├─── Level 1: Control multiple sensors and actuators with a microcontroller
     ├─── Level 2: Establish communication with devices using protocols
     └─── Level 3: Design a PCB integrating a microcontroller, sensors, and actuators
|
└─── [D] Sensor Integration (Prerequisite: [C])
     ├─── Level 1: Build a system with temperature and distance sensors
     ├─── Level 2: Integrate an IMU and LIDAR
     └─── Level 3: Implement sensor fusion for accurate positioning
|
└─── [E] Robotics Systems (Prerequisite: [B] + [D])
     ├─── Level 1: Construct a mobile robot platform
     ├─── Level 2: Implement autonomous navigation
     └─── Level 3: Create an advanced robotics project with 3D cameras and drones

Components of the Tree Structure

  • Root Node: The root of the tree represents the starting point of the skill learning journey. In this case, the root is implicit, as the focus is on the main categories (e.g., Basic Electronics, Mechanical Design) rather than a single starting point, so people can start where they wanna start, without a skill issue.

  • Branches (Categories): Each branch or category represents a major area of focus within robotics hardware, such as Basic Electronics, Mechanical Design, Advanced Electronics and Control, etc. These branches stem from the root and symbolize broad areas of knowledge or skill sets.

  • Nodes (Levels): Nodes represent specific skills or tasks within each category. They are structured in levels, indicating a progression from simpler to more complex concepts or tasks. Each node is a prerequisite for the nodes that follow, ensuring a logical flow of learning.

  • Leaves (Tasks): The leaves of the tree, which are the end points of each branch, represent the tasks or challenges to be completed to demonstrate mastery of the corresponding skill level. These tasks are practical applications of the skills learned at each node.

NOTE: This is not my original idea courtesy of tree structuring and tree structure databases, just customized to our use case.

6 Likes

To balance out with some theory, how about: learn calculus, statistics/estimation, rigid body dynamics, linear algebra, differential equations and maybe a little control theory :stuck_out_tongue:

3 Likes

I really like this as a mentor for people new to ROS, often I find they go too far in one area before understanding a few more fundamental areas. That said, I feel like it would be good to have multiple views of the same tree: a skill based view and a project based view, so that people could choose projects that would teach them that skill (e.g. bash I, bash II, corresponding to modifying bashrc, and piping into grep).

I would also suggest that a few different suggested progressions would be provided for common routes (e.g. electrical focus, mechanical focus, software focus, autonomy focus) (I guess this was also suggested here).

@Katherine_Scott How can one add this(ROS Skill tree/ “progression tree”) to the docs ?
As this will be an entirely new topic on the docs, I thought of consulting with you.

I would want to see a completed skill tree finished and then we talk about where it lands on the docs. I would imagine here would be a good place but I would need to talk it over with the other maintainers.

Would the completed skill tree be in an image format or in text format or is it something else ?
Are there some quality guidelines ?

If I can share my opinion… as a ROS user since a couple of years, I found really difficult the creation and comprehention of CMakeLists. I have no doubt that this problem relies in C/C++ concepts, but there are a lot of people (included myself) that started programming ROS and encounters many problems and little info regarding these concepts. It would be interesting to have some objectives related to package creation for a small project.

1 Like

It would be interesting to have some objectives related to package creation for a small project.

Can you elaborate by what you mean ?

I think you misinterpret this as “something we have done / are doing right now” versus something “that could be done.” If you have have a proposed solution go for it.

1 Like

Yes, the tutorials I have encountered request the creation of some nodes, but the libraries, modules, etc. used are imported from the main package the tutorial is based on. It would be great to somehow have one or two tutorials on how to create (using the standard way) a package explained deeply. I mean, first doing the basic stuff such as creating an executable to a C++, ending with how the ws is distributed (what means the colcon build feature and each directory created inside a ws, tips for modifying the CMakeLists, etc.). I remember my first project in ROS, I had little to no clue about what was happening when I was building the package, and that resolved that when I had a problem compilling, it was very dificult to me to understand the hints from the compiler.

Just a basic draft.

Should Everything be on the same page, or each tree have a different page.
Trying to make it more interactive injecting JS, but that might break the design style of the docs.

2 Likes

Good start. I think an interactive page would be most accessible, so you could select common tracks, etc.
If we really wanted to make this motivational, it could be gameified with an achievement system tied to user accounts and maybe simple quizzes for each skill.

I put together a quick interactive prototype of what I was thinking: Dev Boards Skill Tree
It’s very basic and could use some significant styling work (for fit, images, and more), but it presents all the ideas I was thinking of.

Source: GitHub - RMichaelSwan/skill_tree: Working prototype of interactive ROS skill tree

2 Likes

This is a really nice prototype.
Adding interactive pages will be split from original ROS docs as it breaks the project structure with JS injections.
I am still waiting for a response on my pull request on ROS Docs, but I think this is the way forward.

1 Like