GVR-BOT2.0_Users_Guide_V01.11.pdf

DISTRIBUTION A. Approved for public release; distribution unlimited. OPSEC# 4878

US ARMY – DEVCOM GVSC

GVR-BOT Gen 2.0 User’s Guide

Version 01.11

12/30/2020

User’s guide for any organization receiving a GVR-BOT robot. Includes operating instructions and integration notes for payloads. This document covers GVR-BOT Gen 2.0, SW 02.00.

US Army DEVCOM | GVR-BOT User’s Guide

2 | P a g e

Preface

READ THIS DOCUMENT THOROUGHLY BEFORE POWERING ON THE ROBOT.

3 | P a g e

Warnings and Known Issues GVR-BOT is NOT compatible with any Aware2 or Glue2 iRobot payloads, battery cradles, or equipment. Do not connect these to the robot as this may cause damage.

GVR-BOT’s version of MOCU™ 3 will only work with an Xbox controller. No other game controllers are compatible with the software.

Keep the Payload Ports covered when not used – the power port lugs contain unfiltered battery power and can cause damage to equipment if accidental contact is made. If the batteries are shorted to ground, they should protect themselves and remove power to the robot, but it is not recommended that this safety feature of the battery be relied upon.

The robot is water resistant, but not waterproof. Water should be avoided if possible. Do not wash the robot with water. To clean the robot, use compressed air or suction to remove dirt and debris.

The robot attempts to determine a rough State of Charge (SOC) values of the batteries, but this value is based on voltage only and not accurate. The robot will never provide a value that is lower (less) SOC than actually available, but the robot may have more SOC left than indicated.

There are several components inside the Front Electrical Housing that generate heat. The heat sinks are touching the top of the Front Electrical Housing for optimal conductive heat dissipation. Because of this, the top of the housing will feel warm to the touch.

Do not start the GVR-BOT with a single BB-2590 battery connected. Please connect both batteries to the robot battery cradle before turning on the GVR-BOT.

Compass heading does not work reliably.

4 | P a g e

Table of Contents Preface

Warnings and Known Issues

Introduction

Project History

Key features of GVR-BOT Gen 2.0

GVR-BOT 2.0 Overview

Payload Ports

Battery Power (VBatt)

IOP vs ROS Interfaces

Setup

OCU (Operator Control Unit)

MOCU™ 3

CCDC GVSC WMI

GVR-BOT Ubuntu Controller Software Setup

Robot

Installing batteries

Installing the flippers

Adding an IP camera

Normal Operation

Powering On and Off

GDT 3.6 (GVR-BOT Diagnostic Software)

LED Color & Blink Codes

Connecting Through Wireless (Windows)

Connecting Through Wireless (Ubuntu Linux)

Using MOCU™ 3

Status Area

Odometer

Avatar

Controller

Vehicle Speed

5 | P a g e

Using CCDC GVSC WMI

Selecting the Robot

Controlling the Robot

Disconnecting from the Robot

Powering Down

Using ROS to Interact with the Robot

Using a Xbox360 Controller in ROS to Interact with the Robot

Integrating Payloads

Power

Wired Onboard Communication

External Radios

Mesh Radios

GVR-BOT Frame of Reference

Platform

Flippers

GPS and Compass

Physical Integration

GVR-BOT Diagnostic Cable

IOP Mounting

Other Mounting Locations

Appendix A

Bill of Materials for GVR-BOT Diagnostic Cable

Appendix B

GPS Antennas & Mounting

Appendix C

RTC Information and Reset

Appendix D

Battery and Charger Information

6 | P a g e

Introduction

Project History The mission of the GVR-BOT project is to produce a small unmanned ground vehicle that is robust, easy-to-use, and designed as an open architecture platform. This will enable Research and Development organizations to create and share new technology that makes the warfighter’s job safer, more efficient, and more effective.

The project started as the RS-JPO1 (Robotic System – Joint Program Office) PackBot Standardization project for fielding an open architecture replacement for the PackBot 510 chassis, designed to meet IOP V1 (Inter-Operability Profile Version 1) standards. The intent was to reuse as much of the mechanical hardware as possible, but replace the proprietary design elements with Government-owned design elements: software, electrical hardware, and mechanical hardware. When that project ended, the team renamed the design “GVR-BOT” and became focused on providing a platform that could be used by researchers and developers.

1 This organization is now PdM UGV (Program deputy Manager Unmanned Ground Vehicles)

7 | P a g e

Key features of GVR-BOT Gen 2.0 Weight (without batteries and flippers): 9.07kg (20 lbs) Size: 68.0 X 40.5 X 18.0 cm (26.8 X 15.9 X 7.1 in) Tracked Flippers: 1.0 kg each (2.2 lbs) / Untracked Flippers: 0.4 kg (0.9 lbs) each Top Speed: 2.0 m/s (4.5 mph) Ambient Temperature Range: -20 to +50 C (-4 to +122 F) Main processor: Nvidia TX2 PN: 900-83310-0001-000 Specifications:

• Dual-Core NVIDIA Denver 2 64-Bit CPU, 2.0 GHz

• Quad-Core ARM® Cortex®-A57 MPCore, 2.0GHz

• 256 CUDA cores

• 8GB 128-bit LPDDR4 Memory

• 32GB eMMC 5.1 Storage + additional 32 GB SD card

• 7.5W (MAXQ power mode )/ 15W (MAXN power mode)

Robot Power

• Up to four BB-2590 Li-Ion batteries (requires one battery cradle per two batteries)

• Base chassis consumes approximately 30 Watts when powered up and stationary

Payloads

• Four payload ports

• Three payload bays can physically contain existing, modified PackBot 510 payload tub sized modules

• Mounting rails for the fourth payload bay can be installed above the Front Electrical Housing

(not included), if an IOP Mounting Plate is not installed Communications

• Communicates with any Wi-Fi enabled computer at 2.4 GHz frequency

• Maximum communications range is ~100m

Software Interface

• Designed to meet the IOP V1 standard, internally (between components) and externally (to

OCU)

Sensors

• Internal (IMU) provides accelerometer, heading, and orientation information

