You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

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

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
  • ACOMMS_STATS_SNR_OUT
  • ACOMMS_STATS_SNR_IN
  • ACOMMS_STATS_DQF
  • ACOMMS_STATS_STDDEV_NOISE
  • ACOMMS_STATS_MSE
  • ACOMMS_STATS_DOPPLER
  • ACOMMS_STATS_SPL
  • ACOMMS_STATS_PSK_ERROR_CODE

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

uPokeDBHex ACOMMS_TRANSMIT_DATA_BINARY="68:65:6c:6c:6f"

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_COMMAND - "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
  • THRUST_LIMIT
  • ARDUINO_THRUST
  • ARDUINO_RUDDER
  • RADIO_POWER - "freewave_unlocked", "bullet_unlocked", "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.

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

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:

Diff = (dTheta*Tau*OldDiff)/(Tau+dT)
Differential portion of rudder output = Kd*Diff

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

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.  

 

  • No labels