Talk

24-Benjamin

Talk.24-Benjamin History

Hide minor edits - Show changes to output

Added line 21:
[[<<]] %color=#ff7f00%[[Path:/moos-dawg11/material/24-brief-Benjamin.pdf | '''DOWNLOAD''']]%% the brief given at MOOS-DAWG'11.
Changed lines 5-6 from:
!!!! %color=#7777BB% [[Talk.23-Benjamin | Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.24-Benjamin | Next-Talk]]%% | \
to:
!!!! %color=#7777BB% [[Talk.23-Katz | Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.25-Schneider | Next-Talk]]%% | \
Changed line 5 from:
!!!! %color=#7777BB% [[Talk.22-Kemna | Prev-Talk]]%%  | \
to:
!!!! %color=#7777BB% [[Talk.23-Benjamin | Prev-Talk]]%%  | \
Changed lines 11-12 from:
!! Talk-22: ''The IvP Helm and New Features of MOOS-IvP Release 4.2''
to:
!! Talk-24: ''Writing Behaviors for the IvP Helm - Basic Overview and Summary of Recently Available Tools''
Changed lines 15-19 from:
The IvP Helm is a MOOS application implementing a behavior-based architecture for autonomy. The MOOS-IvP project is a collection of MOOS applications including the IvP Helm, but also many tools for preparing, monitoring, analyzing and debugging autonomous missions run with the IvP Helm.

This talk will both introduce the IvP Helm as well as discuss new features in
the latest release of MOOS-IvP, scheduled for mid-July 2011. The helm introduction will focus on three motivating themes: platform independence, module independence, and nested capabilities. Each of these themes promotes development from a diverse set of contributors, in a meritocracy of functionality. The helm introduction will include a description of the role of multi-objective optimization in the reconciliation of behavior output, descriptions of example missions, tools used in conjunction with the IvP Helm, and a description of MOOS-IvP as a project with development goals.

The latter part of the talk will describe features new to MOOS-IvP 4
.2. This includes new capabilities in the helm for behavior operation using less computational resources - a reflection of recent focus of using MOOS-IvP on low-powered devices. The talk will also include discussion of new MOOS apps in the MOOS-IvP distribution and notable improvements to existing MOOS apps.
to:
The IvP Helm is a behavior-based architecture with a number of freely available general purpose marine autonomy behaviors. These behaviors have been field-tested on many platforms involved in a variety of marine autonomy projects. The core utility of the Helm is derived from both (a) the functionality of these existing freely available behaviors, and (b) the openness of the architecture to additional behaviors by domain experts interested in extending the Helm in new areas. This is particularly true for domain experts with unique knowledge of new sensors and how to influence the vehicle's motion to exploit those sensors. 

New IvP Helm behaviors may be added by third-party users without modification or re-compiling of
the core Helm software. Behavior authors have a few ways to ease the process of developing a new behavior. First there is access to the source code of existing proven behaviors to build new behaviors with a modified capability. Second there is the  IvP Behavior superclass which provides a behavior template and built-in member functions to facilitate new behavior development. Finally there is the IvPBuild Toolbox containing a number of utilities for behavior authors to produce IvP objective functions, the primary output of  IvP Helm behaviors.

This talk provides an overview of these resources for building new behaviors, as well as a summary of recent and planned changes to the IvP Behavior interface providing behavior authors with more implementation options.

Changed lines 24-27 from:
* Anti-Submarine Warfare
* Unmanned Underwater Vehicles (UUVs) / Autonomous Underwater Vehicles (AUVs)
* The Ocean Explorer UUV
* Autonomy / Collaborative Autonomy
to:
* IvP Helm Behavior Development
Changed lines 5-20 from:
!!!! %color=#7777BB% [[Talk.21-Kemna | Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.22-Kemna | Next-Talk]]%% | \
%color=#7777BB%[[Talk.Listing|All-Talks]] | \
%color=#7777BB%[[Talk.ListingSorted|Talks-Sorted]]%% 


!! Talk-22: ''Hardware-in-the-Loop Testing''

!!!!%color=#449944% '''Stephanie Kemna, NATO Undersea Research Centre (NURC)'''

Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Research Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). To verify computational load, benchmark performance, and to reduce the risk of errors due to differences between runtime and simulations, it is useful to test missions in a hardware-in-the-loop (HIL) set-up. This talk discusses the intricacies of setting up such a HIL simulation. In runtime, the OEX’s PC-104 backseat computer is connected to the frontseat computer and on-board equipment, primarily via serial cables. In the HIL simulation, a desktop PC is used to simulate the data which is normally received via these serial cables. Rather than using serial cables, a local area network is utilized to enable running the HIL simulation from any desktop computer. Separating interface applications from data consumer applications greatly simplifies the process of switching between various input channels.

To keep the backseat mission files as close to runtime as possible, separate mission files are used for processes specific to the backseat, frontseat and viewer
. Mission files are generated automatically using sets of configuration files, template files, and generation scripts. This automation system has shown to decrease mission creation time substantially, reduce the possibility of errors in mission files, and increased similarity between runtime and simulation backseat mission files. The result has been increased operator confidence in running backseat missions.

A reprint of this presentation, including the source code of several of the developed processes and utilities, will be made available through NURC, after the conference.

to:
!!!! %color=#7777BB% [[Talk.22-Kemna | Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.24-Benjamin | Next-Talk]]%% | \
%color=#7777BB%[[Talk.Listing | All-Talks]] | \
%color=#7777BB%[[Talk.ListingSorted | Talks-Sorted]]%% 


!! Talk-22: ''The IvP Helm and New Features of MOOS-IvP Release 4.2''

!!!!%color=#449944% '''Mike Benjamin, MIT, Laboratory for Autonomous Marine Sensing Systems (LAMSS), Center for Ocean Engineering'''

The IvP Helm is a MOOS application implementing a behavior-based architecture for autonomy. The MOOS-IvP project is a collection of MOOS applications including the IvP Helm, but also many tools for preparing, monitoring, analyzing and debugging autonomous missions run with the IvP Helm.

This talk will both introduce the IvP Helm as well as discuss new features
in the latest release of MOOS-IvP, scheduled for mid-July 2011. The helm introduction will focus on three motivating themes: platform independence, module independence, and nested capabilities. Each of these themes promotes development from a diverse set of contributors, in a meritocracy of functionality. The helm introduction will include a description of the role of multi-objective optimization in the reconciliation of behavior output, descriptions of example missions, tools used in conjunction with the IvP Helm, and a description of MOOS-IvP as a project with development goals.

The latter part of
the talk will describe features new to MOOS-IvP 4.2. This includes new capabilities in the helm for behavior operation using less computational resources - a reflection of recent focus of using MOOS-IvP on low-powered devices. The talk will also include discussion of new MOOS apps in the MOOS-IvP distribution and notable improvements to existing MOOS apps.
Changed line 28 from:
* Collaborative Autonomy
to:
* Autonomy / Collaborative Autonomy
Changed line 26 from:
* UUVs/AUVs
to:
* Unmanned Underwater Vehicles (UUVs) / Autonomous Underwater Vehicles (AUVs)
Changed line 27 from:
* Ocean Explorer UUV
to:
* The Ocean Explorer UUV
Changed lines 15-19 from:
Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Research Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). To verify computational load, benchmark performance, and to reduce the risk of errors due to differences between runtime and simulations, it is useful to test missions in a hardware-in-the-loop (HIL) set-up. This talk discusses the intricacies of setting up such a HIL simulation.
In runtime, the OEX’s PC-104 backseat computer is connected to the frontseat computer and on-board equipment, primarily via serial cables. In the HIL simulation, a desktop PC is used to simulate the data which is normally received via these serial cables. Rather than using serial cables, a local area network is utilized to enable running the HIL simulation from any desktop computer. Separating interface applications from data consumer applications greatly simplifies the process of switching between various input channels.

To keep the backseat mission files as close to runtime as possible, separate mission files are used for processes specific to the backseat, frontseat and viewer. Mission files are generated automatically using sets of configuration files, template files, and generation scripts. This automation system has shown to decrease mission creation time substan- tially, reduce the possibility of errors in mission files, and increased similarity between runtime and simulation backseat mission files. The result has been increased operator confidence in running backseat missions.
to:
Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Research Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). To verify computational load, benchmark performance, and to reduce the risk of errors due to differences between runtime and simulations, it is useful to test missions in a hardware-in-the-loop (HIL) set-up. This talk discusses the intricacies of setting up such a HIL simulation. In runtime, the OEX’s PC-104 backseat computer is connected to the frontseat computer and on-board equipment, primarily via serial cables. In the HIL simulation, a desktop PC is used to simulate the data which is normally received via these serial cables. Rather than using serial cables, a local area network is utilized to enable running the HIL simulation from any desktop computer. Separating interface applications from data consumer applications greatly simplifies the process of switching between various input channels.

