The vision_bridge node recieves image frames from the camera through either madmux or a ros published topic (depending on the content of the madmux_socket parameter). It then processes them through modules with options for frame rate, resolution, and prioritization. The modules include face detection and tracking, general object detection and simple quality metrics.
Topic for Image messages, if not using madmux (sockets).
vision_msgs::ImageClustering Feedback for moment capture used to track capture of similar moments.
vision_msgs::VisionResults Combined vision module results for a processed frame.
vision_msgs::VisionCmdMsg Interface for managing vision modules. This is the runtime interface for managing which modules are running and their configuration. As there are significant performance consequences to running the neural network based detectors, managing when they are active and their framerate (along with other configuration) is needed.
rosservice call /vision/cmds '[["activate", "face_detector", ["fps": 6], ["skip_ratio", 3]]]'
vision_msgs::VisionQuery Request vision bridge related configuration for a module. These govern how the vision bridge manages the module.
vision_msgs::VisionQuery Request module specific parameters. The parameters returned by this service call are those which are changeable at runtime. For a full listing and description of parameters, see the module’s config yaml file.
vision_msgs::VisionQuery Service that provides a list of currently active vision modules. This is useful for testing or if multiple clients are managing modules.
Path to linux socket provided by madmux
Topic aggregating results from all vision modules for each processed frame
Max fps for any module
Root resolution to resize incoming frames
List of available vision modules
Joints topic used to block processing when eyes are too closed
Maximum value for eyelid joint state to allow before blocking processing