Attachment_0038_-_RAS-G_IOP_V2_-_Payloads_Profile.pdf

i

Robotics and Autonomous Systems – Ground (RAS-G) Interoperability Profile (IOP)

Payloads Profile Version 2.0

PM Force Projection (FP)

SFAE-CSS-FP MS 401

6501 East 11 Mile Road

Warren, MI 48397

February 2016

Distribution A: Approved for Public Release ii

Table of Contents 1 Scope

1.1 Purpose

1.2 Document Overview

1.3 Discussion of Technical Topics

1.3.1 Payload Classification

1.3.2 Compound and Complex Payloads

1.3.3 Control and Status Messages & JAUS Profiling

1.3.4 Custom Messages

1.3.5 Use of the Payloads Interoperability Profile

2 Source Documents

2.1 Government Documents

2.2 Non-Government Documents

3 Payload Architecture

4 Payload System Requirements

4.1 Common Payload Requirements

4.2 Control and Status Messaging Requirements

4.2.1 Payload Command, Control, and Status Messages

4.2.2 Payload Custom Messages

4.2.3 Transport

4.3 Physical Mounting Requirements

4.3.1 Picatinny Rail Option

4.3.2 Optical Bench Option

4.4 Electrical Power Requirements

4.4.1 NATO Slave Receptacle

4.5 Data Connection Requirements

4.5.1 Interoperability Connector Interface A

4.5.2 Interoperability Connector Interface B

4.5.3 AEODRS Interoperability Connector Interface

4.6 Payload Physical Specifications (Payload Model)

4.7 Centralized Self Collision Avoidance

5 Common Sensor Requirements

5.1 Electrical and Mechanical Interfaces

5.2 Protocols, Formats, and Measures

iii

6 Generalized Sensor Requirements

6.1 Situational Awareness Sensors

6.1.1 Drive and Motion Imagery

6.1.2 Still Imagery

6.1.3 Chemical, Biological, Radiological, Nuclear (CBRN) Sensor

6.1.4 Microphone

6.1.5 Range Finder

6.1.6 Thermal Sensor

6.1.7 Pan, Tilt, Zoom Camera

6.1.8 Ground Penetrating Radars (GPRs)

6.1.9 Force Sensor

6.1.10 Obstacle Reporting

7 Specialized Sensor Requirements

8 Common Emitter Requirements

8.1 Electrical and Mechanical Interfaces

8.2 Protocols, Formats, and Measures

9 Generalized Emitter Requirements

9.1 Lights

9.2 Speakers

10 Specialized Emitter Requirements

10.1 Debris Blower

11 Common Actuator Requirements

11.1 Electrical and Mechanical Interfaces

11.2 Protocols, Formats, and Measures

12 Generalized Actuator Requirements

12.1 Manipulator

12.1.1 Basic Manipulator

12.1.2 Basic Pan Tilt Manipulators

12.1.3 Telescoping Mast

13 Specialized Actuator Requirements

14 Interoperability Attributes

15 Conformance and Validation Requirements

16 Appendix A – Acronyms and Abbreviations

17 Appendix B – Planned Expansions iv

17.1 Picatinny Rail (MIL-STD-1913)

17.2 Optical Bench

17.3 Electrical Power

17.4 Interface A

17.5 Interfaces B & C

17.6 Additional Electrical Connectors

17.7 Common Sensor

17.7.1 Other

17.8 Generalized Sensor

17.8.1 Drive / Motion Imagery

17.8.2 Still Imagery

17.8.3 CBRN Sensor

17.8.4 Microphone

17.8.5 Range Finder

17.8.6 Thermal Sensor

17.8.7 Pan, Tilt, Zoom Camera

17.8.8 Ground Penetrating Radar (GPR)

17.9 Generalized Emitter

17.9.1 Lights

17.9.2 Speakers

17.10 Generalized Actuator

17.10.1 Basic Manipulator

17.10.2 Basic Pan Tilt Manipulator

17.10.3 Telescoping Mast

17.10.4 Advanced manipulator

17.10.5 Other Actuators

18 Appendix C – Further Tutorial of SAE AS-4 Messages for Payloads

18.1 Appendix – Function of JAUS Payloads Messages – Sensors

18.2 Appendix – Function of JAUS Payloads Messages – Emitters

18.3 Appendix – Function of JAUS Payloads Messages – Actuators

19. Appendix D – Preliminary Investigation for Weapons Control

19.1 Future Weapons Payloads

19.1.1 Direct fire ballistic weapons

19.1.2 Indirect fire ballistic weapons

v

19.1.3 Direct fire guided or course-correcting weapons

19.1.4 Indirect fire guided or course-correcting weapons

19.2 Interfaces for Standardization

19.3 Existing Standards

19.4 Safety Considerations

19.5 Less Than Lethal Weapons

1 Scope

1.1 Purpose

This document specifies interoperability concepts, architecture, and requirements associated with robotic system payloads. The capabilities addressed within this Interoperability Profile (IOP) relate primarily to payload interoperability with respect to payload operation, control, and status. Payload integration to the Unmanned Ground Vehicle (UGV) platform is addressed within this document and the RAS-G IOP Overarching Profile. To the degree possible, capabilities have been subset utilizing Interoperability Attributes to support the specification of payload system variations from simple payload systems to complex, integrated payload systems.

For the purpose of IOP Version 2 (V2), a limited number of payloads will be discussed – although the number of payloads has been expanded beyond V1. In future versions of this document, payloads and payload capabilities will be added as needed. In addition, this interoperability effort defines payloads as:

A robot payload is a physical device that interfaces to the robot using interoperable physical, power, and / or data interfaces, and is replaceable (modular) based on mission needs. A payload can be similar in nature to other devices that are integrated on a robotic vehicle, but a payload is not required for native UGV capabilities.

