driver_base/Reviews

Package proposal

For now this is a brainstorm of what could be provided. Some of these may be more than we want to do....

• Probe for devices without disturbing devices that are already up.
  • Handle a varying number of devices. (Or is it better to isolate different instances of a device into different processes?) We could have a device auto-spawner that waits for new devices and spawns an appropriate node when a device appears.
• Allow runtime reconfiguration of a device. There are many levels of reconfiguration:
  • Change the device. Add a device. Remove a device. Detect that a device has been added and bring it up automatically. (Use this camera instead of that one.)
  • Change parameters requiring device reinitialization. (Change the resolution of the image stream.)
  • Change parameters that can be changed on the fly. (Change the exposure level.)
  • Change parameters that need to be changed in nearly real time. (Change the exposure in response to image data.)
  • Change ROS related parameters. (Where am I publishing?)

• Publish diagnostics.
  • Check rate
  • Publish device data (addresses, serial numbers, versions)
  • Publish ros information (node name, service and topic names, etc...)
  • Publish current settings.
• Self test.
  • Open device.
  • Read device information.
  • Collect data in each mode.
  • Check that data looks valid.
  • Combine multiple sensors/actuators to produce data and check that it is as it should be. (If I move the gripper, can the forearm camera see it?)
• Driver state. A driver seems like it goes through a few standard states: Unitialized. Device detected. Device configured. Device collecting data. Error. Doing a self-test. The role of the library should be to provide methods to transition between these states (and sometimes to trigger a transition, such as when an error occurs. If we can standardize the API for the library, then the node just needs to be written once. This would provide a lot of uniformity, and avoid repeating the same errors time and time again in the node logic.
• Subscription detection. The devices should really only going into the Device collecting data state when somebody is listening to them.

Some useful functionality that a framework can provide (this covers a lot of the points above with some thought on how to integrate them):

• Reconfiguration capability
  • Knows how to handle all parameter sources: parameter server, reconfigure messages, etc...
  • Parameters could have different levels depending on how much the device has to be uninitialized before they can be applied.
  • The reconfiguration framework changes the device to the correct state, calls a callback to set the parameters and returns the device to its initial state.
• Subscription management
  • Change the driver state automatically from configured to collecting data and back when nodes subscribe.
• Self test and diagnostic code reuse.
  • Functionality such as checking the node frequency should not be reproduced in every single driver.
  • The driver should publish useful information about its state even when it is being brought up or torn down.
• Check for file descriptor leaks when the driver quits.

Package review meeting notes

Create new package review

Enter the date in the appropriate box to generate a template for an API or code review meeting. Check the QAProcess page for more information.