project quality handbook - r5-cop · 2.1.3 radio ..... ..... ..... ..... 12 2.1.4 sensors ......

R5-COP_D 12.12.doc © R5-COP consortium of 19

Grant agreement no. 621447 Project acronym R5-COP Project full title Reconfigurable ROS-based Resilient Reasoning Robotic

Cooperating Systems

Dissemination level CO

Date of Delivery 22.02.2016

Deliverable Number D12.12v1.0

Deliverable Name Hardware interface specification (final)

AL / Task related 12.1

Author Baruch Altman (TTS)

Contributors Baruch Altman (TTS), Mateusz Maciaś (PIAP), Jesús Alonso

(TTS)

Keywords Robot hardware interfaces

Abstract This report presents the current state of the art for robotic

hardware interfaces of major components of relevant robots.

This report shall then enable the consortium members to sync

around these interfaces for any integration needed later.

R5-COP defines and creates a common model for its members

to build the robotic platforms. For that to happen, common in-

terfaces must be used. The intention is to review the potentially

applicable interfaces existing in the market, and later to focus

and specify interfaces that are acceptable to the consortium

members.


Document History

Ver. Date Changes Author

0.1 20/11/2014 Initial descriptions of security robot

interfaces

Mateusz Maciaś (PIAP)

0.2 21/11/2014 Some pictures added Mateusz Maciaś (PIAP)

0.3 24/11/2014 Review, added sensors section, few

inputs on comm and doc opening etc

Baruch Altman (TTS)

0.4 27/11/2014 Review, minor cleanups Mateusz Maciaś (PIAP)

0.5 27/11/2014 Review, release for public review Baruch Altman (TTS)

0.6 7/12/2014 Modifications after ALT review (Heico) Baruch Altman (TTS)

1.0 9/12/2014 End of first version (D12.11) Baruch Altman (TTS)

0.9 9/02/2016 Upgraded version (D12.12) Jesús Alonso (TTS)

1.0 19/02/2016 Reviewed final version (D12.12) Mateusz Maciaś (PIAP)

Note: Filename should be “R5-COP_D##_#.doc”, e.g. „R5-COP_D91.1_v0.1_TUBS.doc“

Fields are defined as follow 1. Deliverable number *.* 2. Revision number: draft version v approved a version sequence (two digits) *.* 3. Company identification (Partner acronym) *


Content

1 Introduction ................................................................................................................. 5 1.1 Summary (abstract)............................................................................................... 5 1.2 Purpose of the document and synchronization with other tasks ............................... 5

2 Security robots ............................................................................................................ 6 2.1 Interfaces in current security robots ....................................................................... 6

2.1.1 Mechanical ..................................................................................................... 6 2.1.2 Electrical ...................................................................................................... 10 2.1.3 Radio ........................................................................................................... 12 2.1.4 Sensors ........................................................................................................ 13

2.2 Interfaces standards in development for security robots ........................................ 15 2.2.1 Unmanned Ground Vehicles Interoperability Profile (UGV IOP) ...................... 15 2.2.2 Advanced Explosive Ordnance Disposal Robotic System (AEODRS) ............. 17

3 Conclusions .............................................................................................................. 18 4 References ............................................................................................................... 19

Figures

Figure 1 Mechanical dimensions of NATO accessory rail. ................................................... 7 Figure 2 Picture of NATO accessory rail. ............................................................................ 7 Figure 3 Picture of mechanical fixture mating with NATO accessory rail............................... 7 Figure 4 PIAP Gryf chasis with NATO accessory rails visible on sides ................................. 8 Figure 5 Gryf chassis with manipulator mounted on NATO accessory rails .......................... 8 Figure 6 Mk3 Calibre robot from Icor Technology, with some rails on chassis. ..................... 9 Figure 7 Telemax robot from Cobham ................................................................................ 9 Figure 8 Logistics & maintenance robots using Schunk gripping systems (from [29]) ............ 9 Figure 9 Close-up on connectors on PIAP Gryf. ................................................................ 10 Figure 10 PIAP Ibis robot with disruptor payload. .............................................................. 11 Figure 11 Video streaming delivery using wireless channels bonding ................................ 13 Figure 12 Common communication link systems block architecture from [5] ...................... 15 Figure 12 Payload relationship with IOP, from [6] .............................................................. 15 Figure 14 Compound payload example, from [6] ............................................................... 16 Figure 15 Payload reference architecture, from [6] ............................................................ 16


