Nekton Submersible Secondary Controller moos interface



Yüklə 45.81 Kb.
tarix20.01.2018
ölçüsü45.81 Kb.

iRobot Maritime Systems Page of

Document No: 0000-30-08-001 Rev. PA-7 Customer Document

Author: M. Morris Date: 7/31/2008


iRobot Submersible Secondary Controller MOOS Interface


Date

Revision

Author

Changes

31 July 2008

PA-1

M. Morris

Original Document

7 Aug 2008

PA-2

M. Morris

Added SBIR data rights footer

10 Nov 2008

PA-3

M. Morris

Added Station Keeping field in SC_OBJ_ATTITUDE

29 Jan 2009

PA-4

M. Morris

Modified Station Keeping to add surge and sway modes

8 April 2010

PA-5

M. Morris

Changed SC_OBJ_DELAY DURATION_TYPE from DURATION to DUR to avoid parsing error

24 April 2010

PA-6

M. Morris

Removed unnecessary fields from SC_OBJ_HOVER

23 August 2010

PA-7

M. Morris

Updated SBIR data rights, and removed SC_RESUME

Table of Contents



3. SC MOOS Messages: 3

4. Comments: 8

5. MOOS References: 9



1. Purpose: This document describes how a payload process will interface with an iRobot submersible to perform a mission through the Mission Oriented Operating System (MOOS) running on the vehicle’s processor. Establishing a connection to the MOOS database will not be described here. This document will only describe what is to be sent to, and received from, the vehicle through the MOOS database for successful operation.
2. Overview: A payload process will communicate with the vehicle through the secondary controller (SC) interface which will be defined in this document. Commands will be issued as strings in the MOOS message format. The only message required to be sent from the SC is the heartbeat message. An SC_HEARTBEAT will be sent at a frequency of 1 Hz to let the vehicle know that the payload process is operational. If the vehicle operates for 3 seconds without receiving an SC_HEARTBEAT message from the payload process, the vehicle will abort to the surface. A mission can also be aborted by request. If the payload process enters an erroneous state, where it is no longer useful to continue the mission, it can issue an SC_ABORT message that will abort the mission. At 2 seconds after receiving the last SC_HEARTBEAT message, the vehicle will send the MOOS database an SC_ERROR message with the value “HEARTBEAT_WARNING”.

Before a payload process can take control of the vehicle the HELM_RUNNING variable in the MOOS database must have a value of TRUE. When a payload process wishes to take control of the vehicle it can send an SC_OBJ_<OBJECTIVE_TYPE> message to the MOOS database. The payload process can take control of the vehicle at any time whether the vehicle has a mission plan or not. When the vehicle receives an SC_OBJ_<OBJECTIVE_TYPE> message it will stop executing its current objective and immediately execute the requested objective from the payload process. Once it has completed that objective, the vehicle will send an SC_OBJECTIVE_COMPLETE message to the MOOS database. It is the responsibility of the payload process to register for the SC_OBJECTIVE_COMPLETE and SC_ERROR messages with the MOOSDB (MOOS database) during its initialization, after establishing connection with the MOOSDB, in order to receive them.

After an SC_OBJECTIVE_COMPLETE message is received from the vehicle, the payload process has 3 seconds to issue another SC_OBJ_<OBJECTIVE_TYPE> message or an SC_ABORT message. If the 3 seconds elapse without one of these messages, the vehicle will abort the mission.

The payload process does not have to wait for the SC_OBJECTIVE_COMPLETE message before sending another SC_OBJ_<OBJECTIVE_TYPE> message to the vehicle. If another SC_OBJ_<OBJECTIVE_TYPE> message is received by the vehicle before it is done executing the last SC_OBJ_<OBJECTIVE_TYPE>, the vehicle will throw away the old SC_OBJ_<OBJECTIVE_TYPE> and begin executing the new one. To ensure successful operation, the payload process should send messages to the MOOS database at no more than 4 Hz.

If an invalid message is sent to the vehicle, the vehicle will reply with an SC_ERROR message with the contents of the erroneous message in the value field of the message, and then abort the mission. All message fields and values will be treated as case insensitive, but the MOOS message names are case sensitive and must be in upper-case letters.

