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.