Skip to content
Snippets Groups Projects
Commit b561da8e authored by Sergi Hernandez's avatar Sergi Hernandez
Browse files

Update README.md

parent 162400cd
No related branches found
No related tags found
No related merge requests found
......@@ -3,7 +3,7 @@ This project is intended to be used as a base class for ROS nodes that have to c
<img src="doc/images/LabRobotica_Philosophy.png" alt="Basic structure of the IRI ROS base driver node" width="1103" height="596">
This node was originally base on the [ROS driver_base node](http://wiki.ros.org/driver_base) which is now deprecated. Since then, it re-implements most of the driver_base features.
This node was originally based on the [ROS driver_base node](http://wiki.ros.org/driver_base) which is now deprecated. Since then, it re-implements most of the driver_base features.
This node is structured into two parts:
......@@ -22,9 +22,9 @@ The next figure shows the possible states and transitions (actions) between them
The driver tries to transition form the initial state (CLOSED) to the RUNNING state every second until it succeeds. To do so, each transition calls a function that must be implemented by the inherited class (openDriver(), closeDriver(), startDriver() and stopDriver()). These functions should interact with the actual hardware to perform the desired action. If the hardware does not support one or more of these actions, the corresponding functions should do nothing but return success (true).
Some of the parameters of the driver may not be changed on the RUNNING state. Therefore, each of the parameters defined in the dynamic reconfigure interface of the driver node (see below for more information) provides the driver state in which it should be modified. Whenever the value of one of these parameters is changed, the state machine automatically transitions to the desired state, and the returns to the previous one, once the parameter has been updated.
Some of the parameters of the driver may not be changed on the RUNNING state. Therefore, each of the parameters defined in the dynamic reconfigure interface of the driver node (see below for more information) provides the driver state in which it should be modified. Whenever the value of one of these parameters is changed, the state machine automatically transitions to the desired state, and then returns to the previous one, once the parameter has been updated.
In addition to the driver transition action functions, a set of callback functions are also provided so that the driver node can perform some action (if necessary) after the drives has been opened (postOpenHook) or started (postStartHook), and before it is stopped (preStopHook) or closed (preCloseHook). These functions do nothing by default, but may be implemented by the inherited class to perform any required action.
In addition to the driver transition action functions, a set of callback functions are also provided so that the driver node can perform some action (if necessary) after the driver has been opened (postOpenHook) or started (postStartHook), and before it is stopped (preStopHook) or closed (preCloseHook). These functions do nothing by default, but may be implemented by the inherited class to perform any required action.
</p>
</details>
......@@ -68,7 +68,7 @@ The driver node provides two separate ROS NodeHandlers:
* the public node handle is initialized by a node handle provided to the constructor of the driver node. If no node handle is defined, "/" will be used.
* the private node handle is initialized to "~" by default.
These node handlers can be used to get/set ROS parameters and to set-up ROS interfaces. Depending on the node handle used, the namespace of the corresponding parameter or interfacewill be different.
These node handlers can be used to get/set ROS parameters and to set-up ROS interfaces. Depending on the node handle used, the namespace of the corresponding parameter or interface will be different.
</p>
</details>
......@@ -92,13 +92,13 @@ This base node has no dependencies.
# How to use it
This ROS node is not deigned to be used on its own, an inherited class is always required.
This ROS node is not designed to be used on its own, an inherited class is always required.
To simplify the process of inheriting from this class, there is an script (*create_driver_package*) which creates a ROS driver package using this node as a base class.
Also, there exist other scripts to easily add ROS interfaces (topic publishers or subscribers, service servers or clients and action servers or clients) and also TF publishers or subscribers.
Also, there exist other scripts to easily add ROS interfaces (topic publishers or subscribers, service servers or clients and action servers or clients) and also TF listener or broadcaster.
Check the [IRI ROS scripts](https://gitlab.iri.upc.edu/labrobotica/ros/iri_core/scripts-catkin) page for further information on all these scripts.
Check the [IRI ROS scripts](https://gitlab.iri.upc.edu/labrobotica/ros/iri_core/iri_ros_scripts) page for further information on all these scripts.
## Disclaimer
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment