Page History

This page documents some of the key applications available in the Hovergroup svn.  

...

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

and pAcommsSimulator

Visit the Acomms Driver and Simulation page for information on these applications.

...

uPokeDBHex

Similar to the normal uPokeDB, but pokes binary strings instead of normal strings using a hex representation.

...

• DESIRED_THRUST
• DESIRED_RUDDER
• RADIO_POWER_COMMAND - "freewave" or "bullet"
• RUDDER_OFFSET - change rudder offset after launch

...

• VOLTAGE
• CPU_BOX_TEMP
• ROBOTEQ_HEATSINK_TEMP
• ROBOTEQ_INTERNAL_TEMP
• ROBOTEQ_BATTERY_CURRENT
• ROBOTEQ_MOTOR_CURRENT
• THRUST_LIMIT
• ARDUINO_THRUST
• ARDUINO_RUDDER
• RADIO_POWER - "freewave_unlocked", "bullet_unlocked", "freewave_locked", or "bullet_locked"

...

pScheduledTransmit

...

• period - time in seconds between transmissions
• offset - measured from midnight, offset in seconds of transmissions. Set different offsets on different vehicles to stagger transmissions.

Configuration can also be done at the command line using the --period and --offset options.  The application will not run if a period is not set at start, either at the command line or in the configuration file.

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

...

• 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:

...

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

New process config options are also available for the speed control.  First, the type of controller must be set using the SPEED_CONTROLLER config variable.  Options are "factor", "pid", and "fit_pid".  The first two are unchanged from the original speed factor and pid control methods.  The fit_pid option uses a linear fit to determine the rough thrust for a given speed request, while a PID is used to provide a correction on top of that fit.  The following additional config variables must be set:

SPEED_SLOPE
SPEED_OFFSET
ANGLE_LIMIT
TIME_DELAY

Slope and offset determine the linear fit according to the equation: 

Thrust = SPEED_SLOPE*speed + SPEED_OFFSET

The PID is only run when heading has been within ANGLE_LIMIT of the desired heading for at least TIME_DELAY seconds.  Even when the PID is not running, the last output of the PID will still be added to the thrust determined by the fit.  

...

pAckedComms(Shoreside/Vehicle)

The AckedComms application provides, as its name would imply, a way of sending acknowledged commands to vehicles from shoreside.  TCP is not reliable over a lossy wireless link, so AckedComms simply repeats messages until it receives an ack, up to a set number of retries.  It also simplifies shoreside configuration by reducing the number of pShare config lines required.  

Example shoreside config:

ProcessConfig = pAckedCommsShoreside
{
    IterateMode = 1    // comms driven iterate and mail
    AppTick     = 20   // iterate lower bound
    MaxAppTick  = 0    // no limit
    
    vehicles = NOSTROMO,SILVANA,KESTREL,ICARUS
    
    BRIDGE = var=MISSION_MODE,repeat=5,delay=0.5
    BRIDGE = var=MOOS_MANUAL_OVERRIDE,repeat=5,delay=0.5
    BRIDGE = var=GOTO_UPDATES,repeat=5,delay=0.5
    BRIDGE = var=SCHEDULED_TRANSMITS,repeat=5,delay=0.5
}

Each variable you wish to bridge uses its own config line.  Repeat and delay set the max number of retries and the delay between consecutive tries.  For each variable $VAR, the vehicle will subscribe to $VAR_ALL and $VAR_$VEHICLE for each defined vehicle name.  When sending a transmission, pAckedCommsShoreside will post to ACKEDCOMMS_TRANSMIT_$VEHICLE, so pShare should be configured to bridge it to the appropriate vehicle.  

The acknowledging app on the vehicles is pAckedCommsVehicle and requires no configuration.  It simply listens for incoming transmissions, parses them when received, and posts an acknowledgement to ACKEDCOMMS_RETURN_ACK.  This variable should be bridged back to shoreside on every vehicle.