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: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)