• Internal GPS Transceiver with external antenna port – a SMA Jack connection is needed to attach an active 3.3V antenna (not included)2

• Internal Real Time Clock (RTC) keeps time synchronization after shutdown of the robot for ~72 hours if no batteries are installed Flippers

• Two detachable flippers may be included and can be rotated continuously in either direction

2 See Appendix B for details on GPS antennas tested

8 | P a g e

GVR-BOT 2.0 Overview The important features of the GVR-BOT chassis are identified in Figure 1.

Figure 1 – Important Features of GVR-BOT Chassis

Payload Ports The robot has 4 Payload Ports that allow integration of payloads, sensors, and additional processing capability.

It is highly recommended that the IP67 covers be installed over the Payload Ports when not in use.

These covers provide protection from dirt and debris to the connectors.

In Figure 2, the Payload Ports on the robot are labeled as well as additional features of the robot.

Right Track

Front Electrical Housing

Radio Antennas

Power On Switch Left Track

Rear Electrical Housing

4 Payload Ports

3 Payload Bays

IOP Mounting Plate

9 | P a g e

Figure 2 – Payload Ports Exposed and GPS Antenna Port Location Identified

Every Payload Port contains a Gigabit Ethernet port and a USB 2.0 port. It also contains unregulated battery power (VBatt) and power ground (VBatt_Rtn). The connector itself is a DB-25 connector in a 17W2 pin configuration, which is not an approved IOP V1 connector. “17W2” is shorthand notation for 2 power lugs3 and 15 signal pins for a total of 17 conductors.

The signal numbers are molded into the 17W2 connectors themselves and shown in Figure 3.

3 17W2 connectors can utilize power lugs or coaxial connectors, GVR-BOT uses the power lug version only.

Port 3

Port 2

Port 1

Port 0

MIMO

Antenna 2

GPS SMA

Antenna Port

0906 IOP

Mounting

Plate

MIMO

Antenna 1

10 | P a g e

Figure 3 – Composite Image of a GVR-BOT Payload Port with Numbered Conductors

The S1 and S2 power lugs are denoted as A1 and A2 on some connectors. The definition of each pin is provided in Table 1. Note that the outer shell of the connector is also grounded - connected electrically to VBatt_Rtn.

11 | P a g e

Table 1 – Payload Port Definition

Pin Name Definition S1 (A1) VBatt Battery Power S2 (A2) VBatt_Rtn Battery Power Return (Robot Gnd)

1 NC No Connection 2 USB_VBus USB +5V Power 3 USB_D- USB 2.0 Signal Negative 4 USB_D+ USB 2.0 Signal Positive 5 USB_GND USB +5V Power Ground 6 DC- Gigabit Ethernet 7 DC+ Gigabit Ethernet 8 NC No Connection 9 NC No Connection

10 DB+ Gigabit Ethernet 11 DB- Gigabit Ethernet 12 DA+ Gigabit Ethernet 13 DA- Gigabit Ethernet 14 DD+ Gigabit Ethernet 15 DD- Gigabit Ethernet

The VBatt_Rtn signal on the robot is electrically connected to the chassis of the robot.

Battery Power (VBatt) Because the VBatt signal is unregulated battery power, its voltage will gradually decrease as the batteries are depleted. With fully charged batteries, the voltage will be as high as 34 Volts. As the batteries are used, the voltage will fall as low as 24 Volts. In addition, large amounts of current drawn from the battery will draw the VBatt voltage down temporarily. A common example of this occurs when the drive motors are being used at full speed and under load. The system voltage will fall as much as 2 Volts during this operation.

GVR-BOT will shut itself off when the battery voltage falls lower than 24 Volts for 1 second.

12 | P a g e

IOP vs ROS Interfaces There are two interfaces that GVR-BOT Gen 2.0 supports: IOP (Interoperability Profile) v1 and ROS (Robotic Operating System) 1 (Melodic). The operating system of the robot is Ubuntu Linux 18.04.

ROS is actually running the robot “under the hood”. ROS is a popular open source publication/subscription software which has many algorithms, interfaces, and drivers available for use.

The ROS interfaces for control and feedback are also available to the user.

The IOP interface is for external communications with payloads and the OCU. IOP is a common DoD robotics interface protocol based on the SAE (Society of Automotive Engineers) AS-4 communication standard. This IOP interface is achieved by a ROS node that provides an IOP interface to the control and feedback elements of the robot.

Setup

OCU (Operator Control Unit) An Operator Control Unit (OCU) is not provided with the robot, but a Windows computer can be set up as an OCU by using one of two OCU software sets: CCDC GVSC WMI or MOCU 3.

A Linux computer can be set up for tele-operation by the GVR-BOT Ubuntu Controller Software or using standard ROS twist messages with any controller. We recommend using Ubuntu 18.04 with ROS melodic installed.

MOCU™ 3

SPAWAR Pacific’s MOCU™ 3 software has been configured for the GVR-BOT and is provided on the Install Disk. MOCU™ 3 has been tested to run in Windows 7 and Windows 10. It uses the IOP interface and provides a user interface to tele-operate the robot and check the internal status and sensor returns.

To install, run executable file MOCUSetup3_2_0_7587_GVRBOT_Q4.exe on a Windows computer. By default it installs the software to the "C:\Program Files (x86)\MOCU" directory on the computer.

CCDC GVSC WMI

CCDC GVSC WMI (Warfighter Machine Interface) software is also provided, which uses an IOP interface.

The controller software provides an interface to drive the robot and check the internal status and sensor returns. This software can control up to 4 GVR-BOTs but they must be configured beforehand as one meshed network.

To install CCDC GVSC WMI, unzip the folder directly to the "C:\" drive of your Windows 7 or Windows 10 computer. This will create and unzip everything into a folder called "C:\RVCA". The software will only work if it resides at "C:\RVCA" directory.

GVR-BOT Ubuntu Controller Software Setup On the GVR-BOT CD included in your robot package, load the CD into the Ubuntu 18.04 computer. Read the Readme.md file in the gvrbot_ros_controller_1.0 folder for details on the instructions for install.

13 | P a g e

Robot The robot should arrive configured for operation. It only requires batteries to operate in tele-operation mode.

Installing batteries The GVR-BOT needs two batteries to run the robot.

All testing has been performed using the Bren-tronics brand Li-Ion BB-2590 rechargeable batteries, shown in Figure 4.

Figure 4 – BB-2590 Li-Ion Batteries

Information about purchasing batteries and chargers for the GVR-BOT is provided in Appendix D.

Figure 5 shows the configuration when driving the robot - two batteries installed and the Battery Cover in place.

14 | P a g e

Figure 5 – Batteries and Battery Cover Correctly Installed

Installing the flippers The flippers have Flipper Release Ball Bearings in the shaft which lock the flippers in place when installed, as indicated in Figure 6.

Figure 6 - Flipper Release Ball Bearings

The other significant feature is the Flipper Release Button, identified in Figure 7, which is used to release the ball bearings when installing or removing the flippers.

Battery Cover Removal Screws

Flipper Release Ball Bearings

Left Front Battery

Left Rear Battery

Battery Cradle

15 | P a g e

Figure 7 - Flipper Release Button

To install the flippers, depress the Flipper Release Button and keep it depressed while inserting the flipper into the flipper shaft opening on the side of the robot. Once inserted fully, release the Flipper Release Button and the flipper should be prevented from coming out. Spin the flipper until it locks into position. Repeat this procedure with the flipper on the other side of the robot.

Figure 8 provides an image of a GVR-BOT with flippers installed.

Figure 8 – Flippers and a Camera Installed on GVR-BOT

Adding an IP camera Any IP-based camera can be added to the system as long as it provides RTSP streaming video.

Flipper Release Button

16 | P a g e

Most IP cameras can be configured to provide their RTSP stream at a user selected location. Follow the camera vendor’s instructions or user manual to configure the camera, then connect it to the robot. GDT (GVR-BOT Diagnostic Tool) can be used to set the robot’s expected rtsp stream to match the camera. If configured correctly, MOCU™ 3 should display the video stream once connected.

Alternatively, if an IOP V1 camera is attached to the robot, it does not need this configuration step since the IOP protocol allows the robot and camera payload to negotiate the stream location automatically.

Normal Operation The Rear Electrical Housing contains several useful features for the user, indicated in Figure 9.

17 | P a g e

Figure 9 – Rear Electrical Housing Features

The ID Tag displays the robot’s unique serial number, which identifies it on the wireless network. This will be located on the back of the robot near the power button.

Powering On and Off With charged batteries installed, the robot is powered on by pressing the PowerOn Button located at the rear of the robot. The robot should begin by flashing the Green LED. After approximately 40 seconds, the Green Status LED should become solid green.

GDT 3.6 (GVR-BOT Diagnostic Software) GDT 3.6 is a GVR-BOT 2.0 diagnostic software used to troubleshoot issues and retrieve error codes if a problem is detected on the robot. The GDT software can be ran using a Windows or Ubuntu computer.

To startup and install the GDT software see the Readme.md file in the GDT folder. GDT is broken down into multiple button selections, as seen in Figure 10.

PowerOn Button

18 | P a g e

Figure 10 – GDT Application

Button Description:

Get System Status

Displays main platform OS version, running ROS nodes, log level, odometer value, disk full percentage, SD card full percentage, status of Flipper Board, Mobility Board, Power Board, IMU, GPS, USB Hub 1, and USB Hub 2.

Set GVR-Bot IPv4 Address

Enter a valid IPv4 address and then select `Set` if GVR-BOT IP address is different than the standard address: 192.168.0.101.

Set Main Camera RTSP URL

Enter a valid main camera RTSP URL and then select `Set` (this will update both IOP and ROS reported main camera stream). If the RTSP stream requires a username and password, this must be embedded in the URL.

Set Secondary Camera RTSP URL

Enter a valid secondary camera RTSP URL and then select `Set` (this will update only IOP reported secondary camera stream). If the RTSP stream requires a username and password, this must be embedded in the URL.

About

Displays basic user info about GDT.

Connect to Internet

Reconfigures GVR-BOT Ethernet interface to be able to connect to Internet (wireless connection will still be available to SSH into GVR-BOT and run commands).

Disconnect from Internet

Reconfigures GVR-BOT Ethernet interface to be a local connection to connect to any payloads.

19 | P a g e

Flash Main Software

Use Browse button to select a main GVR-BOT software update file and install it on GVR-BOT (this file must end with gvrbot_software_update.tar.gz) - GDT copies this file to GVR-BOT, extracts it, looks for an install.sh script inside and executes that script, so this is a powerful feature that can be used for any kind of custom updates desired.

Get Micro Info

Displays firmware version, bootloader version, status, faults for micro selected in dropdown.

Get Count Info

Displays boot count and reset count for micro selected in dropdown.

Set to Bootloader Mode

Sets micro selected in dropdown to bootloader mode (required before flashing micro software).

Set to Application Mode

Sets micro selected in dropdown to application mode (this should only be required if micro unintentionally gets into bootloader mode).

Calibrate Flipper

After selecting 3 times in 5 seconds or less automatically begins flipper calibration process which requires manually moving flipper to desired home position after initial calibration. The calibration process causes the flippers to rotate 720 degrees so this procedure should only be run if the robot is on a stand so the flippers don’t touch the ground.

Flash Micro Software

Use Browse button to select a micro software update file and install it on micro selected in dropdown (micro must be in bootloader mode).

Get Logs

Compresses latest logs in /tmp/latest and copies to logs directory next to GDT executable.

If `Clear Logs` is checked all logs in /tmp/latest will be deleted (original logs will still be retrieved).

If `Restart Software` is checked ROS software will be restarted after logs are retrieved.

Change Log Level

Changes log level to level selected in dropdown (determines which data is published and logged).

LED Color & Blink Codes The LED color & blink codes provide general troubleshooting information for a user and are presented in Table 2.

20 | P a g e

Table 2 – GVR-BOT Blink Codes

Color Meaning Troubleshoot White Blinking on/off Powering On None

Green Solid Working Properly None Purple Solid Pwr Mgt Board Issue Obtain Pwr Mgt Board Info

Using GDT Blue Solid Flipper Board Issue Obtain Flipper Board Info Using

GDT

Red Solid Mobility Board Issue Obtain Mobility Board Info

Using GDT Yellow with two fast purple blinks Pwr Mgt Board in Bootloader Flash Pwr Mgt Board using GDT

Connecting Through Wireless (Windows) To connect wirelessly to the robot, look for the robot to appear in the OCU’s wireless configuration settings. It will appear under wireless connections as the serial number on the ID Tag of the robot, e.g.

“GVR-BOT-033.” Connect to the Wi-Fi using the password "modern0325".

As the screen capture in Figure 11 shows, the icon in the lower right of a Windows 7 computer can be clicked on to show all available wireless networks.

Figure 11 – Wireless Connections in Windows 7

Connecting Through Wireless (Ubuntu Linux) To connect by wireless using Ubuntu 16.04 Linux, click on the network icon in the upper right corner of the screen. Select the GVR-BOT to connect with under the Wi-Fi Networks. Connect to the Wi-Fi using

GVR-BOT-033’s network ID

Available wireless networks icon on windows

21 | P a g e the password "modern0325". Current versions of Ubuntu such as 18.04 and 20.04 will work with the GVR-BOT wireless connection however, connection instructions maybe different depending on the OS release version of Linux used. Each operation version can be different in the configuration of wireless networks.

Figure 12 shows the location of the icon and Wi-Fi Networks to select.

Figure 12 - Connecting with Wi-Fi in Ubuntu 16.04 Linux

Once the OCU computer is connected to the robot and has an IP address assigned to it, you can tele-operate it using MOCU™ 3 or CCDC GVSC WMI.

Using MOCU™ 3 Once installed, the MOCU.exe executable file can be run to start MOCU™ 3. If the main screen shows “Waiting For Robot (Chan)” as shown in Figure 13, it likely means you or the robot haven’t connected to a robot yet.

GVR-BOT-038’s network ID

Available wireless networks icon

22 | P a g e

Figure 13 – “Waiting For Robot” Screen

Verify you are connected to the GVR-BOT Wi-Fi, including changing any of the Firewall settings.

JTSNodeManager.exe must be allowed through the firewall of the computer. Only one OCU can control the robot at any time, so it could also mean that another OCU is already connected to the robot and controlling it.

Once connected, the MOCU™ 3 screen provides status on the robot and OCU, as depicted in Figure 14.

23 | P a g e

Figure 14 – Screen Features

The major features of MOCU™ 3 are described in the following sections.

Status Area The status area provides information about the OCU and robot. See Figure 15.

Figure 15 – Status Area

Odometer Status Area

Avatar Vehicle Speed

Setting

E-Stop Indicator

Xbox Joystick Connected

Network Connection

Indicator UGV Battery Level

OCU Battery Level

Driving Camera View

24 | P a g e

The Xbox Joystick Connected indicator will turn red if the controller is disconnected from the OCU. It is blue if connected and functioning.

The Network Connection Indicator will show whether MOCU™ 3 is communicating with the robot or not.

If there is no connection, a red circle and slash will appear on this indicator as seen in Figure 16.

Figure 16 – Robot Not Connected to OCU

The UGV Battery Level and OCU Battery Level indicators show the approximate State of Charge of both battery systems.

Odometer The Odometer displays the total distance traveled for the robot in miles. Distance includes both forward and reverse direction travel, and the tangential distance while turning in any direction.

Avatar An image of the robot’s orientation in space is provided by the on-screen avatar. This information is provided by the robot’s internal accelerometers. It also displays the current position of the flippers. In some versions of MOCU™ 3, a compass heading is shown underneath this avatar.

Controller With MOCU™ 3, the robot is driven using an Xbox controller. The parts of the Xbox controller are labeled in Figure 17.

25 | P a g e

Figure 17– Xbox Controller Features Labeled

Emergency Stop The GVR-BOT has an emergency stop feature implemented. To immediately shut the robot power off via the controller, press the Back button and Start button both down simultaneously.

To drive the robot, move the Drive Joystick in the desired direction of travel.

To rotate the flippers, use the LB and RB buttons. Both flippers rotate together at a fixed speed.

Vehicle Speed The robot can have 3 different speed settings when using MOCU™ 3: slow, medium, and fast. The setting can be changed by either pressing the F4 key at the OCU, or using the following sequence of the controller: press the Start button to get to the “Main” menu, then use the controller’s D-Pad to select “Platform”, then “Speed”, then the desired speed.

Changing the vehicle speed also changes the speed of the flippers to slow, medium, and fast.

Using CCDC GVSC WMI Once installed, run the script C:\RVCA\V1\scripts\start-packbot.bat. To stop the software, run the script C:\RVCA\V1\scripts\stop-rsjpo.bat.

The CCDC GVSC WMI was originally designed for multiple control screens, but has been configured for GVR-BOT to be run on one laptop screen. CCDC GVSC WMI utilizes two screens, and the ALT+TAB keys must be pressed together to switch between the two.

Left Joystick (Drive Joystick)

Directional Pad (D-Pad)

Back Button Start Button

Right Joystick

LB (Flipper Rotate Forward)

RB (Flipper Rotate Backward)

26 | P a g e

The two screens are referred to as the Map Screen and Control Screen, shown in Figure 18 and Figure 19 respectively.

Figure 18 - CCDC GVSC WMI Map Screen

Available Robots

TELEOP Button

Off Button

27 | P a g e

Figure 19 - CCDC GVSC WMI Control Screen

Selecting the Robot All available robots will be shown in blue boxes on the right side of the MAP screen. In Figure 18, only one robot is available, named “GVRBOT1.”

To select a robot from list, click in the blue box and press the “TELEOP” button. As can be seen in Figure 20, the TELEOP button and engine symbol will turn green.

28 | P a g e

Figure 20 - Select TELEOP on the Map Screen

In addition, a green status bar will continuously move from left to right while the connection is active.

ALT+TAB to the Control Screen, which now should contain the video feed from the selected robot as seen in Figure 21.

29 | P a g e

Figure 21 - Control Screen with Selected Robot Video Feed

The Small Video Feeds from all connected robots will be displayed along the left side of the Control Screen. In Figure 21, there is only one robot so only one video feed is shown. The selected robot will have an icon of a steering wheel overlaid on the Small Video Feed. If a camera feed is faulty or not present, the Small Video Feed will show the default image seen in Figure 22Figure 22.

Figure 22 - Default "No Video" Image

Vehicle Speed Icon

Drive Selection

(PRND)

Vehicle Orientation

Small Video Feeds

30 | P a g e

Controlling the Robot To drive the robot, click on the Drive Selection labelled “P” which then show all 4 “PRND” (Park, Reverse, Neutral, Drive) choices as can be seen in Figure 23.

Figure 23 - All 4 PRND Choices

Click on the “D” to drive the robot in the forward direction or “R” to drive the robot in the reverse direction. This choice can be changed at any time by again clicking on the Drive Selection letter and making another selection.

Once a robot is selected and in D or R, the robot is driven and turned using the Left Joystick of the Xbox Controller.

There are three possible Vehicle Speeds. The speed icons and their values are:

Slow

31 | P a g e

Medium

Fast

These 3 speeds are cycled through by pressing the Left Joystick in and “clicking it” as if it is a button.

Disconnecting from the Robot To disconnect from the robot, place the vehicle back to Park (P). Then go to the Map screen and deselect the TELEOP button by clicking on it. It should become gray.

Powering Down To power off CCDC GVSC WMI, it is recommended to run the shutdown script C:\RVCA\V1\scripts\stop-rsjpo.bat. This script will shut down all parts of the software. This shutdown process can take a couple minutes and is monitored by various command line interfaces. The final command line interface may be on the screen for up to a minute, as see in Figure 24.

32 | P a g e

Figure 24 - Final Stage of Powering Down CCDC GVSC WMI

Using ROS to Interact with the Robot The GVR-BOT 2.0 platform is running ROS 1 (Melodic). Payloads or OCUs can control the robot and read its sensed values using ROS 1. This functionality has been successfully tested with ROS Kinetic, and Melodic.

Architecturally, it is important to know that the GVR-BOT is expecting roscore to be running on its internal Main Processor. Any sensor or computer that uses ROS to interact with a GVR-BOT must be configured so its instance of ROS will use the roscore running on the GVR-BOT. This is accomplished by running the following from the command line, which will tell ROS to look at the GVR-BOT’s main processor (IP address 192.168.0.101) for the roscore:

export ROS_MASTER_URI=http://192.168.0.101:11311

33 | P a g e

This will need to be run every time a new shell is started, unless the command is added to the .bashrc file.

Once this is accomplished, the following command can be used to query the GVR-BOT and see what ROS nodes are running on it:

rostopic list

This command should show a list of all nodes running on the GVR-BOT. If this does not occur, the hosts file on either the computer or GVR-BOT (or both) may need to be updated to allow them to see each other. This can be done by adding the IP address and corresponding hostname of the other computer to each computer’s /etc/hosts file.

Using a Xbox360 Controller in ROS to Interact with the Robot On the install disk a custom controller software will be included if a user wants to control the GVR-BOT platform on a Lunix computer for custom development work. The GVR-BOT ROS Controller is a GUI that allows control and status of a GVR-BOT using ROS commands instead of IOP commands. In order to control the GVR-BOT a joystick is needed that will work with the Joy ROS package (suggest Microsoft Xbox 360 controller). Execute the instructions in the READMD.txt file in the gvrbot_ros_contrller_1.0 directory.

Notes:

/cmd_vel is the twist message that will control the robot (driving)

/imu/data is the feedback (quaternions) of the sensed IMU data from the robot

Integrating Payloads The 4 Payload Ports of the robot can be used to add sensors, processors, radios, and other equipment to the robot.

The first two factors to be considered when integrating anything onto a GVR-BOT are Power and Wired Onboard Communication with the robot.

Power Payloads can be powered from their own batteries, or can receive power from the robot itself. For a payload to receive power from the robot, some considerations should be understood.

Each of the robot’s payload ports supplies raw battery power through the S1 (A1) power lug and uses S2 (A2) as the Power Return (Ground). The voltage seen at the ports will vary between 34 and 24 Volts.

Fully charged batteries in the vehicle will provide 34 Volts maximum, but this voltage will gradually drop off as the batteries drain down, and when 24 Volts is reached the robot will shut itself off.

34 | P a g e

Loads on the battery system may draw voltage down temporarily, as in the case of driving the robot – this will typically cause the system voltage to drop up to 2 Volts while moving.

Each battery in the system will provide 9-10 Amps of continuous power. When high current is drawn from the batteries they will tend to heat up, which can cause them to enter their thermal protection mode. Thermal protection of the batteries can only be reset by completely removing the batteries from the robot, then re-installing them once cooled.

A best practice when powering high current loads from the robot is to use as many fully charged batteries as possible to avoid thermal protection, since current will then be drawn equally from all batteries, reducing their individual current consumption and thereby reducing their likelihood of entering thermal shutdown.

Most payloads require a stable input voltage. Plugging any equipment directly into a payload port may damage it, unless it is designed to accept 24 - 34 Volts for input power.

Common examples of expected input voltages for payloads are 5 Volts, 12 Volts, and 24 Volts. This necessitates the use of a DC-DC converter, which can take the broad range of voltages provided by the robot and convert it into a consistent voltage for a payload.

Any DC-DC converter that meets the requirements will work, and the GVR-BOT team has successfully used a variety of these devices. Table 3 provides some examples of DC-DC converters that are easy to integrate with GVR-BOT for experimental use. The mechanical models for these parts are available from the vendor.

Table 3 - DC-DC Converters

Voltage Input (V)

Voltage Output (V)

Max Current Output (A)

Part Number Vendor Price

(USD)

9 - 36 5 4.0 PYB20-Q24-S5-T Digikey 52.80

9 - 36 12 1.6 PYB20-Q24-S12-

T Digikey 52.80

9 - 36 24 0.8 PYB20-Q24-S24-

T

Digikey 52.80

