ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
![]() | 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.
![]() | 2 | No.2 Revision |
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.