The message LOADED_OBJECTIVE will be sent to the MOOS database, by the vehicle, with the reference string (converted to upper case) of the objective currently being executed. This can be queried to find the current state of the vehicle. If the vehicle is in its Idle state, the value of the LOADED_OBJECTIVE message will be “IDLE”, or if it is in its Manual state, the value of the LOADED_OBJECTIVE message will be “MANUAL”.




3. SC MOOS Messages:


SC_OBJECTIVE_COMPLETE:

Description: The SC_OBJECTIVE_COMPLETE message will be sent from the vehicle to the MOOS database when a requested SC_OBJ_ message has been executed by the vehicle to completion. The REFERENCE field of the requested SC_OBJ_ will be included in the message.
Fields: REFERENCE
Format: Message Name: “SC_OBJECTIVE_COMPLETE”

Message Value: “REFERENCE=transit1”



SC_ERROR:

Description: The SC_ERROR message will be sent from the vehicle to the MOOS database when an invalid message has been sent to the vehicle, when 2 seconds has elapsed since the last SC_HEARTBEAT message was received, or when 3 seconds has elapsed since the last SC_HEARTBEAT message was received. The error returned will be HEARTBEAT_WARNING at 2 seconds after the last SC_HEARTBEAT message, HEARTBEAT_ABORT at 3 seconds after the last SC_HEARTBEAT message, or the contents of the last message from the payload process if its contents were invalid.
Fields: ERROR
Format: Message Name: “SC_ERROR”

Message Value: “ERROR=HEARTBEAT_WARNING”



SC_HEARTBEAT:

Description: The SC_HEARTBEAT message will be sent from the payload process to the MOOS database every second to let the vehicle know it is alive. If 3 seconds elapse without the vehicle receiving a heartbeat, the mission will be aborted.
Fields: Heartbeat Flag
Format: Message Name: “SC_HEARTBEAT”

Message Value: “HEARTBEAT”



SC_ABORT:

Description: The SC_ABORT message will be sent from the payload process to the MOOS database when it enters a state that should cause it to abort to the surface.
Fields: Abort Mission Flag
Format: Message Name: “SC_ABORT”

Message Value: “ABORT_MISSION”



SC_OBJ_ATTITUDE:

Description: The SC_OBJ_ATTITUDE message will be sent from the payload

process to the MOOS database when it wants to command the vehicle’s attitude and/or

pose for a specified amount of time.
Fields: REFERENCE, VEHICLE_MODE, HEADING_MODE, HEADING_VALUE, ROLL_MODE, ROLL_VALUE, PITCH_MODE, PITCH_VALUE, Z_MODE, Z_VALUE, Z_UNIT, SPEED_UNIT, U, V, W, DURATION
REFERENCE: A name to define this objective

VEHICLE_MODE: Defines the controller mode setting. This is directly passed through to the controller and therefore can be any string that has been defined for the vehicle under consideration. For example, Transphibian can operate in either a TRANSIT or a STATION_KEEPING mode. The STATION_KEEPING mode is used for maintaining depth and heading, with 0 pitch and 0 roll, while thrusting in the u (surge) and v (sway) vectors. In the future this mode will also support variable pitch and roll control.

HEADING_MODE: A descriptor for the HEADING_VALUE to instruct the controller whether to control the heading if set to ABS, yaw rate if set to RATE, and leave uncontrolled if set to OFF.

HEADING_VALUE: The value in degrees [0(north) – 360] to be passed to the heading controller for a HEADING_MODE of ABS, and in degrees/sec for a HEADING_MODE of RATE.

ROLL_MODE: A descriptor for the ROLL_VALUE to instruct the controller whether to control the roll if set to ABS, roll rate if set to RATE, and leave uncontrolled if set to OFF.

ROLL_VALUE: The value in degrees [-180 – 180] to be passed to the roll controller.

PITCH_MODE: A descriptor for the PITCH_VALUE to instruct the controller whether to control the pitch if set to ABS, pitch rate if set to RATE, and leave uncontrolled if set to OFF.

PITCH_VALUE: The value in degrees [-90– 90] to be passed to the pitch controller.