Each Payload Port also provides stable 5 Volt output via the USB port (Pins 2 and 5), but the output is limited to 0.5 Amps per the USB specification.

Wired Onboard Communication Communication with the robot is most commonly done through a Payload Port using twisted pair Ethernet; either 100BASE-T or 1000BASE-T. The GVR-BOT includes an unmanaged Ethernet switch inside which allows the main processor, internal radio, and all payload ports to communicate with one another if all are configured to be on the same subnet. By default the robot is on subnet 192.168.0.x and all payloads are recommended to be configured as static IP addresses within the range of

192.168.0.102 ~ 192.168.0.199.

35 | P a g e

When an OCU is connected to a GVR-BOT, the radio’s DHCP assigns it an IP address which places the OCU on the same subnet and enables it to communicate with all the payloads on the robot as well.

An example of an integrated payload is depicted in Figure 25, showing power and communications connected.

Figure 25 - Example Integrated Payload

Figure 8 shows a photograph of this configuration, with an IP camera and DC-DC converter mounted on top of the front of the robot. Electrical connections in this image have been made using a GVR-BOT Diagnostic Cable Figure 30.

This example utilizes a camera connected to the robot, which can then be accessed by the OCU, either as an IOP interface or by another method. For example, most IP cameras can be accessed via web browser or other video viewing software for ex: VLC.

Any IP based or “Ethernet enabled” payload would follow this same route to integrate it on a GVR-BOT.

Examples include ranging sensors (LIDARs, RADARs, ultrasonics, stereo cameras …), cameras and imagers (thermal, IR, visible light, PTZ …), external processing modules (laptops, embedded computers, processing nodes and filters …), and other types of sensors (chemical / biological / nuclear, atmospheric, IP Camera – requires 12V input

12V DC-DC

Converter

Ethernet communications

Payload Port P0

36 | P a g e temperature, pressure, microphones …). External embedded radios are another class of payloads that are discussed separately, but the integration is similar to these payloads.

The GVR-BOT architecture can be thought of as a mobile computer and Ethernet switch network that allows wireless communications to a laptop. When a payload or multiple payloads need to be integrated on the GVR-BOT, several options exist to perform this task from a system design perspective.

The preceding discussion of payload integration, depicted graphically in Figure 26, provides one common way in which all integrated items are on the same network and all can communicate with one another.

Figure 26 - Common Architecture of GVR-BOT Integration

The flexibility of the GVR-BOT design allows a variety of alternative system configurations such as Figure 27.

Operator Control Unit Sensor A

Sensor B

Wireless Communication

Sensor Output A

Sensor Output B

37 | P a g e

Figure 27 - An Example Fused Sensor Architecture

This example doesn’t necessarily allow all the items on the network to see one another, as Sensor A and Sensor B can only be accessed through the Processing Node. If a sensor or processing node fails special considerations will have to be implemented to inform or maintain information to the user.

Figure 28 provides another example architecture - a system that utilizes autonomy and doesn’t require an OCU at all.

Sensor A

Sensor B

Operator Control Unit

Wireless CommunicationProcessing

Node

Fused Sensor Interface

38 | P a g e

Figure 28 - "Headless" (No OCU) Autonomy System Integration

With this design, the user interface could be integrated on the Autonomy Payload and allow the user to change the mode or configuration of the system.

When performing the design for an integrated system, it is recommended that the communications requirements of the sensors be used as a starting point. GVR-BOT integration is easiest with Ethernet based systems, but not all sensors provide this communication standard. If something else is required -like USB or RS-232 – the USB connections in the payload ports can be used either directly or through conversion hardware.

If connecting directly or through a converter to a GVR-BOT USB port, some modification of the robot’s operating system is usually required through the addition of drivers, DLLs, and other software or configuration changes. This can be done but is not recommended. A preferred method of communicating with these types of sensors or payloads is to add an external computer of some kind to the robot, such as an embedded processing node, which can interface to the required sensors and provide an Ethernet interface to the robot. The advantage of this approach is it separates the platform from the system being integrated and allows the organization doing the integration to have complete control over the interface and communications with the sensor.

Another option is to convert the non-Ethernet communication to Ethernet if appropriate conversion hardware is available.

Sensor A Sensor B

Autonomy Payload

Integrated Sensor Package C

39 | P a g e

External Radios The GVR-BOT internal radio provides a wireless connection from the robot to a Wi-Fi enabled computer at the 2.4 GHz frequency range. The radio is configured to allow any channel within this frequency, but tends to use Channel 1.

Integrating an IP Radio is a little more involved than a typical payload. External radio systems tend to act as “closed systems” that communicate seamlessly from one radio node to another, and require the GVR-BOT to communicate through this network to the OCU. That is, the GVR-BOT will connect to the radio via Ethernet using its standard subnet of 192.168.0.x. A second radio is connected to the OCU on the same subnet. The radios usually operate on their own subnet that is separated from – and invisible to - the robot and OCU’s subnet. The system is depicted in Figure 29.

Figure 29 - GVR-BOT with External Radios

To reduce power consumption and minimize possible interference, the internal radio can be disabled.

Contact the GVR-BOT team for instructions and assistance.

Mesh Radios If the external radio being used is part of a meshed network system, it will allow communication to the other robots and nodes on the network. Mesh networking with GVR-BOTs is currently done by changing the internal IP addresses of the various GVR-BOTs on the mesh network so that they all have unique IP addresses. This allows the meshed network to appear as a large “flat” network where every IP component in the mesh can communicate with every other IP component.

The setup for meshed networking is involved and requires pre-mapping the IP addresses for the entire planned network. Each robot must be configured internally to conform to this network design by logging in to each subsystem and reconfiguring its IP address. If this capability is needed, contact the GVR-BOT team for support.

OCU (Operator Control Unit)

Wireless Communications

External Radio B

External Radio A

40 | P a g e

GVR-BOT Frame of Reference

Platform The GVR-BOT platform frame of reference is defined by JAUS Vehicle Coordinate System - X forward, Z down-up, Y right handed.

Positive linear effort is forward, negative linear effort is backwards.

Positive rotational effort is right, negative rotational effort is left.