List of Acronyms

AEODRS Advanced Explosive Ordinance Disposal Robotic System EOD Explosive Ordinance Disposal HDMI High Definitiion Multimedia Interface IOP Interoperability Profile ISO International Organization for Standardization ISR Intelligence, Surveillance and Reconnaissance JAUS Joint Architecture for Unmanned Systems PoE Power Over Ethernet SCART Syndicat des Constructeurs d'Appareils Radiorécepteurs et Téléviseurs SDI Serial Digital Interface UGV Unmanned Ground Vehicle VGA Video Graphics Array


1 Introduction This is deliverable D12.12, “Hardware Interfaces Specification, final”, developed in R5-COP WP12. This document is an actualization of deliverable D12.11 in which the contributing partners have updated the information concerning hardware interfaces based on the experi-ence acquired in R5-COP research during the last year.

1.1 Summary (abstract) R5-COP defines and creates a common model for its members to build the robotic platforms. For that to happen, common interfaces must be used. The intention is to review the potential-ly applicable interfaces existing in the market, and later to focus and specify interfaces that are acceptable to the consortium members in this standard-less industry. For this analysis, security robots are taken as the typical example relevant for the R5-COP. This is because such robots have rich and varied functionality and are at the R5-COP core. It is out of scope for this document to review all sorts of robots with their multiple interfaces, especially as it shall be shown that this is a non-standard compliant industry in general. The hardware interfaces covered are mechanical and electronics.

1.2 Purpose of the document and synchronization with other tasks This report presents the current state of the art for robotic hardware interfaces of major com-ponents of relevant robots. This report has allowed the consortium members to sync around these interfaces for any integration needed later. As part of this sync work, the results of the research done in WP12 have been compared with the results of Task 23.1 ‘Actuation and manipulation’. It’s relevant to note that the partners working in WP12 have drawn similar conclusions to those of partners working in WP23. With regards to hardware interfaces, the partners have observed that, in daily scenarios, the usage of application-specific standard hardware interfaces is rather rare. Instead of that, using de facto industry standards provided by vendors makes integration effort easier.


2 Security robots There are many ground security robots in operation around the world, with most recognizable role as EOD, but not only. Such robots are used by various law enforcement agencies or military. There is no widely used single standard for interfaces and most manufactures use their pro-prietary solutions. Most of those systems consist of robot and operator console paired to-gether, with limited extensibility. But need for modular systems is now being seen both by operators of robotic systems and their manufacturer. There are standards for ISR and unmanned aerial vehicles [16], and there are set of JAUS standards [17]. Those standards are in fact competing with each other, but there is effort mostly driven by United States military to enforce common set of rules for unmanned ground vehicles in sort of standard called UGV Interoperability Profile [18]. There is not much available information on interfaces used by various robot manufacturers, but from what could be gathered those interfaces mostly originate from automotive or indus-trial standards.

2.1 Interfaces in current security robots In this chapter some example standards for mechanical interfaces used currently in security robots will be described, both mechanical and electrical.

2.1.1 Mechanical

2.1.1.1 NATO accessory rail Standard called NATO accessory rail1 was originally developed for accessories mounted on small arms [13]. 1 NATO accessory rail is sometimes called picatiny rail. This is a little confusing since picatiny rail was defined STANAG 2324 or MIL-STD 1913 and NATO accessory rail was defined in STANAG 4694. NATO accessory rail is backward compatible with picatiny, and those names are sometime used interchangeably.


Figure 1 Mechanical dimensions of NATO accessory rail.

