25-Schneider
Talk.25-Schneider History
Hide minor edits - Show changes to markup
Talk-05: Goby: A Framework for Multiple Scientific Autonomous Marine Vehicle Collaboration
Talk-25: Goby-Acomms (including pAcommsHandler) Version 2: An Update on Acoustic Networking for Robotic Marine Platforms
Abstract: Goby (https://launchpad.net/goby) is a collection of ideas and code to provide general purpose interprocess and inter-platform communication based on messaging schemes drawn both from the existing marine robotics and global open source communities. The focus is on a high degree of runtime reliability and collaboration between development communities.
- For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization, routing, sockets, and so on.
- For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g. MOOSDB, LCM multicast).
This talk will focus on the aspects of Goby that pertain directly to MOOS, including the MOOS/Goby gateway and CMOOSMsg logging in the Goby Database SQL logger. The acoustic networking components of Goby are addressed in a separate talk entitled "Goby-Acomms (including pAcommsHandler) Version 2: An Update on Acoustic Networking for Robotic Marine Platforms"
Goby-Acomms (including the MOOS interface application "pAcommsHandler") provides a complete "slow-link" networking package for use on links much slower (in both latency and throughput) than many commonly encountered terrestrial channels. As the name suggests this is useful for acoustic communications (such as with the WHOI Micro-Modem) but also with other very low bandwidth / very high latency links (e.g. satellite comms).
This talk will focus on the changes since MOOS-DAWG 2010 which include:
- Use of Google Protocol buffers instead of XML for the Dynamic Compact Control Language (DCCL) schema.
- Use of completely customizable callbacks for encoding / decoding DCCL types
- More comprehensive support for the WHOI Micro-Modem ranging capabilities
- Full support for extending Goby-Acomms to use other acoustic modems.
- Autonomy Middleware
- High Volume Data Logging
- WHOI Micro-Modem
- For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g.
MOOSDB, LCM multicast).
- For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g. MOOSDB, LCM multicast).
- For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie
together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g.
- For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g.
- For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization,
routing, sockets, and so on.
- For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization, routing, sockets, and so on.
Toby Schneider, MIT, Laboratory for Autonomous Marine Sensing Systems, Center for Ocean Engineering
Goby (https://launchpad.net/goby) is a collection of ideas and code to provide general purpose interprocess and interplatform communication based on messaging schemes drawn both from the existing marine robotics and global open source communities. The focus is on a high degree of runtime reliability and collaboration between development communities. For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization, routing, sockets, and so on. For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g. MOOSDB, LCM multicast).
This talk will focus on the aspects of Goby that pertain directly to MOOS, including the MOOS/Goby gateway and CMOOSMsg logging in the Goby Database SQL logger.
Toby Schneider, MIT, Laboratory for Autonomous Marine Sensing Systems (LAMSS), and Center for Ocean Engineering
Abstract: Goby (https://launchpad.net/goby) is a collection of ideas and code to provide general purpose interprocess and inter-platform communication based on messaging schemes drawn both from the existing marine robotics and global open source communities. The focus is on a high degree of runtime reliability and collaboration between development communities.
- For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization,
routing, sockets, and so on.
- For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie
together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g. MOOSDB, LCM multicast).
This talk will focus on the aspects of Goby that pertain directly to MOOS, including the MOOS/Goby gateway and CMOOSMsg logging in the Goby Database SQL logger. The acoustic networking components of Goby are addressed in a separate talk entitled "Goby-Acomms (including pAcommsHandler) Version 2: An Update on Acoustic Networking for Robotic Marine Platforms"
- Middleware
- Autonomy Middleware
Toby Schneider, MIT
Toby Schneider, MIT, Laboratory for Autonomous Marine Sensing Systems, Center for Ocean Engineering
Goby (https://launchpad.net/goby) is a collection of ideas and code to provide general purpose interprocess and interplatform communication based on messaging schemes drawn both from the existing marine robotics and global open source communities. The focus is on a high degree of runtime reliability and collaboration between development communities. - For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization, routing, sockets, and so on. For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g. MOOSDB, LCM multicast).
Goby (https://launchpad.net/goby) is a collection of ideas and code to provide general purpose interprocess and interplatform communication based on messaging schemes drawn both from the existing marine robotics and global open source communities. The focus is on a high degree of runtime reliability and collaboration between development communities. For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization, routing, sockets, and so on. For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g. MOOSDB, LCM multicast).
Talk-04: Goby: A Framework for Multiple Scientific Autonomous Marine Vehicle Collaboration
Talk-05: Goby: A Framework for Multiple Scientific Autonomous Marine Vehicle Collaboration
Talk-04: Powerful, Lightweight Scripting and Configuration of MOOS Applications Using Lua
Ian Katz, MIT
The cutting edge of AUV development focuses on the major components of navigation and decision-making, but there is a "long tail" of development required for the simpler applications that support them. These minor components perform very mundane tasks and consume very few resources, yet require a measurable amount of development time -- time that is taken away from actual innovation. We provide a framework for rapid development of these minor applications -- allowing the functionality of MOOS to be scripted -- though a language specially suited to that purpose: Lua. This framework allows MOOS applications to be expressed in far fewer lines of code with much better "syntactic sugar" for accessing settings and MOOS messages, ultimately enabling a much faster and more productive development cycle. Additionally, we show how Lua can be used to enhance the runtime configuration of MOOS applications: improving the simplicity, manageability, and power of the configuration system.
Talk-04: Goby: A Framework for Multiple Scientific Autonomous Marine Vehicle Collaboration
Toby Schneider, MIT
Goby (https://launchpad.net/goby) is a collection of ideas and code to provide general purpose interprocess and interplatform communication based on messaging schemes drawn both from the existing marine robotics and global open source communities. The focus is on a high degree of runtime reliability and collaboration between development communities. - For introductory users, it provides an "template" application in C++ that allows object-based messaging (based on Google Protocol Buffers) between processes and platforms without any concern for serialization, routing, sockets, and so on. For advanced users, it provides a transport layer built on ZeroMQ (which supports 20+ languages including C, C++, Java, .NET, Python, and major platforms) for communicating over reliable multicast (PGM) using one or more existing (e.g. MOOS, LCM, Protobuf, CCL, DCCL, ...) messaging schemes. Goby does not mandate a programming language, a messaging scheme, or a development system and thus intends to tie together groups with different goals, styles, and rules. Furthermore, Gateways can be written to interface the ZeroMQ based Goby transport with the native transport systems used by other architectures (e.g. MOOSDB, LCM multicast).
This talk will focus on the aspects of Goby that pertain directly to MOOS, including the MOOS/Goby gateway and CMOOSMsg logging in the Goby Database SQL logger.
- Mission Configuration
- Middleware
Talk-01: Powerful, Lightweight Scripting and Configuration of MOOS Applications Using Lua
Talk-04: Powerful, Lightweight Scripting and Configuration of MOOS Applications Using Lua
Ian Katz, MIT'
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.
Ian Katz, MIT
The cutting edge of AUV development focuses on the major components of navigation and decision-making, but there is a "long tail" of development required for the simpler applications that support them. These minor components perform very mundane tasks and consume very few resources, yet require a measurable amount of development time -- time that is taken away from actual innovation. We provide a framework for rapid development of these minor applications -- allowing the functionality of MOOS to be scripted -- though a language specially suited to that purpose: Lua. This framework allows MOOS applications to be expressed in far fewer lines of code with much better "syntactic sugar" for accessing settings and MOOS messages, ultimately enabling a much faster and more productive development cycle. Additionally, we show how Lua can be used to enhance the runtime configuration of MOOS applications: improving the simplicity, manageability, and power of the configuration system.
- MOOS-IvP
- Anti-Submarine Warfare
- Mission Configuration
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
Kevin LePage, NATO Undersea Research Centre
Talk-01: Powerful, Lightweight Scripting and Configuration of MOOS Applications Using Lua
Ian Katz, MIT'
Talk-01: MOOS Then, Now and Next
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.
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
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.
- MOOS Core
- Academia
- MOOS-IvP
- Anti-Submarine Warfare
Talk-01: MOOS Updates (PLACEHOLDER)
Talk-01: MOOS Then, Now and Next
No Abstract Yet.
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.
- MOOS Core
Talk-29: Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm
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.
Talk-01: MOOS Updates (PLACEHOLDER)
Paul Newman, Oxford
No Abstract Yet.
- Autonomy
- MOOS-IvP
- MCM
- UUVs
- Navy Labs
- Academia
Talk-04: Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm
Talk-29: Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm
Matthew J. Bays, Jean- François Kamath and Signe A. Redfield, NSWC-PCD
Matthew J. Bays, Jean-François Kamath and Signe A. Redfield, NSWC-PCD
Matthew J. Bays, Jean- François Kamath and Signe A. Redfield, NSWC-PCD
Matthew J. Bays, Jean- François Kamath and Signe A. Redfield, NSWC-PCD
Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm
Talk-04: Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm
MOOS-Enabled Semi-Autonomous Remote USV Operations
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.
Integration and Testing of a Novel Reacquire/Identify Pattern Generation Algorithm
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.
- Multi-Vehicle Autonomy
- Neutralization
- MCM
- USVs
Autonomous Adaptive Environmental Feature Tracking on Board AUVs: Tracking the Thermocline
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 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.
MOOS-Enabled Semi-Autonomous Remote USV Operations
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.
- Environmental Sampling
- Neutralization
- USVs
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.
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.
- Acoustic Communications,
- Environmental Sampling
- Autonomy
- Autonomy
- MOOS-IvP
'Stephanie Petillo, MIT (LAMSS)
Stephanie Petillo, MIT (LAMSS)
Unmanned Robot Message Optimization Method (URMOM)
Andrew Bouchard, NSWC-PCD
Autonomous Adaptive Environmental Feature Tracking on Board AUVs: Tracking the Thermocline
'Stephanie Petillo, MIT (LAMSS)
Topics: Acoustic Communications, Multi-Vehicle Autonomy, Autonomy
Topics:
- Acoustic Communications,
- Multi-Vehicle Autonomy
- Autonomy
Topics: Acoustic Communications, Multi-Vehicle Autonomy, Autonomy
Topics: Acoustic Communications, Multi-Vehicle Autonomy, Autonomy
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.
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
Andrew Bouchard, NSWC PCD
Andrew Bouchard, NSWC-PCD
Andrew Bouchard, NSWC PCD%
Andrew Bouchard, NSWC PCD
!!! Andrew Bouchard, NSWC PCD%
Andrew Bouchard, NSWC PCD%
Andrew Bouchard, NSWC PCD
!!! Andrew Bouchard, NSWC PCD%
Andrew Bouchard, NSWC PCD
Andrew Bouchard, NSWC PCD
Title: Unmanned Robot Message Optimization Method (URMOM)
Unmanned Robot Message Optimization Method (URMOM)
Title: Unmanned Robot Message Optimization Method (URMOM)
Title: Unmanned Robot Message Optimization Method (URMOM)
Title: Unmanned Robot Message Optimization Method (URMOM)
Andrew Bouchard, NSWC PCD
(:notitle:) (:notitlegroup:) (:nofooter:)
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 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.
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.
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.
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.
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 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.