Z_MODE: The behavior used to achieve the position in the Z axis. CONSTANT_DEPTH will maintain the vehicle at a constant depth given as the Z_VALUE parameter. CONSTANT_ALTITUDE will maintain the vehicle at a constant altitude given as the Z_VALUE parameter. IDLE will disable the behavior.

Z_VALUE: The value to be passed to the Z controller.

Z_UNIT: METERS or FEET

SPEED_UNIT: Specifies the units of U,V, and W in MPS, KNOTS, FPS, or RPM

U: The desired forward speed (water referenced) of the vehicle.

V: The desired lateral speed (water referenced) of the vehicle taken positive to starboard.

W: The desired vertical speed (water referenced) of the vehicle taken positive down.

DURATION: The time in seconds to execute the objective before timing out. A setting of 0 is treated as infinite.


Format: Message Name: “SC_OBJ_ATTITUDE”

Message Value: “REFERENCE=attitude1,VEHICLE_MODE=TRANSIT,HEADING_MODE=ABS,HEADING_VALUE=110.1,ROLL_MODE=ABS,ROLL_VALUE=2.2,PITCH_MODE=ABS,PITCH_VALUE=3.3,Z_MODE=CONSTANT_DEPTH,Z_VALUE=3.6,Z_UNIT=METERS,SPEED_UNIT=RPM,U=2.6,V=0.0,W=0.0,DURATION=10.0”



SC_OBJ_DELAY:

Description: The SC_OBJ_DELAY message will be sent from the payload process to the MOOS database when it wants to command the vehicle to idle for a specified amount of time or until a set time is achieved.
Fields: REFERENCE, DELAY_TYPE, DURATION, TIMESTRING, MAX_DEPTH, MIN_ALTITUDE
REFERENCE: A name to define this objective

DELAY_TYPE: Specifies the exit criteria for the delay. DUR delays for a specified number of seconds. TIME delays until a specified time defined by the reported time of the master system clock.

DURATION: Time in seconds to delay if DUR DELAY_TYPE is selected.

TIMESTRING: Time of day to delay until if TIME DELAY_TYPE is selected.

MAX_DEPTH: The maximum depth in meters the vehicle can drop to before the delay objective is automatically ended.

MIN_ALTITUDE: The minimum altitude in meters the vehicle can be at before the delay objective is automatically ended.


Format: Message Name: “SC_OBJ_DELAY”

Message Value: “REFERENCE=delay1,DELAY_TYPE=DUR,DURATION=10.0,TIMESTRING=,MAX_DEPTH=100.0,MIN_ALTITUDE=1.1”



SC_OBJ_GPS_FIX:

Description: The SC_OBJ_GPS_FIX message will be sent from the payload process to the MOOS database when it wants to command the vehicle to return to the surface and get a GPS fix before proceeding.
Fields: REFERENCE, VEHICLE_MODE, GPS_FIX_MODE, HEADING, SEARCH_TIME, TIMEOUT, SPEED, SPEED_UNIT
REFERENCE: A name to define this objective

VEHICLE_MODE: Defines the controller mode setting. This is directly passed to the controller and therefore can be any string that has been defined for the vehicle under consideration. For example, Transphibian can operate in either a TRANSIT or STATION_KEEPING mode.

GPS_FIX_MODE: Defines the heading the vehicle will use as it transits to and at the surface. LAST heading uses the last heading. SPECIFIED uses the heading specified.

HEADING: The heading in degrees [0(north) – 360] to be used if GPS_FIX_MODE is set to SPECIFIED or if no heading is specified from the previous behavior.

SEARCH_TIME: The time in seconds allowed at the surface in motion without a fix. 0 is infinite.

TIMEOUT: The maximum time in seconds allowed at the surface without a fix before issuing an SC_OBJECTIVE_COMPLETE.

SPEED: The ground referenced speed of the vehicle to maintain.

SPEED_UNIT: The units that SPEED is defined in. Speed can be referenced in RPM, KNOTS, FPS, or MPS (meters per second).


Format: Message Name: “SC_OBJ_GPS_FIX”