To keep the backseat mission files as close to runtime as possible, separate mission files are used for processes specific to the backseat, frontseat and viewer. Mission files are generated automatically using sets of configuration files, template files, and generation scripts. This automation system has shown to decrease mission creation time substantially, reduce the possibility of errors in mission files, and increased similarity between runtime and simulation backseat mission files. The result has been increased operator confidence in running backseat missions.
Added lines 26-28:
* UUVs/AUVs
* Ocean Explorer UUV
* Collaborative Autonomy
Changed lines 15-16 from:
Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Research Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). To verify computa- tional load, benchmark performance, and to reduce the risk of errors due to differences between runtime and simulations, it is useful to test missions in a hardware-in-the-loop (HIL) set-up. This talk discusses the intricacies of setting up such a HIL simulation.
In runtime, the OEX’s PC-104 backseat computer is connected to the frontseat com- puter and on-board equipment, primarily via serial cables. In the HIL simulation, a desktop PC is used to simulate the data which is normally received via these serial ca- bles. Rather than using serial cables, a local area network is utilized to enable running the HIL simulation from any desktop computer. Separating interface applications from data consumer applications greatly simplifies the process of switching between various input channels.
to:
Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Research Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). To verify computational load, benchmark performance, and to reduce the risk of errors due to differences between runtime and simulations, it is useful to test missions in a hardware-in-the-loop (HIL) set-up. This talk discusses the intricacies of setting up such a HIL simulation.
In runtime, the OEX’s PC-104 backseat computer is connected to the frontseat computer and on-board equipment, primarily via serial cables. In the HIL simulation, a desktop PC is used to simulate the data which is normally received via these serial cables. Rather than using serial cables, a local area network is utilized to enable running the HIL simulation from any desktop computer. Separating interface applications from data consumer applications greatly simplifies the process of switching between various input channels.
Changed line 5 from:
!!!! %color=#7777BB% [[Talk.20-Schmidt | Prev-Talk]]%%  | \
to:
!!!! %color=#7777BB% [[Talk.21-Kemna | Prev-Talk]]%%  | \
Changed lines 11-12 from:
!! Talk-21: ''BHV OpRegionBounce: An OpRegion that Can Bounce You Back''
to:
!! Talk-22: ''Hardware-in-the-Loop Testing''
Changed lines 15-17 from:
Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Re- search Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer autonomous underwater vehicles (AUVs). During NURC’s March engineering trial, we encountered a situation where one AUV came so near the defined operational region (OpRegion) that fears were raised of the vehicle hitting the perimeter. In such a case the currently used BHV OpRegion would have created a behaviour error and set all DESIRED * values to zero. For surface vehicles, setting the DESIRED * values to zero makes sense, but for underwater vehicles, this can be dangerous without adequate surface safety measures.

This talk discusses BHV OpRegionBounce developed in response to the above described scenario. The behaviour is an adaptation of BHV OpRegion with a bounce buffer for perimeter, maximum depth and minimum altitude. It has been tested in simulation for all potential combinations of all three possible safety breaches
. Performance has been verified during NURC’s June Engineering Trial, and results will be presented.
to:
Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Research Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). To verify computa- tional load, benchmark performance, and to reduce the risk of errors due to differences between runtime and simulations, it is useful to test missions in a hardware-in-the-loop (HIL) set-up. This talk discusses the intricacies of setting up such a HIL simulation.
In runtime, the OEX’s PC-104 backseat computer is connected
to the frontseat com- puter and on-board equipment, primarily via serial cables. In the HIL simulation, a desktop PC is used to simulate the data which is normally received via these serial ca- bles. Rather than using serial cables, a local area network is utilized to enable running the HIL simulation from any desktop computer. Separating interface applications from data consumer applications greatly simplifies the process of switching between various input channels.

To keep the backseat mission files as close to runtime as possible, separate mission files are used for processes specific to the backseat, frontseat and viewer. Mission files are generated automatically using sets of configuration files, template files, and generation scripts. This automation system has shown to decrease mission creation time substan- tially, reduce the possibility of errors in mission files, and increased similarity between runtime and simulation backseat mission files. The result has been increased operator confidence in running backseat missions.

A reprint of this presentation, including the source code of several of the developed processes and utilities, will be made available through NURC, after the conference
.
Changed lines 5-6 from:
!!!! %color=#7777BB% [[Talk.17-Vermeij | Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.19-Schmidt | Next-Talk]]%% | \
to:
!!!! %color=#7777BB% [[Talk.20-Schmidt | Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.22-Kemna | Next-Talk]]%% | \
Changed lines 11-29 from:
!! Talk-18: ''The EvoLogics Acoustic Modem Integration into NURC’s MOOS Environment''

!!!!%color=#449944% '''Arjan Vermeij, NATO Undersea Research Centre (NURC)'''

The NATO Undersea Research Centre (NURC) recently acquired acoustic modems from EvoLogics. These modems, of type S2C R 8/16, are to be used in an upcoming sea trial on board our two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). They should provide the ability to communicate at longer ranges and possibly with a higher data throughput, than currently achievable with our WHOI (Woods Hole Oceanographic Institute) Micro-Modems.

As part of the Collaborative Anti-Submarine Warfare programme, NURC researches communications and networks in the maritime environment
. This project aims to evolve underwater communications from point-to-point underwater messaging into true net- working, taking into account the limitations imposed by the underwater acoustic channel, such as high latency and bandwidth constraints. This involves the development of an underwater communications stack.

There are some requirements on the integration of the EvoLogics modem into NURC’s MOOS environment:

* The EvoLogics modem has the ability to operate in different modes, which should remain available
.
* The MAC layer, already available in the EvoLogics modem, should be usable.
* The integration should allow for potential replacement and addition of components developed within the communications and networking task.
* If possible, the EvoLogics modem should be able to work in parallel to the WHOI Micro-Modem.

This presentation discusses the design and developed applications as part of this inte- gration process. Furthermore, initial results obtained during the June engineering trial are presented.

A reprint of this presentation, including the source code of the developed processes, will be made available through NURC, after the conference.

to:
!! Talk-21: ''BHV OpRegionBounce: An OpRegion that Can Bounce You Back''

!!!!%color=#449944% '''Stephanie Kemna, NATO Undersea Research Centre (NURC)'''

Within the Cooperative Anti-Submarine Warfare programme at the NATO Undersea Re- search Centre, MOOS-IvP is used as the autonomy middleware for NURC’s two Ocean Explorer autonomous underwater vehicles (AUVs). During NURC’s March engineering trial, we encountered a situation where one AUV came so near the defined operational region (OpRegion) that fears were raised of the vehicle hitting the perimeter. In such a case the currently used BHV OpRegion would have created a behaviour error and set all DESIRED * values to zero. For surface vehicles, setting the DESIRED * values to zero makes sense, but for underwater vehicles, this can be dangerous without adequate surface safety measures.

This talk discusses BHV OpRegionBounce developed in response to the above described scenario. The behaviour is an adaptation of BHV OpRegion with a bounce buffer for perimeter, maximum depth and minimum altitude. It has been tested in simulation for all potential combinations of all three possible safety breaches
. Performance has been verified during NURC’s June Engineering Trial, and results will be presented.
Changed line 13 from:
!!!!%color=#449944% '''Arjan Vermeij, NATO Undersea Research Centre'''
to:
!!!!%color=#449944% '''Arjan Vermeij, NATO Undersea Research Centre (NURC)'''
Changed lines 5-6 from:
!!!! %color=#7777BB% [[Talk.01-Lepage|Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.02-YaariA|Next-Talk]]%% | \
to:
!!!! %color=#7777BB% [[Talk.17-Vermeij | Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.19-Schmidt | Next-Talk]]%% | \
Changed lines 21-22 from:
The EvoLogics modem has the ability to operate in different modes, which should remain available.
to:
* The EvoLogics modem has the ability to operate in different modes, which should remain available.
Changed lines 11-16 from:
!! Talk-01: ''Behaviour Development for Anti-Submarine Warfare: The Design of a MOOS-IvP Behavior Based on Maximizing the Doppler of Autonomous Assets Operating Within a Bistatic Sonar System''

!!!!%color=#449944% '''Kevin LePage, NATO Undersea Research Centre'''

The NATO Undersea Research Centre is currently exploring system concepts for collaborative ASW using AUVs.  As part of this effort the design of autonomy algorithms (behaviours) which are adaptive on Doppler-sensitive sonar signals is being pursued.  MOOS-IvP is
currently used onboard two Ocean Explorer AUVs which each have horizontal line arrays and accompanying CW signal processing software capable of converting acoustic signals into time-bearing-Doppler contacts.  These contacts are fused with FM contacts within NURC's DMHT tracker.  The fused CW-FM tracks are acted on by the behaviours implemented within the MOOS-IvP software architecture.  In this talk we explore the performance of a behaviour which seeks to maximize the future Doppler on contacts of interest. The collaborative use of this behaviour with a second vehicle performing traditional FM processing is also considered.
to:
!! Talk-18: ''The EvoLogics Acoustic Modem Integration into NURC’s MOOS Environment''

!!!!%color=#449944% '''Arjan Vermeij, NATO Undersea Research Centre'''

The NATO Undersea Research Centre (NURC) recently acquired acoustic modems from EvoLogics. These modems, of type S2C R 8/16, are to be used in an upcoming sea trial on board our two Ocean Explorer (OEX) autonomous underwater vehicles (AUVs). They should provide the ability to communicate at longer ranges and possibly with a higher data throughput, than
currently achievable with our WHOI (Woods Hole Oceanographic Institute) Micro-Modems.

As part of the Collaborative Anti-Submarine Warfare programme, NURC researches communications and networks in the maritime environment
. This project aims to evolve underwater communications from point-to-point underwater messaging into true net- working, taking into account the limitations imposed by the underwater acoustic channel, such as high latency and bandwidth constraints. This involves the development of an underwater communications stack.

There are some requirements on the integration
of the EvoLogics modem into NURC’s MOOS environment:

• The EvoLogics modem has the ability to operate in different modes, which should remain available
.

* The MAC layer, already available in the EvoLogics modem, should be usable.
* The integration should allow for potential replacement and addition of components developed within the communications and networking task.
* If possible, the EvoLogics modem should be able to work in parallel to the WHOI Micro-Modem.

This presentation discusses the design and developed applications as part of this inte- gration process. Furthermore, initial results obtained during the June engineering trial are presented.

A reprint of this presentation, including the source code of the developed processes, will be made available through NURC, after the conference.
Changed line 5 from:
!!!! %color=#7777BB% [[Talk.01-Newman|Prev-Talk]]%%  | \
to:
!!!! %color=#7777BB% [[Talk.01-Lepage|Prev-Talk]]%%  | \
Changed lines 11-21 from:
!! Talk-01: ''MOOS Then, Now and Next''

!!!!%color=#449944% '''Paul Newman, Oxford'''

I will provide a perspective about where MOOS came from, why I designed it as I did, where I think its
strengths lie and where I think there
is room for improvement. I will describe of the range of
platforms and projects MOOS has been, is and will be used on. I won't restrict attention to the marine domain - indeed some of the most challenging deployments have been on land in particular large scale infrastructure free navigation. As I conclude I'll look ahead to the planned next substantial release of MOOS  and describe the new functionality therein
.



to:
!! Talk-01: ''Behaviour Development for Anti-Submarine Warfare: The Design of a MOOS-IvP Behavior Based on Maximizing the Doppler of Autonomous Assets Operating Within a Bistatic Sonar System''

!!!!%color=#449944% '''Kevin LePage, NATO Undersea Research Centre'''

The NATO Undersea Research Centre
is currently exploring system concepts for collaborative ASW using AUVs.  As part of this effort the design of autonomy algorithms (behaviours) which are adaptive on Doppler-sensitive sonar signals is being pursued.  MOOS-IvP is currently used onboard two Ocean Explorer AUVs which each have horizontal line arrays and accompanying CW signal processing software capable of converting acoustic signals into time-bearing-Doppler contacts.  These contacts are fused with FM contacts within NURC's DMHT tracker.  The fused CW-FM tracks are acted on by the behaviours implemented within the MOOS-IvP software architecture.  In this talk we explore the performance of a behaviour which seeks to maximize the future Doppler on contacts of interest. The collaborative use of this behaviour with a second vehicle performing traditional FM processing is also considered.



Changed lines 22-24 from:
* MOOS Core
* Academia

%%
to:
* MOOS-IvP
* Anti-Submarine Warfare

%%
Changed lines 11-12 from:
!! Talk-01: ''MOOS Updates (PLACEHOLDER)''
to:
!! Talk-01: ''MOOS Then, Now and Next''
Changed lines 15-18 from:
No Abstract Yet.


to:
I will provide a perspective about where MOOS came from, why I designed it as I did, where I think its
strengths lie and where I think there is room for improvement
. I will describe of the range of
platforms and projects MOOS has been, is and will be used on. I won't restrict attention to the marine domain - indeed some of the most challenging deployments have been on land in particular large scale infrastructure free navigation. As I conclude I'll look ahead to the planned next substantial release of MOOS  and describe the new functionality therein.




Added line 24:
* MOOS Core
Changed line 8 from:
%color=#7777BB%[[Talk.ListingSorted|All-Sorted]]%% 
to:
%color=#7777BB%[[Talk.ListingSorted|Talks-Sorted]]%% 
Changed line 7 from:
%color=#7777BB%[[Talk.Listing|All-Talks]] |
to:
%color=#7777BB%[[Talk.Listing|All-Talks]] | \
Changed lines 7-8 from:
%color=#7777BB%[[Talk.Listing|All-Talks]]%% 
to:
%color=#7777BB%[[Talk.Listing|All-Talks]] |
%color=#7777BB%[[Talk.ListingSorted|All-Sorted
]]%% 
Changed lines 5-6 from:
!!!! %color=#7777BB% [[Talk.03-Redfield|Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.05-BillinGumstix|Next-Talk]]%% | \
to:
!!!! %color=#7777BB% [[Talk.01-Newman|Prev-Talk]]%%  | \
%color=#7777BB%[[Talk.02-YaariA|Next-Talk]]%% | \
Changed lines 10-17 from:
!! Talk-29: ''Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm''

!!!!%color=#449944% '''Matthew J. Bays, Jean-François Kamath and Signe A. Redfield, NSWC-PCD'''

We address the integration and field testing of a novel reacquire/identify(RID) pattern generation algorithm.  This algorithm, known as Probabilistic Reacquire/ID Optimal Path Selection (PROPS), is designed to plan a path for a sidescan sonar equipped underwater vehicle in order to produce multiple views of a cluster of discrete targets.  The desired pattern minimizes the total number of turns and time required, while attaining appropriate coverage of the targets. Initial tests of the pattern generation algorithm suggest that it requires between 35% and 95% of the time required by the standard “star” RID pattern.  Following a brief description of the algorithm itself, we present the integration of the algorithm, both as a stand-alone MOOS module and as a library using a standard RID pattern generator created from the MOOS-IvP Helm autonomy toolkit.  Simulation and field test results of the algorithm on a REMUS 100 autonomous underwater vehicle are included
.


to:
!! Talk-01: ''MOOS Updates (PLACEHOLDER)''

!!!!%color=#449944% '''Paul Newman, Oxford'''

No Abstract Yet
.