1.2 Document Overview

This document provides the base concepts, architecture, requirements, and overview for defining the required interoperability of payloads. As shown in Figure 1-1 below, this IOP is tightly coupled with the RAS-G IOP SAE JAUS Profiling Rules, and the RAS-G IOP Communications Profile.

Manipulator

Drive Camera

Sensor

- Video

- Data

- Power

Platform

JAUS IOP

C C

L

Communications IOP

Figure 1-1 Payload IOP Relationships

The block diagram in the figure depicts a UGV platform with several integrated payload components: a teleoperation/driving camera, a manipulator, and a sensor. For this example, the RAS-G IOP SAE JAUS Profiling Rules would specify payload status/control message as applicable, to payload operations. The RAS-G IOP Communications Profile would specify the communications transport to/from integrated payload devices. This IOP is dedicated to payload interoperability with respect to data formats, metadata, and payload unique functionality.

1.3 Discussion of Technical Topics

1.3.1 Payload Classification

Within the IOP Composability Taxonomy (defined within the RAS-G IOP Overarching Profile), the payload branch is partitioned into Sensors, Emitters, and Actuators (see Figure 1-2 below).

Sensors

Emitters

Actuators

Robotic System

Situational Awareness

Target Acquisition

Drive

Tactile/ Proprioceptive

Acoustic/Seismic

Meteorological

Other EM Vision Radar

Acoustic

EM

Light Aerosol

Jet Ballistic

Eject Launch

Manipulator Telescoping

Pan/Tilt End Effector

NBC

- AFUS Extension

- Not used in classification

Figure 1-2 IOP Payload Composability Taxonomy

For the purposes of this IOP, the following payload definitions, extracted from the SAE AIR5665A, Architecture Framework for Unmanned Systems (AFUS) have been applied:

Sensor – Sensors codify information from the environment and can be used to reason about the environment. Typical sensor types include, but are not limited to, tactile, proprioceptive, seismic, acoustic, meteorological, chemical, biological, radiological, nuclear, visual, and range finding. All sensors fall into two categories, either passive or active. Passive sensors perform their detection without effecting or altering the environment (i.e. thermometer). Active sensors use some form of emission to detect the reflection or other effect that emission has on the environment (i.e. radar).

Emitter – An emitter is a device that can discharge a substance, object, or energy into the environment. Examples include radio, RADAR, LASER, loudspeaker, liquid jet or disruptor or sprayer, ballistic weapons, and launchers for various self-propelled devices.

Most weapons fall into the class of emitters.

Actuator – An actuator is a mechanical device that can change shape in response to a signal. An actuator can be a simple device that has linear movement (prismatic) or Rotational movement (revolute) or it can be an articulated manipulator arm with many joints and links. The classic manipulator is an “arm” of a robotic system used to position an end-effector. Another common manipulator is a pan-tilt unit often used to position a directional sensor or emitter. At this time, all unpowered devices attached to a robot will also be classified as an actuator. (Examples include rakes, extensions, and bumpers.)

Within this IOP, payloads are organized in accordance with this taxonomy and also employ a loose class hierarchy, where interfaces and standards defined at upper levels are inherited, as applicable, and/or overridden in lower levels. A representation of this concept is depicted below in Figure 1-3.

Common Payload Requirements/Standards

Common Sensor, Emitter, and Actuator Requirements / StandardsSensors Emitters Actuators

Meteorological Sensors

NBC

Sensors

… Sensors

Acoustic Emitter

Illuminator Emitter

… Emitter

Manipulator Actuator

Telescoping Actuator

… Actuator

Generalized Sensor, Emitter, and Actuator Requirements / Standards (as required)

Payload

Specialized Sensor, Emitter, and Actuator Requirements / Standards (as required) may be added for very specific payloads

Figure 1-3 Payload Classification

As depicted in the figure, general interoperability standards and requirements applicable across the payload class are defined at the highest level (Section 4). These standards, unless stated otherwise, retain applicability as payloads are traversed through the lower levels of the classification. The Common Sensor (Section 5), Common Emitter (Section 8), and Common Actuator (Section 11) level define standards and requirements specialized to each individual branch. As with the payload level of the classification, these standards retain their applicability within each of the individual branches. The decomposition within the classification continues to Generalized sections (Sections 6, 9, and 12) which cover a subset of sensors, emitters, or actuators. The Specialized sections (Sections 7, 10, and 13) will cover unique payload products as necessary. This will allow the ability to extend and specialize the classification to support future revisions of this IOP, as required.

1.3.2 Compound and Complex Payloads

It is understood within the IOP that payloads can be compound or complex, and that certain payloads may span multiple categories. For example, a Reconnaissance, Surveillance, and Target Acquisition (RSTA) system could include multiple payloads, including multiple sensors, emitters, and possibly actuators. Typically a RSTA solution will provide a defined interface with the operator for configuration, control, imagery, target reports, etc vs. requiring the operator to address each component of the RSTA separately. A compound payload will include associated, physically integrated capabilities where each payload requires the other payloads to provide a useful capability. A complex payload will included associated but independent capabilities where each payload is independent, where each capability does not rely on other payloads. The RAS-G IOP SAE JAUS Profiling Rules document define other differences related to the logical structure differences.

Manipulator Arm

Sensor

Platform

Compound Payload

Figure 1-4 Compound Payload Example

Sensor

Computer

Emitter

Pan/Tilt Gimbal

Complex Payload

Platform

Sensor

Figure 1-5 Complex Payload Example

Figure 1-4 shows an example of a Compound Sensor. The manipulator arm has a sensor mounted on top. Without the sensor, the arm serves no purpose, and without the arm, the sensor cannot be positioned in a useful manor. Figure 1-5 shows an example of a Complex Payload. This example has an Emitter (such as a speaker), a sensor (such as a chemical sensor), and a Compound Sensor (such as a pan-tilt-zoom camera). Each payload can function without the aid of the other payloads. All the payloads are tied together with a processor.