Figure 2 Picture of NATO accessory rail.

NATO accessory rail I defined as dimensions of simple rail (as shown on Figure 1 and Figure 2) that accessories can mount to, with various fixtures (such as shown on Figure 3).

Figure 3 Picture of mechanical fixture mating with NATO accessory rail.


This standard was adopted with some modern security such as PIAP Gryf that has two rails, as can be seen on Figure 4 and Figure 5. Those rails can be used to mount manipulator or some other payload.

Figure 4 PIAP Gryf chasis with NATO accessory rails visible on sides

Figure 5 Gryf chassis with manipulator mounted on NATO accessory rails

2.1.1.2 Other Some examples of other mechanical interfaces are shown on Figure 6, Figure 7 and Figure 8. Figure 6 shows a robot with some rail along its chassis, seemingly using standard alumini-um profiles readily available on the market, or close to that. Figure 7 shows a Telemax robot that has a special plate behind its manipulator for carrying additional equipment. Figure 8 shows Schunk grips and non-security robots using them (logistics and maintenance).


Figure 6 Mk3 Calibre robot from Icor Technology, with some rails on chassis.

Figure 7 Telemax robot from Cobham

Figure 8 Logistics & maintenance robots using Schunk gripping systems (from [29])


2.1.2 Electrical

2.1.2.1 Power Power may be provided by the Robot power supply system. There is no standard here either. The current implementations use batteries that supply a range of 12VDC to 36VDC, and sometimes outside this range. In other cases the robot provides a regulated stabilized power, usually at 12VDC or 24VDC. Again, in some implementations this may vary. Further, the supported power consumption (Ampere, Watt, W/h etc), stability and power con-sumption protection mechanisms (such as surge protection) are not standardised at all. The power connectors are also non standard. A new standard being developed for security robots called UGV IOP (2.2.1 unterhalb) ad-dresses power standardization in a weak way.

2.1.2.2 Connectors There is no common connector or pin layout used, but most of manufacturers use some con-nector from MIL-DTL-38999 standard, from manufacturers like Souriau[19].

Figure 9 Close-up on connectors on PIAP Gryf.

Example connector can be seen on Figure 9, and provides a high level of robustness and proper environmental and electromagnetic protection. Various pins can be used with dose connectors providing for example high current capability, or shielded coaxial. Connectors come with various sizes and can have various keys2, so system can be config-ured in way disallowing wrong connections. 2 Connector can mate only with plug with the same setting. Same type of connector can be procured with multiple (often five) different keys.


2.1.2.3 Protocols

2.1.2.3.1 On/Off Basic payload for EOD robot is a pyrotechnic disruptor. Those payloads are usually con-trolled by simple pair of wires providing proper voltage and current to fire the disruptor. Some typical example is the PIAP Ibis robot seen on Figure 10, we can see just two wires connect-ing robot and its payload. What can also be noted that mechanical interface in this case is proprietary, with a mechanical adapter attached to the robot arm for holding the device itself.

Figure 10 PIAP Ibis robot with disruptor payload.

2.1.2.3.2 CAN Controller Area Network (CAN or CAN-bus) is a vehicle bus standard designed to allow mi-crocontrollers and devices to communicate with each other within a vehicle without a host computer. The standard was originally developed by Bosch and released by the Society of Automotive Engineers [24]. It is standardized as ISO-11898. [23]. CAN is a message based protocol, designed specifically for automotive applications but now also used in other areas such as industrial automation and medical equipment. CAN is a multi-master broadcast serial bus standard for connecting electronic control units (ECUs). This is very robust protocol, using twisted pair differential signalling, and some safety fea-tures embedded into protocol higher layer. There are some high level communication protocols based on CAN, such as CANOpen or J1939.

