// alogeval
// alogload
// alogtest
// alogtm
// ffview
// geoview
// manifest_test
// nsplug
// lib_evalutil
// uFldWrapDetect
//====================================================================
module = alogavg
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Utility for averaging Y-values per X-Value for file with X-Y value per line
depends = lib_mbutil, lib_logutils, lib_apputil
borndate = 211215
doc_url = http://oceanai.mit.edu/ivpman/apps/alogavg
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = Given a file of data, two values per line, treat each line
as having an x value and y value. This tool will calculate the
average y value given several (x,y) pairs. It will also calculate
the min, max, standard deviation of for each x value.
//====================================================================
module = alogbin
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Utility for binning data within similar ranges into clusters
depends = lib_mbutil, lib_logutils
borndate = 200826
doc_url = http://oceanai.mit.edu/ivpman/apps/to-be-written
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = Given a file of data, one value per line, bin each value
into the given delta and count the number in each bin.
//====================================================================
module = alogcat
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = ConCATinate two alog files into one alog file
depends = lib_mbutil, lib_logutils
borndate = 180813
doc_url = http://oceanai.mit.edu/ivpman/apps/alogcat
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = Create a new MOOS .alog file from two or more given .alog
files. Given files are meant to be non-overlapping in time,
presumably made by starting and stopping a single MOOS community.
//====================================================================
module = alogcd
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Scan an alog file for collision detection reports.
depends = lib_mbutil, lib_logutils
borndate = 151223
doc_url = http://oceanai.mit.edu/ivpman/apps/alogcd
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = Scan an alog file for collision detection reports. Tally
the totals and averages, and optionally create a file holding all
the timestamps of events. By default, it scans for events defined
by postings to the following three MOOS variables: (1) COLLISION,
(2) NEAR_MISS, and (3) ENCOUNTER.
//====================================================================
module = alogcheck
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Scan an alog file and check if given condition is satisfied
depends = lib_mbutil, lib_logutils, lib_logic
borndate = 151223
doc_url = Pending
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogcheck is a command line utility that checks if a
specified condition has been satisfied in an alog file. It can
be used as part of an autonomated verification and validation scheme
to check whether a certain success or failure condition was produced
by a mission.
The tool can accept a start and end timestamp, or work with the whole
file. A pass condition may be specified, or alternatively a failure
condition may be specified. A results output file may be specified or
else all output goes to the terminal.
//====================================================================
module = alogclip
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Trim an alog file given a start and end time stamp
depends = lib_mbutil, lib_logutils,
borndate = 080605
doc_url = http://oceanai.mit.edu/ivpman/apps/alogclip
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogclip is a command line utility that creates a new alog
file from a given alog file, by removing all entries outside a given
time window. Often useful in post-mission handling of data, especially
when an alog file inadvertently contains perhaps hours of data not
relevant to the mission, e.g., if the logger recorded substantial data
prior or after in-water deployment.
//====================================================================
module = alogeplot
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Produce an encounter plot image from encounters from and alog file.
depends = lib_mbutil, lib_logutils, lib_encounters
borndate = 160116
doc_url = Pending
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogeplot is a command line utility that creates an image,
an "encounter plot", rendering all encounters found in the given alog
file on a 2D plot with the axes of safety (based on CPA distance)
and efficiency (application dependent).
//====================================================================
module = aloggrep
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Trim an alog file by retaining specified MOOS variables
depends = lib_mbutil, lib_logutils,
borndate = 080806
doc_url = http://oceanai.mit.edu/ivpman/apps/aloggrep
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = aloggrep is a command line utility that create a new alog
file, from a given alog file, by retaining only the given MOOS
variables or sources, named on the command line. Often useful in
post-mission analysis if one wants to look at only the data from
a particular source, such as NAV for GPS data for example.
//====================================================================
module = aloghelm
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Scan an alog file to generate one of several helm reports
depends = lib_mbutil, lib_logutils, lib_helmivp, lib_behaviors,
lib_ivpbuild, lib_ivpcore, lib_ivpsolve
borndate = 100310
doc_url = http://oceanai.mit.edu/ivpman/apps/aloghelm
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = aloghelm is a command line utility that will perform one of
several user specified helm reports based on helm output logged in
the given alog file. Reports include:
(1) Life events: A report on IvP Helm life events, i.e. behavior spawnings
and destructions.
(2) Behavior state changes: A report showing which behaviors changed state
when, and to which states.
(3) Helm Mode changes: A report showing when the helm changed modes and
to which modes.
//====================================================================
module = alogiter
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Scan an alog file to analyze avg application load by iterations
depends = lib_mbutil, lib_logutils
borndate = 131222
doc_url = http://oceanai.mit.edu/ivpman/apps/alogiter
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogiter is a command line utility that will scan a given alog
file and produce a report on the noted iteration length, and gap between
iterations, for all applications that have produced the ITER_GAP and
ITER_LEN output variables. This is a quick way to check if a certain
application may have peaked in load at some point during the mission,
perhaps to the point where it was not able to run at its requested
frequency.
//====================================================================
module = alogpare
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Prune an alog file based on events and mark values
depends = lib_mbutil, lib_logutils
borndate = 151225
doc_url = http://oceanai.mit.edu/ivpman/apps/alogpare
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogpare is a command line utility that will create a new
alog file from a given alog file. It will pare the original file in
a two-pass manner. The first pass detects events defined by provided
mark variables. The second pass will remove lines involving variables
on a hit-list that are not within a specified window of time of an
event line.
This utility may be useful in post-mission data managment by greatly
thinning large log files by reducing information outside of events
of interest. For example in collision avoidance testing, the log files
may be pruned unless an encounter involving a near collision is noted.
There may be no need for full data outside of near collision windows.
//====================================================================
module = alogrm
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Prune an alog file by removing nammed MOOS variables
depends = lib_mbutil, lib_logutils
borndate = 080806
doc_url = http://oceanai.mit.edu/ivpman/apps/alogrm
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogrm is a command line utility that will generate a new
alog file from a given alog file, by removing certain lines. A line
may be targeted for removal if its name matches one or more provided
MOOS variables. Or it may be removed if its source matches one or
more provided app names.
This utility may be useful in post-mission data managment by greatly
thinning large log files if certain data in those files can be safely
discarded.
//====================================================================
module = alogscan
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Scan an alog file and produce breakdowns on log volume
depends = lib_mbutil, lib_logutils
borndate = 080605
doc_url = http://oceanai.mit.edu/ivpman/apps/alogscan
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogscan is a command line utility that will create summary
report from a given alog file. This report will contain a line for all
logged MOOS variables, noting which app(s) published to it, the first
and last publish time, and the total number of lines and characters in
the alog file used by this variable.
//====================================================================
module = alogsort
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Create new alog file sorting entries based on timestamp
depends = lib_mbutil, lib_logutils
borndate = 130622
doc_url = Pending
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogsort is a command line utility that will create a new alog
file from a given alog file, by ensuring absolute ordering of all lines
based on their timestamps. In general pLogger/alog lines are ordered, but
occasionally they are not. Most alog utilities do not rely on the assumption
of absolute ordering. But if a utility does indeed depend on this absolute
ordering, this tool can be used to create an equivalent alog file with
guaranteed absolute ordering of lines.
//====================================================================
module = alogsplit
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Split an alog file into dedicated alog files per variable
depends = lib_mbutil, lib_logutils
borndate = 150215
doc_url = http://oceanai.mit.edu/ivpman/apps/alogsplit
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogsplit is a command line utility that will take a given
alog file and split the contents into a directory, within which each
MOOS variable is split into its own (klog) file containing only that
variable. The split will also create a summary .klog (pronounced "kay-log") file with
summary information. The original alog file is unchanged. It will
not overwrite the directory if previously created.
This is essentially the operation done at the outset of launching
the alogview applicaton. The split allows for faster access for
information indexed on a given variable name. This utility can be
run prior to launching alogview, which will shorten the launch time
of alogview. Otherwise alogview will perform this step autonomically
the first time it is launched with the given alog file.
//====================================================================
module = alogview
type = GUI utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A GUI tool for replaying and analyzing one or more vehicle alog files
depends = lib_mbutil, lib_logutils, lib_marineview, lib_helmivp,
lib_geometry, lib_contacts, lib_ipfview, lib_encounters,
lib_ivpbuild, lib_apputil
borndate = 150215
doc_url = http://oceanai.mit.edu/ivpman/apps/alogview
license = GPL
group = MOOS-IvP, ALog Toolbox
distro = moos-ivp.org
synopsis = alogview is a GUI based tool for rendering vehicle paths
from multiple MOOS .alog files. The user may simply replay logged
data, or step through manually, or index anywhere on the timeline
with a single mouse click. Supports several specialized pop-up
windows for viewing helm state, objective functions, any logged
variable across vehicles. If multiple alog files are given, they
will be synchronized. Upon launch, the original alog files are split
into dedicated directories to cache data base on the MOOS variable
name.
//====================================================================
module = gen_obstacles
type = General Utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A command line tool for random generation of obstacle polygons to a file
depends = lib_mbutil, lib_geometry, lib_obstacles
borndate = 171018
doc_url = http://oceanai.mit.edu/ivpman/apps/to-be-written
license = GPL
group = MOOS-IvP, Simulation
distro = moos-ivp.org
synopsis = gen_obstacles is a utility for generating a obstacle file,
a set of polygon obstacles, all guaranteed to be within the user
specified polygon region, none of them overlapping and guaranteed to
have a minimum separation range.
//====================================================================
module = BHV_AvdColregs
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for avoiding collision based on CPA and COLREGS considerations.
borndate = 130516
doc_url = http://oceanai.mit.edu/ivpman/bhvs/AvdColregs
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = The AvdColregs behavior will produce IvP objective
functions designed to avoid collisions (and near collisions) with
another specified vehicle, based on the protocol found in the US
Coast Guard Collision Regulations (COLREGS). The IvP functions
produced by this behavior are defined over the domain of posssible
heading and speed choices. The utility assigned to a point in this
domain (a heading-speed pair) depends in part on the calculated
closest point of approach (CPA) between the candidate maneuver leg,
and the contact leg formed from the contact's position and
trajectory. A further user-defined utility function is applied to
the CPA calculation for a candidate maneuver.
//====================================================================
module = BHV_AvoidCollision
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for avoiding collision based primarily on CPA considerations.
borndate = 061118
doc_url = http://oceanai.mit.edu/ivpman/bhvs/AvoidCollision
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = The AvoidCollision behavior will produce IvP objective
functions designed to avoid collisions (and near collisions) with
another specified vehicle. The IvP functions produced by this
behavior are defined over the domain of posssible heading and speed
choices. The utility assigned to a point in this domain (a
heading-speed pair) depends in part on the calculated closest point
of approach (CPA) between the candidate maneuver leg, and the
contact leg formed from the contact's position and trajectory. A
further user-defined utility function is applied to the CPA
calculation for a candidate maneuver.
//====================================================================
module = BHV_ConstantDepth
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for specifying the desired depth of the vehicle.
depends =
borndate = 050603
doc_url = http://oceanai.mit.edu/ivpman/bhvs/ConstantDepth
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle at a specified
depth. This behavior merely expresses a preference for a particular
depth. If other behaviors also have a depth preference,
coordination/compromise will take place through the multi-objective
optimization process.
//====================================================================
module = BHV_ConstantHeading
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for specifying the desired heading of the vehicle.
depends =
borndate = 050721
doc_url = http://oceanai.mit.edu/ivpman/bhvs/ConstantHeading
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle at a specified
heading. This behavior merely expresses a preference for a
particular heading. If other behaviors also have a heading
preference, coordination/compromise will take place through the
multi-objective optimization process.
//====================================================================
module = BHV_ConstantSpeed
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for specifying the desired speed of the vehicle.
depends =
borndate = 050724
doc_url = http://oceanai.mit.edu/ivpman/bhvs/ConstantSpeed
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle at a specified
speed. This behavior merely expresses a preference for a particular
speed. If other behaviors also have a speed preference,
coordination/compromise will take place through the multi-objective
optimization process.
//====================================================================
module = BHV_CutRange
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior intercepting, closing range, to another moving vessel.
depends =
borndate = 050510
doc_url = http://oceanai.mit.edu/ivpman/bhvs/CutRange
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle to reduce the range
between itself and another specified vehicle (nearly the opposite of
the BHV_AvoidCollision behavior). A "patience" parameter may be set
to determine if the vehicle should drive straight toward the contact's
present position (no patience), or drive instead to an intercept point
at speed (high patience).
//====================================================================
module = BHV_GoToDepth
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for specifying a sequence of desired depths of the vehicle.
depends =
borndate = 060801
doc_url = http://oceanai.mit.edu/ivpman/bhvs/GoToDepth
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle to a sequence of
specified depths and duration at each depth. This behavior merely
expresses a preference for a particular depth. If other behaviors
also have a depth preference, coordination/compromise will take
place through the multi-objective optimization process.
//====================================================================
module = BHV_Loiter
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for repeatedly traversing a given convex polygon of waypoints.
borndate = 050726
doc_url = http://oceanai.mit.edu/ivpman/bhvs/Loiter
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = A behavior for transiting to and repeatedly traversing a
set of waypoints forming a convex polygon. A similar effect can be
achieved with the Waypoint behavior but this behavior assumes a set
of waypoints forming a convex polygon to exploit certain useful
algorithms. It also utilizes the non-monotonic
arrival criteria used in the Waypoint behavior to avoid loop-backs
upon waypoint near-misses. It also robustly handles dynamic exit and
re-entry modes when or if the vehicle diverges from the loiter
region due to external events. It is dynamically reconfigurable to
allow a mission control module to repeatedly reassign the vehicle to
different loiter regions by using a single persistent instance of
the behavior.
//====================================================================
module = BHV_MaxDepth
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior to influence the vehicle to go no deeper than a given depth.
depends =
borndate = 140417
doc_url = http://oceanai.mit.edu/ivpman/bhvs/MaxDepth
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle within a configured
depth tolerance. This behavior merely expresses a preference for a
particular depth. If other behaviors also have a depth preference,
coordination/compromise will take place through the multi-objective
optimization process. This behavior differs from the maximum depth
in the OpRegion behavior. In the MaxDepth behavior, an objective
function is produced to prevent the vehicle from exceeding the
maximum depth, perhaps tempering other behaviors that may prefer
deeper depths. In the OpRegion behavior there is no attempt to
influence the vehicle depth, but rather only to monitor the observed
depth and produce an error if the depth is exceeded.
//====================================================================
module = BHV_MemoryTurnLimit
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior preventing quick wrap-around turns, especiall with
towed sensor.
depends =
borndate = 060807
doc_url = http://oceanai.mit.edu/ivpman/bhvs/MemoryTurnLimit
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = The objective of the MemoryTurnLimit behavior is to avoid
vehicle turns that may cross back on its own path and risk damage to
the towed equipment. Its configuration is determined by the two
parameters which combine to set a vehicle turn radius
limit. However, it is not strictly described by a limited turn
radius; it stores a time-stamped history of recent recorded headings
and maintains a heading average, and forms its objective function on
a range deviation from that average. This behavior merely expresses
a preference for a particular heading. If other behaviors also have
a heading preference, coordination/compromise will take place
through the multi-objective optimization process.
//====================================================================
module = BHV_OpRegion
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior monitoring vehicle position to remain within a convex polygon region.
depends =
borndate = 050501
doc_url = http://oceanai.mit.edu/ivpman/bhvs/OpRegion
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior provides four different types of safety
functionality, (a) a boundary box given by a convex polygon in the
x-y or lat-lon plane, (b) an overall timeout, (c) a depth limit,
(d) an altitude limit. The behavior does not produce an objective
function to influence the vehicle to avoid violating these safety
constraints. This behavior merely monitors the constraints and posts
an error which results in the posting of all-stop commands, which
could put the vehicle into the PARK state if the helm is configured
with park_on_allstop is set to true.
//====================================================================
module = BHV_PeriodicSpeed
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for periodically influencing the vehicle speed.
depends =
borndate = 060609
doc_url = http://oceanai.mit.edu/ivpman/bhvs/PeriodicSpeed
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will periodically influence the speed of the
vehicle while remaining neutral at other times. The timing is
specified by a given period in which the influence is on (busy), and
a period specifying when the influence if off (lazy). It was
conceived for use on an AUV equipped with an acoustic modem to
periodically slow the vehicle to reduce self-noise and reduce
communication difficulty. One can also specify a flag (a MOOS
variable and value) to be posted at the start of the period to
prompt an outside action such as the start of communication
attempts.
//====================================================================
module = BHV_PeriodicSurface
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for periodically influencing the vehicle to surface.
depends =
borndate = 070221
doc_url = http://oceanai.mit.edu/ivpman/bhvs/PeriodicSurface
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will periodically influence the depth and
speed of the vehicle while remaining neutral at other times. The
purpose is to bring the vehicle to the surface periodically to
achieve some event specified by the user, typically the receipt of a
GPS fix. Once this event is achieved, the behavior resets its
internal clock to a given period length and will remain idle until a
clock time-out occurs.
//====================================================================
module = BHV_Shadow
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior matching the heading and speed of a contact vehicle.
depends =
borndate = 050510
doc_url = http://oceanai.mit.edu/ivpman/bhvs/Shadow
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle to match the
trajectory of another specified vehicle. This behavior in
conjunction with the BHV_CutRange behavior can produce a "track and
trail" capability.
//====================================================================
module = BHV_StationKeep
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for holding a vehicle at a given position.
borndate = 060825
doc_url = http://oceanai.mit.edu/ivpman/bhvs/StationKeep
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior is designed to keep the vehicle at a given
lat/lon or x,y station-keep position by varying the speed to the
station point as a linear function of its distance to the point. The
parameters allow one to choose the two distances between which the
speed varies linearly, the range of linear speeds, and a default
transit speed if the vehicle is outside the outer radius. An
alternative to this station keeping behavior is an active loiter
around a very tight polygon with the Loiter behavior. This station
keeping behavior conserves energy and aims to minimize propulsor
use. The behavior can be configured to station-keep at a pre-set
point, or wherever the vehicle happens to be when the behavior
transitions into an active state. The station-keep behavior was
initially developed for use on a small autonomous surface
craft. It's worth pointing out that a control system provided by a
vehicle manufacturer, i.e., the front-seat system, may have a native
station-keeping mode. In this case the activation of this behavior
would be replaced by a message from the backseat autonomy system to
invoke the station-keeping mode.
//====================================================================
module = BHV_TestFailure
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior designed to fail, to test the helm's handling of a behavior failure.
depends =
borndate = 111031
doc_url = http://oceanai.mit.edu/ivpman/bhvs/TestFailure
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = The TestFailure behavior is used to test the helm in two
conceivable behavior failure modes. First, it may be used to
simulate a behavior that crashes and thereby results in the crash of
the helm. Second, it may be used to simulate a behavior that
consumes a sufficiently large enough amount of time so as cause the
helm to be considered "hung" by consumers of the helm output.
Recall that the helm is compiled, with behaviors, into a single MOOS
application. Although some behaviors may be compiled into shared
libraries loaded at run time, thereby not requiring a recompile, all
behaviors do run as part of a single helm process. A crashed
behavior results in a crashed helm. Furthermore the helm, on each
iteration, queries each participating behavior for its input. It
does not do this in separate threads, and there is no timeout with a
default reply should a behavior never answer. A hung behavior
results in a hung helm. These are architecture decisions that on one
hand allow a substantial amount of simplicity in the helm
implementation and debugging. Furthermore, it's not clear that a
graceful and safe policy exists to safely handle a rogue behavior
other than to either (a) abort the mission or (b) put the vehicle in
the hands of a much more conservatively configured "standby"
instance of the helm, perhaps just to get the vehicle home. This
behavior is used to simulate both kinds of rogue behaviors, a
behavior that crashes and a behavior the hangs. The crash is
implemented simply with an assert(0) statement, and the hang is
implemented with a long for-loop.
//====================================================================
module = BHV_Timer
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for posting to the MOOSDB based on other events or timing.
depends =
borndate = 050731
doc_url = http://oceanai.mit.edu/ivpman/bhvs/Timer
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = The Timer behavior is a somewhat unique behavior in that it
never produces an objective function. It has virtually no
functionality beyond what is derived from the parent IvPBehavior
class. It can be used to set a timer between the observation of one
or more events (with condition flags) and the posting of one or more
events (with end flags). The duration, duration_status,
duration_idle_decay, condition, runflag and endflag parameters are
all defined generally for behaviors. There are no additional
parameters defined for this behavior.
//====================================================================
module = BHV_Trail
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for maneuvering ownship at a relative bearing and range to a contact.
depends =
borndate = 050603
doc_url = http://oceanai.mit.edu/ivpman/bhvs/Trail
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = This behavior will drive the vehicle to trail or follow
another specified vehicle at a given relative position. A tool for
"formation flying".
//====================================================================
module = BHV_Waypoint
type = Behavior
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A behavior for traversing a given set of waypoints.
depends =
borndate = 041101
doc_url = http://oceanai.mit.edu/ivpman/bhvs/Waypoint
license = GPL
group = MOOS-IvP, Helm Behaviors, Core Autonomy
distro = moos-ivp.org
synopsis = The Waypoint behavior is used for transiting to a set of
specified waypoint in the x-y plane. The primary parameter is the
set of waypoints. Other key parameters are the inner and outer
radius around each waypoint that determine what it means to have met
the conditions for moving on to the next waypoint. The behavior may
also be configured to perform a degree of track-line following, that
is, steering the vehicle not necessarily toward the next waypoint,
but to a point on the line between the previous and next
waypoint. This is to ensure the vehicle stays closer to this line in
the face of external forces such as wind or current. The behavior
may also be set to "repeat" the set of waypoints indefinitely, or a
fixed number of times. The waypoints may be specified either
directly at start-up, or supplied dynamically during operation of
the vehicle. There are also a number of accepted geometry patterns
that may be given in lieu of specific waypoints, such as polygons,
lawnmower pattern and so on.
//====================================================================
module = MOOSDB
type = MOOS App
author = Paul Newman
contact = pnewman@robots.ox.ac.uk
org = Oxford
thumb = The main communication mechanism for all MOOS apps
depends = lib_MOOS
borndate = 000101
doc_url = https://sites.google.com/site/moossoftware/
license = GPL
group = MOOS-IvP, Oxford MOOS
distro = moos-ivp.org, themoos.org
synopsis = MOOS has a star-like communications topology. Each application
within a MOOS community, a MOOSApp, has a connection to a single
“MOOS Databaseâ€, called MOOSDB, that lies at the heart of the software
suite. All communication happens via this central “serverâ€
application, via a publish and subscribe protocol.
//====================================================================
module = iMatlab
type = MOOS App
author = Paul Newman
contact = pnewman@robots.ox.ac.uk
org = Oxford
thumb = A tool for connecting Matlab to a running MOOS community.
depends = lib_MOOS
borndate = 000101
doc_url = http://oceanai.mit.edu/ivpman/apps/iMatlab
license = GPL
group = MOOS-IvP, Oxford MOOS
distro = moos-ivp.org, themoos.org
synopsis = Not everyone wants to program in C++. Many folks are happy
using Matlab as their research tool. Whilst not advising the use of
Matlab to control a real vehicle, it seemed useful to build an
application that allows Matlab to join a MOOS community - if only
for listening in and rendering sensor data. iMatlab allows that to
happen. In essence it "mexes" (compiles into a binary form Matlab
can call directly) up some central MOOS code so it can be called
from inside Matlab. The CMake build system supported by current
releases of MOOS will build the project for the Linux or Windows
version of Matlab.
//====================================================================
module = iRemoteLite
type = MOOS App
author = Paul Newman
contact = pnewman@robots.ox.ac.uk
org = Oxford
thumb = A remote control interface for manual vehicle control.
depends = lib_MOOS
borndate = 000101
doc_url = http://oceanai.mit.edu/ivpman/apps/iRemote
license = GPL
group = MOOS-IvP, Oxford MOOS
distro = moos-ivp.org, themoos.org
synopsis = Not everyone wants to program in C++. Many folks are happy
using Matlab as their research tool. Whilst not advising the use of
Matlab to control a real vehicle, it seemed useful to build an
application that allows Matlab to join a MOOS community - if only
for listening in and rendering sensor data. iMatlab allows that to
happen. In essence it "mexes" (compiles into a binary form Matlab
can call directly) up some central MOOS code so it can be called
from inside Matlab. The CMake build system supported by current
releases of MOOS will build the project for the Linux or Windows
version of Matlab.
//====================================================================
module = iSay
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Invokes system text to voice upon postings to the MOOSDB
depends = lib_mbutil, lib_genutil, lib_apputil, lib_MOOS
borndate = 130520
doc_url = http://oceanai.mit.edu/ivpman/apps/iSay
license = GPL
group = MOOS-IvP, General Utility, Mission Control
distro = moos-ivp.org
synopsis = The iSay application is a way to invoke the native speech
generation utilities of OSX (the say command) and GNU/Linux (the
espeak command). It may also invoke the afplay command available in
both OSX and GNU/Linux to play a given wav or mp3 file.
Each instance of sound generation is done on a cue in MOOS, based on
user configured logic conditions. For example, a user may configure
a sound to be generated when a vehicle goes outside a region, or
comes to the surface. iSay may run in the vehicle MOOS community, or
more typically in a Shoreside MOOS community to indicate a status
change in one of the deployed vehicles.
//====================================================================
module = lib_MOOS
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = Core MOOS comms, MOOS App superclass, and utitlities implementation.
borndate = 000101
doc_url = themoos.org
license = GPL
group = MOOS-IvP, Libraries, Oxford MOOS
distro = themoos.org, moos-ivp.org
synopsis =
//====================================================================
module = lib_apputil
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library for supporting AppCasting MOOS apps
borndate = 120612
doc_url = https://oceanai.mit.edu/ivpman/appcasting
license = GPL
group = MOOS-IvP, Libraries, General Utility
distro = moos-ivp.org
synopsis = AppCasting MOOS apps produce an output on each iteration, separate
from what they publish to the MOOSDB. This output goes both to the terminal,
if there is one open, and also is serialized into a APPCAST message to the
MOOSDB. This message then may be viewed by any AppCast viewing application
such as pMarineViewer, uMAC, and uMACView. This library contains classes
used by all AppCasting MOOS apps, and any of the AppCast viewing utilities.
//====================================================================
module = lib_behaviors-colregs
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library holding the COLREGS collision avoidance behavior
implementation.
borndate = 061118
doc_url = http://oceanai.mit.edu/ivpman/bhvs/AvdColregs
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy, Helm Behaviors
distro = moos-ivp.org
synopsis = The lib_behaviors-colregs library holds a single behavior, the COLREGS
collision avoidance behavior. This behavior is also implemented by several other
classes in this library, and other libraries such as the lib_geometry library.
//====================================================================
module = lib_behaviors-marine
type = Library
author = Michael Benjamin, Henrik Schmidt
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library holding most of the IvP behaviors of MOOS-IvP
borndate = 041101
doc_url = http://oceanai.mit.edu/ivpman/bhvs
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy, Helm Behaviors
distro = moos-ivp.org
synopsis = The lib_behaviors-marine library holds the two dozen+ IvP behaviors
distributed with the IvP Helm in the MOOS-IvP code base. Each of these
behaviors is compiled into the pHelmIvP executable. Third party behaviors
may exist in other libraries and are typically compiled as shared libraries,
loaded by the helm at run time.
//====================================================================
module = lib_behaviors
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library containing superclass code for all IvP behaviors.
depends =
borndate = 031021
doc_url = http://oceanai.mit.edu/ivpman/bhvs
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy, Helm Behaviors
distro = moos-ivp.org
synopsis = The lib_behaviors library contains the superclasses IvPBehavior
and IvPContactBehavior used by all IvP behaviors and all IvP contact
related behaviors (e.g., collision avoidance, COLREGS). This library
also contains the definitions for helm LifeEvents, to capture the events
of behavior spawnings and destruction.
//====================================================================
module = lib_bhvutil
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library holding several utility classes used by behaviors
borndate = 050510
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy, Helm Behaviors
distro = moos-ivp.org
synopsis = The lib_bhvutil library contains utilities essential to
many IvP behavior implementations. This includes the WaypointEngine
and LoiterEngine which do the heavy lifting for the Waypoint and
Loiter behaviors. It also includes many "AOF" classes, which
implement the underlying utility function used by many behaviors to
build their IvP objective functions. (Honestly this library could be
merged with the lib_behaviors-marine library, but remains split to
avoid what would otherwise be a very large library.)
//====================================================================
module = lib_contacts
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library implementing the node report message structure
depends =
borndate = 100227
doc_url = http://oceanai.mit.edu/ivpman/apps/pNodeReporter
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy, Helm Behaviors
distro = moos-ivp.org
synopsis = The NODE_REPORT variable is used by many MOOS applications
to represent the time-stamped status of a vesssel position, heading
and speed, along with other fields of information on vessel type and
state. This library implementes the NodeReport class and methods for
serialization and deserialization.
//====================================================================
module = lib_encounters
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library holding the Encounter class, for vehicle CPA encounters
depends =
borndate = 151215
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldCollisionDetect
license = GPL
group = MOOS-IvP, Libraries
distro = moos-ivp.org
synopsis = A vehicle "encounter" is an event comprised of two vehicles
approaching one another (decreasing range), reaching a closest point of
approach (CPA) followed by indefinite opening (increasing range). This
library implements a data structure holding the information for such
encounters. The library holds only this class, but it is used in a few
applications, so it has its own library.
//====================================================================
module = lib_genutil
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library used by applications having both a MOOS and user interface
borndate = 041104
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, General Utility
distro = moos-ivp.org
synopsis = A library used by applications having both a MOOS and user interface,
by supporting a separate thread for user keyboard interaction.
//====================================================================
module = lib_geometry
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = Core geometry libraries for autonomy behaviors and GUIs. Includes CPAEngine.
depends =
borndate = 040420
doc_url = http://oceanai.mit.edu/ivpman/apps/geometry
license = GPL
group = MOOS-IvP, Libraries, General Utility, Core Autonomy, Helm Behaviors
distro = moos-ivp.org
synopsis = The geometry library implements dozens of core geometry
data structures used in several helm behaviors, GUI applications and
many other apps. It includes the CPAEngine which does the heavy
lifting in many contact-related behaviors such as the COLREGS
collision avoidance behavior. The library also contains
serialization and deserialization functions for most if not all
geometry data structures.
//====================================================================
module = lib_helmivp
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library holding most non-MOOS specific code of the IvP Helm
depends =
borndate = 041027
doc_url = http://oceanai.mit.edu/ivpman/helm
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy
distro = moos-ivp.org
synopsis = The lib_helmivp library contains a substantial portion of
the implementation of the IvP Helm. It does not contain the behavior
implementations (see lib_behaviors, lib_behaviors-marine), and it
contains no code dependent on MOOS libraries. This library contains
the definition of a BehaviorSet, the primary data structure managed
by the helm, holding all behaviors, behavior templates and the helm
information buffer. It contains all the code for reading a behavior
(.bhv) file for initialize the helm for a given mission.
//====================================================================
module = lib_ipfview
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library with classes to support the rendering of IvP Functions
depends =
borndate = 060112
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, Mission Control
distro = moos-ivp.org
synopsis = The lib_ipfview library contains classes used by applications
rendering IvP functions. IvP functions are piecewise linearly defined,
and this library contains data structures for representing such pieces
in a form suitable for rapid rendering. It also contains a IPFViewer
superclass that applications derive from, doing most of the OpenGL
heavy lifting.
//====================================================================
module = lib_ivpbuild
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library with utilities for build IvP Functions
depends =
borndate = 030515
doc_url = http://oceanai.mit.edu/ivpman/ivpbuild
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy, IvPBuild Toolbox
distro = moos-ivp.org
synopsis = The IvPBuild Toolbox is set of classes and utility
functions to aid behavior developers in the generation of IvP
Functions within their behaviors. Ultimately any behavior that
wishes to influence the trajectory of the vehicle must produce an
IvP function as output. All IvP functions are piecewise linearly
defined, and must be in a particular format to be accepted by the
IvP solver. The IvPBuild Toolbox simplifies the generation of these
functions by providing tools that accept a finite set of parameters
and produce syntactically valid instances of an IvP function. One
set of utilities (the ZAIC classes) facilitate the generation of IvP
functions in 1 dimension. Another set of utilities (the Reflector
tools) facilitate the generation of IvP functions in (N>1)
dimensions.
//====================================================================
module = lib_ivpcore
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library with core classes for representing IvP Functions and IvP Domains.
depends =
borndate = 970101
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy
distro = moos-ivp.org
synopsis = The lib_ivpcore library contains all the classes necessary
for representing instances of an IvP Function and an IvP Domain. An
IvP Function is a piecewise linearly defined function defined over
one or more uniformly discrete decision variables. Each decision
variable in the domain also has an lower and upper bound, and the
IvP Domain represents the collective decision space taken as the
Cartesian product of all decision variables. For example, for marine
surface vehicles, the decision space is typically 2D with heading and
speed as the two decision variables. For underwater vehicles it would
be 3D, heading, speed and depth.
//====================================================================
module = lib_ivpsolve
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library for representing and solving IvP Problems.
depends =
borndate = 970101
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, Core Autonomy
distro = moos-ivp.org
synopsis = The lib_ivpsolve library contains the class for
representing IvP problems, including the methods for solving problem
instances. This library also includes more naive versions of the
solution algorithm. They remain to support benchmarking and
validation testing.
//====================================================================
module = lib_logic
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library for implementing simple Boolean logic in applications
depends =
borndate = 100919
doc_url = http://oceanai.mit.edu/ivpman/logic
license = LGPL
group = MOOS-IvP, Libraries, Core Autonomy, ALog Toolbox
distro = moos-ivp.org
synopsis = The lib_logic library implements simple Boolean logic,
typically applied to MOOS variables. For example, an application
like the helm, uTimerScript, or uQueryDB, may condition its actions
on a MOOS variable having a certain value, such as "DEPLOY=true", or
more complex conditions such as "((RETURN != true) or (MISSION_TIME >
600")). This library also contains the implementation of the InfoBuffer
class which is used by the helm to hold a snapshot of a subset of the
MOOSDB, directly accessed by helm behaviors. The InfoBuffer is also used
in the uTimerScript and uQueryDB applications.
//====================================================================
module = lib_logutils
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library of utilities to support many of the apps in the ALog Toolbox
depends =
borndate = 050531
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, ALog Toolbox
distro = moos-ivp.org
synopsis = Many tools in the ALog Toolbox need to do similar things,
such as reading alog files, splitting alog files into cached
subidirectories. This library contains many support classes used
across many of the applications in the ALog Toolbox.
//====================================================================
module = lib_manifest
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A library with key manifest data structures an I/O functions for populat ing manifests.
depends =
borndate = 180109
doc_url = http://oceanai.mit.edu/moos-ivp/manifest-howto
license = GPL
group = MOOS-IvP, General Utility
distro = moos-ivp.org
synopsis = The lib_manifest contains the class definitions for a Manifest,
ManifestSet and the utilities for populating these data structures from
as set of files.
//====================================================================
module = lib_marineview
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library common classes for supporting GUIs with marine
operation views.
depends =
borndate = 041104
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries
distro = moos-ivp.org
synopsis = The lib_marineview library implements GUI and OpenGL superclassses
used in applications involved in rendering marine operation views, e.g.,
pMarineViewer and alogview. This library also contains classes defining
the various vehicle shapes used in these viewers.
//====================================================================
module = lib_mbutil
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library of kitchen-sink utilities used by many applications.
depends =
borndate = 970101
doc_url = Pending
license = GPL
group = Libraries, General Utility
distro = moos-ivp.org
synopsis = The lib_mbutil library contains many basic utility classes
and C++ functions used in virtually all applications. This include
many string manipulation utilities, classes supporting definitions
of supported colors in many apps, utilities for reading from files
into a vector of strings and many more.
//====================================================================
module = lib_obstacles
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library of classes and utilities for representing and generating obstacles
depends =
borndate = 200529
doc_url = Pending
license = GPL
group = Libraries, General Utility
distro = moos-ivp.org
synopsis = The lib_obstacles library contains classes for both representing
obstacles and tools for generating random obstacles constrained by location
and inter-obstacle spacing. Obstacle generation is done in the gen_obstacles
command line utility and in uFldObstacleSim if enabled.
//====================================================================
module = lib_realm
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library of classes and utilities for supporting RealmCasting
depends =
borndate = 970101
doc_url = Pending
license = GPL
group = Libraries, General Utility
distro = moos-ivp.org
synopsis = The lib_realm library contains utility classes to support
realmcasting. Realmcast objects are needed in both pRealm where information
is generated, and in realcasting clients such as pMarineViewer and uMACView.
//====================================================================
module = lib_ucommand
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library for supporting CommandFolios - mission control pre-defined sets of commands.
depends =
borndate = 160701
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, Mission Control
distro = moos-ivp.org
synopsis = The lib_ucommand library contains class definitions for
CommandFolios which are pre-defined sets of mission-control
commands, and corresponding postings to the MOOSDB. It also contains
the superclass GUI for rendering CommandFolio button panels, used
by the pMarineViewer application and the uCommand GUI utility.
//====================================================================
module = lib_ufield
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library for holding a few classes shared across apps in the uField Toolbox
depends =
borndate = 110107
doc_url = Pending
license = GPL
group = MOOS-IvP, Libraries, uField Toolbox
distro = moos-ivp.org
synopsis = The lib_ufield library contains classes shared across apps
in the uField Toolbox, such as the NODE_MESSAGE class used in
uFldNodeBroker and uFldMessageHandler.
//====================================================================
module = lib_zaicview
type = Library
author = Michael Benjamin
contact = mikerb@mit.edu, issues@mit.edu
org = MIT
thumb = A library with common superclasses used by all the zaic utilities
depends =
borndate = 150602
doc_url = http://oceanai.mit.edu/ivpman/zaic
license = GPL
group = MOOS-IvP, Libraries
distro = moos-ivp.org
synopsis = The lib_zaicview library provides common GUI and OpenGL
functionality by way of a few superclasses used by all the zaic
viewer utilities. The zaic utilities are simple viewers used during
the development of the ZAIC utilities in IvPBuild Toolbox. They
are also included in the MOOS-IvP distribution to allow users to
gain familiarity with these tools.
//====================================================================
module = manifest_test
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A command line utility for correctness testing of manifest files.
depends = lib_mbutil, lib_apputil, lib_manifest
borndate = 180109
doc_url = http://oceanai.mit.edu/moos-ivp/manifest-howto
license = GPL
group = MOOS-IvP, General Utility
distro = moos-ivp.org
synopsis = The manifest test utility is a convenience utility for
manifest authors. It will check for syntax and semantic correctness
of manifest files. Ideally this utility is used by all manifest
authors prior to sharing their content. This utility is included in
the MOOS-IvP codebase in releases after 17.7, and in the development
trunk as of this writing.
//====================================================================
module = manifest_wiki
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A command line utility for generating web content from manifest files.
depends = lib_mbutil, lib_apputil, lib_manifest
borndate = 180109
doc_url = http://oceanai.mit.edu/moos-ivp/manifest-howto
license = GPL
group = MOOS-IvP, General Utility
distro = moos-ivp.org
synopsis = The manifest wiki utility is used for auto-generation of
web pages. While this is also part of the MOOS-IvP distribution, it
primarily does its thing on the web server hosting MOOS-IvP to
generate web content as manifest files change. The typical user or
author of manifest content will never need to run this. But the end
goal is to generate valid manifest file content as input to
manifest_wiki to produce rich manifest web content. All of the
manifest web pages on the moos-ivp.org website were produced by
manifest wiki.
//====================================================================
module = pAntler
type = MOOS App
author = Paul Newman
contact = pnewman@robots.ox.ac.uk
org = Oxford
thumb = A utility for launching a batch of MOOS processes
depends = lib_MOOS
borndate = 000101
doc_url = http://oceanai.mit.edu/ivpman/apps/pAntler
license = GPL
group = MOOS-IvP, Oxford MOOS
distro = moos-ivp.org, themoos.org
synopsis = The pAntler tool is used to launch multiple MOOS
processes. This is a useful tool for starting up a set of MOOS
processes, all of which share a single configuration file but which
can be distributed over multiple machines and operating systems.
//====================================================================
module = pBasicContactMgr
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Manages known contacts and generates alerts consumed by the helm
depends = lib_mbutil, lib_apputil, lib_geometry, lib_contacts, lib_MOOS
borndate = 100224
doc_url = http://oceanai.mit.edu/ivpman/apps/pBasicContactMgr
license = GPL
group = MOOS-IvP, Core Autonomy
distro = moos-ivp.org
mod_date = 170926, added alert region support
synopsis = The pBasicContactMgr application deals with information
about other known vehicles in its vicinity. It is not a sensor
application, but rather handles incoming "contact reports" which may
represent information received by the vehicle over a communications
link, or may be the result of on-board sensor processing. By default
the pBasicContactMgr posts to the MOOSDB summary reports about
known contacts,
The contact manager may also may be configured to post alerts, i.e.,
MOOS variables, with select content about one or more of the
contacts. An alert is typically used by the helm to spawn
a behavior for a new contact, for collision avoidance for example.
//====================================================================
module = pContactMgrV20
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Manages known contacts and generates alerts consumed by the helm
depends = lib_mbutil, lib_bhvutil, lib_apputil, lib_geometry, lib_contacts, lib_MOOS
borndate = 200708
doc_url = http://oceanai.mit.edu/ivpman/apps/pContactMgrV20
license = GPL
group = MOOS-IvP, Core Autonomy
distro = moos-ivp.org
synopsis = The pContactMgrV20 application is newer version to replace
pBasicContactMgr. It is designed to be backward compatible with
pBasicContactMgr but for ease in adoption, the user continues to
have the option of using the earlier version. Like pBasicContactMgr,
it deals with information about other known vehicles in its
vicinity. It is not a sensor application, but rather handles
incoming "contact reports" which may represent information received
by the vehicle over a communications link, or may be the result of
on-board sensor processing.
The contact manager may also may be configured to post alerts, i.e.,
MOOS variables, with select content about one or more of the
contacts. An alert is typically used by the helm to spawn
a behavior for a new contact, for collision avoidance for example.
This new contact manager has better suport for memory management,
guarding against unbounded growth of contacts, using a policy for
dropping contacts based on contact age, range, and total number
of contacts. It also has imroved support for exclusion filters, allowing
the user to control which types of contacts are ignored. This can be
configured in both the contact manager and within behaviors using
the contact manager. The exclusion filter can also be based on the
operation region. The new contact manager also supports some swarm
autonomy algorithms by posting configurable information about the
set of teammates in range, and/or the closest teammate.
//====================================================================
module = pDeadManPost
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Enable configured postings to be staged in the absence of other events
depends = lib_mbutil, lib_apputil, lib_MOOS
borndate = 100224
doc_url = http://oceanai.mit.edu/ivpman/apps/pDeadManPost
license = GPL
group = MOOS-IvP, Core Autonomy
distro = moos-ivp.org
mod_date = 170926, added alert region support
synopsis = The pDeadManPost application allows the user to arrange
configured posts to the MOOSDB in the absence of another event. The
following are a few of the motivating scenarios:
(1) On a shoreside community, a dead-man post can be made to trigger
an alert when a deployed vehicle is out of contact after some period
of time. The alert could be a posting to trigger an alarm .wav file
or a spoken alert message through iSay.
(2) On a surface vehicle, a dead-man post can be made to put the
vehicle in a station-keeping mode if comms to the shoreside command
and control goes silent for some period of time.
(3) On an underwater vehicle, a dead-man post can be made to put the
vehicle in a return-to-home mode if it loses updates from navigation
beacons for some period of time.
//====================================================================
module = pEchoVar
type = MOOS App
author = Michael Benjamin
org = MIT
contact = mikerb@mit.edu
thumb = Re-post configured MOOS variables under a different name(s)
depends = lib_mbutil, lib_apputil, lib_logic, lib_geometry, lib_MOOS
borndate = 060722
doc_url = http://oceanai.mit.edu/ivpman/apps/pEchoVar
license = GPL
group = MOOS-IvP, General Utility
distro = moos-ivp.org
synopsis = The pEchoVar application is a lightweight process that runs
without any user interaction for "echoing" the posting of specified
variable-value pairs with a follow-on posting having different
variable name. For example the posting of FOO=5.5 could be echoed
such that BAR=5.5 immediately follows the first posting. The
motivation for this tool was to convert, for example, a posting such
as GPS_X to become NAV_X. The former is the output of a particular
device, and the latter is a de facto standard for representing the
vehicle's longitudinal position in local coordinates.
//====================================================================
module = pHelmIvP
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A behavior-based helm with multi-objective optimization based
(IvP) action selection.
depends = lib_helmivp, lib_contacts, lib_behaviors-marine,
lib_behaviors-colregs, lib_behaviors, lib_bhvutil, lib_ivpbuild,
lib_ivpcore, lib_ivpsolve, lib_geometry, lib_apputil, lib_mbutil,
lib_logic, lib_genutil, lib_MOOS
group = MOOS-IvP, Core Autonomy
borndate = 020101
doc_url = http://oceanai.mit.edu/ivpman/apps/pHelmIvP
license = GPL
distro = moos-ivp.org
synopsis = pHelmIvP is a behavior-based autonomous decision-making
MOOS application. It consists of a set of behaviors reasoning over a
common decision space such as the vehicle heading and speed.
Behaviors are reconciled using multi-objective optimization with the
Interval Programming (IvP) model.
//====================================================================
module = pHostInfo
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Auto-detect the machine's IP address and MOOSDB port number
depends = lib_mbutil, lib_ufield, lib_apputil, lib_MOOS
borndate = 111214
doc_url = http://oceanai.mit.edu/ivpman/apps/pHostInfo
license = GPL
group = MOOS-IvP, General Utility
distro = moos-ivp.org
synopsis = Automatically detect the vehicle's host information
including the IP addresses, port being used by the MOOSDB, the port
being used by local pShare for UDP listening, and the community name
for the local MOOSDB. Post these to facilitate automatic
group = General Utility, uField Toolbox
intervehicle communications in especially in multi-vehicle
scenarios where the local IP address changes w/ DHCP.
//====================================================================
module = pLogger
type = MOOS App
author = Paul Newman
contact = pnewman@robots.ox.ac.uk
org = Oxford
thumb = A utility for logging the variables histories from the MOOSDB
depends = libMOOS
borndate = 000101
doc_url = http://oceanai.mit.edu/ivpman/apps/pLogger
license = GPL
group = MOOS-IvP, Oxford MOOS
distro = moos-ivp.org, themoos.org
synopsis = The pLogger process is intended to record the activities of
a MOOS session. It can be configured to record a fraction of or
every publication of any number of MOOS variables. It is an
essential MOOS tool and is worth its weight in gold in terms of
post-mission analysis, data gathering and post-mission replay. There
are many tools for manipulating and rendering pLogger generated log
files: aloggrep, alogrm, alogview, alogscan, alogclip, and
uPlayBack.
//====================================================================
module = pMarinePID
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Simple PID controller for heading, speed and depth
depends = lib_mbutil, lib_geometry, lib_MOOS
borndate = 060410
doc_url = Pending
license = GPL
group = MOOS-IvP, Core Autonomy, Simulation
distro = moos-ivp.org
synopsis = The pMarinePID MOOS app is a basic PID controller interface
to control heading speed and depth based on incoming desired
heading, speed and depth objectives and output on rudder, thrust and
elevator fed through three PID controllers.
//====================================================================
module = pMarineViewer
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Mission control GUI for monitoring, deploying and commanding vehicles
depends = lib_mbutil, lib_apputil, lib_geometry, lib_contacts, lib_ucommand,
lib_marineview, lib_genutil, lib_MOOS
borndate = 041101
doc_url = http://oceanai.mit.edu/ivpman/apps/pMarineViewer
license = GPL
group = MOOS-IvP, Mission Control, Simulation
distro = moos-ivp.org
synopsis = pMarineViewer is a GUI based MOOS App for rendering events
in an area of vehicle operation. It repeatedly updates vehicle
positions from incoming node reports, and will render several
geometric types published from other MOOS apps. The viewer may also
post messages to the MOOSDB based on user-configured keyboard or
mouse events.
//====================================================================
module = pNodeReporter
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Gather vehicle navigation info into single published node report
depends = lib_mbutil, lib_apputil, lib_geometry, lib_contacts, lib_MOOS
borndate = 060213
doc_url = http://oceanai.mit.edu/ivpman/apps/pNodeReporter
license = GPL
group = MOOS-IvP, Core Autonomy
distro = moos-ivp.org
synopsis = A tool for collecting node information such as present
vehicle position, trajectory and type, and posting it in a single
report for sharing between vehicles or sending to a shoreside
display.
//====================================================================
module = pObstacleMgr
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Manages known contacts and generates alerts consumed by the helm
depends = lib_mbutil, lib_apputil, lib_geometry, lib_MOOS
borndate = 170917
doc_url = http://oceanai.mit.edu/ivpman/apps/pObstacleMgr
license = GPL
group = MOOS-IvP, Core Autonomy
distro = moos-ivp.org
synopsis = The pObstacleMgr manages incoming sensor dataabout
obstacles and posts alerts suitable for spawning obstacle avoidance
behaviors.
//====================================================================
module = pRealm
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Shadow the local MOOSDB and support RealmCasting requests
depends = lib_realm, lib_mbutil, lib_apputil, lib_geometry, lib_MOOS
borndate = 201202
doc_url = http://oceanai.mit.edu/ivpman/apps/pRealm
license = GPL
group = MOOS-IvP, General Utility, Mission Control
distro = moos-ivp.org
synopsis = The pRealm application is used for shadowing the local MOOSDB
and generating on-demand RealmCast reports. These reports are
requested and consumed by pMarineViewer or similar app
configured to interact with pRealm. Typically pRealm is run
on both the shoreside and vehicle communities.
//====================================================================
module = pShare
type = MOOS App
author = Paul Newman
contact = pnewman@robots.ox.ac.uk
org = Oxford
thumb = A tool for bridging between MOOS communities.
depends = libMOOS
borndate = 000101
doc_url = http://oceanai.mit.edu/ivpman/apps/pShare
license = GPL
group = MOOS-IvP, Oxford MOOS
distro = moos-ivp.org, themoos.org
synopsis = pShare is a newer version of pMOOSBridge that supports
dynamic registrations and a few other important features used by
components of the uField Toolbox. Like pMOOSBridge, pShare is a
powerful tool in building MOOS-derived systems. It allows messages
to pass between communities and is able to rename the messages as
they are shuffled between communities.
//====================================================================
module = pickpos
type = Command line utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A cmdline utility choosing simulation starting values
depends = lib_mbutil, lib_geometry
borndate = 180922
doc_url = http://oceanai.mit.edu/ivpman/apps/pickpos
license = GPL
group = MOOS-IvP, General Utility, Simulation
distro = moos-ivp.org
synopsis = pick_pos is a utility for generating starting points for
simulated vehicles. It can generate points from a set of pts
given in a file, or by picking random points from within one
or more convex polygons. The starting heading position can
also be chosen, in a random range, or relative to a given
position. Vehicle names and group names may also be chosen randomly.
//====================================================================
module = uFldBeaconRangeSensor
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Simulates range information derived from pinging a buoy
depends = lib_mbutil, lib_apputil, lib_geometry, lib_contacts, lib_MOOS
borndate = 110202
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldBeaconRangeSensor
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = Typically run in a shoreside community. Configured with one
or more beacons with known beacon locations. Takes range requests
from a remote vehicle and returns a range report indicating that
vehicle's range to nearby beacons. Range requests may or may not be
answered depending on range to beacon. Reports may have noise added
and may or may not include beacon ID.
//====================================================================
module = uFldCollisionDetect
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Monitors ship traffic collisions and reports near collisions
depends = lib_mbutil, lib_apputil, lib_geometry, lib_ufield, lib_logic,
lib_encounters, lib_contacts, lib_MOOS
borndate = 151221
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldCollisionDetect
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox, COLREGS Toolbox
distro = moos-ivp.org
synopsis = The uCollisionDetect application is run by the shoreside
and detects if two vehicles have had an ecounter. An encounter is
defined as being within the distance specified by the
encounter_range parameter.
An encounter constituting a near miss or collision will also produce
a posting to UCD_REPORT indicating the two vehicle names, the CPA
distance, and rank (near miss or collision).
Flags may be configured to be posted upon each event type -
collision, near-miss or encounter. These flags are simply MOOS
variable and value pairs like the flags in many other MOOS
applications and helm behaviors. For example, such a flag may be
used to trigger an evaluation of the mission efficiency for a window
of time around the encounter.
//====================================================================
module = uFldCollObDetect
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Monitors ship traffic obstacle collisions and reports near collisions
depends = lib_mbutil, lib_apputil, lib_geometry, lib_contacts, lib_MOOS
borndate = 190902
doc_url = http://oceanai.mit.edu/ivpman/apps/to-be-written
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = The uFldCollObDetect app runs on the shoreside and monitors
vehicle positions in the context of known obstacle locations. It
watches for encounters, near misses and collisions. It will publish
user-specified flags on the events of collision, near- miss, and
encounters. If the user does not specify flags, then no reports are
generated. Each flag type supports a number of macros to allow the
user to generate data of their liking.
//====================================================================
module = uFldContactRangeSensor
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Simulates range measurements to other moving contacts
depends = lib_mbutil, lib_apputil, lib_geometry, lib_contacts, lib_MOOS
borndate = 110202
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldContactRangeSensor
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = Typically run in a shoreside community. Takes reports from
remote vehicles, notes their position. Takes a range request from a
remote vehicle and returns a range report indicating that vehicle's
range to nearby vehicles. Range requests may or may not be answered
dependent on inter-vehicle range. Reports may also have noise added
to their range values.
//====================================================================
module = uFldMessageHandler
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Handles and unwraps incoming messages from other vehicles.
depends = lib_mbutil, lib_apputil, lib_ufield, lib_MOOS
borndate = 120130
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldMessageHandler
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = The uFldMessageHandler tool is used for handling incoming
messages from other nodes. An instance of this app is typically
running on each vehicle. The message is a string that contains the
source and destination of the message as well as the MOOS variable
and value. This app simply posts to the local MOOSDB the
variable-value pair contents of the message.
//====================================================================
module = uFldShoreBroker
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Facilitates shoreside share connections to vehicle communities
depends = lib_mbutil, lib_apputil, lib_ufield, lib_MOOS
borndate = 111219
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldShoreBroker
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = Typically run in a shoreside community. Takes reports from
remote vehicles describing how they may be reached. Posts
registration requests to shoreside pShare to share user-provided
list of variables out to vehicles. Upon learning of vehicle JAKE
will create bridges FOO_ALL and FOO_JAKE to JAKE, for all such
user-configured variables.
//====================================================================
module = uFldNodeComms
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Shoreside MOOS App for conditionally sending messages between vehicles.
depends = lib_mbutil, lib_apputil, lib_ufield, lib_contacts, lib_geometry, lib_MOOS
borndate = 111204
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldNodeComms
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = The uFldNodeComms application is a tool for handling node
reports and messages between vehicles. Rather than directly sending
node reports and messages between vehicles, uFldNodeComms acts as an
intermediary to conditionally pass a report or message on to another
vehicle, where conditions may be the inter-vehicle range or other
criteria. The assumption is that uFldNodeComms is running on a
topside or shoreside computer, and receiving information about the
present physical location of deployed vehicles through node reports.
In short, uFldNodeComms subscribes for incoming node reports for any
number of vehicles, and keeps the latest node report for each
vehicle. On each iteration, for a each vehicle, if the node report
has been updated, the report is published to a specially created
MOOS variable for the other n-1 vehicles. A user-configured criteria
is applied before publishing the new information. Typically this
criteria involves the range between vehicles, but the criteria may
be further involved. Often uFldNodeComms is run purely in
simulation, but is is often used in 2.680 with surface vehicles on
the water, to simulate the bandwidth and range communication challenges
found underwater and in mission with greater disances between vehicles.
//====================================================================
module = uFldObstacleSim
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Simulation of obstacle (re)generation and lidar sensing of obstacles
depends = lib_obstacles, lib_geometry, lib_contacts, lib_mbutil, lib_apputil, lib_MOOS
borndate = 200531
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldObstacleSim
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = The uFldObstacleSim app will simulate the posting of
obstacles loaded from a text file, to be shared to all vehicles in
the uField environment. The obstacle simulator may also be
configured to periodically randomly re-generate the obstacle
locations and sizes. The random generation considers an region of
containment, minimum inter-obstacle range, min and max size of
obstacles. It may also be configured to only regenerated obstacles
with no vehicles are within the obstacle region.
The simulation generates information in one of two modes, (1)
Obstacle polygons are simply published and shared to all vehicles,
or (2) simulated sensor data, similar to Lidar points on the
obstacle, are published and shared to the vehicles. Downstream apps
are then left with the job of inferring the obstacle from the sensor
data.
//====================================================================
module = uFldScope
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Shoreside MOOS App for monitoring user-chosen fields across vehicles.
depends = lib_mbutil, lib_apputil, lib_MOOS
borndate = 111204
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldNodeScope
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = The uFldScope application is a tool for collecting diverse
sets of information regarding a field of vehicles remotely
deployed. Suppose, for example, one is interested in monitoring, for
each deployed vehicle, the (a) helm mode, (b) total distance
travelled, (c) battery level, and (d) the number of times it has
visited a certain beacon. Each piece of information may be embedded
in one of a number of MOOS variables, perhaps along with a lot of
other information of no concern.
While there are several methods to scope on the above variable and
pick out the helm mode, the goal of the uFldScope tool is to have
this information readily visible for each vehicle perhaps alongside
other key fields for all vehicles, in a continuously updated simple
table.
The assumption is that uFldScope is running on a topside computer,
interacting with a user, and receiving information on deployed
vehicles primarily through node reports or other summary report
variables.
//====================================================================
module = uFldNodeBroker
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = Facilitates vehicle share connections to shoreside community
depends = lib_mbutil, lib_apputil, lib_ufield, lib_MOOS
borndate = 111219
doc_url = http://oceanai.mit.edu/ivpman/apps/uFldNodeBroker
license = GPL
group = MOOS-IvP, Simulation, uField ToolBox
distro = moos-ivp.org
synopsis = The uFldNodeBroker app is typically run on a
vehicle or simulated vehicle in a multi-vehicle context.
Used for making a connection to a shoreside
community by sending local information about the vehicle such
as the IP address, community name, and port number being used
by pShare for incoming UDP messages. Presumably the shoreside
community uses this to know where to send outgoing UDP
messages to the vehicle.
//====================================================================
module = uFunctionVis
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A GUI based MOOS App for monitoring IvP Helm objective functions
depends = lib_mbutil, lib_genutil, lib_apputil, lib_ivpbuild, lib_geometry,
lib_ivpcore, lib_ipfview, lib_MOOS, lib_fltk, lib_fltk_gl
borndate = 060512
doc_url = Pending
license = GPL
group = MOOS-IvP, Mission Control
distro = moos-ivp.org
synopsis = uFunctionVis is a GUI application for rendering IvP
functions. It automatically registers for IvP functions posted by
the helm and renders them in 3D typically for heading/speed
functions but also for depth objective functions.
//====================================================================
module = uHelmScope
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A terminal based MOOS App for monitoring the state of IvP Helm
depends = lib_mbutil, lib_genutil, lib_apputil, lib_helmivp, lib_behaviors,
lib_ivpbuild, lib_MOOS
borndate = 080412
doc_url = http://oceanai.mit.edu/ivpman/apps/uHelmScope
license = GPL
group = MOOS-IvP, Mission Control
distro = moos-ivp.org
synopsis = The uHelmScope application is a terminal-based (non-GUI)
MOOS app, for scoping a running IvP Helm process, and key MOOS
variables. uHelmScope provides behavior summaries, activity states,
and recent behavior postings to the MOOSDB.
//====================================================================
module = uLoadWatch
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A utility for monitoring the load of MOOS Apps
depends = lib_mbutil, lib_apputil, lib_MOOS
borndate = 131224
doc_url = http://oceanai.mit.edu/ivpman/apps/uLoadWatch
license = GPL
group = MOOS-IvP, General Utility, Mission Control
distro = moos-ivp.org
synopsis = The uLoadWatch application is used for monitoring load of
apps in the MOOS community. It works by checking for *_ITER_GAP and
*_ITER_LEN information posted by each app. An app, pFooBar, posts
PFOOBAR_ITER_GAP as the ratio of observed application interval over
requested application interval. For an app running at 4Hz, a
reported ITER_GAP of 3 means a gap 0.75 seconds was observed between
two successive iterations.
//====================================================================
module = uMAC
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A terminal based MOOS app for monitoring appcasts
depends = lib_mbutil, lib_genutil, lib_geometry, lib_apputil, lib_MOOS,
lib_fltk
borndate = 120412
doc_url = http://oceanai.mit.edu/ivpman/apps/uMAC
license = GPL
group = MOOS-IvP, Mission Control
distro = moos-ivp.org
synopsis = The uMAC application is a utility, run in a terminal
window, for Monitoring AppCasts. It is launched and run in a
terminal window and will parse appcasts generated within its own
MOOS community or those from other MOOS communities bridged or
shared to the local MOOSDB. The primary advantage of uMAC vs. other
appcast monitoring tools is that one may remotely log into a vehicle
via ssh and launch uMAC locally in a terminal.
//====================================================================
module = uMACView
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A GUI based MOOS app for visually monitoring appcasts
depends = lib_mbutil, lib_genutil, lib_geometry, lib_apputil, lib_MOOS,
lib_fltk
borndate = 120518
doc_url = http://oceanai.mit.edu/ivpman/apps/uMACView
license = GPL
group = MOOS-IvP, Mission Control
distro = moos-ivp.org
synopsis = uMACView is a GUI tool for visually monitoring appcasts. It
will parse appcasts generated within its own MOOS community or those
from other MOOS communities bridged or shared to the local
MOOSDB. Its capability is nearly identical to the appcast viewing
capability built into pMarineViewer. It was intended to be an
appcast viewer for non pMarineViewer users.
//====================================================================
module = uMS
type = MOOS App
author = Paul Newman
contact = pnewman@robots.ox.ac.uk
org = Oxford
thumb = A graphical scope for monitoring the contents of a running MOOSDB
depends = libMOOS
borndate = 000101
doc_url = http://oceanai.mit.edu/ivpman/apps/uMS
license = GPL
group = MOOS-IvP, Oxford MOOS
distro = moos-ivp.org, themoos.org
synopsis = The uMS application allows a user to place a stethoscope on
the MOOS network and watch what variables are being written, which
processes are writing them, and how often this is happening. After
starting up the scope and specifying the host name and port number
of the MOOSDB the user is presented with a list of all MOOS
variables in the server and their current state. Several times a
second uMS calls into the DB and uses a special/unusual (and
intentionally undocumented) message that requests that the server
inform the client about all variables currently stored along with
their update statistics. uMS is a central tool in the MOOS suite. It
is cross-platform and should be used to spy on and present visual
feedback on any MOOS community.
//====================================================================
module = uMemWatch
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A MOOS app for monitoring the memory usage of other apps
depends = lib_mbutil, lib_apputil, lib_MOOS
borndate = 190504
doc_url = http://oceanai.mit.edu/ivpman/apps/uMemWatch
license = GPL
group = MOOS-IvP, Mission Control
distro = moos-ivp.org
synopsis = The uMemWatch application is used for measuring the current
memory used by a set of MOOS apps. To measure an app, the app must
publish the MYAPP_PID variable with its own PID. This app will use
that PID and the command line utility "ps" to measure the current
memory usage. This app can be configured to selectively watch items
on a watch list, or watch all apps but selectively ignore apps on an
ignore list. The primary output is through both AppCasting, and the
publication to MYAPP_MEM each time a new measurement is made.
//====================================================================
module = uPlotViewer
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A GUI based MOOS app for plotting a frequency bar graph
depends = lib_mbutil, lib_genutil, lib_MOOS, lib_fltk, lib_fltk_gl
borndate = 120518
doc_url = Pending
license = GPL
group = MOOS-IvP, Mission Monitoring
distro = moos-ivp.org
synopsis = uPlotViewer is a GUI tool for rendering a frequency bar graph
for a configurable set of variables.
//====================================================================
module = uPokeDB
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A command line app for poking the MOOSDB
depends = lib_mbutil, lib_MOOS
borndate = 080509
doc_url = http://oceanai.mit.edu/ivpman/apps/uPokeDB
license = GPL
group = MOOS-IvP, General Utility, Simulation
distro = moos-ivp.org
synopsis = The uPokeDB application is a command-line tool for poking a
MOOSDB with variable-value pairs provided on the command line. It
finds the MOOSDB via mission file provided on the command line, or
the IP address and port number given on the command line. It will
connect to the DB, show the value prior to poking, poke the DB, and
wait an iteration for mail from the DB to confirm the result of the
poke.
//====================================================================
module = uProcessWatch
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A MOOS app for monitoring the presence of other MOOS apps
depends = lib_mbutil, lib_apputil, lib_MOOS
borndate = 070527
doc_url = http://oceanai.mit.edu/ivpman/apps/uProcessWatch
license = GPL
group = MOOS-IvP, Mission Control
distro = moos-ivp.org
synopsis = The uProcessWatch application monitors the presence of MOOS
apps on a watch-list. If one or more are noted to be absent, it will
be so noted on the MOOS variable PROC_WATCH_SUMMARY. uProcessWatch
is appcast enabled and will produce a succinct table summary of
watched processes and the CPU load reported by the processes
themselves. The items on the watch list may be named explicitly in
the config file or inferred from the Antler block or from list of
DB_CLIENTS. An application may be excluded from the watch list if
desired.
//====================================================================
module = uQueryDB
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A command line app, connect to MOOSDB, check condition, then exit
depends = lib_mbutil, lib_logic, lib_MOOS
borndate = 151229
doc_url = http://oceanai.mit.edu/ivpman/apps/uQueryDB
license = GPL
group = MOOS-IvP, Simulation, Mission Control, Mission Monitoring
distro = moos-ivp.org
synopsis = uQueryDB is a command line tool for querying a MOOSDB with
a logic condition provided on the command line. It finds the MOOSDB
via mission file provided on the command line, or the IP address and
port number given on the command line. It will connect to the DB,
register for the variables involved in the logic condition and
determine if the condition holds. It will then exit with 0 if it
holds or 1 otherwise.
It will return its value as soon as the app has received mail for
all variables involved in the logic condition. Otherwise it will
wait for 10 seconds. This can be changed with the --wait=N
parameter. If a variable in the logic condition is unknown to the
MOOSDB, then the whole condition will fail after the wait period.
//====================================================================
module = uSimMarine
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A simple marine vehicle simulator
depends = lib_mbutil, lib_apputil, lib_geometry, lib_contacts, lib_MOOS
borndate = 041025
doc_url = http://oceanai.mit.edu/ivpman/apps/uSimMarine
license = GPL
group = MOOS-IvP, Simulation
distro = moos-ivp.org
synopsis = The uSimMarine application is a simple 3D vehicle simulator
that updates vehicle state, position and trajectory, based on the
present actuator values and prior vehicle state. The typical usage
scenario has a single instance of uSimMarine associated with
each simulated vehicle.
//====================================================================
module = uTermCommand
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A terminal MOOS app for poking the MOOSDB with pre-configured pokes
depends = lib_mbutil, lib_genutil, lib_MOOS
borndate = 070626
doc_url = http://oceanai.mit.edu/ivpman/apps/uTermCommand
license = GPL
group = MOOS-IvP, Mission Control
distro = moos-ivp.org
synopsis = The uTermCommand application is a terminal based tool for
poking the MOOS database with pre-defined variable-value pairs. A
unique key may be associated with each poke. The user initiates a poke
to the MOOSDB by typing in the key.
//====================================================================
module = uTimerScript
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = An app for generating scripted pokes to the MOOSDB
depends = lib_mbutil, lib_apputil, lib_geometry, lib_logic, lib_MOOS
borndate = 090521
doc_url = http://oceanai.mit.edu/ivpman/apps/uTimerScript
license = GPL
group = MOOS-IvP, Simulation, Core Autonomy
distro = moos-ivp.org
synopsis = The uTimerScript application allows the user to script a
set of pre-configured posts to a MOOSDB. In its most basic form, it
may be used to initialize a set of variables to the MOOSDB, and
immediately terminate itself if a quit event is included.
Additionally, uTimerScript may be used with the following advanced
functions:
(1) Each entry in the script may be scheduled to occur after a
specified amount of elapsed time.
(2) Event timestamps may be given as an exact point in time relative
to the start of the script, or a range in times with the exact time
determined randomly at run-time.
(3) The execution of the script may be paused, or fast-forwarded a
given amount of time, or forwarded to the next event on the script
by writing to a MOOS variable.
(4) The script may be conditionally paused based on user defined logic
conditions over one or more MOOS variables.
(5) The variable value of an event may also contain information
generated randomly.
(6) The script may be reset or repeated any given number of times.
(7) The script may use its own time warp, which can be made to vary
randomly between script executions.
In short, uTimerScript may be used to effectively simulate the
output of other MOOS applications when those applications are not
available.
//====================================================================
module = uXMS
type = MOOS App
author = Michael Benjamin
contact = mikerb@mit.edu, issues@moos-ivp.org
org = MIT
thumb = A command line app for scoping the MOOSDB
depends = lib_mbutil, lib_genutil, lib_apputil, lib_MOOS
borndate = 070527
doc_url = http://oceanai.mit.edu/ivpman/apps/uXMS
license = GPL
group = MOOS-IvP, General Utility, Mission Control
distro = moos-ivp.org
synopsis = uXMS is a terminal-based (non GUI) tool for scoping a
MOOSDB. Users may precisely configure the set of variables they wish
to scope on by naming them explicitly on the command line or in the
MOOS configuration block. The variable set may also be configured by
naming one or more MOOS proceses on which all variables published by
those processes will be scoped. Users may also scope on the history
of a single variable.
//====================================================================
module = zaic_hdg
type = GUI utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A GUI utility for exploring the ZAIC_HDG IvPBuild tool
depends = lib_mbutil, lib_ivpbuild, lib_zaicview
borndate = 150602
doc_url = http://oceanai.mit.edu/ivpman/zaic
license = GPL
group = MOOS-IvP, General Utility, IvPBuild Toolbox
distro = moos-ivp.org
synopsis = The zaic_hdg utility launches a simple GUI rendering a
utility function, piecewise defined, over one discrete variable. The
pieces are formed by a few parameters provided to an instance of the
ZAIC_HDG utility in the IvPBuild Toolbox. The GUI user has the
ability to change the ZAIC_HDG parameters via the keyboard and watch
the effects of these changes as the rendering of the utility
function is updated.
//====================================================================
module = zaic_hleq
type = GUI utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A GUI utility for exploring the ZAIC_LEQ and ZAIC_HEQ IvPBuild tools
depends = lib_mbutil, lib_ivpbuild, lib_zaicview
borndate = 050620
doc_url = http://oceanai.mit.edu/ivpman/zaic
license = GPL
group = MOOS-IvP, General Utility, IvPBuild Toolbox
distro = moos-ivp.org
synopsis = The zaic_hleq utility launches a simple GUI rendering a
utility function, piecewise defined, over one discrete variable. The
pieces are formed by a few parameters provided to an instance of
either the ZAIC_LEQ or ZAIC_HEQ utility in the IvPBuild Toolbox. The
GUI user has the ability to change the ZAIC parameters via the
keyboard and watch the effects of these changes as the rendering of
the utility function is updated.
//====================================================================
module = zaic_peak
type = GUI utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A GUI utility for exploring the ZAIC_PEAK IvPBuild tool
depends = lib_mbutil, lib_ivpbuild, lib_zaicview
borndate = 050620
doc_url = http://oceanai.mit.edu/ivpman/zaic
license = GPL
group = MOOS-IvP, General Utility, IvPBuild Toolbox
distro = moos-ivp.org
synopsis = The zaic_peak utility launches a simple GUI rendering a
utility function, piecewise defined, over one discrete variable. The
pieces are formed by a few parameters provided to an instance of the
ZAIC_PEAK utility in the IvPBuild Toolbox. The GUI user has the
ability to change the ZAIC_PEAK parameters via the keyboard and watch
the effects of these changes as the rendering of the utility
function is updated.
//====================================================================
module = zaic_spd
type = GUI utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A GUI utility for exploring and rendering the ZAIC_SPD build tool
depends = lib_mbutil, lib_ivpbuild, lib_zaicview
borndate = 150602
doc_url = http://oceanai.mit.edu/ivpman/zaic
license = GPL
group = MOOS-IvP, General Utility, IvPBuild Toolbox
distro = moos-ivp.org
synopsis = The zaic_spd utility launches a simple GUI rendering a
utility function, piecewise defined, over one discrete variable. The
pieces are formed by a few parameters provided to an instance of the
ZAIC_SPD utility in the IvPBuild Toolbox. The GUI user has the
ability to change the ZAIC_SPD parameters via the keyboard and watch
the effects of these changes as the rendering of the utility
function is updated.
//====================================================================
module = zaic_vect
type = GUI utility
author = Michael Benjamin
contact = mikerb@mit.edu
org = MIT
thumb = A GUI utility for exploring the ZAIC_VECT IvPBuild tool
depends = lib_mbutil, lib_ivpbuild, lib_zaicview
borndate = 100505
doc_url = http://oceanai.mit.edu/ivpman/zaic
license = GPL
group = MOOS-IvP, General Utility, IvPBuild Toolbox
distro = moos-ivp.org
synopsis = The zaic_vect utility launches a simple GUI rendering a
utility function, piecewise defined, over one discrete variable. The
pieces are formed by a few parameters provided to an instance of the
ZAIC_VECT utility in the IvPBuild Toolbox. The GUI user has the
ability to change the ZAIC_VECT parameters via the keyboard and watch
the effects of these changes as the rendering of the utility
function is updated.