Message Value: “REFERENCE=gps1,VEHICLE_MODE=TRANSIT,GPS_FIX_MODE=SPECIFIED,HEADING=90.0,SEARCH_TIME=25.5,TIMEOUT=25.0,SPEED=2.5,SPEED_UNIT=MPS”



SC_OBJ_HOVER:

Description: The SC_OBJ_HOVER message will be sent from the payload process to the MOOS database when it wants to command the vehicle to hover at a given depth.
Fields: REFERENCE, Z_VALUE, Z_UNIT, DURATION
REFERENCE: A name to define this objective

Z_VALUE: The Z_VALUE axis setpoints in meters defining the ZMODE behavior.

Z_UNIT: METERS or FEET

DURATION: The time in seconds to hover. A setting of 0 would result in an indefinite hover.


Format: Message Name: “SC_OBJ_HOVER”

Message Value: “REFERENCE=hover1,Z_VALUE=2.5,Z_UNIT=METERS,DURATION=100.0”



SC_OBJ_LOITER:

Description: The SC_OBJ_LOITER message will be sent from the payload process to the MOOS database when it wants to command the vehicle to loiter around a position in the XY plane at a specified depth or altitude. It is assumed that the vehicle is in the proximity of the position in the XY plane when the objective is instantiated.
Fields: REFERENCE, VEHICLE_MODE, POSITION_LAT, POSITION_LON, Z_MODE, Z_VALUE, Z_UNIT, MAX_DEPTH, MIN_ALTITUDE, LOITER_MODE, R1, R2, SPEED, SPEED_UNIT, DURATION
REFERENCE: A name to define this objective

VEHICLE_MODE: Defines the controller mode setting. This is directly passed to the controller and therefore can be any string that has been defined for the vehicle under consideration. For example, Transphibian can operate in either a TRANSIT or STATION_KEEPING mode.

POSITION_LAT: The latitude in decimal degrees specifying the position in the XY plane to transit to.

POSITION_LON: The longitude in decimal degrees specifying the position in the XY plane to transit to.

Z_MODE: The behavior used to achieve the position in the Z axis. CONSTANT_DEPTH will maintain the vehicle at a constant depth given as the Z_VALUE parameter. CONSTANT_ALTITUDE will maintain the vehicle at a constant altitude given as the Z_VALUE parameter.

Z_VALUE: The Z axis setpoints in meters defining the Z_MODE behavior.

Z_UNIT: METERS or FEET

MAX_DEPTH: The maximum depth in meters the vehicle is allowed to go.

MIN_ALTITUDE: The minimum altitude in meters the vehicle is allowed to go.

LOITER_MODE: The behavior used to hold position. ORBIT will maintain a circular path between R1 and R2 weighted towards R1 but allowing slippage due to current to R2. DRIFT will allow the vehicle to drift until R2 is exceeded and then the vehicle will power to within R1.

R1: Inner radius in meters

R2: Outer radius in meters

SPEED: The ground referenced speed of the vehicle to maintain.

SPEED_UNIT: The units that SPEED is defined in. Speed can be referenced in RPM, KNOTS, FPS, or MPS (meters per second).

DURATION: The time in seconds to loiter. A setting of 0 would result in an indefinite loiter.
Format: Message Name: “SC_OBJ_LOITER”

Message Value: “REFERENCE=loiter1,VEHICLE_MODE=TRANSIT,POSITION_LAT=42.3,POSITION_LON=9.8,Z_MODE=CONSTANT_DEPTH,Z_VALUE=2.3,Z_UNIT=METERS,MAX_DEPTH=100.0,MIN_ALTITUDE=2.1,LOITER_MODE=DRIFT,R1=5.0,R2=15.0,SPEED=2.5,SPEED_UNIT=MPS,DURATION=100.2”



SC_OBJ_TRANSIT:

