I teach a robotics lab and my students lose about a week each semester to
workspace and sourcing problems before they write any robot code. I recorded
the whole thing end to end on Jazzy, including the errors rather than a clean
take: workspace, package, first node, entry points, --symlink-install, and
why sourcing is per-terminal.
It’s aimed squarely at first-week beginners. Happy to take corrections —
I’d rather fix a video than leave something wrong in front of students.
In our robotics course, we have however decided to hide most of these things from the students. Our startup script autoruns colcon build, sources the correct file, changes the shell prompt and that’s how students know that “ROS works in this window” (it also runs everything in the correct Apptainer image).
Our students never try to create a ROS package, they never create a new file in the packages we provide, and they never write any file from scratch (so they can’t forget shebangs). All they do is fill in TODOs we’ve left them in the code and then run the code and debug its behavior.
I was long opposing this approach, but in the end I agree.
The things you describe in your video are beginner mistakes that are relatively easy to find answers for once students need them (although it takes some time). We try to focus on the more complex parts - writing and testing algorithms in real and in sim, finding out if a part of the system works as expected, hitting real-world limits and noise, or high-level behavior design.
Of course this is not a criticism of your course. It’s definitely great you care about your students in this way and you tech them ROS! I just wanted to add our point of view which (I hope) might be useful to others.
@aaish most Jazzy material still works on Lyrical. Nodes, topics, services, actions, params, launch, colcon, and workspaces haven’t changed in any way a beginner would notice. The official docs have a distro selector; set it to Lyrical and follow the beginner CLI + client library tutorials in order. Where something breaks, it’s usually at the package/API edges, not the concepts. For example, ros2_control just removed APIs that had been deprecated since Jazzy, so older controller examples can fail on Lyrical.
on learning with AI, two things made it much less “limited” for me:
give it the exact error plus your package.xml / CMakeLists / setup.py and say which distro you’re on. Most bad answers come from it guessing Humble.
check against what’s actually installed, not what it remembers. ros2 interface show, ros2 pkg prefix <pkg>, and reading the installed headers/python will tell you the real API on your machine.
also +1 to both approaches above. Hiding the sourcing/build mess lets students get to robot behavior fast, but at some point you have to break it once on purpose. Delete your install/ folder, forget to source, and see what errors you get. After that, “package not found” stops being scary.