Stanford OnlineStanford AA274A Principles of Robotic Autonomy | Autumn 2019 | The Robot Operating System (ROS)
Stanford Online
ROS and robotics 0:05
ROS, the Robot Operating System, is the software environment used in the class to build the autonomous stack across the quarter. It matters a lot in robotics, and if you work in the field, you are very likely to use it. The lecture will show what ROS is, give a demo, and prepare you to build and deploy your own stack on the robot used in the class.
Pub sub modularity 4:00
Robotics software is hard because it has many moving parts, so the usual answer is modularity. The class uses a design pattern called pub-sub, short for publish-subscribe. You break the system into modules, define a topic, and let each module publish messages or subscribe to receive them. Mailing lists and Reddit threads are close everyday examples, and ROS is an implementation of this pattern for robotics.
ROS foundations and wrappers 14:00
ROS is tied to Willow Garage and now to the Open Source Robotics Foundation in the Bay Area, which funds work on ROS, Gazebo, and related tools. It also brings in existing libraries through wrappers, so software you already know, such as OpenCV for vision or OpenSLAM for navigation, can be integrated with ROS more easily. The point is to reuse what already works and connect it cleanly to robot software.
Nodes master and messages 15:00
The core of ROS is nodes and a master. A node is a process, often like a Python script, that runs one algorithm and can publish or subscribe to topics. Topics carry messages such as camera images, laser scans, pose estimates, or motion commands. The master does not carry the data itself; it only sets up the connections between publishers and subscribers, then steps back.
Publisher setup 28:00
A simple Python node is shown first. It is named talker, marked anonymous so ROS can give it a unique ID, and set up as a publisher on the chatter topic. The message type is ROS String, not a plain Python string. A queue size limits how many messages are kept if the network falls behind, and a rate parameter controls how often the node publishes.
Subscriber callback 37:31
The same pattern is then reversed for receiving. A subscriber listens on chatter for String messages and names a callback to run when one arrives. ROS spin keeps the node alive and handles the repeated waiting for messages. The callback just takes the incoming message and prints it, but the same pattern can support heavier work if needed.
ROS nodes and topics 41:31
A node has to register itself with the master so the system knows it exists and can subscribe to or publish from it. The talker and listener example shows how messages move between nodes, and how ROS can queue messages, drop old ones, or keep only the latest if a publisher is faster than a subscriber.
Running and launching 43:01
The demo runs roscore, then starts a talker that publishes chatter at 1 Hz and a listener that receives it. ROS topic list shows what topics exist, and ROS topic hz reports the publish rate. For Python, you can use rosrun or run the script directly, but rosrun captures normal print output, so ROS logging is safer. Launch files then bundle nodes and parameters in one XML file. A launch file can set the talker rate to five hertz and start a whole stack together.
Launch file parameters 56:30
Launch files can set parameters, and you can override some of them from your own file. That is useful when a large launch file already wires up many cameras or devices. Sometimes it is easier to reuse someone else’s work. Other times it makes more sense to write the setup from the node yourself.
Workspace and packages 58:31
ROS development uses a catkin workspace. It is a directory on your machine that organizes packages so the build tools can find what they need. Inside the workspace you usually have a source folder, then packages, then scripts for Python nodes, plus launch files, config files, and C++ source. Python scripts must often be made executable before rosrun can find them. A package is usually a reusable chunk of robot capability, while the workspace holds several packages together.
Simulation and ROS 1:10:31
Use simulation first, because Gazebo can test physics and show whether your controller and path follower work. It matters that the simulator matches the software setup, so the same ROS nodes and messages can move from simulation to the real robot without rewriting everything. Use the wiki, GitHub, Stack Overflow, and TAs, and avoid ROS 2 for now.
AI-generated summary. It can be wrong or incomplete - check anything that matters against the original.