Flippers The angle 0 radians is when the Flippers are horizontally pointed backwards, as depicted in Figure 30.

Figure 30- Flipper Home Position

Starting at this position, negative effort is rotating up and positive effort is rotating down.

GPS and Compass The GVR-BOT 2.0 contains an IMU that is the BOSH BNO055 9 axis gyro, accelerometer, and magnetometer. This sensor provides accelerometer information in 3 axes (X, Y, Z), accelerometer, gyro, and magnetometer readings. For GPS an Ublox NEO-M8M sensor was used.

For the GPS to function, a GPS antenna using a SMA connection must be installed on the robot. The GPS antenna port lies in the rear section of the top middle of the robot (Figure 2) and should be covered when no antenna is installed. To add a GPS antenna, the GVR-BOT Team can provide a list of off-the-self GPS Antennas that can be easily bought separately, or see the Bill of Materials in Appendix B.

Active GPS antennas with applicable 3.3V input with an SMA male connector should work with the GVR- BOT 2.0. Two that have been tested and verified are UBlox ANN-MS-0-005 and Antenna Factor Series:

SH. Please make sure that the robot has a clear sky view to receive strong GPS signal.

41 | P a g e

Physical Integration

GVR-BOT Diagnostic Cable The GVR-BOT Diagnostic Cable breaks out the power, Ethernet, and USB ports of the payload connection into their more standard connectors. This makes integration of payloads more convenient.

An image of a GVR-BOT Diagnostic Cable is provided in Figure 31.

Figure 31 - GVR-BOT Diagnostic Cable

The cables are easy and inexpensive to create. A complete Bill of Materials for this cable is provided in Appendix A.

IOP Mounting The IOP V1 standard allows for mounting of IOP Payloads by threaded ¼-20 holes in a 1” X 1” grid pattern. This type of mounting can be provided by the 0906 IOP Mounting Plate which installs directly over the Front Electrical Housing of the GVR-BOT. An air gap exists between the IOP Mounting Plate and the Front Electrical Housing to facilitate conductive cooling of the components within the Front Electrical Housing.

42 | P a g e

Figure 32 shows an IOP Mounting Plate integrated on a GVR-BOT.

Figure 32 - IOP Mounting Plate Installed on GVR-BOT

The 0906 IOP Mounting Plate facilitates easy physical integration of payloads but provides a limited amount of space. Unless payloads are very small, only one or two will fit in the space provided. To overcome this limitation, the GVR-BOT team designed the 0909 Large IOP Mounting Plate which sits atop the entire robot and provides an increased mounting area. Installation of the Large IOP Mounting Plate requires an adapter bracket - the 0910 IOP Mounting Plate 3 inch Adapter - and six 3” standoffs.

The Large Mounting Plate uses the “standard” 0906 IOP Mounting Plate as the front attachment point.

An installed Large IOP Mounting Plate is shown in Figure 33.

IOP Mounting Plate

43 | P a g e

Figure 33 - Large IOP Mounting Plate Installed

The large IOP Mounting Plate is not standard equipment with a GVR-BOT. Please contact the GVR-BOT Team if this capability is needed.

Other Mounting Locations Payloads, sensors, and bracketry can be mounted on the GVR-BOT in a variety of places in addition to the IOP Mounting Plate. The most common location is the area of the Payload Bays.

Payload Bays There are 3 Payload Bays, and their location on the robot is indicated in Figure 1.

If a simple bracket is needed to mount things in the Payload Bay area, the relative locations of the mounting holes are provided in Figure 34.

0909 Large IOP Mounting Plate

0906 IOP

Mounting Plate

0910 IOP Mounting Plate 3 inch Adapter (Not visible, it is underneath)

3” Standoffs (not visible, they are underneath)

44 | P a g e

Figure 34 - Relative Locations of Payload Bay Mounting Holes (units in mm)

The mechanical model for this simple bracket is available upon request from the GVR-BOT Team. The mounting holes in the robot contain 10-32 threads and the hole sizes in this bracket should not be threaded, but allow 10-32 screws to pass through unimpeded.

The locations provided are only for the mounting holes, and do not include the Payload Port location.

This mounting bracket is shown installed on a GVR-BOT in Figure 35.

45 | P a g e

Figure 35 - Payload Bay Bracket Mounted

PackBot Payload Tubs – depicted in Figure 36 - will fit in the GVR-BOT Payload Bays, but they must be modified to fit properly because the original PackBot connectors have been replaced with something different.

46 | P a g e

Figure 36 - PackBot Payload Tub

These tubs are used as a component of the PackBot CAM and SAM payloads, or as standalone housings to contain electronics and other mechanical and electrical hardware. If used as standalone, a cover is placed over the tub with an O-ring for environmental sealing.

To use a PackBot Payload Tub with a GVR-BOT, the Payload Port Connector Opening must be enlarged on the long side of the opening by 1-2 mm to allow the back (solder cup) side of a 17W2 connector to fit within. In the PackBot design, the connector lies inside the Payload Tub and the mating connector on the robot side passes inside the Payload Port Connector Opening. The GVR-BOT design usually has the 17W2 on the outside of the Payload Tub, which requires spacers underneath the mounting holes and a longer gasket to environmentally seal the opening. A modified PackBot Payload Tub with these changes applied is shown in Figure 37.

Payload Port Connector Opening

O- Ring Channel

47 | P a g e

Figure 37 - Modified PackBot Payload Tub Detail

The GVR-BOT Team has designed an alternate payload tub that provides more volume inside the housing and creates the mechanical and connector interfaces specific to the GVR-BOT. This part is called the 0900 Single Wide Payload Tub. The mechanical model is available upon request from which a 3-D printed part can be made. A view of the top and bottom of the GVR-BOT Payload Tub is provided in Figure 38.

Figure 38 - Top and Bottom View of GVR-BOT Payload Tub

Siderail Mounting There are numerous 10-32 threaded holes on the inside and outside faces of the Left and Right Siderails which can also be used for mounting of brackets and equipment. The holes are highlighted in Figure 39 and Figure 40.

Mounting Spacer

Extended Gasket

17W2 Connector

Opening must be widened 1-2 mm in this direction to fit the 17W2 connector

