Skip to content

Handler Subsystem

Jump to bottom
Jim Jing edited this page Mar 17, 2014 · 9 revisions
  • Load info about handlers (class inspection)
  • Load and write experiment config files
  • Instantiate handlers
  • Mediate calls to handlers during execution

Handlers

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
      • ...

Class

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

Configuration

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

HandlerSubsystem

  • 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)

Internal Methods

  • 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()
Clone this wiki locally