2.1.2.3.3 LIN The LIN-Bus (Local Interconnect Network) is a vehicle bus standard or computer networking bus-system used within current automotive network architectures. The LIN bus is a small and slow network system that is used as a cheap sub-network of a CAN bus to integrate intelligent sensor devices or actuators in today’s cars. Recently LIN may be used also over the vehicle's battery power-line with a special DC-LIN transceiver. This standard was developed by LIN Steering Group and is being transcribed to ISO stand-ard ISO 17987 (1 to 7) [25].


2.1.2.3.4 FlexRay The FlexRay communications bus is a deterministic, fault-tolerant and high-speed bus sys-tem developed in conjunction with automobile manufacturers and leading suppliers. FlexRay delivers the error tolerance and time-determinism performance requirements for x-by-wire applications (i.e. drive-by-wire, steer-by-wire, brake-by-wire, etc.). Many aspects of FlexRay are designed to keep costs down while delivering top performance in a rugged environment. FlexRay uses unshielded twisted pair cabling to connect nodes together. Flex ray is standardized as ISO 17458 (1 to 5) [26].

2.1.2.3.5 IEEE 802.3 based (Ethernet) Computer standard for local are (LAN) networks. There are many variants, with most com-mon using some numbers of twisted pair electric wires with differential signalling. Historically not used in embedded environment because of its complexity (it was used rather to communicate between computers than microcontrollers), it is currently considered as one of possible standards for interfaces for ground robots. There are many higher level protocols defined on top of IEEE 802.3, providing higher layers description.

2.1.2.3.6 EtherCat (IEC 61158) Wikipedia [30]: EtherCat is an open high performance Ethernet-based fieldbus system, invented by Beckhoff Automation. The protocol is standardized in IEC 61158 and is suitable for both hard and soft real-time requirements in automation technology. It includes several mechanisms that make its performance appealing to robots implementations: “process on the fly” which means delivering messages first and then processing them if relevant to the node, better synchronization, topology flexibility, includes safety protocols, and several device profiles (master, slave, servo drive and more) This standard is gaining traction with recent robots vendors as it addresses a major problem of Ethernet protocol: ensuring “real-time”, minimally buffered delivery of the automation control func-tions. This open standard is developed in the industry group [31].

2.1.2.3.7 RS485 Standard for multipoint (but not multi-master) communication using twisted pair of wires.

2.1.3 Radio Normally communication is not standardized in ground security robots. Therefore most man-ufacturers use proprietary solutions. What often can be determined is that robots use two frequencies, one for telemetry (two way channel), the second, being high bandwidth, for video (from robot to operators console only). There is no standard in designating and allocating spectrum for security robots, and there is no international conclusion on whether such spectrum band will be provided. For example in Poland current idea is that ground unmanned systems should share band with unmanned aerial vehicles. Also, there is no standard for the air interface and associated protocols to be used on any such allocated (or public) spectrum. These observations are true both for short range communications between robot and opera-tor, as well as for long-range communications, or backhaul, from robot or operator to remote monitoring headquarters or similar. It is worth noting that communications is also a matter to jam, since, for example with IED, some of them are remote-activated using cell phones or other RF controls.

http://en.wikipedia.org/wiki/Fieldbus

http://en.wikipedia.org/wiki/Beckhoff

http://en.wikipedia.org/wiki/IEC_61158


A novel method for communication from remote involves using (a) commercial networks and (b) bonding – using multiple networks/modems combined together. The goal with such a method is to provide a reliable, high-quality broadband remote commu-nication, especially for remote monitoring of what the robot visual sensor see (video camera), and sometimes for all the sensors (data). The operator still controls the robot locally. Encod-ing the video in conjunction with the wireless performance has the advantage over executing these functions separately. The advantage is in being able to encode the video according to the real time available “goodput”, hence resulting in high and stable quality video on the re-ceiving side. The interfaces to such bonding systems are:

• Video feed from a camera, discussed separately below • Communication modems/modules such as 1 or more LTE modems, or 3G modems,

or satellite modem etc • Power, as specified by vendor

The following picture shows a scenario in which several radio channels based on different wireless technologies are bonded in order to provide a reliable wireless link with sufficient uplink capacity for the video streamed from security robots.