Changed lines 20-24 from:
* Autonomy
* MOOS-IvP
* MCM
* UUVs
* Navy Labs
to:
* Academia
Changed line 18 from:
!!!!%color=#BD614A% '''Categories:''' \
to:
!!!!%color=#4444BB% '''Categories:''' \
Changed line 10 from:
!! Talk-04: ''Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm''
to:
!! Talk-29: ''Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm''
Changed line 18 from:
!!!%color=#BD614A% '''Categories:''' \
to:
!!!!%color=#BD614A% '''Categories:''' \
Changed line 18 from:
%color=#BD614A% '''Categories:''' \
to:
!!!%color=#BD614A% '''Categories:''' \
Changed lines 6-7 from:
%color=#7777BB%[[Talk.05-BillinGumstix|Next-Talk]]%% 
to:
%color=#7777BB%[[Talk.05-BillinGumstix|Next-Talk]]%% | \
%color=#7777BB%[[Talk.Listing|All-Talks
]]%% 
Changed line 11 from:
!!!!%color=#449944% '''Matthew J. Bays, Jean- François Kamath and Signe A. Redfield, NSWC-PCD'''
to:
!!!!%color=#449944% '''Matthew J. Bays, Jean-François Kamath and Signe A. Redfield, NSWC-PCD'''
Changed line 5 from:
!!!! %color=#7777BB% [[Talk.03-Redfield|Prev-Talk]]%%  |
to:
!!!! %color=#7777BB% [[Talk.03-Redfield|Prev-Talk]]%%  | \
Changed lines 5-6 from:
!!!! %color=#7777BB% [[Talk.03-Redfield|Prev-Talk]]%%  | [[Talk.05-BillinGumstix|Next-Talk]] 
to:
!!!! %color=#7777BB% [[Talk.03-Redfield|Prev-Talk]]%%  |
%color=#7777BB%[[Talk.05-BillinGumstix|Next-Talk]]%% 
Changed line 5 from:
!!!! %color=#444499% [[Talk.03-Redfield|Prev-Talk]]%%  | [[Talk.05-BillinGumstix|Next-Talk]] 
to:
!!!! %color=#7777BB% [[Talk.03-Redfield|Prev-Talk]]%%  | [[Talk.05-BillinGumstix|Next-Talk]] 
Changed line 5 from:
!!!! %color=#449944% [[Talk.03-Redfield|Prev-Talk]]%%  | [[Talk.05-BillinGumstix|Next-Talk]] 
to:
!!!! %color=#444499% [[Talk.03-Redfield|Prev-Talk]]%%  | [[Talk.05-BillinGumstix|Next-Talk]] 
Changed line 5 from:
[[Talk.03-Redfield|Prev-Talk]]  | [[Talk.05-BillinGumstix|Next-Talk]] 
to:
!!!! %color=#449944% [[Talk.03-Redfield|Prev-Talk]]%%  | [[Talk.05-BillinGumstix|Next-Talk]] 
Changed line 5 from:
[[Talk.04-Redfield|Prev-Talk]]  | [[Talk.04-Redfield|Next-Talk]] 
to:
[[Talk.03-Redfield|Prev-Talk]]  | [[Talk.05-BillinGumstix|Next-Talk]] 
Added lines 4-6:

[[Talk.04-Redfield|Prev-Talk]]  | [[Talk.04-Redfield|Next-Talk]] 

Changed line 7 from:
%color=#449944% '''Matthew J. Bays, Jean- François Kamath and Signe A. Redfield, NSWC-PCD'''
to:
!!!!%color=#449944% '''Matthew J. Bays, Jean- François Kamath and Signe A. Redfield, NSWC-PCD'''
Changed line 5 from:
!! ''Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm''
to:
!! Talk-04: ''Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm''
Changed line 13 from:
%color=#BD614A% '''Topics:''' \
to:
%color=#BD614A% '''Categories:''' \
Added line 19:
* Navy Labs
Changed lines 5-11 from:
!! ''MOOS-Enabled Semi-Autonomous Remote USV Operations''

%color=#449944% '''Signe Redfield, NSWC-PCD'''

A multi-vehicle mission involving simultaneous identification (by UUVs) and neutralization (by a USV)
of targets is complicated by the need to keep the neutralization efforts distant from the
identification vehicles.  As targets are identified by the UUVs, they are relayed to the USV for imaging (proxy for neutralization).  The USV plans
a sequence of neutralization efforts based on desired efficiency (prosecuting targets in close proximity in the same sequence), neutralization capacity (number of targets that can be prosecuted without reloading), the location of the reloading depot, and distance from other vehicles.  We present a solution to this variation of the capacitated vehicle routing problem, implemented on a semi-autonomous USV.  MOOS performed the autonomous portion of the mission running on a remote laptop while a human operator ran a teleoperated underwater vehicle launched and retrieved from the USV as a proxy for the neutralization system as each target was reached. Together the system demonstrated semi-autonomous remote USV operations, with the human operator working smoothly with the autonomous system.
to:
!! ''Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm''

%color=#449944% '''Matthew J. Bays, Jean- François Kamath and Signe A. Redfield, NSWC-PCD'''

We address the integration and field testing
of a novel reacquire/identify(RID) pattern generation algorithm.  This algorithm, known as Probabilistic Reacquire/ID Optimal Path Selection (PROPS), is designed to plan a path for a sidescan sonar equipped underwater vehicle in order to produce multiple views of a cluster of discrete targets.  The desired pattern minimizes the total number of turns and time required, while attaining appropriate coverage of the targets. Initial tests of the pattern generation algorithm suggest that it requires between 35% and 95% of the time required by the standard “star” RID pattern.  Following a brief description of the algorithm itself, we present the integration of the algorithm, both as a stand-alone MOOS module and as a library using a standard RID pattern generator created from the MOOS-IvP Helm autonomy toolkit.  Simulation and field test results of the algorithm on a REMUS 100 autonomous underwater vehicle are included.


