IVALab Python Libraries
Collection of code for computer vision and robotics with specific API.
Classes
perceiver.monitor Namespace Reference

A simple interface class for monitoring the outcomes of a perceived scene. More...

Classes

class  BuildCfgMonitor
 Build configuration instance for a monitor.
More...
 
class  CfgMonitor
 Configuration instance for a Monitor.
More...
 
class  Monitor
 A simple interface class for monitoring the outcomes of a perceived scene. More...
 

Detailed Description

A simple interface class for monitoring the outcomes of a perceived scene.

A Monitor tacks on some form of action recognition to make sense of the perceiver information. As in it monitors the activity state of the perceived scene and reports out the activity observations. If the intent is to compare against some target state or establish completion, then take a look at the Progress subclass. It tacks on a target/goal state and includes a progress estimator.

The choice was made to have the Monitor class independent of the Perceiver class (i.e., not a derived class of it). Rather it will receive a Perceiver instance and snag the signals from it as needed. Doing so permits a little more flexibility regarding how the actual implementation operates, which may be a future need. It is still put in the perceiver package based on the implicit messaging of the "perceiver" name. Of course, such a design might interfere with or render difficult factory methods (24/01/12: to be determined as implemented).

One reason to change this later on would be that some systems might start with a perceiver but then later receive an upgrade to a monitor but keep the same overall API. While it doesn't make sense in a standard sequential processing setting, it does make sense in a federated processing (like ROS) setting as it will simply adjust the published topics in a natural manner. We won't know what's best until actually getting there. I do believe that it is possible to create an interface that is agnostic to this difference. The core interface may not be agnostic, but specialized builder methods could be; one that takes argument minimal inputs and one that takes argument maximal inputs and builds intermediate instances before passing on the argument minimal version. That might be best. [01/04/2024]

Author
Patricio A. Vela, pvela.nosp@m.@gat.nosp@m.ech.e.nosp@m.du
Date
2024/01/04 [created]