=========================================================== Day 1 Morning, Lecture 1: An overview of Marine Autonomy and the MOOS-IvP Open Source Software Stack. =========================================================== In this lecture we reflect on the recent history of the field of marine robotics, mission aspirations of early and current sponsors, investors and industry startups. We discuss different types of marine robotic platforms as they relate to different missions. The MIT open-source software stack, MOOS-IvP is introduced with discussion of former projects and current users. We start the dicussion the five recurring high level learning objectives for this course: \begin{packed_itemize} \item Core Decision Layers \item Collaboration Paradigms \item Core Architectures \item Mission Structures \end{packed_itemize} ----------------------------------------------------------- Day 1 Morning, Lab 1: Getting started with the autonomy software, simulation environment and initial reference missions. Initial proficiency with the Linux/MacOS command-line-interface (CLI) and a text editor is required. Expecting some variety in these skills, we baseline our expectations and provide newer users the help they need to download the code and run the course software. For those with less experience in the CLI environment or text editors, we provide crash-course refernce documents to come up to speed. =========================================================== Day 2 Afternoon, Lecture 2: MOOS Middleware An overview of the MOOS middleware and the style of structuring a software system as a set of independent, ansynchronous communicating software modules. The MOOS robot middleware architecture is introduced and the publish/subscribe paradigm. Inter-process communication is discussed along with methods for message serialization and de-serialization. Students will be introduced to methods for scoping (monitoring) data in a live mission, as well as poking (writing) data through bothe command-line interface (CLI) and through a command-and-control(C2) GUI. A reference mission will be discussed in detail to describe how a full autonomy simulation can be comprised of distinct inter-related modules. \noindent Component Learning objectives addressed: \begin{itemize} \item Primary robot system components \item Robot middleware \item Software communities \item Simulation \item Data injection and scoping \end{itemize} ----------------------------------------------------------- Day 1 Afternoon, Lab 2: Interacting with MOOS software communities through simulation. In this lab we return to the reference mission from Lab 1 to explore how we can visualize (scope) and monitor data flowing through the key applications comprising the mission. Students are introduced to CLI tools for scoping, as well as dedicated GUI tools, and tools embedded in the C2 GUI. Students are introduced to tools for injecting changes (poking) to the live software community through the CLI and through the C2 interface. The MOOS logger application is introduced and students are guided to explore the log files after the reference mission has completed, and to replay the refrence mission from the log files. Basic scripting is also introduced using simple text files, to explore the power to alter a running mission. =========================================================== Day 2 Morning, Lecture 3: Helm autonomy =========================================================== Autonomous decision-making through the IvP helm is introduced. We review the role of a helm in the overall robot software architecture and review the nature of decision-making distinct from planning and control. The general concepts of a behavior-based architecture are introduced, followed by methods for behavior reconciliation through action selection. Options for action selection are presented with respective strengths and weaknesses. Multi-ojective optimization is introduced as prefered means for effective action selection. The notion of helm modes and mission modes is introduced, along with mechanisms in behaviors for carrying out prescribe mission modes. IvP Behaviors are introduced by describing capabilities available to all behaviors and how specific behaviors can extend general functionality to become advanced specialty behaviors. High-level learning objectives addressed: \begin{itemize} \item Core Decision Layers \item Core Architectures \item Mission Structures \end{itemize} Component learning objectives addressed: \begin{itemize} \item Autonomy software community \item Simulation \item Basic C2 \item Behavior-based Architecture \item Action selection \item Multi-objective optimization \end{itemize} ----------------------------------------------------------- Day 2 Morning, Lab 3: Mission construction and modification methods In this lab we make use of a pair of working example missions, with several modification goals to achieve new mission objectives. These exercises will allows users to explore the role of behavior conditions, behavior states, event flags, and mission modes. These exercises will provide further experiences in how to launch a mission, utilize command-and-control during the mission, and analyze and replay a misison from log files after the mission has completed. =========================================================== Day 2 Afternoon, Lecture 4: Behaviors Generally and Specifically Missons are constructed with initial helm behavior configurations, many of which retain their configuration, and any of which may be dynamically configured based on local events, or external events during the course of the mission. Example scenarios of such events are described in this lecture as well as the mechanisms for shaping the event effects for any given behavior. The aim is to convey the new user that options for both behavior configuration and policies for handline events, provides an autonomy programming language. The latter part of the lecture examines closely a handful of common helm behaviors, their primary functionality and how each is configured to generate configurable events, enabling a user to compose endless mission variations. High-level learning objectives addressed: \begin{itemize} \item Mission Structures \end{itemize} Component learning objectives addressed: \begin{itemize} \item Behavior-based architecture \item Mission modes and structures \item Dynamic behavior modification \item Behavior events \item Core behaviors \end{itemize} ----------------------------------------------------------- Day 2, Lab 4: Simulated AUV operations and Event Planning In this lab, the mission simulation involves an autonomous underwater vehicle (AUV). We show how the simulation, autonomy and control regime can be augmented to involve the third dimension of depth. Using the newly introduced concepts of behavior conditions and events, the user will construct a mission where the AUV will deploy, dive, and periodically come to the surface for a GPS fix, and periodically come home to recharge its battery. =========================================================== Day 3 Morning, Lecture 5: Multi-vehicle Operations =========================================================== Vehicle autonomy is undeniably much more interesting when it involves multiple coordinated and communicating vehicles. Initial considerations in this lecture involve the additional applications and mechanics for launching and simulating multiple vehicles under one C2 GUI, and the steps require to ensure proper flow of information enabled between a C2 node and the vehicle nodes. Students are introduced to the uField Toolbox component of the MOOS-IvP software, and the inter-MOOSDB UDP based communications pShare app distributed with the core MOOS project. Pre-launch and post-mission analysis considerations are presented to enable the generalization of multi-vehicle missions. High-level learning objectives addressed: \begin{itemize} \item Collaboration paradigms \item Core architectures \end{itemize} Component learning objectives addressed: \begin{itemize} \item Simulation \item Multi-vehicle autonomy \item Mission planning and launching \item Scripting \item Post-mission analysis toos \end{itemize} ----------------------------------------------------------- Day 3 Morning, Lab 5: Multi-vehicle Mission Constuction and Simulation In this lab students begin working with a new simulation paradigm and baseline example mission. The uField architecture is introduced, involving a shoreside MOOS community for C2, and multiple vehicle MOOS communities, one for each vehicle. Users will be asked to examine the baseline mission from several angles: the changes in launch structure, C2 control, mission scoping, and post-mission analysis. Students will be introduced to the concept meta and plug files for creation of target mission launch files. Building on the previous lab involving event handling, a simple two vehicle mission will be built, with vehicles periodically returning to a charging station. =========================================================== Day 3 Afternoon, Lecture 6: Inter-vehicle Messaging for Coordination Certain kinds of multi-vehicle collaboration requires inter-vehicle messaging. In this lecture the methods for constructing, sending, receiving inter-vehicle messaging in MOOS-IvP are introduced. Inherent limits on inter-vehicle messaging are discussed, and common mediums for messaging in surface and underwater vehicles are discussed. The MOOS-IvP simulation environment has provisions for mimicking limits on communication, to challenge developers of autonomy to confront these limits and build contingencies for overcoming them. High-level learning objectives addressed: \begin{itemize} \item Collaboration paradigms \item Core architectures \end{itemize} Component learning objectives addressed: \begin{itemize} \item Simulation \item Multi-vehicle autonomy \item Inter-vehicle messaging \end{itemize} ----------------------------------------------------------- Day 3 Afternoon, Lab 6: Coordinated Missions with Messaging In this lab we will utilize inter-vehicle messaging to enable a cooperation between a pair of vehicles. Each vehicle will be deployed in a region where the communications range periodically is too far for inter-vehicle communication. Vehicles will detect the loss of comms and take action to maneuver close enough to re-establish communications. The last step in the lab is to download a template software tree for extending MOOS-IvP with apps and behaviors, in preparation for the next day's lab activities. We will discuss the structure of the software tree and build system. =========================================================== Day 4 Morning, Lecture 7: Writing MOOS Apps =========================================================== MOOS-IvP is comprised of two architectures (MOOS Middleware and the IvP Helm) each with provisions for extending capabilities with new modules. In MOOS this means new applications. With the helm it means new behaviors. Students are introduced to the mechanics or writing a new MOOS app, and the core steps of registering for mail, publishing mail, handling app configuration, and performing the core business of the app. This lecture will describe the functionality built into all new apps before customization, and then how to override or customize apps to capture the domain expertise of the user. The moos-ivp-extend software tree build structure is discussed in more detail, to enable app creation in the lab exercises to follow.MOOS-IvP is comprised of two architectures (MOOS Middleware and the IvP Helm) each with provisions for extending capabilities with new modules. In MOOS this means new applications. With the helm it means new behaviors. Students are introduced to the mechanics or writing a new MOOS app, and the core steps of registering for mail, publishing mail, handling app configuration, and performing the core business of the app. This lecture will describe the functionality built into all new apps before customization, and then how to override or customize apps to capture the domain expertise of the user. The moos-ivp-extend software tree build structure is discussed in more detail, to enable app creation in the lab exercises to follow. \vspace{0.1in} \noindent Component learning objectives addressed: \begin{itemize} \item Extending MOOS-IvP \item MOOS App Development \end{itemize} ----------------------------------------------------------- Day 4 Morning, Lab 7: Writing a First MOOS App Part One In this lab, students will utilized the moos-ivp-extend tree, and a provided app-generating script for creating a template MOOS app, followed by adding prescribed functionality. Students will create a MOOS app that registers for the position of a vehicle in the x-y plane, and posts a command to stop the vehicle when/if it enters a prescribed rectangular region. will become familiar with app construction and addition to the build system, handling and publishing mail, and coordination from C2 via commanded messages from the operator. =========================================================== Day 4 Afternoon, Lecture 8: Analyzing and Debugging MOOS Apps =========================================================== MOOS-IvP has a number of provisions for confirming expected operation during launch time, during mission operation, and during post-mission analysis. Some of these provisions require app developers to add the proper hooks to their code during development. We discuss all these provisions and which ones require compliant code hooks during development. A look a the full pipeline of debugging is discussed, and best practices for investigation when symptoms of problems are observed. ----------------------------------------------------------- Day 4 Afternoon, Lab 8: Writing a First MOOS App Part 2 The morning lab will continue, starting with an additional requirement: once the vehicle has stopped, it may be commanded from the C2 GUI to proceed. Message configuring from with the C2 GUI is required, along with aligning the chosen message variable and content to be respected by the student's newly created MOOS app. Bonus challenges will be provided, including the integration of the iSay app to trigger audio alerts when a vehicle has entered a region. Students can also configure the app to respect multiple regions, each with different outcomes. A bonus task will be to implement custom event flags rather than hard-coded MOOS postings. =========================================================== Day 5 Morning, Lecture 9: Overview of Challenge problem Part One =========================================================== The final day will be comprised of a two-phase challenge problem. The first phase of this problem will be introduced and visualized from a staff working solution. ----------------------------------------------------------- Day 5 Morning, Lab 9: Writing and Using an Odometry App Users will create MOOS app similar to the once created on day four. It will also register for ownship vehicle position, and will calculate a running odometry distance, and publish this distance to the MOOS community. Students will use this information in their vehicle MOOS community to trigger a vehicle to return home for refueling after a certain odometry distance. After refueling the odemetry will be reset and the vehicle will be redployed. This continues indefinitely. =========================================================== Day 5 Afternoon, Lecture 10: Overview of Challenge problem Part Two =========================================================== The second phase of this challenge problem will be introduced and visualized from a staff working solution. ----------------------------------------------------------- Day 5 Afternoon, Lab 10: A Multi-vehicle Mission Using Odometry In the final lab, users will begin with a completely new baseline mission with three vehicles. Two vehicles will be traversing separate racetrack patterns. The third vehicle will be the student controlled vehicle, it will be equipped with a behavior to follow one of the two racetrack vehicles. Students will add their working odometry app to fluctuate between following either of the two vehicles, switching after a certain odometry distance has been reached in each phase.