1.3.3 Control and Status Messages & JAUS Profiling

To the degree possible, and in accordance with the RAS-G IOP Overarching Profile, this IOP uses the SAE AS-4 Joint Architecture for Unmanned Systems (JAUS) standards to define the control and status messages transmitted between an Operator Control Unit (OCU) and the UGV payloads, as well as among on-board UGV payload subsystems. The RAS-G IOP SAE JAUS Profiling Rules document provides guidance with respect to the profiling of the JAUS standard to define the manner in which JAUS messages are applied/interpreted as a means of limiting ambiguity and maximizing interoperability among disparate vendors.

As applicable, other standards are specified. For example, the Common CBRN Sensor Interface (CCSI) is called out for Chemical, Biological, Radiologic and Nuclear sensor interfaces.

1.3.4 Custom Messages

Similarly to the RAS-G IOP Overarching Profile, this IOP may require the specification of “custom” payload messages (documented within the RAS-G IOP Custom Services Messages and Transports) to provide mission capabilities scoped within the RAS-G IOP domain that are either not currently available in the SAE AS-4 JAUS standards or require SAE JAUS extension by the SAE AS-4 Committee. The specification and required usage of “custom” messages will be in accordance with the implementation requirements cited within the RAS-G IOP SAE JAUS Profiling Rules. The rules governing the development and usage of custom messages can be found in the RAS-G IOP Overarching Profile

1.3.5 Use of the Payloads Interoperability Profile

Robotic systems may include several payloads. Payloads are constantly being created or improved. It is suggested that each acquisition program carefully define what aspects of interoperability are required for each payload, and determine how many future capabilities may be needed in the “instantiation” of the Interoperability Profile for a particular program. The program manager may allow non-compliance to the IOP in certain cases, however steps should be taken to reduce non-compliance over time.

Each RAS-G program should determine what capabilities need to be integral to the robot. This integral capability would then be associated with the robotic platform, and may still be required to use interoperable messages as defined by the RAS-G IOP SAE JAUS Profiling Rules, but may not need to meet other payload interoperability requirements. In fact, a capability that is integrated into the platform is not classified as a payload. This is intended to allow a unique capability to be used on a system without complying with the payload interoperability profile, if that capability is integral to the platform and is determined by the program office to provide a non-modular capability.

The program should also determine how many additional, and possibly initially unused, interoperable payload interfaces to include. This would provide a path to adding unanticipated payloads to a robotic system later in the program. There are several strategies for implementing these requirements, which will be up to the program to decide on and implement.

The program may, at its discretion, incorporate the use of hardware and software adaptors, converters, or wrappers to allow a payload and a robotic platform to interoperate with each other. Allowable adaptations will be determined by the program, based on unique programmatic trade space and lifecycle plans.

2 Source Documents The following documents are referenced within this IOP and shall be used to implement the requirements contained within the IOP.

2.1 Government Documents

MIL-DTL-38999 L CONNECTORS, ELECTRICAL, CIRCULAR, MINIATURE, HIGH DENSITY,

QUICK DISCONNECT (BAYONET, THREADED, AND BREECH COUPLING),

ENVIRONMENT RESISTANT, REMOVABLE CRIMP AND HERMETIC

SOLDER CONTACTS, GENERAL SPECIFICATION FOR

MIL-DTL-55116 MILITARY SPECIFICATION: CONNECTORS: MINIATURE AUDIO, FIVE-PIN

AND SIX-PIN GENERAL SPECIFICATION FOR

MIL-STD-1913 DIMENSIONING OF ACCESSORY MOUNTING RAIL FOR SMALL ARMS

WEAPONS

MIL-STD-810 G Environmental Engineering Considerations and laboratory test

MIL-PRF-62122-E CABLE ASSEMBLY, INTER-VEHICLE

POWER: PLUG, RECEPTACLE, AND ADAPTER

MIL-HDBK-454B MILITARY HANDBOOK: GENERAL GUIDELINES FOR ELECTRONIC

EQUIPMENT

CCSI Version 1.1.1 Common Chemical, Biological, Radiological, Nuclear (CBRN) Sensor Interface

(CCSI) v1.1.1 RAS-G IOP SAE JAUS Profiling Rules RAS-G IOP Custom Services Messages and Transports RAS-G IOP Overarching Profile RAS-G IOP Communications Profile RAS-G IOP Applique Profile

2.2 Non-Government Documents

AIR5665A SAE Aerospace Information Report, Architecture Framework for Unmanned

Systems (AFUS), April 2009.

IEEE 802.3-2008 Standards for Ethernet based LANs AES42-2010 AES standard for acoustics – Digital interface for microphones RFC 2326 Network Working Group, Real-Time Streaming Protocol, 1998 RFC 3550 Network Working Group, RTP: A Transport Protocol for Real-Time Applications, STANAG 4074 NATO Slave Receptacle

3 Payload Architecture The RAS-G IOP reference architecture, defined in the UGV RAS-G Overarching IOP with respect to the UGV platform and its payload(s) is presented below in Figure 3-1.

- Integrated Component

- Interface

- Potential Interface

- Video

- Audio

- Data

Payload(s)

UGV

Platform Controller

P ow er

- Power

C C

L

Figure 3-1 Payload Reference Architecture

As stated in Section 1, the payload(s) themselves are treated by this IOP as black boxes in that the IOP does not specifically mandate internal standards, computing platforms, operating systems, or other integral components within the payload. Rather the IOP defines interoperability with respect to payload integration to onboard elements as well as payload integration, through the Common Communications Link (CCL), to external systems and controllers.

4 Payload System Requirements

4.1 Common Payload Requirements

