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.

Wiki: driver_base/Reviews (last edited 2009-12-05 22:22:43 by BlaiseGassend)