Why is Pub/Sub the ideal communication pattern for ROS or robots in general instead of Request/Response?

edit

ROS tries to provide a framework for the most common/useful communication patterns. It just happens that the most common pattern of communication in robot applications is best represented by Publisher/Subscriber kind of communication.

Usually the sensors in a robot produce a stream of data at a regular interval (laser readings, images from a camera, ticks from wheel encoders, etc...) and you want the robot to react in some way to the information coming from the sensors whenever new information is available. In that sense, a publisher/subscriber communication pattern comes quite handy. A node publishes the information from a sensor whenever a new reading is available and any node interested in those updates can subscribe to the sensor topic.

Request/Response is more suited for short, unscheduled communications like "enable/disable" operations, setting parameters and things like that.

Anyway, ROS just aims at providing the tools and maybe some good practices, but the way you use the tools is entirely up to you. You can use Request/Response pattern of communication to get the latest information from a sensor without any problem if that makes more sense for your application, no one is holding a gun to your head to use publisher/subscriber communication pattern :P

Pub/Sub is NOT the ideal communication method for all scenarios and this is also the reason ROS is implementing several other methods, namely Services (via XMLRPC) and Actions (which are implemented with several Pub/Sub-connections).

Services are most often used for small computations or configurations which can't be aborted by the caller.

Actions are used to control longer tasks, for example moving the robot somewhere. One node decides where to go next and sends this pose to the navigation node through an action-goal. The navigation node then starts to move the robot and will regularly send the current position back to the calling node until it reaches its goal, gets blocked or the calling nodes decides to go somewhere else and cancels the action. The navigation node itself could have a subscriber to the current pose that is published/streamed from the localization node (which in turn subscribes to laserscan messages (and maybe uses a service to configure/activate other sensors)).