Page History

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

iAcommsDriver 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.

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.