LITE-NYLE|date> 250222
LITE-NYLE|who> pav
LITE-NYLE|type> augmentation
LITE-NYLE|branch> main
LITE-NYLE|module> pFooBar
LITE-NYLE|short> Added Foo
#---------------------------------
WISE-COLT|date> 250222
WISE-COLT|who> pav
WISE-COLT|type> bugfix
WISE-COLT|branch> main
WISE-COLT|module> BHV_AvoidObstacleV24
WISE-COLT|short> Handle when helm not configured w/ platform model
The AvoidObstacleV24 behavior is the first behavior to use the new platform
model feature of the helm. However the behavior was not properly handling the
case where the helm was not configured with a Dubins model. This has been
corrected, to default the helm to a holonomic model, and post a warning that
a Dubins model is prefered for this behavior. The warning can be silenced by
settting holonomic_ok = true when configuring the behavior.
#---------------------------------
THIN-SPAT|date> 250218
THIN-SPAT|who> smr
THIN-SPAT|type> augmentation
THIN-SPAT|branch> main
THIN-SPAT|module> pMarineViewer
THIN-SPAT|short> Added SMR vessel type in viewer applications
Added a new vessel type for the SMR USV, selectable with the vessel type "smr"
in pNodeReporter. The type will render in pMarineViewer and alogview.
#---------------------------------
MILD-OMNI|date> 250216
MILD-OMNI|who> smr
MILD-OMNI|type> augmentation
MILD-OMNI|branch> main
MILD-OMNI|module> pNodeReporter
MILD-OMNI|short> Added static node report riders
A node report generatxed by pNodeReporter has certain fields present by
default, such as lat/lon, heading, speed. The app can now be
configured to include custom additions by param=value pairs in the
with the platform_aspect config parameter. These pairs are tagged onto
every node report and are not tied to any incoming MOOS variable (as
with dynamic riders).
#---------------------------------
DULL-VIEW|date> 250215
DULL-VIEW|who> smr
DULL-VIEW|type> augmentation
DULL-VIEW|branch> main
DULL-VIEW|module> pNodeReporter
DULL-VIEW|short> Enabled dynamic node report riders
A node report generated by pNodeReporter has certain fields present by
default, such as lat/lon, heading, speed. The app can now be
configured to include custom additions by specifying (a) a MOOS
variable to subscribe for and watch, (b) a field name in the custom
node report, (c) the frequency of the addition to the node report, and
(d) the precision of the numerical value of the field if it is of type
double.
#---------------------------------
DULL-NICO|date> 250214
DULL-NICO|who> pav
DULL-NICO|type> bugfix
DULL-NICO|branch> main
DULL-NICO|module> lib_bhvutil
DULL-NICO|short> Fixed bug in RefineryCPA for missions with non-zero min speed
The RefineryCPA utility is used with collision avoidance behaviors to create
IvP functions with far fewer pieces. An inner loop could be entered indefinitely
in certain conditions, essentially hanging the helm. This was triggered in
helm configurations where the IvPDomain for speed had a minimum value different
from zero. This may be the case for missions with air vehicles where choosing
a speed of zero is not an option. For this reason it went un-noticed until
this bug fix. The bug fix now handles cases with non-zero min speed.
#---------------------------------
POSH-LYLE|date> 250127
POSH-LYLE|who> pav
POSH-LYLE|type> augmentation
POSH-LYLE|branch> main
POSH-LYLE|module> uFldObstacleSim
POSH-LYLE|short> Added request to pLogger to log obstacle file
The obstacle file is ingested upon startup of uFldObstacleSim. At that
point a message is posted to pLogger, \var{PLOGGER\_CMD} to copy the
obstacle file into the log folder.
#---------------------------------
WIDE-NOTE|date> 250126
WIDE-NOTE|who> pav
WIDE-NOTE|type> augmentation
WIDE-NOTE|branch> main
WIDE-NOTE|module> pMissionEval
WIDE-NOTE|short> Support for new macros, report formats, appcast output
Added several new macros the user can use for formatting custom report
lines, including time/date options, the mission form, mission mod, and
grade. User has more separator options in formating report lines. The
appcast output provide supported macro confirmation for user defined
macros derived from naming MOOS variables in a report column. Appcast
output also better conveys progress in overall mission test. Normally,
once a mission and evaluation has been developed and tested, appcast
output is not seen, since the mission is presumably being run
headlessly. Improved appcast output is helpful when
developing/debugging the mission.
#---------------------------------
DRAB-HACK|date> 250125
DRAB-HACK|who> pav
DRAB-HACK|type> augmentation
DRAB-HACK|branch> main
DRAB-HACK|module> pHelmIvP
DRAB-HACK|short> Added check for initial nav solution before proceeding
The helm now supports a grace period, \var{nav\_grace=N}, upon startup.
Within this grace period it will not post an appcast warning if the nav
values have not yet been received, x, y, speed, heading and depth if an
underwater vehicle.
#---------------------------------
ZERO-TONE|date> 250113
ZERO-TONE|who> smr
ZERO-TONE|type> augmentation
ZERO-TONE|branch> cmgr
ZERO-TONE|module> lib_contacts
ZERO-TONE|short> Added JSON serialization for NodeRecords
The string2NodeRecord deserialization method now checks if the string is
in CSP or JSON format and deserializes accordingly.
#---------------------------------
HALS-CLEM|date> 250112
HALS-CLEM|who> smr
HALS-CLEM|type> augmentation
HALS-CLEM|branch> main
HALS-CLEM|module> alogview
HALS-CLEM|short> Added ability detach a numerical variable for plotting.
Normally alogview launches and offers the option to plot any numerical
variable from the log files. However, string variables with multiple
numerical parts, e.g., \var{POINT=x=4,y=5,z=0}, are not
plottable. With the command-line option \var{--detatched=POINT:y},
alogview, in the pre-launch splitting phase, will create a separate
option to plot a variable presented as \var{POINT:y}.
#---------------------------------
FULL-CARY|date> 250112
FULL-CARY|who> smr
FULL-CARY|type> augmentation
FULL-CARY|branch> main
FULL-CARY|module> alogsplit
FULL-CARY|short> Added ability to isolate numerical subcomponents of strings
Normally alogsplit will split into klog files based on logged MOOS
variable name, e.g, \var{NAV_X} will be split into a file
NAV_X.klog. And a variable say \var{POINT} which may have values like
\var{x=4,y=5,z=0} is similarly split into a file \var{POINT.klog}. The
alogsplit app now allows the user to specify a "detached" variable and
sub-component. For example, on the command-line, the argument
\var{--detached=POINT:y}, would result in the creation of the file
\var{POINT:y.klog}. This is primarily useful because the internal
splitting functionality is also used by alogview, and this allows
alogview to plot numerical variables that may be buried in a
multi-part string. This functionality works on both CSP and JSON
string formats.
#---------------------------------
BONY-ANTS|date> 250114
BONY-ANTS|who> smr
BONY-ANTS|type> augmentation
BONY-ANTS|branch> main
BONY-ANTS|module> pNodeReporter
BONY-ANTS|short> Added option to publish JSON formatted reports
The pNodeReporter app normally publishes node reports in CSP formatted
strings, e.g, NAME=abe,LON=42.358436,LON=-71.087448,SPD=2.2. The user
now has the option to publish this in JSON format, e.g.,
{"NAME":"abe","LON":42.358436,"LON":-71.087448,"SPD":2.2}. By setting
\var{json_report=true}, the node reports are in JSON format. By setting
\var{json_report=VAR}, an additional node report is published to VAR,
while the CSP formatted report is published as normal.
#---------------------------------
VAIN-FONT|date> 250114
VAIN-FONT|who> smr
VAIN-FONT|type> augmentation
VAIN-FONT|branch> main
VAIN-FONT|module> lib_mbutil
VAIN-FONT|short> Added JsonUtils for converting to/from JSON to CSP strings
The most common format for MOOS-IvP strings for complex object is the
common-separated pairs format, e.g., x=23,y=5,z=7. Some users prefer
to deal with JSON strings, e.g., {"x":23,"y":5,"z":5}. These two new
utilities allow for conversion between formats.
#---------------------------------
DARN-ROOM|date> 250111
DARN-ROOM|who> smr
DARN-ROOM|type> augmentation
DARN-ROOM|branch> main
DARN-ROOM|module> pContactMgrV20
DARN-ROOM|short> Added support for early warning time
The contact manager, pContactMgrV20, supports early warning
configuration with earl_warning_time=N. When configured, configurable
warnings as event flags are generated when the contact comes within
range to ownship, roughly 30 secs prior to an alert event. If there
are multiple alert events configured for contacts, the early warning
time is relative to the event with the largest range value. The user
may configure to have early warning radii rendered as XYCircle
postings. In this augmentation, the feature of early warning based on
reference speed and fixed warning distance was disabled. Benefits: The
newer approached is automatically tied to the configured alert of the
contact behaviors, and the configuration parameter of "warning time" is
essentially in the units that the operator cares about.
#---------------------------------
WAVY-REID|date> 250108
WAVY-REID|who> smr
WAVY-REID|type> augmentation
WAVY-REID|branch> main
WAVY-REID|module> uSimMarineV22
WAVY-REID|short> Added option to publish USM_NAVPOS_SUMMARY
uSimMarineV22 will publish both NAV_X/Y and NAV_LAT/LONG as doubles, and
pLogger records double out to 5 decimal places. The USM_NAVPOS_SUMMARY
will publish a string with both, and at sufficient precision, e.g.,
x=68.932,y=-60.32,lat=43.824767,lon=-70.3295309. To opt for this publication
the new configuration parameter: \var{post_navpos_summary=true} should
be used in the uSimMarineV22 configuration.
#---------------------------------
SICK-CODI|date> 250103
SICK-CODI|who> smr
SICK-CODI|type> bugfix
SICK-CODI|branch> main
SICK-CODI|module> pContactMgrV20
SICK-CODI|short> Early warning system fixes and rel speed change
The early warning feature added previously was fixed and augmented to
use the relative speed between ownship and the contact in its policy
to expand the warning range. A new mission, berta_cmgr was created and
added to missions-auto for testing the new features.
#---------------------------------
SOFT-IVER|date> 241229
SOFT-IVER|who> pav
SOFT-IVER|type> augmentation
SOFT-IVER|branch> helmcl
SOFT-IVER|module> uFldBeaconRangeSensor
SOFT-IVER|short> Integrated ContactLedger into the app
The ContactLedger utility was integrated to handle all incoming
NodeReport messages. The ContactLedger has built-in support for
dynamic datums and handling of global and local coordinates.
#---------------------------------
WIDE-RITZ|date> 241229
WIDE-RITZ|who> pav
WIDE-RITZ|type> augmentation
WIDE-RITZ|branch> helmcl
WIDE-RITZ|module> uFldContactRangeSensor
WIDE-RITZ|short> Integrated ContactLedger into the app
The ContactLedger utility was integrated to handle all incoming
NodeReport messages. The ContactLedger has built-in support for
dynamic datums and handling of global and local coordinates.
#---------------------------------
GRIM-KALE|date> 241229
GRIM-KALE|who> smr
GRIM-KALE|type> augmentation
GRIM-KALE|branch> helmcl
GRIM-KALE|module> uFldCollObDetect
GRIM-KALE|short> Integrated ContactLedger into the app
The ContactLedger utility was integrated to handle all incoming
NodeReport messages. The ContactLedger has built-in support for
dynamic datums and handling of global and local coordinates. While
uFldCollObDetect is not part of the autonomous decision-making
process, it is an essential tool for monitoring and validating the
obstacle avoidance algorithms.
#---------------------------------
NUDE-GROG|date> 241228
NUDE-GROG|who> smr
NUDE-GROG|type> augmentation
NUDE-GROG|branch> helmcl
NUDE-GROG|module> uFldObstacleSim
NUDE-GROG|short> Integrated ContactLedger into to the simulator
The ContactLedger utility was integrated to handle all incoming
NodeReport messages. The ContactLedger has built-in support for
dynamic datums and handling of global and local coordinates. While
uFldObstacleSim is not part of the autonomous decision-making
process, it is an essential tool for monitoring and validating the
obstacle avoidance algorithms.
#---------------------------------
FULL-DUKE|date> 241228
FULL-DUKE|who> smr
FULL-DUKE|type> augmentation
FULL-DUKE|branch> helmcl
FULL-DUKE|module> uFldCollisionDetect
FULL-DUKE|short> Integrated ContactLedger into the collision detector
The ContactLedger utility was integrated to handle all incoming
NodeReport messages. The ContactLedger has built-in support for
dynamic datums and handling of global and local coordinates. While
uFldCollisionDetect is not part of the autonomous decision-making
process, it is an essential tool for monitoring and validating
the collision avoidance algorithms.
#---------------------------------
MEGA-MOLD|date> 241222
MEGA-MOLD|who> smr
MEGA-MOLD|type> augmentation
MEGA-MOLD|branch> helmcl
MEGA-MOLD|module> IvPBehavior
MEGA-MOLD|short> Modified interface for accessing contact info
Contact info prior to this mod has resided in the information buffer,
a pointer to which is shared between the helm and all behaviors. For
most contact behaviors, the contact position was handled at the
IvPContactBehavior superclass level in the updatePlatformInfo function. So this
mod should not require any behavior authors to modify code unless their
behavior was accessing contact info from the info buffer directly. The
IvPContact behavior now access information from the ContactLedger snapshot
through four new functions, e.g., getLedgerInfoDbl(), which takes the
name of the contact and the field information, e.g., the x position or
longitude position of the contact. This change is a preparation for
the helm and behaviors supporting dynamic datums in an upcoming release.
#---------------------------------
SLIM-TOUR|date> 241222
SLIM-TOUR|who> smr
SLIM-TOUR|type> augmentation
SLIM-TOUR|branch> main
SLIM-TOUR|module> pHelmIvP
SLIM-TOUR|short> Integrated ContactLedger into the helm and behaviors
The ContactLedger utility was integrated to handle all incoming
NodeReport messages. The ContactLedger has built-in support for
dynamic datums and handling of global and local coordinates. Support
was added to allow access for all helm behaviors, typically only
IvPContactBehaviors, to the contact ledger. The helm behaviors no
longer obtain contact information from the information buffer. This
addresses a potential unbounded memory growth issue for long autonomy
missions with thousands+ contact IDs posted and expiring, since the
information buffer didn't clear old contact information. The contact
ledger handles expiring contacts gracefully. The helm behaviors only
get a snapshot of the contacts currently held in the contact ledger
and thus behaviors are not concerned with contact memory management.
#---------------------------------
AVID-SONG|date> 241209
AVID-SONG|who> smr
AVID-SONG|type> augmentation
AVID-SONG|branch> main
AVID-SONG|module> pContactMgrV20
AVID-SONG|short> Integrated the ContactLedger into the contact manager.
The ContactLedger utility was integrated to handle all incoming NodeReport
messages. The ContactLedger has built-in support for dynamic datums and
handling of global and local coordinates.
#---------------------------------
DANK-ACHE|date> 241206
DANK-ACHE|who> smr
DANK-ACHE|type> augmentation
DANK-ACHE|branch> main
DANK-ACHE|module> pMarineViewer
DANK-ACHE|short> Integrated the ContactLedger into pMarineViewer
The ContactLedger utility was integrated to handle all incoming NodeReport
messages. The ContactLedger has built-in support for dynamic datums and
handling of global and local coordinates.
#---------------------------------
EASY-BAND|date> 241203
EASY-BAND|who> smr
EASY-BAND|type> augmentation
EASY-BAND|branch> main
EASY-BAND|module> lib_geodaid
EASY-BAND|short> Added lib_geodaid with ContactLedger util class
The lib_geodaid library was created, with a the ContactLedger utility
class. This class is for use in all MOOS-IvP apps that receive, store
and reason about NodeReports. The ContactLedger has a Geodesy and
declared datum. As node reports are received with lat/lon coordinates
the the local planar coordinates are filled in, based on the current
dataum setting. If a datum shifts mid-mission, any app using the
contact ledger simply needs to set to the new datum, and all previously
received and held node reports will be updated with new local coords.
The ContactLedger was moved to its own library, rather than existing
in lib_contacts, to allow apps (and behaviors) that previously had no
dependency on Geodesy, to remain so.
#---------------------------------
OPEN-ZALE|date> 241130
OPEN-ZALE|who> smr
OPEN-ZALE|type> augmentation
OPEN-ZALE|branch> cmgr
OPEN-ZALE|module> pContactMgrV20
OPEN-ZALE|short> Added support for event flags when contact ages out
The contact manager will drop a contact after some period of time with
no updates from the contact. There is now the user option of posting a
flag upon this event, for each contact, with support for macros
revealing the contact name and UTC time of timeout. This can be useful
for proactively informing a UI module to cease rendering a contact.
#---------------------------------
COLD-COBY|date> 241130
COLD-COBY|who> smr
COLD-COBY|type> augmentation
COLD-COBY|branch> cmgr
COLD-COBY|module> pContacMgrV20
COLD-COBY|short> Added support for early warnings
The contact manager now supports an early warning capability. The
user specifies a range to ownship within which a contact will trigger
an early warning, typically substantially before a contact related
behavior will be spawned. This allows an operator or other app to
act on the early warning by choosing to disable a contact if other
information indicates that the contact does not pose a safety concern.
The early warning range can be speed regulated, potentially enlarging
for contacts above a certain reference speed threshold.
#---------------------------------
NINE-ALAN|date> 241129
NINE-ALAN|who> smr
NINE-ALAN|type> augmentation
NINE-ALAN|branch> cmgr
NINE-ALAN|module> pHelmIvP
NINE-ALAN|short> Added support for disabling/enabling contacts
The helm can now accept requests to disable or re-enable a named
contact. This change is in coordination with the changes to the
IvPBehavior and IvPContactBehavior to support the new disabled state
for behaviors. HelmEngine maintains an ordered cache of
disable/enable requests, to ensure that such requests are applied even
if a behavior has not yet been spawned.
#---------------------------------
FLAT-LADY|date> 241129
FLAT-LADY|who> smr
FLAT-LADY|type> augmentation
FLAT-LADY|branch> cmgr
FLAT-LADY|module> pContactMgrV20
FLAT-LADY|short> Added support for disabling/enabling contacts
The contact manager can now optionally accept input through a
user-provided variable to broker the helm the disabling of behavior(s)
associated with a named contact. Same is true for re-enabling a
contact. The contact manager will keep a local slate of
disabled/enabled contacts. The contact manager has new flags
associated with the disabling/enabling events with associate
macros. The latter allows the contact manager to post confirmations to
whatever app requested the disabling or enabling.
#---------------------------------
DRAB-SLUM|date> 241127
DRAB-SLUM|who> smr
DRAB-SLUM|type> augmentation
DRAB-SLUM|branch> cmgr
DRAB-SLUM|module> aloghelm
DRAB-SLUM|short> Added support for disabled behaviors
The aloghelm output for the --bhvs mode, now reflects disabled behaviors
as part of its standard output. This is a good post-mission method for
verifying behavior disabling and re-enabling proceeded as intended.
#---------------------------------
GOOD-SOUP|date> 241117
GOOD-SOUP|who> smr
GOOD-SOUP|type> augmentation
GOOD-SOUP|branch> cmgr
GOOD-SOUP|module> IvPBehavior
GOOD-SOUP|short> Added new state, disabled, alongside idle, running etc
In certain, especially USV, operations an operator may wish to disable
a safety behavior for a specific contact or set of contacts by direct
command. Although the contact manager can be configured to filter out
contacts based on a number of criteria, in this scenario, the behavior
may have already been spawned, and the operator may simply wish to
apply their discretion to filter out an active behavior. When a
behavior is in this new "disabled" state, it will essentially do
nothing. The behavior author can implement an onDisabledState()
function, and users can utilize the new disable_flag and enable_flag
options. Run-time disabling is communicated to the helm with the
BHV_ABLE_FILTER message. This can contain a message identifying the
contact explicitly, and/or also identifying the behavior
type. Subsequent messages to this variable can server to (re)enable
the behavior. Behaviors can be configured with can_disable=false which
will make them immune to run-time disable messages. For example a
close-in last line of defense collision avoidance behavior can be set
with can_disable=false.
#---------------------------------
VAST-NOEL|date> 241107
VAST-NOEL|who> smr
VAST-NOEL|type> augmentation
VAST-NOEL|branch> pnr
VAST-NOEL|module> BHV_CutRange
VAST-NOEL|short> Allow users to have patience param up to 100.
The CutRange behavior allowed for a patience parameter up to 100, but
the value was essentially clipped in AOF_CutRangeCPA, to be 85. Some
users want the full range. The default setting and upper bound remain
the same, but now users can set \var{max_patience} in the CutRange
behavior to be say 90 or 100. Then, a higher patience parameter will
be respected.
#---------------------------------
HAZY-KIAN|date> 241102
HAZY-KIAN|who> pav
HAZY-KIAN|type> augmentation
HAZY-KIAN|branch> pnr
HAZY-KIAN|module> mhash_gen
HAZY-KIAN|short> Added zhash capability for zbatch auto-testing
A zhash is new hash type comprised of US cities, for tagging batches
of missions in auto-testing. The 'z' is due to the convention of using
a zlaunch script to run a batch of missions. With distributed
auto-testing over a cluster of machines, the missions may not be
orchestrated by a zlaunch script, but nevertheless we settle on the
term of a "zbatch" to apply to a set of auto-tested missions and the
notion of "zhash" to be tagged to a zbatch. This mod is mostly
implemented in the HashUtils.cpp utility which is used by mhash_gen
when passed the -z flag.
#---------------------------------
PINK-WINE|date> 241031
PINK-WINE|who> smr
PINK-WINE|type> augmentation
PINK-WINE|branch> pnr
PINK-WINE|module> pAutoPoke
PINK-WINE|short> New thin MOOS app for poking MOOSDB upon startup
pAutoPoke is a thin MOOS app for poking the MOOSDB with a user-configured set
of pokes, typically at the start of the mission. In the initial verison of this
app, the intended use is in a shoreside community, after some specified number
of vehicles have been declared to be connected, based on the UFSB_NODE_COUNT
variable. This ensures that the full N-vehicle plus shoreside is running before
the poke(s) are made. In follow-on versions, the condition will be generalized
to any logic condition. This app was added to remove complexity of the xlaunch.sh
script used in auto-testing. With this app, the auto-launch simply launches the
mission and the kickoff commands are injected into the shoreside when ready.
In follow-on versions, when general logic conditions are supported, this app
can also be run in a vehicle community.
#---------------------------------
HIGH-TOWN|date> 241031
HIGH-TOWN|who> smr
HIGH-TOWN|type> augmentation
HIGH-TOWN|branch> pnr
HIGH-TOWN|module> uMayFinish
HIGH-TOWN|short> New thin cmdline MOOS app for monitoring mission finish
uMayFinish is typically a terminal-launched MOOS app launched within a
shell script, e.g., xlaunch.sh. It will connect to a MOOS community
and monitor for a completion event or timeout based on DB_UPTIME. When
completed, it simply exits. Presumably to allow the executing script
to proceed to a next phase. For example a script could proceed to
bring down the MOOS community for the mission it was monitoring.
This app was created as a thinnner, simpler alternative to uQueryDB when
running in a shell script running an automated test mission. The script
will launch uMayFinish and when uMayFinish completes, and disconnects from
the MOOSDB, the script may proceed to bring down the mission.
#---------------------------------
DANK-GIBB|date> 241020
DANK-GIBB|who> pav
DANK-GIBB|type> augmentation
DANK-GIBB|branch> pnr
DANK-GIBB|module> IvPBehavior
DANK-GIBB|short> Added getBufferIsKnown(string)
Added the getBufferIsKnown(string var) function to allow behavior authors
to test whether the info buffer has ever had the var.
#---------------------------------
MEEK-OVAL|date> 241020
MEEK-OVAL|who> smr
MEEK-OVAL|type> augmentation
MEEK-OVAL|branch> pnr
MEEK-OVAL|module> BHV_AvoidObstacleV24
MEEK-OVAL|short> Additional macro support for obs id and min_util_cpa
The BHV_AvoidObstacleV24 behavior was augmented to support addional
macros, (a) MINU_CPA, for the config parameter for min_util_cpa,
(b) MAXU_CPA, for the config parameter for max_util_cpa and (c) the
OIDX, for the obstacle ID based on the last component of the obstacle
label, separated by underscored, e.g., "1234" from a label "alpha_1234".
#---------------------------------
MALE-KENT|date> 241020
MALE-KENT|who> pav
MALE-KENT|type> augmentation
MALE-KENT|branch> pnr
MALE-KENT|module> BHV_FixedTurn
MALE-KENT|short> Added alt subscription for DESIRED_RUDDERX
The FixedTurn behavior will normally subscribe for DESIRED_RUDDER
simply to log the rudder values during a turn. It is not part of the
behavior functionality. When using uSimMarineV22 with an embedded PID
controller, DESIRED_RUDDER is not published. uSimMarineV22 can be
configured with post_des_rudder=DESIRED_RUDDERX to publish the
internal rudder values and feed the FixedTurn behavior in this
operation.
#---------------------------------
SOFT-ALEX|date> 241020
SOFT-ALEX|who> pav
SOFT-ALEX|type> augmentation
SOFT-ALEX|branch> pnr
SOFT-ALEX|module> uSimMarineV22
SOFT-ALEX|short> mod uSimMarineV22 to halt on OBSTACLE_HIT=true
uSimMarineV22 had a partially implemented feature to react to a posting
to OBSTACLE_HIT=true, resulting in the vehicle coming to stop. This mod
ensures that the event (a) more immediately results in speed=0, and
also ensures that the NAV_*_GT values also instantly halt.
#---------------------------------
FLAT-MARK|date> 241017
FLAT-MARK|who> pav
FLAT-MARK|type> augmentation
FLAT-MARK|branch> pnr
FLAT-MARK|module> BehaviorSpec
FLAT-MARK|short> Added optional spawning cap for templating behaviors
For a behavior configured for templating, prior to this change, an arbitrary
number of instances could be spawned. For a behavior like collision avoidance,
this is fine. For a goal-oriented behavior like CutRange or Trail, it doesn't
make sense to spawn more than one instance at a time. This mod allows for
a behavior to be configured to cap the number of instances to an arbitrary
number like 1. NOTE: currently if a behavior is spawned and completes, the
completion event does not decrement the counter.
#---------------------------------
FAST-RIOT|date> 241012
FAST-RIOT|who> smr
FAST-RIOT|type> augmentation
FAST-RIOT|branch> pnr
FAST-RIOT|module> AOF_R16
FAST-RIOT|short> Option added to disallow any port turn during giveway
A user opted for a slightly different conservative policy in the
COLREGS behavior, specifically in the "Give-way" mode. It pertains to
which set of maneuvers are outright prohibited in this mode. The
AOF_R16 class was modified to support conservative policy as a
configuration option.
#---------------------------------
SAFE-CODE|date> 241010
SAFE-CODE|who> smr
SAFE-CODE|type> augmentation
SAFE-CODE|branch> pnr
SAFE-CODE|module> BHV_AvdColregsV22
SAFE-CODE|short> Additional status macros, quieter idle output
The BHV_AvdColregs behavior produces a number of status messages,
mostly for post-mission analysis/debugging. To facilate users who wish
to make their own status messages, a number of supported macros were
added. These include AVD_MODE (the main avoid mode, e.g., headon,
giveway), AVD_SMODE (the sub-mode when the main mode has sub-modes),
APWT (the applied priority weight given by the static priority wt and
relevance, MODE_ID (a unique integer associated with all mode:sub-mode
values), and FULL_MODE (simply the string comprised of
mode:sub-mode). Macros may be used in any flag defined for the
behavior and behavior superclasses. This behavior is now configured
by default to not publish any status messages in the idle mode. This
can be overridden by setting post_status_info_on_idle=true.
#---------------------------------
LONG-MELL|date> 241009
LONG-MELL|who> smr
LONG-MELL|type> augmentation
LONG-MELL|branch> main
LONG-MELL|module> uFldNodeComms
LONG-MELL|short> Integration of ContactLedger as key data structure
The uFldNodeComms app received node repprts from all vehicles, and
uses this information to pass on node reports to other vehicles, and
uses the node report position information to decide whether to allow
messages to be routed to other vehicles. The ContactLedger class is a
new super-utilty class for receiving and storing node reports. The old
data structures were swapped out and replaced with the ContactLedger.
This allows this app to support dynamic datum changes.
#---------------------------------
ZERO-LAND|date> 241009
ZERO-LAND|who> smr
ZERO-LAND|type> augmentation
ZERO-LAND|branch> pnr
ZERO-LAND|module> ContactLedger
ZERO-LAND|short> Introduced ContactLedger class, NodeRecord mods
The ContractLedger class is a new super-utility class to be used in
all applications that receive and reason about node reports. It
ensures that every node report has both Lat/Lon and X/Y coordinates,
converting as needed if a node report has only one or the other. It
the dynamic update of a datum, recalculating local coordinates on each
update. It also is able to answer queries about node report staleness
and requests to remove stale nodes. It it first being integrated into
uFldNodeComms, but will also be integrated into pMarineViewer,
pHelmIvP, pContactMgrV20 and any other app reasoning about contacts.
#---------------------------------
MEEK-RUST|date> 241003
MEEK-RUST|who> smr
MEEK-RUST|type> augmentation
MEEK-RUST|branch> pnr
MEEK-RUST|module> pHelmIvP
MEEK-RUST|short> IvPHelm now handles node reports w/ only lat/lon
Prior to this change, the helm received node reports assuming each
node report contained local X/Y coordinates. The helm needs the local
coordinates for many behaviors using planar math. Things are moving
to where all inter-vehicle messages with position coordinates will use
only lat/lon coordinates and not local coordinates at all. The helm
was augmented to have an instances of MOOSGeodesy to allow incoming
node reports to convert reports with only lat/lon to also have local
coordinates, stored locally in the helm for access by the behaviors.
This change was to HelmIvP.h/.cpp.
#---------------------------------
VERY-LADY|date> 241003
VERY-LADY|who> smr
VERY-LADY|type> augmentation
VERY-LADY|branch> pnr
VERY-LADY|module> lib_contacts
VERY-LADY|short> NodeRecord class serialize only global coords
Serialization of node records happends in the NodeRecord class. The
class was augmented to have a "coord_policy" which can be set to
global, resulting in all serializations using only lat/lon coordinates
while omitting local x/y coordinates.
#---------------------------------
DRAB-EMIL|date> 241005
DRAB-EMIL|who> pav
DRAB-EMIL|type> augmentation
DRAB-EMIL|branch> pnr
DRAB-EMIL|module> mhash_gen
DRAB-EMIL|short> mhash_gen --shore,-s produces short mhash
The mhash_gen utility produces a full mission hash, e.g.,
241005-1954L-SOFT-LEAF. With the --short (-s) option, the short
version can be produced, e.g., SOFT-LEAF. This is useful in some
shell scripts.
#---------------------------------
PINK-BRAM|date> 241004
PINK-BRAM|who> pav
PINK-BRAM|type> bugfix
PINK-BRAM|branch> pnr
PINK-BRAM|module> pMarineViewer
PINK-BRAM|short> Fixed infocast pane browser reset upon refresh
Infocast panes with content larger than the pane will result in a
scroll bar. Using the scroll bar only worked until an instant later
when the pane was updated and the scroll position reset to the
top. Previous work-arounds included (a) making the pane bigger or (b)
pausing the infocast refresh. This bug fix ensures the position of the
content of the pane remains the same even as refreshes are arriving.
#---------------------------------
LIVE-JAWS|date> 241003
LIVE-JAWS|who> smr
LIVE-JAWS|type> augmentation
LIVE-JAWS|branch> pnr
LIVE-JAWS|module> pNodeReporter
LIVE-JAWS|short> Enable node reports to be posted with just lat/lon
New support for a configuration that results in \mvar{NODE\_REPORT}
messages containing only Lat/Lon value and NOT include X/Y
coordinates. This is to support a larger effort to no longer use local
coordinates between vehicles. To enable this mode of operation, a new
configuration parameter was added, \var{coord\_global\_policy}. When
set to true, only LAT/LON position information will be present in
outgoing \mvar{NODE\_REPORT\_LOCAL} messages. Note, for backward
compatability purposes, \var{coord\_global\_policy} is FALSE by
default. Perhaps in the furture, the inclusion of X/Y in reports will
be deprecated, but for now we err on the side of no unexpected
behavior for those who are not concerned by this issue.
#---------------------------------
GRIM-WINS|date> 241003
GRIM-WINS|who> smr
GRIM-WINS|type> augmentation
GRIM-WINS|branch> main
GRIM-WINS|module> pMarineViewer
GRIM-WINS|short> Handle node reports with only lat/lon and no x/y
Now able to handle incoming \mvar{NODE\_REPORT} messages that do not
contain an X/Y value, only LAT/LON. Part of the migration to use only
global coordinates between vehicles and command/control. This will
support certain users where vehcles have different datums, or set
their datum to the current vehicle position at time of mission start.
#---------------------------------
HALF-PAWS|date> 241001
HALF-PAWS|who> pav
HALF-PAWS|type> augmentation
HALF-PAWS|branch>
HALF-PAWS|module> pMarineViewer
HALF-PAWS|short> Added Infocast Layout options esp for swarms
Support was added for optional infocast pane layouts. In addition to
the default layout (nodes upper left, procs upper right, cast on the
botttom), two other layouts are supported. A "swarm" mode with nodes
taking the entire PMV height on the left, and a "fullcast" mode where
only the cast pane is shown large.
#---------------------------------
JUST-ZIGS|date> 240930
JUST-ZIGS|who> pav
JUST-ZIGS|type> augmentation
JUST-ZIGS|branch>
JUST-ZIGS|module> pMarineViewer
JUST-ZIGS|short> Added Infocast panes darker colors
Support was added for a few more darker colors for infocast
background. To help in certain lighting situations or on monitors
where lighter colors appear washed out.