Figure 11 Video streaming delivery using wireless channels bonding

2.1.4 Sensors Sensors are an essential part of the robotic system. There are numerous vendors of sensors. There are many types of sensors, both according to their functionality and according to their specific implementation. For each type of sensor (e.g. visual – camera, audible- microphone, etc), there may be sev-eral de-facto standards or applicable practices. Sensors hardware interfaces may include: mechanical, power, monitoring and control (electronics, connectors, protocols). In view of this magnitude, diversity and non-standardization of the sensors, this document is satisfied in bringing up the topic so to ensure being addressed by the other relevant groups (such as integration), and shall not elaborate further in this matter.


However, it’s worth to summarize as illustrative example what happens with regards to video cameras. There are hundreds camera vendors in the market and a large diversity of camera types. Robot vendors usually prefer to choose video interfaces that offer a larger amount of potential cameras to be installed on board. Cameras with digital interfaces like SDI [32], HDMI [33] and even older analog ones like VGA [34] and SCART [35] are very common. Therefore, robot vendors include typically such type of interfaces unless the applications that they want to target require specific types of camera and interface.


2.2 Interfaces standards in development for security robots Currently in United States there are two main efforts standardizing security robot interfaces running in parallel. UGV IOP – Unmanned Ground Vehicles Interoperability Profile (currently v1) AEODRS – Advanced Explosive Ordinance Disposal Robotic Those are cooperating efforts, where IOP is more oriented on creating documents describing interoperability standards for usage in robotics, and AEODRS is more concentrated on build-ing actual robots.

2.2.1 Unmanned Ground Vehicles Interoperability Profile (UGV IOP) Standard developed by The Robotic Systems Joint Project Office, for future robots acquisi-tion by various United States agencies and military forces [27][28]. The main communications requirements involve two distinct data streams:

• bidirectional telemetry • single direction (from UGV) video streams.

Radio used for communicating with the UGV varies from platform to platform. Radios can be single-channel or multi-channel (using more frequencies, with multiple radios). In most sys-tems those are COTS, point to point solutions. Tethered operation is also possible. Common Communication Link (CCL) is defined by box-ing proprietary radio, and stating that it should have Ethernet interface on both sides, but IOP itself don’t care about frequency or waveform at this moment [5].

Figure 12 Common communication link systems block architecture from [5]

Communication with payloads and optional systems is defined. In various configuration. Main data connection is Ethernet, with JAUS based communication protocol.

Figure 13 Payload relationship with IOP, from [6]


Figure 14 Compound payload example, from [6]

Figure 15 Payload reference architecture, from [6]

As for mechanical interface IOP does not provide standard interface, but options: • Picatiny rail option, as described in [9] and [13]. • Optical bench option - rectangular grid of threaded holes with 1in x 1in spacing. Holes

are 1/4in-20UNC.


The electrical interface is specified weakly in IOP: on one side it states that there are two possible interfaces:

• A – with 12V DC and 5A • B – with 24V DC and 5A

On the other it states that it is reasonable for platform to meet voltage requirements but may be unable to support current requirements. Connectors are from MIL-DTL-38999L series. IOP specifies three different types (A, B, and AEODRS interoperability connector). Special interfaces are specified for CBRN sensor, microphone and speaker. [14]

2.2.2 Advanced Explosive Ordnance Disposal Robotic System (AEODRS) Advanced Explosive Ordinance Disposal Robotic System is a US Navy acquisition program developing open modular robotic system. The AEODRS Common Architecture defines a physical layer for the connection of the com-ponents s to the power bus and to the communications bus. Additionally, the physical layer defines the mechanical mounting of the components to the base platform or other CMs where required. Because of the environmental requirements and availability of military standards as well as a precedent set forth in the UGV and other related fields, MIL-STD-38999-series connectors were selected. These connectors are used for both the power and communication buses. The mechanical mounting of components to the host platform or to other components is specified through the use of a mechanical breadboard approach. The breadboard approach uses a 1 × 1 in. grid array of threaded holes for 1/4 in.-20 hardware. By sizing the requisite grid on a CM basis for the worst-case torque/force loading, a reliable and simple interface is achieved. [15]