Deleted line 14:
* Multi-Vehicle Autonomy
Changed line 17 from:
* Neutralization
to:
* MCM
Deleted line 18:
* USVs
Changed lines 5-10 from:
!! ''Autonomous Adaptive Environmental Feature Tracking on Board AUVs: Tracking the Thermocline''

%color=#449944% '''Stephanie Petillo, MIT (LAMSS)'''

This talk addresses the challenge of autonomously and adaptively tracking features of the underwater environment using AUVs running the MOOS-IvP autonomy software.  This problem is addressed from concept to implementation in the field on various AUV platforms, developing specifically the example of thermocline trackingSome recent research involving methods for feature tracking on board multiple AUVs operating simultaneously and collaboratively to detect an underwater feature will also be discussed briefly.
to:
!! ''MOOS-Enabled Semi-Autonomous Remote USV Operations''

%color=#449944% '''Signe Redfield, NSWC-PCD'''

A multi-vehicle mission involving simultaneous identification (by UUVs) and neutralization (by a USV) of targets is complicated by the need to keep the neutralization efforts distant from the
identification vehicles.  As targets are identified by
the UUVs, they are relayed to the USV for imaging (proxy for neutralization)The USV plans a sequence of neutralization efforts based on desired efficiency (prosecuting targets in close proximity in the same sequence), neutralization capacity (number of targets that can be prosecuted without reloading), the location of the reloading depot, and distance from other vehicles.  We present a solution to this variation of the capacitated vehicle routing problem, implemented on a semi-autonomous USV.  MOOS performed the autonomous portion of the mission running on a remote laptop while a human operator ran a teleoperated underwater vehicle launched and retrieved from the USV as a proxy for the neutralization system as each target was reached. Together the system demonstrated semi-autonomous remote USV operations, with the human operator working smoothly with the autonomous system.
Deleted line 13:
* Environmental Sampling
Added line 17:
* Neutralization
Added line 19:
* USVs
Added line 17:
* UUVs
Changed lines 9-10 from:
One of the greatest challenges of working in the underwater regime is the severe limitations of acoustic communications. This problem becomes even more evident in multi-vehicle autonomy, when vehicles must continually update each other with their state and intentions to achieve cooperative goals. In order to support tests of a multi-vehicle arbiter framework, an optimization scheme was created and implemented as a MOOS module to enable sufficient message passing between vehicles. Using this tool, vehicle state and destination, shared map updates, updated algorithm parameters, target information, and decision reconciliation can be effectively shared between vehicles using the published Compact Control Language (CCL) standard for acoustic messages.
to:
This talk addresses the challenge of autonomously and adaptively tracking features of the underwater environment using AUVs running the MOOS-IvP autonomy software.  This problem is addressed from concept to implementation in the field on various AUV platforms, developing specifically the example of thermocline tracking.  Some recent research involving methods for feature tracking on board multiple AUVs operating simultaneously and collaboratively to detect an underwater feature will also be discussed briefly.
Changed line 13 from:
* Acoustic Communications,
to:
* Environmental Sampling
Changed lines 15-17 from:
* Autonomy%%
to:
* Autonomy
* MOOS-IvP
%%
Changed line 7 from:
%color=#449944% '''Stephanie Petillo, MIT (LAMSS)''
to:
%color=#449944% '''Stephanie Petillo, MIT (LAMSS)'''
Changed lines 5-7 from:
!! ''Unmanned Robot Message Optimization Method (URMOM)''

%color=#449944% '''Andrew Bouchard, NSWC-PCD'''
to:
!! ''Autonomous Adaptive Environmental Feature Tracking on Board AUVs: Tracking the Thermocline''

%color=#449944% '''Stephanie Petillo, MIT (LAMSS)''
Changed lines 11-15 from:
%color=#BD614A% '''Topics:''' Acoustic Communications, Multi-Vehicle Autonomy, Autonomy%%
to:
%color=#BD614A% '''Topics:''' \

*
Acoustic Communications,
*
Multi-Vehicle Autonomy
* Autonomy%%
Changed line 11 from:
''Topics:'' Acoustic Communications, Multi-Vehicle Autonomy, Autonomy
to:
%color=#BD614A% '''Topics:''' Acoustic Communications, Multi-Vehicle Autonomy, Autonomy%%
Changed lines 9-11 from:
One of the greatest challenges of working in the underwater regime is the severe limitations of acoustic communications. This problem becomes even more evident in multi-vehicle autonomy, when vehicles must continually update each other with their state and intentions to achieve cooperative goals. In order to support tests of a multi-vehicle arbiter framework, an optimization scheme was created and implemented as a MOOS module to enable sufficient message passing between vehicles. Using this tool, vehicle state and destination, shared map updates, updated algorithm parameters, target information, and decision reconciliation can be effectively shared between vehicles using the published Compact Control Language (CCL) standard for acoustic messages.
to:
One of the greatest challenges of working in the underwater regime is the severe limitations of acoustic communications. This problem becomes even more evident in multi-vehicle autonomy, when vehicles must continually update each other with their state and intentions to achieve cooperative goals. In order to support tests of a multi-vehicle arbiter framework, an optimization scheme was created and implemented as a MOOS module to enable sufficient message passing between vehicles. Using this tool, vehicle state and destination, shared map updates, updated algorithm parameters, target information, and decision reconciliation can be effectively shared between vehicles using the published Compact Control Language (CCL) standard for acoustic messages.

