- doesn't take place in ROS system, must be done on OS level (monitoring for network interfaces - connectivity)
idea: observer node
e.g. publishes wifi connectivity every 10s in ROS
the idea is that the general framework has no OS coupling (works independent of the OS)
such problems are external to the framework, shouldn't care about the OS, the observer node takes care of such issues
i.e. it's an abstraction layer that is established there
the assumption is the following: For my framework to work, I assume a node that publishes the connectivity every 10s in this specific format (percentage...) - where that comes from is totally irrelevant..
then: I implement such a node exemplarily for an Ubuntu system to demonstrate it
if someone wants to use my framework on Windows, my code of the framework doesn't have to be modified, you just have to implement such an observer node for Windows and replace the Ubuntu-specific one
- therefore, my core topic: "robot monitoring framework" and not "OS-specific wifi monitoring" is totally OS-independent and abstract
generally, network monitoring can be done arbitrarily detailed, not just a percentage..
- the OS-dependent observer nodes provide the information (e.g. disk info, file sizes, wifi connectivity, ..) and make them available in the ROS system, i.e. publish them on some topic
again: my general monitoring framework is OS-independent, the specific information provider nodes are not -> two levels of abstraction
the general robot monitoring framework completely stays in the ROS world: you have defined ROS messages that it works with and where these information come from is irrelevant.. I just expect that these information are given in a specific format
this difference in abstraction will be relevant for many aspects of the work (ROS world only vs. OS-dependent), should be strictly separated
-
doesn't take place in ROS system, must be done on OS level (monitoring for network interfaces - connectivity)idea: observer nodee.g. publishes wifi connectivity every 10s in ROSthe idea is that the general framework has no OS coupling (works independent of the OS)such problems are external to the framework, shouldn't care about the OS, the observer node takes care of such issuesi.e. it's an abstraction layer that is established therethe assumption is the following: For my framework to work, I assume a node that publishes the connectivity every 10s in this specific format (percentage...) - where that comes from is totally irrelevant..then: I implement such a node exemplarily for an Ubuntu system to demonstrate itif someone wants to use my framework on Windows, my code of the framework doesn't have to be modified, you just have to implement such an observer node for Windows and replace the Ubuntu-specific one-therefore, my core topic: "robot monitoring framework" and not "OS-specific wifi monitoring" is totally OS-independent and abstract