This section identifies interoperability requirements with respect to standards and interfaces that are common across all payloads. Interoperability requirements specific to payloads are also defined in the sections detailing the common, generalized, and specialized sections of this document. Requirements listed in this section are inherited as applicable and/or overridden in lower levels, as seen in Figure 4-1. As an example, all “payloads” would inherit requirements in Section 4, all “sensors” would inherit requirements in Section 5, all “motion imagery cameras” would inherit requirements in Section 6, and “Camera Part Number XXX from Vendor Y” would inherit requirements from Section 7.

Section 4 Payload System Requirements

Section 5 Common

Sensor Requirements

Section 8 Common Emitter

Requirements

Section 11 Common Actuator

Requirements

Section 9 Generalized

Emitter Requirements

Section 6 Generalized

Sensor Requirements

Section 12 Generalized

Actuator Requirements

Section 7 Specialized

Sensor Requirements

Section 10 Specialized

Emitter Requirements

Section 13 Specialized

Actuator Requirements

Currently Used

Future Use

Figure 4-1 Layout of Payload Sections

4.2 Control and Status Messaging Requirements

SAE AS-4 JAUS messages provide the means for robotic controllers to connect to and control robotic systems, to include robotic system payloads. Conformant implementations of this IOP shall use the SAE AS-4 JAUS message set as specified within these IOP documents and in accordance with the specified profiling rules.

4.2.1 Payload Command, Control, and Status Messages

Payload command, control, and status messages specify the set of messages used to control a robotic system payload to perform a mission function(s). These messages support control of one or more integrated robotic system payloads. This section provides the interoperability messaging requirements relevant to controllers and robotic system payloads.

[V2.PAY 001] Unless specified otherwise, Payload command, control and status messages shall be implemented using the SAE AS-4 JAUS standards as profiled by the RAS-G IOP SAE JAUS Profiling Rules associated with any required (specified) Interoperability Attributes.

4.2.2 Payload Custom Messages

Payload custom messages, as described in section 1.3.4, provide a mechanism to specify necessary payload command, control, and status messages that have not been defined within the specified SAE AS-4 JAUS standards. For the RAS-G IOP, all custom messages approved for use are defined within the RAS-G IOP Custom Services Messages and Transports. Custom messages are controlled within the RAS-G IOP activity and it is the intent of the DoD to seek standardization of these private messages within the applicable SAE AS-4 JAUS committees following adoption within the RAS-G community.

The RAS-G IOP will specify the use of SAE AS-4 JAUS messages to achieve interoperability and only employ custom messages when no JAUS message will suffice.

[V2.PAY 002] Unless specified otherwise, Custom payload command, control and status messages shall be implemented in accordance with the RAS-G IOP Custom Services Messages and Transports.

4.2.3 Transport

Transport requirements and interoperability attributes are defined within the RAS-G IOP Overarching IOP. Payloads shall conform to the transport requirements at the vehicle level. This could be accomplished via direct communication between a controller/subsystem and a payload or via a translator that can interface to a payload via a native protocol and to a controller/subsystem via the vehicle specified JAUS transport.

[V2.PAY 003] Unless specified otherwise, the payload transport shall be identical to the vehicle transport in accordance with the Transport Interoperability Attribute, described in section 5.6.1.3 of the RAS-G IOP Overarching IOP.

4.3 Physical Mounting Requirements

The physical mounting requirements listed in this document describe which standards should be used. This does not ensure that a particular mounting will support a payload, provide stable mounting, or provide the proper vehicle dynamic characteristics. It is up to the designers to ensure that these characteristics are met, and would pass testing, in a particular implementation.

4.3.1 Picatinny Rail Option

Use MIL-STD-1913 as the standard for the mounting rail for payloads. The platform program will specify the length of the rail, and is dependent on the intended use of the rail. The program will specify the quantity of rails on a platform, dependent on the intended use of the rails. The program will specify the location of each rail, dependent on the intended use of the rail.

[V2.PAY 004] If the Picatinny Rail Interoperability Attribute is selected, the payload shall be capable of mounting to a rail in accordance to MIL-STD-1913.

4.3.2 Optical Bench Option

The optical bench option is defined as a series of threaded holes placed in a rectangular grid. The grid is 1” by 1” spacing. The threaded holes are 1/4"-20 UNC (Unified National Coarse). The program will specify the size of the grid, the material used, and the depth of the holes, based on the requirements of the vehicle program. This optical bench set up is not intended to provide the same vibration damping, stability, and stiffness as an actual optical bench – it only provides a standard hole and layout for attachment of payloads. The platform program will specify the type of bolt head, based on the drivers available. (I.E. – Socket head cap)

[V2.PAY 005] If the Optical Bench Interoperability Attribute is selected, the payload shall be capable of mounting to a plate that has 1” X 1” grid spacing, ¼-20 UNC threaded holes. Configuration, quantity, material characteristics, depth, and tolerances to be listed by the platform program.

4.4 Electrical Power Requirements

There will be several electrical power interfaces available for selection, and may be expanded in this IOP for payloads over time. Each robotic program will determine which power interfaces will be required. The purpose of specifying electrical power requirements is to limit the number of power standards that will exist in interoperability compliant standards. The ability of the platform to provide the necessary power and current, both steady state and peak, will need to be verified and is not inherently provided by the interoperability profile. It is reasonable to expect that a platform may meet a voltage requirement, but would be unable to support a current draw for an unexpected future payload capability, and thus may not be able to support the unexpected future payload capability.

Power Interface

Nominal Voltage

Minimum Voltage

Maximum Voltage

Maximum Power (Watts)

Maximum Current (Amps)

A 12 VDC 10 VDC 14 VDC 60 Watts 5 Amps B 24 VDC 20 VDC 28 VDC 120 Watts 5 Amps C 48 VDC 36 VDC 60 VDC 240 Watts 5 Amps

