Considering a ROS application a system where the behaviour is as much determined by the flow of data as it is by the way it is orchestrated is something I think many of us have been doing for a long time, precisely because -- as you write -- it is a natural way to think about these systems. I've seen quite some applications where ROS is essentially used to physically distribute what is essentially a monolithic program with a traditional (imperative) flow of control over a set of nodes that are all tightly coupled in both time and space by just replacing regular function/method calls with RPC (services). Those typically also include some form of sampling (storing 'the latest' msg in a member variable, delagating the processing of data to a separate flow of control), which can lead to synchronisation issues between components and dataflows (the `move_base` problem with late laser scans is a famous example of this). Perhaps it would be a good idea to expand the [wiki/ROS/patterns](http://wiki.ros.org/ROS/Patterns) page with some actual software patterns. Reactive (or Event Based) systems would seem to be a good candidate. --- [Visit Topic](https://discourse.ros.org/t/reactive-ros/1176/2) or reply to this email to respond. If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates. ______________________________________________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users Unsubscribe: