ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org
Ask Your Question
2

What's the state machine of DriverNode?

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

LucaGhera gravatar image

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

ngrennan gravatar image

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

2 Answers

Sort by ยป oldest newest most voted
2

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

joq gravatar image

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 more
0

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

cnhzcy14 gravatar image

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 more

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.

joq gravatar imagejoq ( 2012-06-29 07:12:28 -0500 )edit

Thank you very much for the advice Joq! I do find that some newer camera drivers only take use of SensorLevels in driver_base.

cnhzcy14 gravatar imagecnhzcy14 ( 2012-06-29 16:37:47 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

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

Seen: 321 times

Last updated: Jun 28 '12