What's the state machine of DriverNode?

asked 2012-05-10 05:14:09 -0500

LucaGhera
128 ●19 ●20 ●27

updated 2014-01-28 17:12:17 -0500

ngrennan
1 ●1 ●1

Hi all,

I'm looking at the hokuyo node. As far as I understood the class HokuyoDriver extends driver_base::Driver which provides the methods

doOpen
doClose
doStart
doStop

The class HokuyoNode instead extends driver_base::DriverNode<hokuyodriver>. However in the code I cannot find how this node calls the methods doXYZ of the HokuyoDriver. In other words I would like to understand the (implicit or explicit) state machine of driver_base::DriverNode and when the methods doXYZ are called.

edit retag flag offensive close merge delete

add a comment

2

answered 2012-05-10 05:46:48 -0500

joq
25443 ●181 ●256 ●408

It is a bit hard to follow. As best I can tell, driver_base implements three states:

Closed: not connected to the device.
Opened: device is open, but not streaming data.
Running: device is streaming data.

There is some confusion about the names: some comments refer to the Opened state as Stopped (following doStop()), but I think they the same.

The dynamic reconfigure parameters are coded with a bit mask, indicating what state changes are necessary for updating each parameter. That is a useful idea, which can easily be implemented without using driver_base explicitly.

edit flag offensive delete link

add a comment

0

answered 2012-06-28 20:58:34 -0500

cnhzcy14

58 ●3 ●4 ●8

updated 2012-06-28 21:06:49 -0500

It is very difficult to follow! I'm sorry but I used a very stupid way to track the doOpen in driver.h and driver_node.h: Driver::doOpen is called by Driver::raiseState called by Driver::goState called by Driver::goRunning called by DriverNode< Driver >::spin.

It is also very difficult to track the callback of dynamic_reconfigure. Some existed drivers use Driver::config_update called by DriverNode< Driver >::reconfigure as the callback. However there is not Driver::config_update in the original driver_base::Driver class.

I'm also suffering lots of problems when writing a driver for FLIR GigE Vision camera. I find that most of the camera drivers depend on some common packages like driver_base, dynamic_reconfigure, image_transport, diagnostic_updater, camera_info_manager and so on. However the ways by which they have been coded are different. More accurately, the way by which driver_base have been used are very different. I understand the API of driver_base is still under development, but I still expect a brief guide line for writing driver.

edit flag offensive delete link

Comments

driver_base was created for a few drivers written a couple of years ago. It is not actively maintained, except for those drivers. I do not recommend basing a new driver on it. A similar state machine can more easily be coded in-line, without all those templates and other indirection.