Handler Subsystem - VerifiableRobotics/LTLMoP GitHub Wiki

• Load info about handlers (class inspection)
• Load and write experiment config files
• Instantiate handlers
• Mediate calls to handlers during execution

A handler file defines a handler object that interacts with low-level controllers. All handler files are stored in the lib/handlers folder. LTLMoP gets access to handlers through interaction with handler subsystem module. User can view and modify the setting of handlers through config editor module.

###Folder structure:

• lib/handlers
  • robot1
    • InitHandler
    • DriveHandler
    • SensorHandler
  • robot2
    • InitHandler
    • ActuatorHandler
  • shared
    • pose
    • motionControl
    • ...

All handlers are a subclass of the Handler object (as defined in lib/handlers/handlerTemplates.py), which takes a reference of the Executor object when instantiated.

• InitHandler: Perform any pre-experiment initialization
• SensorHandler: Handle connection to sensors and abstraction (continuous sensor value -> discretized value over proposition(s))
• ActuatorHandler: Handle connection to actuators and abstraction (discretized actuator value -> continuous action)
• PoseHandler: Handle connection to pose provider and abstraction (continuous pose -> region in discrete workspace)
• MotionControlHandler: Control high-level region-to-region movement (start region, dest. region -> motion)
  • Needs to specify whether it depends on lower-level movement handlers or not (or both)
  • Needs to provide a stop() method to abort any action and stay in place
• DriveHandler (optional): Converts global [v_x, v_y] vector to-- for example-- [v, w]
  • Needs to specify what type(s) of command it generates
• LocomotionCommandHandler (optional): Sends motor commands to robot
  • Needs to specify what type(s) of command it expects to receive

All configurations are defined in hsubConfigObjects.py to keep things separated. Each configuration object has a __repr__() function for user friendly printing.

###Hierarchy (generally, top to bottom):

• ExperimentConfig

  • Information necessary to run in a specific experimental setup
  • Corresponds to a .config file in the configs/ subdirectory of a Project
  • Contains:
    • One or more RobotConfigs
    • Name of the main robot for this experiment config
    • Set of propositions that are initially True for the experiment
    • Path to .config file, or None
    • Mapping from proposition names to collection (Boolean formula?) of HandlerConfigs
    • (Optional) Region tags

• RobotConfig

  • Information about a robot involved in an experiment
  • The default values are stored in a .robot file in lib/handlers/robot_type/
  • Contains:
    • Robot name
    • Robot type
    • One or more HandlerConfigs

• HandlerConfig

  • Three possible states (no need to explicitly track; evident from storage location)
    1. Load from handler module, fill with defaults from comments (hsub.handler_configs[robot_type][handler_type] where handler_type is a handler class and robot_type is a robot type (string) or "share"). Warn if type does not match folder name, but don't halt.
    2. Override method parameter configs with any defaults from .robot file (hsub.robot_configs[robot_type].handlers[handler_type])
    3. Override method parameter configs with any defaults from .config file (hsub.experiment_configs[exp_cfg_name].robots[robot_name].handlers[handler_type])
  • Contains one or more HandlerMethodConfig
  • If initialized for execution, contains reference to instantiated Handler object

• HandlerMethodConfig

  • Contains one or more MethodParameterConfig
  • Initialize()
  • If initialized for execution, contains reference to function object and exports a call(value) function

• MethodParameterConfig

  • An argument to a handler method
  • Contains name, description, type, value, and default as determined by performing introspection on the individual handler modules

• Input: executor, config file path
• Main Method: construct compiled runtimeStr for each handler, instantiate all handlers, string2Method for configEditor(?)
• prop_mapping maps from prop names to handler method string connected with boolean operators
• Public methods:
  • prepareHandler()
  • initializeAllMethods()
  • getSensorValue(sensor_name)
  • setActuatorValue(actuator_name)
  • doMotion(destination_region, robot_name=None)

• Ways that data will be queried:
  • ConfigEditor
    • Get list of config objects, given a proj reference (to know which spec dir to load)
      • config.robots
      • config.propMapping
      • config.otherStuff
    • Get list of loadable robot types (list of str)
    • Get default robot config object given type (str)
    • Get loadable handler candidate names (str) given robot type (str, possibly "share") and handler type (base class)
    • Get default handler config object given rtype (str: share or robot type (str)), htype (class), hname (str). NOT yet overridden by .robot defaults. Function Name: getHandlerConfigDefault
    • Get default handler config object given context_robot_type (str), rtype (str: share or ==context_robot), htype (class), hname (str). Already overridden by .robot defaults (unless not specified in .robot file corresponding to context_robot_type) Function Name: getHandlerConfigInRobot
    • Handler config object needs: .getDescription() == .getMethodByName("init").getDescription() [str] .getParameters() == .getMethodByName("init").getParameters() [list of para obj] .getMethodNames() [list of str] .getMethodByName() [method obj]
    • MethodObj has: .getDescription() .getParameters()
    • Param has: .getDescription() .getValue() .setValue() .getType() .getDefault() .getMin() .getMax() .reset()