Overview of ModuleHub Architecture for Autonomous Decision-Making Systems
This document provides a comprehensive overview of the ModuleHub architecture used for controlling autonomous decisions in robotic systems. It details the finite state machine framework that utilizes Lua scripts to manage various states based on sensor input and timeouts. Key components include the Director, Vision, and Controls modules, which interact through a centralized controller that employs a pseudo publish-subscribe pattern. It highlights the current responsibilities and issues related to state management, race conditions, and model initialization, emphasizing the need for a robust data handling approach.
Overview of ModuleHub Architecture for Autonomous Decision-Making Systems
E N D
Presentation Transcript
ModuleHub ::A quick overview Carlo del Mundo 8-16-2011
Architecture • Director • Finite state machine • Controls autonomous decisions • Controlled by Lua scripts • States triggered by timeout or variables • Controls • Simulink Module • Movement algorithms • Reads sensor input • Outputs thruster data • Actuators • Reads thruster data and mechanism states • Sends serial commands to output devices • Vision • Simulink Module • Relays algorithm information to state data • Software Abstraction Layer (SAL) • Initializes and monitors hardware • Sends data to State Data SAL, Director, Vision, Controls, and Actuators are modules Cameras State Data Director SAL Maestro Micro-Strain OS-5000 Actuators Vision Controls Thrusters Mechanisms
Definitions • ModuleHub • A centralized location where modules are aggregated; the “controller” • Module • The smallest unit that performs some task Module Hub Director Controllers Vision
Current Responsibilities • “Pseudo” Publish-Subscribe Pattern (Observer Pattern) Module Hub (Controller) New Data (ex: isFire = 1) Vision Director State Data (Model)
Correct Responsibility • “Pseudo” Publish-Subscribe Pattern (Observer Pattern) Module Hub (Controller) New Data (ex: isFire = 1) Vision State Data (Model) Director
Summary of Previous Slide • Modules (Director, Vision, etc) should be listening to changes in the model (AUVT State Data) • Our current paradigm is flawed; modules are listening for changes in ModuleHub (the Controller) • Problems: • Race Conditions • At startup when modules are initialized, there is no centralized model/database. Some variables are not being set at initialization • Controller Responsibilities • Controller is performing model responsibilities; when requesting for data, controller is attempting to regenerate data through Model
Actual/Revised Roles • Controller of “MVC” or “MVD” pattern • Intercept user commands • Observer objects should NOT listen to controller, but instead the model • Modules should listen to State Data (Model)