48 | P a g e

Figure 39 - View of Mounting Holes from Left Side of Vehicle

Right Siderail “Inside”

Mounting Locations

Left Siderail “Outside”

49 | P a g e

Figure 40 - View of Mounting Holes from Right Side of Vehicle

The GVR-BOT Team has scanned most mechanical components of the original PackBot and can provide the 3-D models of these parts upon request.

Appendix A

Bill of Materials for GVR-BOT Diagnostic Cable The GVR-BOT Diagnostic Cable breaks out the power, Ethernet, and USB ports of the payload connection on the robot into their more standard connectors. This makes integration of payloads more convenient.

Figure 41 provides the pinout and wiring diagram of the GVR-BOT Diagnostic Cable.

Left Siderail “Inside”

Mounting Locations

Right Siderail “Outside”

50 | P a g e

Figure 41 - Pinout of GVR-BOT Diagnostic Cable

1 BI_DA+

2 BI_DA-

3 BI_DB+

4 BI_DC+

5 BI_DC-

6 BI_DB-

7 BI_DD+

8 BI_DD-

DSub 17W2 Male (DB25 Shell size)

VBatt A1

VBatt_Rtn A2

NC 1

USB_VBus 2

USB_D- 3

USB_D+ 4

USB_GND 5

DC- 6

DC+ 7

NC 8

NC 9

DB+ 10

DB- 11

DA+ 12

DA- 13

DD+ 14

DD- 15

Red – 24 AWG

White – 24 AWG

Green – 24 AWG

Black – 24 AWG

White/Orange – 24 AWG

Orange – 24 AWG

White/Green – 24AWG

Blue – 24AWG

White/Blue – 24AWG

1 VBus

2 D-

3 D+

4 GND

USB Std Type A Receptacle

Red – 20 AWG

Green – 24AWG

Brown – 24AWG

White/Brown – 24AWG

RJ45 Gigabit Ethernet Plug (T568B Wiring

Colors)

Black – 20 AWG

2 VBatt

1 VBatt_Rtn

Molex MiniFit Jr Housing PN 0039012020 Socket PN 0039000039

51 | P a g e

The GVR-BOT Diagnostic Cable is created using the pinout in Figure 41 and the parts listed in the Bill of Materials in Table 4.

Table 4 - GVR-BOT Diagnostic Cable Bill of Materials

Description Manufacturer Mfr Part Number Vendor

Vendor Part Number Qty

Price

(USD)

Ethernet Patch Cable - T568B, 3 ft www.cablesandkits.

com PC5-BL-03 www.cablesandkits.

com PC5-BL-03 0.5* $0.84

USB Male - Female Patch Extension Cable, 12 in QVS CC2210C-01 www.staples.com IM1TW8090 1 $4.49

Payload Connector DB25 / 17W2 NorComp

680M17W210 3L401 www.digikey.com NOR1280-ND 1 $9.68

DB25 Backshell Kit TE Connectivity 5748677-3 www.digikey.com A34130-ND 1 $7.83

Network Extender / Joiner Insten n/a www.walmart.com RJ45 Ethernet

Connector Adapter 1 $2.59

20 AWG Red Hookup Wire, ~20 cm length Alpha Wire 3053 RD005 Mouser 602-3053-100-03 1 n/a

20 AWG Black Hookup Wire, ~20 cm length Alpha Wire 3053 BK005 Mouser 602-3053-100-02 1 n/a

Molex Minifit Jr Receptacle Housing 2 position Molex 0039-01-2020 Digikey WM3700-ND 1 $0.28

Molex Minifit Jr Socket Molex 0039-00-0039 Digikey WM2501-ND 2 $0.19

Total Price $25.90

*One Ethernet Patch Cable can be used for two GVR-BOT Diagnostic Cables. Cut the cable in half and use the two ends for two cables.

Notes

Only the receptacle end of the USB Extension cable is used, the other end is discarded.

Any male 17W2 connector can be used, as long as it is the solder cup version and has power lugs, not coax connections.

Appendix B

GPS Antennas & Mounting The GPS uses a standard SMA antenna mount to secure GPS antenna receivers to the robot as seen in Figure 42. The GPS SMA port accepts a wide range of active GPS/GNSS antennas. Any active GPS antenna will work as long as it can accept a 3.3V input to run the active filtering. Most GPS will have this listed on the datasheet or website. However, we have a list of recommended tested GPS antennas below.

52 | P a g e

Figure 42 – SMA GPS Antenna Mount

Compatible SMA Antennas:

Ublox ANN-MS-0-005

Antenna Factor Series: SH (PN: ANT-GPS-SH-SMA)

Appendix C

RTC Information and Reset

The RTC is internally enabled by the Nvidia TX2 processor, and can keep time synchronization for several days if the robot is powered off. However, when first arrival of the GVR-BOT, time synchronization may have to be updated depending on time zones, or if shipment took a while. An easy way to check to see if the RTC is working on the GVR-BOT is to notice if the date and time are kept after a reboot is completed.

To do this ssh into the GVR-BOT and type $date to see the current time and date of the GVR-BOTs processor. If after a hard reboot the date is not synchronized to keep track of time after a reboot, a reset

PowerOn Button

GPS SMA

Antenna Mount

53 | P a g e of the RTC will be needed. If a RTC reset is needed ssh into the GVR-BOT platform and enter the commands below.

In terminal set the date example “2020-3-02 10:06:00”

$sudo date --set " Year-Month-Day Hour:Minutes:Seconds"

In terminal set the hardware clock to the date above

$sudo hwclock -w -f /dev/rtc1

Reboot the robot.

After rebooting the robot check to see if the $date is kept. If not check to see if you typed the date correctly.

The RTC implemented on the GVR-BOT in initial testing can last 3-4 days after powering off the robot.

However, the charging circuit is not the most efficient, and can take 20 minutes to fully charge the super capacitor after power up.

Appendix D

Battery and Charger Information Bren-tronics is the company that manufactures the BB-2590 battery and supplies chargers of different sizes and price ranges.

The National Stock Number (NSN) used to order the batteries for Government purchases can be fulfilled by multiple products…