Table 4-1 Power Attributes

[V2.PAY 006] If a Power Interface Interoperability Attribute is selected, the power provided by the platform will meet the requirements listed for the power attribute selected, and the payload will accept the power listed in the power attribute that was selected.

System designers implementing Power Option C should refer to MIL-HDBK-454B for safety guidelines regarding high voltages, which begin to take effect at 30V.

4.4.1 NATO Slave Receptacle

Systems requiring the use of the North Atlantic Treaty Organisation (NATO) slave receptacle shall utilize connectors & cables that meet the specifications in MIL-PRF 62122-E and STANAG 4074.

4.5 Data Connection Requirements

Several data connections are currently used on robotic platforms in order to connect to payloads. It is anticipated that several data connections will continue to be used to support unique or proprietary payloads. This Payloads IOP defines standard data connections for use in interoperable payloads. Each robotic program will be able to select which connector interface(s) will be included. Payloads will be able to connect directly to the interoperability based connectors, or use an adaptor, converter, or wrapper (which may be only physical, or may include electronics and software).

The Data Connection Interoperability Attribute can be selected as None, Connector A, and/or Connector B. These values can be selected in any quantity required for the system. Some payloads, such as the CBRN sensors, may also have other connectors that can be specified; please see the individual payloads for these descriptions.

[V2.PAY 007] The data format will be compliant with IEEE 802.3-2008 (Gigabit Ethernet), as defined by RAS-G IOP Overarching Profile.

4.5.1 Interoperability Connector Interface A

The connector will meet MIL-DTL-38999L series II 13-pin 10-35 insert, with nominal rotation keyway. The platform side will consist of 22D size sockets in the receptacle.

The payload side will consist of 22D pins in the plug. Both sides will use 22 AWG wire to support a 5 amp current requirement. The power provided will be Power Attribute A or B. The pinout is listed in Table 4-2, and a notional diagram is show in Figure 4-2. The pinout was selected to be compatible with other interoperability efforts currently underway.

Pin # Signal PIN # Signal

1 GND 8 C+

2 A+ 9 B-

3 A- 10 B+

4 D+ 11 PWR

5 D- 12 PWR

6 GND 13 NA

7 C-

Table 4-2 Interoperability Connector “A” pinout

Figure 4-2 Interoperability Connector “A” Diagram

4.5.2 Interoperability Connector Interface B

The connector will meet MIL-DTL-38999L series II 22-pin 12-35 insert, with nominal rotation keyway. The platform side will consist of 22D size sockets in the receptacle.

The payload side will consist of 22D pins in the plug. Both sides will use 22 AWG wire to support a 5 amp current requirement. The power provided will be Power Attribute A or B. The pinout is listed in Table 4-3, and a notional diagram is show in Figure 4-3. The pinout was selected to be compatible with other interoperability efforts currently underway, and is different that Interoperability Connector Interface A in that there are more power lines available. Pins 4, 11, 16, and 20 are currently reserved for later use, and shall be left floating on both the platform and payload side. Reserved lines shall never be connected to ground or power.

Plug

- Pins

- Payload Side

- Nominal Key

Receptacle

- Sockets

- Platform Side

- Nominal Key

1 10

6 5

13 12

12 13

1 A- 13 B-

2 C+ 14 A+

3 C- 15 D-

4 Reserved 16 Reserved

5 PWR 17 GND

6 PWR 18 GND

7 PWR 19 GND

8 PWR 20 Reserved

9 PWR 21 D+

10 PWR 22 GND

11 Reserved

12 B+

Table 4-3 Interoperability Connector “B” pinout

Figure 4-3 Interoperability Connector “B” Diagram

[V2.PAY 008] If a Connector Interoperability Attribute is selected, the connector will meet the MIL-DTL-38999L Series II connector selected, with the keyway and pinout identified for the connector listed.

Plug

- Pins

- Payload Side

- Nominal Key

Receptacle

- Sockets

- Platform Side

- Nominal Key

7 8

8 7

4.5.3 AEODRS Interoperability Connector Interface

The Advanced Explosive Ordinance Disposal Robotic System (AEODRS) Interoperability Connector Interface shall be identical to Interoperability Connector Interface B except for a change in the pinout. The pinout is listed in table 4-4.

1 A- 13 B-

2 C+ 14 A+

3 C- 15 D-

4 CONFIG_D 16 CONFIG_C

5 PWR 17 GND

6 PWR 18 GND

7 PWR 19 GND

8 PWR 20 CONFIG_B

9 PWR 21 D+

10 PWR 22 GND

11 CONFIG_A

12 B+

Table 4-4 AEODRS Interoperability Connector Diagram

The pins CONFIG_A, CONFIG_B, CONFIG_C, and CONFIG_D represent a 4-bit configuration bus that is used to assign unique locations codes to a payload. There are 16 possible values. CONFIG_A represents the high order bit of a 4-bit location code value, and CONFIG_B represents the lowest order bit.

When this value is selected for a payload, the payload shall provide resistive pull-ups on the 4-bit configuration bus. When this value is selected for a platform, the platform shall either ground a configuration line to represent a 0 logical value, or leave the line floating to yield a logical value of 1. Figure 4-5 shows this setup. Note that the example in figure 4-5 is conceptual – an actual implementation will need to implement circuitry on both the payload and platform side to:

• Prevent payload internal voltage rails and logic pins from direct connector exposure

• Allow multiple payloads to share a single configuration bus ID

• Survive temporary exposure to the power rail

• Support multiple logic voltages

• Limit static power dissipation

R1

Vcc

Logic Reading Device

R1

Vcc

Logic Reading Device

Connected – Logic Level 0

Floating – Logic Level 1

Platform Platform