Description: The SC_OBJ_TRANSIT message will be sent from the payload process to the MOOS database when it wants to command the vehicle to transit to a latitude and longitude in the xy plane and a depth or altitude in the z plane. It encapsulates the guidance methodologies used and the completion criteria to be applied.
Fields: REFERENCE, VEHICLE_MODE, PATH_TYPE, POSITION_LAT, POSITION_LON, Z_MODE, Z_AXIS_COUPLED, Z_VALUE, Z_UNIT, SPEED, SPEED_UNIT, EXIT_RADIUS, MAX_DEPTH, MIN_ALTITUDE, PORPOISE_TIME, DURATION
REFERENCE: A name to define this objective

VEHICLE_MODE: Defines the controller mode setting. This is directly passed to the controller and therefore can be any string that has been defined for the vehicle under consideration. For example, Transphibian can operate in either a TRANSIT or STATION_KEEPING mode.

PATH_TYPE: The method used to transit in the XY plane. LOS (line of sight) points the vehicle on a bearing from the current position to the intended position. TRACK_LINE, maintains the vehicle’s trajectory along a line from the previous position to the intended position. In the case that there is not a previous point, as in the first point in a list, the current position when the objective is instantiated is used as the beginning of the line.

POSITION_LAT: The latitude in decimal degrees specifying the position in the XY plane to transit to.

POSITION_LON: The longitude in decimal degrees specifying the position in the XY plane to transit to.

Z_MODE: The behavior used to achieve the position in the Z axis. CONSTANT_DEPTH will maintain the vehicle at a constant depth given as the Z_VALUE parameter. CONSTANT_ALTITUDE will maintain the vehicle at a constant altitude given as the Z_VALUE parameter.

Z_AXIS_COUPLED: A flag (0 or 1) to denote whether the path in the XY plane and the path in the Z axis are coupled, as in a landing at a specified point behavior.

Z_VALUE: The Z axis setpoint in meters defining the ZMODE behavior.

Z_UNIT: METERS or FEET

SPEED: The ground referenced speed of the vehicle to maintain.

SPEED_UNIT: The units that SPEED is defined in. Speed can be referenced in RPM, KNOTS, FPS, or MPS (meters per second).

EXIT_RADIUS: The radius in meters of the intended XY position defining successful completion of the objective.

MAX_DEPTH: The maximum depth in meters the vehicle is allowed to go.

MIN_ALTITUDE: The minimum altitude in meters the vehicle is allowed to go.

PORPOISE_TIME: The time the vehicle is allowed to be sub-surface before returning to the surface for a GPS fix. A value of 0 will allow the vehicle to remain at depth indefinitely.

DURATION: The time in seconds to execute the objective before timing out. A setting of 0 is treated as infinite.


Format: Message Name: “SC_OBJ_TRANSIT”

Message Value: “REFERENCE=transit1,VEHICLE_MODE=TRANSIT,PATH_TYPE=LOS,POSITION_LAT=42.5,POSITION_LON=9.5,Z_MODE=CONSTANT_DEPTH,Z_AXIS_COUPLED=0,Z_VALUE=2.0,Z_UNIT=METERS,SPEED=2.5,SPEED_UNIT=MPS,EXIT_RADIUS=5.0,MAX_DEPTH=20.2,MIN_ALTITUDE=2.0,PORPOISE_TIME=20.5,DURATION=100.5”




4. Comments:



5. MOOS References:


Main Oxford Moos Web Page

Getting Started with MOOS (pdf file)

Introduction to Programming With MOOS (pdf file)

MOOS Tasks Web Page

Moos Contributors


Small Business Innovation Research (SBIR) Program Data Rights

Contract # N00014-08-C-0020, N00024-07-C-4108, N00014-02-M-0209, and N00014-05-C-0277

Contractor Name: iRobot Corporation

Address: 4625 Industry Lane, Durham NC 27713

Expiration of SBIR Data Rights Period: November 30, 2015

The Government’s rights to use, modify, reproduce, release, perform, display, or disclose technical data or computer software marked with this legend are restricted during the period show as provided in paragraph (b) (4) of the Rights in Noncommercial Technical Data and Computer Software – Small Business Innovation Research (SBIR) Program clause contained in the above identified contract. No restrictions apply after the expiration date shown above. Any reproduction of technical data, computer software, or portions thereof marked with this legend must also reproduce the markings.





Dostları ilə paylaş:


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2017
rəhbərliyinə müraciət

    Ana səhifə