''Topics:'' Acoustic Communications, Multi-Vehicle Autonomy, Autonomy
Changed line 7 from:
%color=#449944% '''Andrew Bouchard, NSWC PCD'''
to:
%color=#449944% '''Andrew Bouchard, NSWC-PCD'''
Changed line 7 from:
%color=#449944% '''Andrew Bouchard, NSWC PCD'''%
to:
%color=#449944% '''Andrew Bouchard, NSWC PCD'''
Changed line 7 from:
%color=#449944% !!! '''Andrew Bouchard, NSWC PCD'''%
to:
%color=#449944% '''Andrew Bouchard, NSWC PCD'''%
Changed line 7 from:
!!! '''Andrew Bouchard, NSWC PCD'''
to:
%color=#449944% !!! '''Andrew Bouchard, NSWC PCD'''%
Changed line 7 from:
'''Andrew Bouchard, NSWC PCD'''
to:
!!! '''Andrew Bouchard, NSWC PCD'''
Changed line 5 from:
!! Title: ''Unmanned Robot Message Optimization Method (URMOM)''
to:
!! ''Unmanned Robot Message Optimization Method (URMOM)''
Changed line 5 from:
Title: ''Unmanned Robot Message Optimization Method (URMOM)''
to:
!! Title: ''Unmanned Robot Message Optimization Method (URMOM)''
Changed lines 1-3 from:
Title: Unmanned Robot Message Optimization Method (URMOM)

Andrew Bouchard, NSWC PCD
to:
(:notitle:)
(:notitlegroup:)
(:nofooter:)

Title: ''Unmanned Robot Message Optimization Method (URMOM)''

'''Andrew Bouchard, NSWC PCD'''
Changed lines 5-6 from:
     One of the greatest challenges of working in the underwater regime is the
severe limitations of acoustic communications. This problem becomes even more evident in multi-vehicle autonomy, when vehicles must continually update each other with their state and intentions to achieve cooperative goals. In order to support tests of a multi-vehicle arbiter framework, an optimization scheme was created and implemented as a MOOS module to enable sufficient message passing between vehicles. Using this tool, vehicle state and destination, shared map updates, updated algorithm parameters, target information, and decision reconciliation can be effectively shared between vehicles using the published Compact Control Language (CCL) standard for acoustic messages.
to:
One of the greatest challenges of working in the underwater regime is the severe limitations of acoustic communications. This problem becomes even more evident in multi-vehicle autonomy, when vehicles must continually update each other with their state and intentions to achieve cooperative goals. In order to support tests of a multi-vehicle arbiter framework, an optimization scheme was created and implemented as a MOOS module to enable sufficient message passing between vehicles. Using this tool, vehicle state and destination, shared map updates, updated algorithm parameters, target information, and decision reconciliation can be effectively shared between vehicles using the published Compact Control Language (CCL) standard for acoustic messages.
Changed lines 5-14 from:
     One of the greatest challenges of working in the underwater regime is the \
severe limitations of acoustic communications. This problem becomes even more e\
vident
in multi-vehicle autonomy, when vehicles must continually update each ot\
her
with their state and intentions to achieve cooperative goals. In order to s\
upport
tests of a multi-vehicle arbiter framework, an optimization scheme was c\
reated
and implemented as a MOOS module to enable sufficient message passing be\
tween
vehicles. Using this tool, vehicle state and destination, shared map upda\
tes
, updated algorithm parameters, target information, and decision reconciliat\
ion
can be effectively shared between vehicles using the published Compact Cont\
rol
Language (CCL) standard for acoustic messages.
to:
     One of the greatest challenges of working in the underwater regime is the
severe limitations of acoustic communications. This problem becomes even more evident in multi-vehicle autonomy, when vehicles must continually update each other with their state and intentions to achieve cooperative goals. In order to support tests of a multi-vehicle arbiter framework, an optimization scheme was created and implemented as a MOOS module to enable sufficient message passing between vehicles. Using this tool, vehicle state and destination, shared map updates, updated algorithm parameters, target information, and decision reconciliation can be effectively shared between vehicles using the published Compact Control Language (CCL) standard for acoustic messages.
Added lines 1-14:
Title: Unmanned Robot Message Optimization Method (URMOM)

Andrew Bouchard, NSWC PCD

    One of the greatest challenges of working in the underwater regime is the \
severe limitations of acoustic communications. This problem becomes even more e\
vident in multi-vehicle autonomy, when vehicles must continually update each ot\
her with their state and intentions to achieve cooperative goals. In order to s\
upport tests of a multi-vehicle arbiter framework, an optimization scheme was c\
reated and implemented as a MOOS module to enable sufficient message passing be\
tween vehicles. Using this tool, vehicle state and destination, shared map upda\
tes, updated algorithm parameters, target information, and decision reconciliat\
ion can be effectively shared between vehicles using the published Compact Cont\
rol Language (CCL) standard for acoustic messages.