Day 1: ------------------------------- Session 1: 45 mins: Lecture: Overview of Marine Autonomy 45 mins: Lecture: Overview of MOOS-IvP 120 mins: Lab exercise: - everyone has a working machine, able to download and build/run moos-ivp, is comfortable with a text editor. - download example missions git repo - Series of exercises to try, running example missions noting certain aspects of the mission and C2 software Session 2: 60 mins: Lecture: MOOS Middleware 120 mins: Lab exercise: Launching MOOS (cmdline, pAntler, launch scripts) Scoping tools, Poking via scripts, command-line and GUI Intro to logger and file formats, methods for data extraction Optional Homework reading: intro to bash scripts, launching missions Day 2: ------------------------------- Session 1: 60 mins: Lecture: Helm intro, behavior based arch, action selection, Full discussion of alpha mission. Planning vs. autonomy vs control. Behavior conditions, helm modes 120 mins: Lab exercise: Mission files, event flags, iSay app. Five short exercises to modify missions to achieve new objectives, touching on conditions, modes, events and behavior states Session 2: 60 mins: Lecture: Deep dive Helm behaviors. Dynamic updates, event flags, macros. Waypoint, loiter, op-region, station-keep behaviors. 120 mins: Lab Exercise: Adding depth (UUVs) to simulation, develop mission to dive, transit and periodically surface for a GPS fix. Day 3: ------------------------------- Session 1: 60 mins: Lecture: Multi-Vehicle Operations. Shoreside/vehicle communities, launching mission MOOS communities and inter-DB comms with pShare. Intro to uField toolbox tools 120 mins: Lab exercise: Run first multi-vehicle (three MOOSDB) community mission. Commanding vehicles as a group or individually. Two vehicle auto-refuel mission. Session 2: 60 mins: Lecture: Inter-vehicle messaging. Message structure, and routing 120 mins: Lab exercise: Construction of inter-vehicle message, from the command-line, and from within a pair of vehicles. Optional homework reading: The moos-ivp-extend tree Day 4: ------------------------------- Session 1: 60 mins: Lecture: Writing MOOS Apps. How to generate app from template. Simple variable registration and publication. 120 mins: Lab exercise: Getting the moos-ivp-extend tree, augment shell path, Generate and build an empty new app, add a subscription and publication. Detect when a vehicle enters a NAV_XY box, then publish a message to stop the vehicle. Session 2: 60 mins: Lecture: More MOOS app writing. Debugging tips. Using the alogview utility. Configuration handling. Appcasting. 120 mins: Lab Exercise: Continue above MOOS app development. Reset mission after vehicle enters box and stops, from C2 GUI. implement run warning, and config warnings. Day 5: Final exam ------------------------------- Session 1: 20 mins: Description of exercise. Students tasked with building an odometry app. Register for NAV_XY, update odometry. Use the odometry app in their double-loiter mission to return home for fuel automatically. 160 mins: Time to complete the exercise Session 2: 20 mins: Description of exercise Students to use their odometry app in a three vehicle mission. Two target vehicles are traversing a pair of racetrack patterns. The student vehicle will chace one vehicle for a set odometry distance, and then the other for the same distance. Extra credit, reason about the target vehicle position (wait) to ensure student vehicle will capture the target vehicle within odometry limit 120 mins: Time to complete the exercise 30 mins: Wrap up and discussions Exam: 1. publish accurate odometry 2. immune to time warp 3. come home after odo Session 2: Two-vehicle mission, two vehicles on separate race tracks. Goal follow one vehicle until odometry reached. Switch to the other vehicle until odometry reached, then back again. (B) instead of follow, use cut range. Can you use conditions to ensure cut range results in an intercept? Q: Is there an op-area near Pisa that might be nicer for use in our exercises? Q: OK to assume the students know how to use a text editor? Q: Ok to give them a "pre-course" material a week before arriving? For those who may not be familiar with the command-line or text editor? Topics: Planning/Autonomy/Control Session 1: Overview of Marine Autonomy and Setup of Lab Simulation Tools ======================================================================== Discussion 1: An overview of the field of marine robotics from the perspective of ongoing research activities at MIT in marine autonomy, sensing and communication. This discussion will also include an overview of how marine autonomy fits in to the larger field of Artificial Intelligence. Lab 1: The goal of this lab is to ensure that all attendees have a working simulation environment on their laptops, to support the remaining labs of the mini-course. A Linux or MacOS machine is required. The MOOS-IvP software will need to be downloaded and built, allow with a few additional publicly available packages. This step could be done entirely prior to the start of the course. If time remains, the lab will continue with several optional measures that are recommended for effectively working with the command-line. The lab will present the tools and techniques we have found most useful in practice. We will go through as many as possible as time permits, leaving the rest as exercises for attendees to pursue offline. Session 2: MOOS Overview and MOOS labs ======================================================================== Discussion 2: An overview of MOOS, including the context of its genesis in marine robotics circa 2000 and its current day usage. The technical discussion will include (a) inter-process messaging, messaging format, and timing, (b) launching marine autonomy mission in MOOS, (c) scoping on MOOS during mission operation, including remote scoping, (d) poking MOOS during mission operation with command-and-control messages or any other message, and how to verify message receipt, (e) data logging in MOOS, data format, and tools for post-mission analysis and visualization of data. Lab 2: The goal of this lab is to gain initial experience with running MOOS on the course laptops. At the end of Lab 1, students should have been able to run the basic "Alpha" mission, running a single vehicle through waypoints. While this constitutes a full suite of MOOS apps, in this lab, students will focus on components of this this mission including (a) how to launch a MOOSDB from the command line, (b) how to scope (monitor) the activity of a MOOSDB from the command line, (c) how to inject data into a MOOSDB from the command line. Scripted postings to the MOOSDB with the uTimerScript utility are introduced. A simple MOOS app, pXRelay, will be investigated to gain insight into the publish/subscribe nature of the MOOSDB. If time remains, students are encouraged to examine the code of the pXRelay application to make simple modification of its structure. There will also be an optional challenge exercise to create a timer script to produce a command-and-control posting on the Alpha mission. Session 3: Helm Overview and Helm labs ======================================================================== Discussion 3: An overview of the IvP Helm, including a discussion of the design philosophy of open, collaborative, incremental software development. The technical discussion will include (a) the payload autonomy paradigm, (b) the helm internal process cycle, (b) an in-depth analysis of the applications and messages constituting the Alpha mission, (c) an introduction to behavior mission file structure, (d) behavior logic conditions and their use in building up complex missions from simple behaviors, (e) high-level mission modes and their relationship to participating behaviors, (f) behavior states guiding the level of activity of a given behavior participation in a vehicle mission for a point in time, (g) behavior flags, and their role in stitching together complex mission from simple building blocks. Lab 3: The goal of this lab is to introduce the IvP Helm to new users. It assumes nothing regarding prior experience with the Helm, other than the material introduced in Discussion 3. The goals of this lab are to (a) understand the role of mission files (.moos) and behavior files (.bhv) in constructing new missions, (b) get comfortable with different ways to generate mission changing events, with endflags, pMarineViewer and the uTimerScript, (c) explore the iSay MOOS App, (d) explore the StationKeeping behavior. The lab includes five exercises to modify or augment provided missions to achieve a new mission goal. If time remains, two additional exercises are provided with additional objectives introducing further tools. All exercise solutions are provided online to enable students to keep pace. Session 4: A Deeper Dive into Helm Behaviors and Dynamic Updating ===================================================================== Discussion 4: A deeper discussion of several helm behaviors is presented along with a discussion of the mechanics of making dynamic behavior updates. Dynamic updates are critical for constructing adaptive autonomy missions that utilize information from sensors, messages from collaborating vehicles, and command-and-control field operators. A detailed discussion is presented of (a) the waypoint behavior, (b) the loiter behavior, (c) the min/max depth behavior, (d) the op-region behavior, and (e) the station-keeping behavior. The key legal parameters of each behavior is discussed along with how they are used in typical missions. Lab 4: The goal of this lab is to provide further experience with the IvP Helm to new users. It assumes some experience with the Helm, editing mission and behavior files, from the previous lab. The focus here is to use the helm state flag mechanisms, along with dynamic update mechanism, to build more complex missions using the deeper knowledge of the behaviors presented in the discussion. The exercises include: (a) modifying the Alpha mission to use the loiter behavior, (b) adding depth to our simulated vehicles to simulate UUV deployments and utilize the depth control behaviors, (c) allow users to dynamically modify the vehicle depth during mid-mission operation, (d) generate a script to modify vehicle depth to different values during a mission, (e) add the max-depth behavior to a mission to ensure a hard depth limit despite possible external commands to the contrary. If time permits, two additional exercises are provided: (a) modify a UUV mission to automatically surface for a GPS fix and automatically resume operation after a fix has been obtained, (b) add a simulated ocean drift to a mission to observe (and counter) the effects on vehicle trajectory. All exercise solutions are provided online to enable students to keep pace. Session 5: Multi-Vehicle Operations ===================================================================== Discussion 5: An introduction is presented on concepts of deploying multiple independent but collaborating vessels working together with periodic communications with one another and periodic communications with a single field control operator. Messaging between two unique MOOS communities is introduced with a discussion of the pShare MOOS app. The uField Toolbox, containing several MOOS app utilities for multiple vehicles, is introduced. A simple baseline multi-vehicle mission, the Berta mission, is presented and discussed in detail. Finally, a discussion of the mechanics of developing, maintaining, and launching multiple vehicle missions is presented, as well as tools for replaying and analyzing multi-vehicle missions from recorded log files. Lab 5: The goal of this lab is to shift focus to autonomy configurations involving multiple vehicles. Ultimately the inter-MOOSDB or inter-vehicle communication may come over a acoustic modem link, radio link, or even a satellite link, but our primary initial focus is on communications over an internet connection, even if the multiple nodes are all running on your one laptop. Gaining familiarity with this mode of operation is also essential for later labs. The exercises include: (a) modification of the (single vehicle) Alpha mission into a two vehicle mission, (b) initial use of the uField Toolbox utilities to facilitate the construction of a two-vehicle loiter mission, (c) augmentation of the previous mission to allow a user to remotely command all vehicles to return to given location for refueling before commanding redeployment. (d) augmentation of the previous mission to allow vehicles to automatically redeploy after refueling has been completed. Session 6: Inter-vehicle messaging ===================================================================== Discussion 6: An overview of inter-vehicle messaging for marine vehicles is introduced, along with the inherent limitations and difficulties associated with certain kinds of communications. We present methods for simulating inter-vehicle communications within the set of MOOS-IvP simulation environment. Two additional tools with the uField Toolbox, uFldNodeComms and uFldMessageHandler, are introduced for simulating range-limited, bandwidth-limited and frequency-limited inter-vehicle communication situations. Practical methods for analyzing and debugging inter-vehicle communications are presented. Lab 6: The focus of this lab is an introduction to inter-vehicle messaging, focusing first on messaging without restrictions. Messages originating on a source vehicle are packaged into a preset message format and routed to a recipient vehicle to be unpacked and posted into the receiving vehicle's local MOOSDB. The lab contains three exercises involving two simulated vehicles, (a) a two-vehicle mission is augmented to allow vehicles to stream their position information to one another. (b) the two-vehicle is further augmented to allow inter-vehicle messaging, initially from a user injection, (c) the two vehicle is augmented to use an on-board timer script, to periodically send each other messages to alter the location of their deployment. If time permits, and additional challenge exercise is provided to augment the previous mission to allow the two deployed vehicles to recover when/if they are re-deployed outside of communications range. Session 7: Writing MOOS App extensions ===================================================================== Discussion 7: An overview of writing MOOS applications in C++ is presented. The ability to extend the autonomy system by adding or modifying apps is a key design concept of MOOS-IvP. The technical discussion will include: (a) an overview of key C++ MOOS App classes for creating new apps, (b) the message structure used in MOOS, (c) posting outgoing and receiving incoming mail within a MOOS app, (d) key overloadable functions of MOOS apps for implementing unique functionality, (e) serialization and deserialization of messages, (f) MOOS time warp for faster than real time simulation, (g) app-casting MOOS apps for managing operation over multiple vehicles, and (h) a discussion of common MOOS app conventions. Lab 7: The goal of this lab is to write a first simple MOOS app, and understand the mechanics of adding the app to your software build system, and using your new app in a mission. A template software tree is provided to the students for download with an example MOOS app so the new app does not need to be written from scratch. The lab exercises are: (a) download and build the template "moos-ivp-extend" tree to the student machines and augment the shell path to include the extension software, (b) build a first MOOS app which implements an odometry function, keeping a running value of distance traveled for a marine robot, (c) use the new odometry app in a mission to influence the trajectory of a vehicle. If time permits, students are encouraged to convert the odometry app to implement appcasting, and add meaningful reports to the appcasting output of the odometry app. Session 8: Advanced MOOS App writing ===================================================================== Discussion 8: Additional MOOS programming topics are introduced to aid developers, and users, of more advanced MOOS applications. Topics include (a) how to reliably kill and MOOS communities an verify a clean shut down, (b) recommended practices for debugging app development at different stages from compile errors to run-time and post-mission detection of error, (c) MOOS-IvP C++ utility libraries and functions essential for certain tasks common to many MOOS apps. (d) implementing configuration handling properly in MOOS apps, and connecting configuration warnings to appcasting output, (e) handling run-time warnings properly in MOOS apps, and (f) the role of shell scripts in managing and launching missions. Lab 8: This lab will involves a single advanced exercise with two simulated vehicles. A set of visit waypoints is randomly generated and the points are parsed into two clusters and assigned to each vehicle. The vehicles then need to traverse the assigned points in a greedy shortest path. A MOOS app will be written on the command-and-control side to receive the random points, cluster them, and post messages to both vehicles with their assignments. A MOOS app will be written to run on each vehicle to receive their assignments, generate a greedy shortest path, and post this path to be consumed by the waypoint behavior. If time permits, the mission may be further augmented to allow the vehicles to periodically interrupt their missions to return home for refueling. After refueling the vehicles will automatically resume their traversal mission where they left off. Session 9: Writing Helm Behavior extensions ===================================================================== Discussion 9: An overview of writing Helm behaviors in C++ is presented. The ability to extend the autonomy system by adding or modifying helm behaviors is a key design concept of MOOS-IvP. The technical discussion will include: (a) an overview of key C++ IvPBehavior classes for creating new behaviors, (b) the key behavior template functions to be overloaded to implement a new behaviors, (c) methods for behaviors to access the information they require from the larger autonomy system, (d) methods for behaviors to post information to the larger autonomy system. Lab 9: The goal of this lab is to write a first simple Helm behavior, and understand the mechanics of adding the behavior to your software build system, and using your new behavior in a mission. A template software tree is provided to students for download with an example Helm behavior as a template, so the new behavior does not need to be written from scratch. The lab exercise are: (a) build a "pulse" behavior which monitors other mission events to simply post a visual artifact (a pulse) when the event happens. This initial behavior does not influence the vehicle trajectory, but does require the behavior author to address many of the mechanics of generating a new behavior, (b) build a "zigleg" behavior that, upon a sensed event, will influence the vehicle to generate a zigzag pattern for a short period before resuming its original trajectory.