PayloadPayload

Figure 4-5 Configuration Line Logic Levels Simplified Example

Table 4-5 shows the 16 possible values that can be achieved using different configurations of the 4 configuration lines (LOW = line connected to platform ground, Not Connected = line is floating). These values can be used as location codes (uniquely identifying where a payload is plugged into on a platform) and can also support unique payload identification.

Location Code (hex)

CONFIG_A CONFIG_B CONFIG_C CONFIG_D

0x00 LOW LOW LOW LOW 0x01 LOW LOW LOW Not Connected 0x02 LOW LOW Not Connected LOW 0x03 LOW LOW Not Connected Not Connected 0x04 LOW Not Connected LOW LOW 0x05 LOW Not Connected LOW Not Connected 0x06 LOW Not Connected Not Connected LOW 0x07 LOW Not Connected Not Connected Not Connected 0x08 Not Connected LOW LOW LOW 0x09 Not Connected LOW LOW Not Connected 0x0A Not Connected LOW Not Connected LOW 0x0B Not Connected LOW Not Connected Not Connected 0x0C Not Connected Not Connected LOW LOW 0x0D Not Connected Not Connected LOW Not Connected 0x0E Not Connected Not Connected Not Connected LOW 0x0F Not Connected Not Connected Not Connected Not Connected

Table 4-5 Configuration Line Location Codes

4.6 Payload Physical Specifications (Payload Model)

When specified, payloads should be capable of reporting their physical specifications.

This data will be used by other subsystems in order to provide self-collision avoidance, center of gravity management, power management, or other smart functions.

IOP V2 provides a custom Physical Specifications JAUS service for use in payloads and platforms.

