...
This
...
page
...
documents
...
some
...
of
...
the
...
key
...
applications
...
available
...
in
...
the
...
Hovergroup
...
svn.
...
| Table of Contents |
|---|
...
iAcommsDriver
iAcommsDriver provides our standard interface between MOOS and the WHOI uModem. It implements the GOBY uModem driver class and allows other MOOS applications to make use of the modem through several MOOS variables.
Simple Interface
Great for simple applications or human use.
Transmitting
Transmitting is very easy - simply post a string to the variable ACOMMS_TRANSMIT_DATA and the modem will immediately send that data if it is not currently receiving or transmitting data. The variable ACOMMS_DRIVER_STATUS indicates whether the modem is ready (0), transmitting (1), or receiving (2). The transmission rate and destination can be set by posting the the variables ACOMMS_TRANSMIT_RATE and ACOMMS_TRANSMIT_DEST. If sending non-ASCII data, post a binary string to ACOMMS_TRANSMIT_DATA_BINARY
...
instead.
...
Request an ack by posting 1 to ACOMMS_REQUEST_ACK.
...
Lockout transmits by posting 1 to ACOMMS_TRANSMIT_LOCKOUT.
...
Receiving
To use simple receiving, the "enable_legacy"
...
option
...
must
...
be
...
enabled
...
in
...
the
...
MOOS
...
process
...
config.
...
Whenever
...
a
...
transmission
...
is
...
received,
...
information
...
about
...
the
...
reception
...
is
...
posted
...
to
...
several
...
variables:
...
- ACOMMS_RECEIVED_DATA
...
- -
...
- binary
...
- string
...
- type
...
- -
...
- contains
...
- all
...
- the
...
- received
...
- data.
...
- Data
...
- from
...
- multiple
...
- frames
...
- is
...
- concatenated
...
- together,
...
- even
...
- if
...
- frames
...
- in
...
- the
...
- middle
...
- are
...
- missing.
...
- ACOMMS_BAD_FRAMES
...
- -
...
- string
...
- type
...
- -
...
- comma
...
- delimited
...
- list
...
- of
...
- bad
...
- frame
...
- indices
...
- ACOMMS_SOURCE_ID
...
- -
...
- double
...
- type
...
- -
...
- integer
...
- ID
...
- of
...
- the
...
- transmitting
...
- modem
...
- ACOMMS_DEST_ID
...
- -
...
- double
...
- type
...
- -
...
- integer
...
- ID
...
- of
...
- the
...
- destination
...
- modem
...
- (0
...
- =
...
- broadcast)
...
- ACOMMS_RATE
...
- -
...
- double
...
- type
...
- -
...
- integer
...
- rate
...
- of
...
- the
...
- transmission
...
- ACOMMS_RECEIVED_STATUS
...
- -
...
- double
...
- type
...
- -
...
- integer
...
- indicated
...
- status.
...
- 0=good,
...
- 1=partial,
...
- 2=bad
...
- ACOMMS_ONE_WAY_TRAVEL_TIME
...
- -
...
- double
...
- type
...
- -
...
- posted
...
- if
...
- synced
...
- to
...
- pps,
...
- or
...
- requesting
...
- two-way
...
- ranging
...
Unified
...
Interface
...
Sometimes
...
the
...
simple
...
interface
...
is
...
cumbersome
...
because
...
applications
...
have
...
to
...
subscribe
...
to
...
many
...
variable
...
to
...
get
...
enough
...
information
...
about
...
incoming
...
acomms
...
transmissions.
...
With
...
the
...
unified
...
interface,
...
only
...
one
...
variable
...
is
...
required
...
to
...
send
...
or
...
receive
...
data.
...
Transmitting
Note that the simple transmitting method is supported regardless of the "enable_legacy"
...
setting.
...
Alternatively,
...
use
...
the
...
AcommsTransmission
...
class
...
defined
...
in
...
the
...
HoverAcomms
...
library.
...
Post
...
the
...
serialized
...
object
...
to
...
ACOMMS_TRANSMIT
...
and
...
the
...
acomms
...
driver
...
will
...
set
...
the
...
rate,
...
destination,
...
data,
...
etc.
...
all
...
from
...
the
...
information
...
stored
...
in
...
that
...
object.
...
Receiving
With each receipt an object of the AcommsReception class defined in the HoverAcomms libary is posted to the binary string ACOMMS_RECEIVED.
...
This
...
posting
...
is
...
still
...
available
...
if
...
"enable_legacy"
...
is
...
turned
...
on.
...
Logging
Several postings are made specifically for logging purposes, but applications may use them as well. These postings are always enabled. The serial communications between the host and modem are also recorded in a goby_log.txt
...
file
...
in
...
the
...
same
...
directory
...
pLogger
...
uses.
...
Transmitting
- ACOMMS_TRANSMITTED_DATA_HEX
...
- -
...
- string
...
- -
...
- a
...
- hex
...
- translation
...
- of
...
- the
...
- transmitted
...
- data
...
- ACOMMS_TRANSMITTED_ALL
...
- -
...
- string
...
- -
...
- a
...
- loggable
...
- serialization
...
- of
...
- the
...
- transmission
...
- protobuf
...
Receiving
- ACOMMS_RECEIVED_ALL
...
- -
...
- string
...
- -
...
- a
...
- loggable
...
- serialization
...
- of
...
- the
...
- reception
...
- protobuf
...
- ACOMMS_RECEIVED_DATA_HEX
...
- -
...
- string
...
- -
...
- a
...
- hex
...
- translation
...
- of
...
- the
...
- received
...
- data
...
- ACOMMS_IMPULSE_RESPONSE
...
- -
...
- string
...
- -
...
- self
...
- explanatory
...
Additional
...
Options
...
and
...
Special
...
Rates
...
Mini
...
Packets
...
-
...
Rate
...
100
...
Just
...
a
...
13-bit
...
packet.
...
If
...
only
...
one
...
byte
...
is
...
provided,
...
it
...
will
...
be
...
packed
...
with
...
a
...
leading
...
0x00.
...
If
...
two
...
or
...
more
...
bytes
...
are
...
provided,
...
only
...
the
...
first
...
two
...
bytes
...
will
...
be
...
taken
...
and
...
a
...
bitwise
...
and
...
with
...
0x1f
...
will
...
be
...
performed
...
on
...
the
...
first
...
byte.
...
Examples:
...
0x6161
...
-->
...
0x0161
...
0x0061
...
-->
...
0x0061
...
0x6100
...
-->
...
0x0100
...
0x61
...
-->
...
0x0061
...
FSK
...
or
...
PSK
...
encoding
...
can
...
be
...
set
...
using
...
the
...
"PSK_minipackets"
...
process
...
config.
...
Default
...
is
...
FSK.
...
REMUS
...
LBL
...
-
...
Rate
...
101
...
A
...
ping
...
that
...
contains
...
no
...
data.
...
Each
...
LBL
...
transponder
...
in
...
the
...
water
...
will
...
yield
...
a
...
range
...
response.
...
As
...
many
...
as
...
four
...
responses
...
are
...
published
...
in
...
comma
...
delimited
...
form
...
to
...
REMUS_LBL_TIMES.
...
Two
...
Way
...
Ranging
...
-
...
Rate
...
102
...
Must
...
set
...
a
...
destination
...
ID.
...
Range return should arrive as an independent reception.
One Way Ranging
Enabled using the "enable_ranging"
...
process
...
config,
...
this
...
option
...
syncs
...
all
...
transmissions
...
to
...
a
...
PPS
...
pulse
...
provided
...
by
...
PPS.
...
Both
...
sending
...
and
...
receiving
...
modems
...
must
...
have
...
this
...
option
...
enabled
...
to
...
work.
...
If
...
the
...
legacy
...
option
...
is
...
enabled
...
the
...
travel
...
time
...
will
...
be
...
posted
...
to
...
ACOMMS_ONE_WAY_TRAVEL_TIME,
...
otherwise
...
the
...
travel
...
time
...
will
...
be
...
contained
...
in
...
the
...
AcommsReception
...
object.
...
Scheduler
Use the MOOS config line "use_scheduler"
...
to
...
enable
...
use
...
with
...
the
...
application
...
pAcommsScheduler.
...
This
...
will
...
substitute
...
the
...
following
...
subscriptions:
...
- ACOMMS_TRANSMIT_DATA
...
- -->
...
- SCHEDULER_TRANSMIT_DATA
...
- ACOMMS_TRANSMIT_DATA_BINARY
...
- -->
...
- SCHEDULER_TRANSMIT_BINARY
...
- ACOMMS_TRANSMIT
...
- -->
...
- SCHEDULER_TRANSMIT
...
Other
...
Variables
...
Publications
- ACOMMS_DRIVER_WARNING
...
- -
...
- string
...
- -
...
- debug
...
- warnings
...
- SYSTEM_TIME_SECONDS
...
- -
...
- double
...
- -
...
- time
...
- of
...
- system
...
- clock
...
- from
...
- midnight,
...
- used
...
- for
...
- synchronization
...
- purposes.
...
- VIEW_RANGE_PULSE
...
- -
...
- blue
...
- for
...
- transmissions;
...
- green,
...
- yellow,
...
- or
...
- red
...
- for
...
- receptions
...
- depending
...
- on
...
- status.
Subscriptions
Quirks and Works in Progress
- Two way ranging
- Driver crashes if pLogger is not started first
- Acomms stats may be incorrect if, for example, one and a fraction of three available frames are used
...
uPokeDBHex
Similar to the normal uPokeDB, but pokes binary strings instead of normal strings using a hex representation.
Usage
| Code Block |
|---|
*Subscriptions* h4. Quirks and Works in Progress * Two way ranging * Driver crashes if pLogger is not started first * Acomms stats may be incorrect if, for example, one and a fraction of three available frames are used ---- h2. uPokeDBHex Similar to the normal uPokeDB, but pokes binary strings instead of normal strings using a hex representation. *Usage* {code} uPokeDBHex ACOMMS_TRANSMIT_DATA_BINARY="68:65:6c:6c:6f" {code} ---- h2. iHoverKayak The interface between MOOS and the low level kayak control running on the Arduino. h3. Switch radios Poke the variable RADIO_POWER with either "bullet" or "freewave". To lock in the change, poke again with the same value within |
...
iHoverKayak
The interface between MOOS and the low level kayak control running on the Arduino.
Switch radios
Poke the variable RADIO_POWER with either "bullet" or "freewave". To lock in the change, poke again with the same value within RADIO_WAIT_TIME
...
seconds
...
(default
...
120).
...
When
...
locked
...
in,
...
the
...
driver
...
will
...
post
...
"freewave_locked"
...
or
...
"bullet_locked"
...
to
...
RADIO_POWER.
...
Thrust
...
and
...
Rudder
...
Positive
...
rudder
...
or
...
offset
...
turns
...
the
...
boat
...
to
...
starboard.
...
DESIRED_THRUST
...
can
...
be
...
0
...
to
...
100
...
ARDUINO_THRUST
...
varies
...
from
...
0
...
to
...
1000.
...
ARDUINO_RUDDER
...
is
...
an
...
indication
...
of
...
the
...
set
...
point
...
only,
...
not
...
the
...
current
...
position.
...
RUDDER_OFFSET
...
can
...
be
...
used
...
to
...
change
...
the
...
constant
...
offset
...
after
...
launch.
...
List of Configuration Settings and Variables
Configuration
- PORT_NAME
...
- -
...
- serial
...
- port
...
- name,
...
- defaults
...
- to
...
- /dev/ttyO0
...
- (hardware
...
- serial
...
- port)
...
- BAUD_RATE
...
- -
...
- defaults
...
- to
...
- 115200
...
- INVERT_RUDDER
...
- -
...
- boolean
...
- RUDDER_OFFSET
...
- -
...
- constant
...
- offset
...
- to
...
- rudder
...
- angle
...
- RADIO_WAIT_TIME
...
- -
...
- in
...
- seconds,
...
- time
...
- to
...
- wait
...
- for
...
- confirmation
...
- when
...
- switching
...
- radios
...
Subscriptions
- DESIRED_THRUST
...
- DESIRED_RUDDER
...
- RADIO_POWER
...
- -
...
- "freewave"
...
- or
...
- "bullet"
...
- RUDDER_OFFSET
...
- -
...
- change
...
- rudder
...
- offset
...
- after
...
- launch
...
Publications
- VOLTAGE
- CPU_BOX_TEMP
...
- ROBOTEQ_HEATSINK_TEMP
...
- ROBOTEQ_INTERNAL_TEMP
...
- ROBOTEQ_BATTERY_CURRENT
...
- ROBOTEQ_MOTOR_CURRENT
...
- CPU_BOX_CURRENT
...
- ARDUINO_THRUST
...
- ARDUINO_RUDDER
...
- RADIO_POWER
...
- -
...
- "freewave_locked"
...
- or
...
- "bullet_locked"
...
pScheduledTransmit
A simple application for collecting acomms data. Can be configured to transmit on a regular schedule using a period and offset, and measured using the system clock. Can be used across several vehicles as long as their clocks are in sync. Posts a long string of random alphanumeric characters that should completely fill any rate transmission.
Configuration
- period - time in seconds between transmissions
- offset - measured from midnight, offset in seconds of transmissions. Set different offsets on different vehicles to stagger transmissions.
Subscriptions
- SCHEDULED_TRANSMITS - "on" or "off" to enable/disable transmits
- SCHEDULED_TRANSMITS_PERIOD - use to set period after launch
- SCHEDULED_TRANSMITS_OFFSET - use to set offset after launch
Publications
- ACOMMS_TRANSMIT_DATA - 2048 random alphanumeric characters
...
pAcommsScheduler
The scheduler is an application that can be run on all topside modems to provide synchronization with respect to a single underwater vehicle. pAcommScheduler expects the AUV to transmit updates with a constant period, which much be provided as a config variable, along with the AUV's modem ID. The scheduler will listen to incoming transmissions for those from the AUV, and average the last four receptions to determine the schedule. It will lockout the acomms driver to prevent transmission when receipts from the AUV are expected.
The scheduler will also post its current state and estimates of the offset and duration of incoming receipts from the AUV. Other applications can use this offset by utilizing system time as provided by the JoshUtils library.
Configuration
- period - time in seconds of AUV's expected transmit period
- source_ID - modem id of AUV
- pre_lock - time before expected receive start when modem lockout will begin
- post_lock - time after receive stop when modem lockout will end
Publications
- ACOMMS_SCHEDULER_OFFSET - the estimated offset of the receive start
- ACOMMS_SCHEDULER_DURATION - the estimated duration of the receive
- ACOMMS_SCHEDULER_STATE - current state: 0=unlocked, 1-3=locked (pre, mid, post), 4=unset (no observation)
—
pMarinePID_Hover
A slightly modified version of the pMarinePID application included with MOOS-IvP. Differential control is properly implemented by the following equation:
| Code Block |
|---|
---- h2. pScheduledTransmit A simple application for collecting acomms data. Can be configured to transmit on a regular schedule using a period and offset, and measured using the system clock. Can be used across several vehicles as long as their clocks are in sync. Posts a long string of random alphanumeric characters that should completely fill any rate transmission. *Configuration* * period - time in seconds between transmissions * offset - measured from midnight, offset in seconds of transmissions. Set different offsets on different vehicles to stagger transmissions. *Subscriptions* * SCHEDULED_TRANSMITS - "on" or "off" to enable/disable transmits * SCHEDULED_TRANSMITS_PERIOD - use to set period after launch * SCHEDULED_TRANSMITS_OFFSET - use to set offset after launch *Publications* * ACOMMS_TRANSMIT_DATA - 2048 random alphanumeric characters ---- h2. pAcommsScheduler The scheduler is an application that can be run on all topside modems to provide synchronization with respect to a single underwater vehicle. pAcommScheduler expects the AUV to transmit updates with a constant period, which much be provided as a config variable, along with the AUV's modem ID. The scheduler will listen to incoming transmissions for those from the AUV, and average the last four receptions to determine the schedule. It will lockout the acomms driver to prevent transmission when receipts from the AUV are expected. The scheduler will also post its current state and estimates of the offset and duration of incoming receipts from the AUV. Other applications can use this offset by utilizing system time as provided by the JoshUtils library. *Configuration* * period - time in seconds of AUV's expected transmit period * source_ID - modem id of AUV * pre_lock - time before expected receive start when modem lockout will begin * post_lock - time after receive stop when modem lockout will end *Publications* * ACOMMS_SCHEDULER_OFFSET - the estimated offset of the receive start * ACOMMS_SCHEDULER_DURATION - the estimated duration of the receive * ACOMMS_SCHEDULER_STATE - current state: 0=unlocked, 1-3=locked (pre, mid, post), 4=unset (no observation) --- h2. pMarinePID_Hover A slightly modified version of the pMarinePID application included with MOOS-IvP. Differential control is properly implemented by the following equation: {code} Diff = (dTheta*Tau*OldDiff)/(Tau+dT) Differential portion of rudder output = Kd*Diff {code} |
The
...
integral
...
limit
...
is
...
applied
...
before
...
Ki.
...
Hence
...
max
...
integral
...
rudder
...
command
...
is
...
Ki*IntegralLimit.
...
Yaw
...
gains
...
and
...
limit
...
can
...
be
...
updated
...
after
...
the
...
fact
...
using
...
the
...
MOOS
...
variables:
...
YAW_PID_KP
...
YAW_PID_KD
...
YAW_PID_KI
...
YAW_PID_INTEGRAL_LIMIT