3 Conclusions This report reviewed the most common hardware interfaces available today in security ro-bots. No single standard to any of the interfaces, mechanical or electrical, exists. Work is being done in several industry groups in parallel on future potential interfaces to some of these functions. But interoperability is commonly achieved nowadays via the utilization of de-facto standards. Only in exceptional occasions, when there’s a clear need for something dif-ferent, vendors decide to bet on new type of hardware interfaces that allows them to target specific applications. Our conclusions are therefore pretty similar to those extracted from the work done in Task 23.1.


4 References [1] IOP V1 Capabilities Plan March 2012 [2] MIL-C-62122(B) [3] STANAG 4074 [4] SN-215 [5] IOP V1 Communications profile [6] IOP V1 Payloads profile [7] MIL-DTL-38999 L [8] MIL-DTL-55116 [9] MIL-STD-1913 [10] MIL-STS-810 G [11] CCSI Version V1 [12] IEE802.3 [13] STANAG 4694 [14] Common Chemical, Biological, Radiological, Nuclear (CBRN) Sensor Interface (CCSI) [15] “Advanced Explosive Ordnance Disposal Robotic System (AEODRS): A Common Archi-tecture Revolution” Mark A. Hinton, Michael J. Zeher, Matthew V. Kozlowski and Matthew S. Johannes [16] AEDP-2, STANAG 4586 [17] SAE/TP 2009-01-3250 [18] Interoperability Standards Analysis Report, NDIA [19] http://www.souriau.com/range-presentation/mil-dtl-38999-series-platform/ [20] http://en.wikipedia.org/wiki/Power_over_Ethernet [21] http://en.wikipedia.org/wiki/IP_camera [22] http://www.onvif.org/ [23] http://www.iso.org/ [24] http://www.can-cia.de/index.php?id=161 [25] http://www.lin-subbus.org/ [26] http://en.wikipedia.org/wiki/FlexRay [27] https://www.dawnbreaker.com/portals/phase3/us-marine-corps/independent-pms/robotic-systems-joint-program-office-pm-rsjpo/ [28] https://wiki.nps.edu/pages/viewpage.action?pageId=233013250 [29] Schunk http://mobile.schunk-microsite.com/ [30] http://en.wikipedia.org/wiki/EtherCAT [31] http://www.ethercat.org/default.htm [32] https://en.wikipedia.org/wiki/Serial_digital_interface [33] https://en.wikipedia.org/wiki/HDMI [34] https://en.wikipedia.org/wiki/Video_Graphics_Array [35] https://en.wikipedia.org/wiki/SCART

http://www.souriau.com/range-presentation/mil-dtl-38999-series-platform/

http://en.wikipedia.org/wiki/Power_over_Ethernet

http://en.wikipedia.org/wiki/IP_camera

http://www.onvif.org/

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=33422

http://www.can-cia.de/index.php?id=161

http://www.lin-subbus.org/

http://en.wikipedia.org/wiki/FlexRay

https://www.dawnbreaker.com/portals/phase3/us-marine-corps/independent-pms/robotic-systems-joint-program-office-pm-rsjpo/

https://www.dawnbreaker.com/portals/phase3/us-marine-corps/independent-pms/robotic-systems-joint-program-office-pm-rsjpo/

https://wiki.nps.edu/pages/viewpage.action?pageId=233013250

http://mobile.schunk-microsite.com/

http://en.wikipedia.org/wiki/EtherCAT

http://www.ethercat.org/default.htm

https://en.wikipedia.org/wiki/Serial_digital_interface

https://en.wikipedia.org/wiki/HDMI

https://en.wikipedia.org/wiki/Video_Graphics_Array

project quality handbook - r5-cop · 2.1.3 radio ..... ..... ..... ..... 12 2.1.4 sensors ......

Documents