[V2.PAY 009 Payloads implementing payload physical specifications shall do so by using the custom Physical Specifications Service in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 5.12 Physical Specifications Attribute.

4.7 Centralized Self Collision Avoidance

When specified, systems should be capable of providing self-collision avoidance of payloads. This service will be to prevent on-board collisions in situations where there are multiple manipulator arms or moving payloads that could negatively interact with other physical dynamic subsystems.

IOP V2 provides custom services for use in these situations.

[V2.PAY 010 Payloads implementing centralized self collision avoidance shall do so by using the custom Self Collision Avoidance Policy Mapper Service and the Filter Mapping Service, in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Sections 9.3.23 and 9.3.24.

5 Common Sensor Requirements This section specifies common requirements associated with sensors in accordance with the IOP composability taxonomy. Common requirements are those requirements that are common to the sensor class.

5.1 Electrical and Mechanical Interfaces

As of this version of the IOP, there are no additional sensor specific electrical and mechanical interface requirements beyond the requirements specified in Section 4.

This section serves as a placeholder for future requirements and/or capabilities.

5.2 Protocols, Formats, and Measures

Protocols, Formats, and Measures characterize the outputs associated with sensor payloads. Interoperability requirements defined here provide for the ability to define a standardized interchange from a payload on a UGV to a controller or to an external system. Standards and requirements identified within this section are applicable to and inherited by other sensors defined in subsequent paragraphs.

6 Generalized Sensor Requirements This section specifies general requirements associated with sensors in accordance with the IOP composability taxonomy. General requirements are those requirements that are generic to a sensor subclass but not to all sensor subclasses; e.g., a situational awareness sensor. Sensors identified within this section inherit standards defined in the previous section (Common Sensor Requirements); however, common requirements may be refined or overridden within this section, as applicable. As of this version of the IOP, few sensor payloads have been defined; and for sake of clarity only applicable sections of the composability taxonomy have been included. Other sections of the taxonomy will be addressed, as applicable, in future revisions of this IOP.

6.1 Situational Awareness Sensors

6.1.1 Drive and Motion Imagery

6.1.1.1 Digital

A Digital Drive and Motion Imagery value may be selected within the Generalized Sensor Interoperability Attribute. IOP compliant digital motion imagery sensors must support H.264 or H.262 video standards.

IOP compliant digital motion imagery sensors may support either Real-Time Streaming Protocol (RTSP) based or JAUS based (AEODRS) streaming control protocols. RTSP is an “application-level protocol for control over the delivery of data with real-time properties” [RFC 2326] such as video and audio. Any digital motion imagery sensor using RTSP shall implement the following at a minimum:

• Implement the minimal server implementation items described in RFC 2326, Section D.2

• Implement RTP [RFC 3550] as a valid transport for video data

• Include the Server header

• Implement the DESCRIBE method

• Generate SDP session descriptions as defined in RFC 2326 Appendix C

If using the AEODRS method, control shall be done as specified in RAS-G IOP SAE JAUS Profiling Rules, section 5.4.1.4. The transport protocol for the AEODRS method is RTP [RFC 3550].

IOP provides a multitude of video resolutions capable to be used on the platform ranging from very small (sqcif) to very large (whuxga). In order to ensure basic interoperability between platform and controller, a standard resolution, bit rate, and frame rate must be implemented by IOP-compatible payloads. At a minimum, IOP-compatible payloads must support a basic 4:3 resolution of 640x480. If a platform only supports 16:9 resolutions exclusively or resolutions with a pixel count greater than 640x480, it shall be acceptable to squeeze, stretch, or crop a video in order to fit the requirement. Additionally, IOP-compliant payloads must be capable of streaming digital video of at least 10 frames per second at 200 kbps. Video formats beyond these requirements are discretionary.

Systems that provide H.264 encoded video may implement one or more optional “Presets”, which capture H.264 encoder parameter sets that are intended to be used under specific circumstances. The presets chosen may incorporate H.264 encoder parameters as applicable, which are not specified by the IOP and shall be defined by the payload manufacturer. Preset names and numerical designators shall be chosen from the following list:

Enum 0: LowLatency Enum 1: SlowComms Enum 2: PersistentStare Enum 3: DriveVision Enum 4: Manipulation Enum 5: BestQuality Enum 12-15: ProgramSpecific

If the Presets option is selected, preset names shall be reported in response to QueryH264VideoEncodingCapabilities or QueryH264VideoEncodingConfiguration messages.

Systems utilizing H.264 shall implement the Baseline Profile, as defined in ITU-T H.264 Infrastructure of Audiovisual Services – Coding of Moving Video Annex A, at a minimum. In addition, systems utilizing H.264 shall support H.264 level 3 or higher, as defined by ITU-T H.264 Infrastructure of Audiovisual Services – Coding of Moving Video Annex A.

Additional suggested profiles to be supported are the Main and High profile. It is recommended that high quality video sources support level 4.1 or higher.

Systems which support stereoscopic video, such as stereovision cameras, shall support the Stereo High Profile.

[V2.PAY 011] Payloads implementing the digital drive and motion imagery capability shall do so by implementing the digital video component in accordance with the definition and rules specified above and also in the RAS-G IOP SAE JAUS Profiling Rules, Section 4.5.1 Digital Video Interoperability Attribute. The payload shall use one or more of the following:

[V2.PAY 011a] The payload shall support H.264 video standards along with the above described requirements at a minimum.

[V2.PAY 011b] The payload shall support H.262 video standards along with the above described requirements at a minimum.

6.1.1.2 Analog

An Analog Drive and Motion Imagery value may be selected within the Generalized Sensor Interoperability Attribute. Interoperability compliant analog motion imagery sensors must support National Television System Committee (NTSC) video standards.

Analog cameras shall use the MIL-DTL-55116, 6 contact connector, with the pin out listed below. This may be in conjunction with platform based microphone which will be defined under the Speaker section. The MIL-DTL-55116, 6 contact connector has been selected to remain consistent with the analog microphone / speaker connector.

Analog_Video_In Protocol: NTSC Signal Type: Analog Single Ended

[V2.PAY 012 If the Analog Video Connector Interoperability Attribute is selected, the connector shall meet the MIL-DTL-55116, 6 contact connector selected, with the pinout identified. Audio_In and Audio_GND pins are not necessary, but are left as an option for integrated microphone / camera payloads. Payloads using a common Power_GND and Video_GND should tie these signals together internally. Platforms may choose to keep these signals isolated or tie them together, based on need.

Pin Signal Name

A Power_GND B Power_12V C Audio_In D Audio_GND E Video_In F Video_GND

6.1.2 Still Imagery

A Still Imagery value may be selected within the Generalized Sensor Interoperability Attribute. IOP compliant still imagery must support JPEG or JPEG2000 imagery standards for lossy compressed images, PNG for lossless compressed images, and BMP for uncompressed images.

IOP-compliant payloads must support a minimum 4:3 resolution of 640x480 (vga). If a platform only supports 16:9 resolutions exclusively or resolutions with a pixel count greater than 640x480, it shall be acceptable to squeeze, stretch, or crop an image in order to fit the requirement. Image formats beyond these requirements are discretionary.

[V2.PAY 013] Payloads implementing the still imagery capability shall do so by implementing the still image component in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 4.5.2 Still Image Interoperability Attribute, and will support JPEG or JPEG2000 image standards at a minimum.

6.1.3 Chemical, Biological, Radiological, Nuclear (CBRN) Sensor A CBRN value may be selected within the Generalized Sensor Interoperability Attribute.

The Common Chemical, Biological, Radiological, Nuclear (CBRN) Sensor Interface (CCSI) standard v1.1.1 shall be used for CBRN sensor interfaces. CCSI messaging and logical protocols shall be employed for IOP V2. The CCSI standard, along with its software verification tools, can be requested from JPEO CBD by emailing JPMIS_CM@jpmis.mil . The CCSI also specifies physical connections which may be called out for use. Otherwise, adapters may be used to interface the CBRN sensor to the platform.

[V2.PAY 014] Payloads implementing the CBRN sensor capability shall do so by implementing the Common CBRN Sensor Interface v1.1.1.

6.1.4 Microphone

A platform based Microphone value may be selected within the Generalized Sensor Interoperability Attribute. For IOP V2, audio data will be sent in digital format. If a Digital Microphone is used, the Audio Engineering Society (AES) 42-2010 standard will be used. Digital microphone physical interface has not been defined. Analog microphones will follow the standards below. Analog microphones will use the MIL-DTL-55116, 5 contact connector, with the pin outs listed below. This is in conjunction with platform based speakers which will be defined under the Speaker section. The MIL-DTL-55116, 5 contact connector has been selected to remain consistent with other robot standards development currently in development.

Audio_In Protocol: N/A Signal Type: Analog Single Ended Voltage Range (V): ‐2 to 2 mailto:JPMIS_CM@jpmis.mil

Current Range (mA): 0‐250

At a minimum, IOP-compliant microphones must support Vorbis compression at a sample rate of 11kHz, and a bitrate of at least 10 kbps. The use of additional codecs is discretionary.

IOP compliant audio may support either Real-Time Streaming Protocol (RTSP) based or JAUS based (AEODRS) streaming control protocols. RTSP is an “application-level protocol for control over the delivery of data with real-time properties” [RFC 2326] such as video and audio. Any audio sensor using RTSP shall implement the following at a minimum:

• Implement RTP [RFC 3550] as a valid transport for video data

• Include the Server header

JAUS Profiling Rules, section 5.4.5.2. The transport protocol for the AEODRS method is RTP [RFC 3550].

[V2.PAY 015] Payloads implementing the microphone capability shall do so by implementing the microphone component in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 4.5.6 Microphone Interoperability Attribute.

[V2.PAY 016] If the Microphone Connector Interoperability Attribute is selected, the connector will meet the MIL-DTL-55116, 5 contact connector selected, with the pinout identified. This will remain consistent with other Interoperability efforts. Audio_Out pins are not necessary for speaker, but are labeled for consistency with the Speaker Connector.

6.1.5 Range Finder

A Range Finder value may be selected within the Generalized Sensor Interoperability Attribute.

[V2.PAY 017] Payloads implementing the range finder sensor capability shall do so by implementing the range finder component in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 4.5.3 Range Finder Interoperability Attribute Option.

6.1.6 Thermal Sensor

A Thermal Sensor value may be selected within the Generalized Sensor Interoperability Attribute. Thermal sensors typically include video and image cameras that can detect radiation in the infrared range of the electromagnetic spectrum. Its most typical use is in sensing temperature variations in order to generate images. The data format will be in the same format as the previously described motion and still imagery data.

Generally, the resolution of a thermal sensor is lower than that of a standard RGB camera, and thusly, the resolution requirements of a thermal sensor image is also lower. For IOP compliance, a thermal sensor must be able to generate an image or video of at least 160x120 pixels (qqvga). Higher resolutions are discretionary. Video frames per second and bit rate will be defined in a future IOP release.

[V2.PAY 018] Payloads implementing the thermal sensor capability shall do so by implementing the appropriate imagery component in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules. The formats will be the same as those presented in 6.1.1 (for thermal motion imagery) and 6.1.2 (for thermal still imagery) in this document.

6.1.7 Pan, Tilt, Zoom Camera

The pan, tilt, zoom (PTZ) camera is a compound payload comprised of a digital video sensor and a pan/tilt gimbal.

The PTZ camera sensor shall be realized via a PTZ camera attribute defined within the RAS-G IOP SAE JAUS Profiling Rules, Section 4.5.5.

[V2.PAY 019] Payloads implementing the PTZ camera sensor capability shall do so by using the pan tilt video sensor attribute in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 4.5.5 Pan Tilt Video Sensor Interoperability Attribute.

6.1.8 Ground Penetrating Radars (GPRs)

There are no specialized IOP requirements for GPRs. Implementation of GPR functionality should be achieved using existing IOP support for Range Finder. It should be noted, however, that larger GPR units have considerable power draw. Consequently, the 12 and 24 volt busses provided in Power Attributes A or B may not be sufficient. In such cases, Power Attribute C should be considered.

[V2.PAY 020] Payloads implementing the Ground Penetrating Radar capability shall do so by implementing the range finder component in accordance with the definition and rules specified in RAS-G IOP SAE JAUS Profiling Rules, Section 4.5.3 Range Finder Interoperability Attribute.

6.1.9 Force Sensor

While the SAE JAUS Manipulator Service Set offers per-joint force/torque sensing, there is currently no JAUS end effector-based sensor for measuring forces/torques at the tool point. IOP V2 includes a new custom-service modeled after existing End Effector sensors. Furthermore, a generalized force-sensor suitable for mounting directly on the vehicle for bump/impact and/or vibration sensing is included.

Force sensing shall be realized at the tool point, or on any general system location by using the custom services defined in the RAS-G IOP SAE JAUS Profiling Rules document.

[V2.PAY 021] Payloads implementing force sensing at the tool point shall do so by using the custom Manipulator End Effector Force/Torque Sensor Service in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 9.23.26 Manipulator End Effector Force/Torque Sensor Interoperability Attribute.

[V2.PAY 022 Payloads implementing generalized force sensing for bump/impact and/or vibration sensing shall do so by using the custom Force Torque Sensor Service in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 9.1.16 Force Torque Sensor Interoperability Attribute.

6.1.10 Obstacle Reporting

The Obstacle Reporting Interoperability Attribute Option provides a method to report obstacles, hazardous terrain, and no-go zones using an overhead 2D cost map.

The Cost Map 2D Service provides a mechanism to report obstacles, hazardous terrain, and no-go zones using an overhead 2D cost map. The cost map is represented by a list of cells, broken into a specified number of rows and columns, which in turn corresponds to the width and height (respectively) of the map in meters. Each cell within the map specifies a cost value, and in some cases, a confidence value. The cost is a relative measure of occupancy or effort to traverse the cell, such that a value of zero (0) means no occupancy or no effort, while a maximum cost value means a cell is non-traversable. The center point of the cost map may be specified in global or local coordinates, depending on the particular implementation, as defined by [AS6009]. The map may also be rotated around the coordinate frame’s Z-axis by the specified yaw value.

Cells within the list must be sequenced such that the most northwest point, relative to the non-rotated coordinate frame, is the first element. Subsequent elements represent cells in an easterly direction, until the end of the row is reached. At that point, the next row starts again on the west side of the map. The following diagrams demonstrate the requirement list element indexing.

[V2.PAY 023 Payloadsor subsystems implementing obstacle reporting shall do so by using the custom Cost Map 2D Service in accordance with the definition and rules specified in the RAS-G IOP SAE JAUS Profiling Rules, Section 5.11 Obstacle Reporting.

7 Specialized Sensor Requirements This section specifies specialized requirements associated with sensors in accordance with the IOP composability taxonomy. Specialized requirements are those requirements that are unique to a specific sensor within or across a sensor subclass;

e.g., a specific type of sensor or manufactured item. Sensors identified within this section inherit standards defined in the previous section (Generalized Sensor Requirements); however, generalized requirements may be refined or overridden within this section, as applicable. As of this version of the IOP, there are no specialized sensor requirements. This section has been incorporated as a placeholder for future requirements.

8 Common Emitter Requirements This section specifies common requirements associated with emitters in accordance with the IOP composability taxonomy. Common requirements are those requirements that are common to the emitter class.

8.1 Electrical and Mechanical Interfaces

As of this version of the IOP, there are no additional Emitter specific…