1 / 8

ModuleHub :: A quick overview

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

domani
Download Presentation

ModuleHub :: A quick overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ModuleHub ::A quick overview Carlo del Mundo 8-16-2011

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

  3. Definitions • ModuleHub • A centralized location where modules are aggregated; the “controller” • Module • The smallest unit that performs some task Module Hub Director Controllers Vision

  4. Current Responsibilities • “Pseudo” Publish-Subscribe Pattern (Observer Pattern) Module Hub (Controller) New Data (ex: isFire = 1) Vision Director State Data (Model)

  5. WRONG

  6. Correct Responsibility • “Pseudo” Publish-Subscribe Pattern (Observer Pattern) Module Hub (Controller) New Data (ex: isFire = 1) Vision State Data (Model) Director

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

  8. 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)

More Related