ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

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 camsra. 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.

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 camsra. 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.