Arquitectura para Teleoperacion Inalambrica conRealimentacion Visual de ROVs basados en ArduSub

Diego Centelles†, Antonio Soriano‡ Raul Marın† and Pedro J. Sanz†† Departamento de Ingenierıa y Ciencia de los Computadores. Universitat Jaume I

Av. Sos Baynat, s/n, 12071 Castellon de la Plana (Espana)‡ Departament d’Informatica. Universitat de Valencia. Av. de la Universitat, s/n. 46100 Burjassot (Espana)

centelld@uji.es, antonio.soriano-asensi@uv.es, rmarin@uji.es, sanzp@uji.es

Resumen

En este trabajo se presenta la adaptacion de la ar-quitectura de un BlueROV para habilitar la teleop-eracion inalambrica sobre un canal que, por natu-raleza, dispondra de un ancho de banda muy limi-tado. Para ello se propone la aplicacion de un pro-tocolo cross-layer fuera de la pila TCP/IP. El sis-tema de teleoperacion integra el algoritmo de com-presion de imagen progresivo DEBT (Depth Em-bedded Block Tree) para habilitar la realimentacionvisual y utiliza el simulador UWSim como ex-tension de realidad virtual del HRI (Human-Robot-Interface).

Palabras clave: Robotica Submarina, Comuni-cacion Inlambrica, Sonar, Radio Frecuencia, Pro-tocolos Red, Compresion de imagen, Control Su-pervisado

1 Introduccion

La realizacion de actividades en entornos sub-marinos a cierta profundidad suele conllevar unriesgo y unos costes considerables. Cada vez esmas frecuente el uso de robots para la realizacionde tareas relacionadas con la arqueologıa y cien-cias marinas, ası como en el mantenimiento deplataformas petrolıferas o en la industria del gas,porque permite reducir el riesgo y los costes. Lastareas desempenadas por robots en entornos sub-acuaticos son cada vez mas complejas. La real-izacion de algunas de ellas requiere del trabajocooperativo de varios robots. Es necesario que to-dos los robots que colaboran en una misma tareatengan la capacidad de comunicarse, sin necesidadde cables que puedan restringir aun mas su capaci-dad de operacion. Es por este motivo que en losultimos anos ha habido un interes creciente en eldesarrollo de comunicaciones inalambricas en en-tornos submarinos. Este tipo de comunicacioneses especialmente importante en tareas donde senecesitan equipos de robots y sensores realizandotareas de forma cooperativa.

La solucion mas habitual en comunicacioninalambrica submarina se basa en senalesacusticas, que permiten conectar dispositivos sep-

arados a varios kilometros de distancia. El incon-veniente de esta comunicacion es su sensibilidad alruido acustico, lo que restringe el rango de frecuen-cias acusticas a unos pocos kHz. El bajo anchode banda y el elevado retardo (≈ 0.6 ms/m) difi-culta la implementacion de enlaces full-duplex conesta tecnologıa. Ademas, la comunicacion acusticaes sensible a los problemas de camino-multiple enlas proximidades de objetos solidos. A pesar detodo ello se ha podido demostrar la transmisionde video en un entorno submarino empleando uncanal acustico[6].

En los casos en que no es viable el uso de senalesacusticas tambien es posible la comunicacion me-diante VLC (Visible Light Communication)[2].La tecnica VLC proporciona un mayor ancho debanda que las senales acusticas, pero su alcancees limitado, del orden de metros, debido a la aten-uacion de la luz visible en el agua. Es una buenasolucion en aguas claras pero su rendimiento se vemuy afectado en aguas turbias o en funcion de lascondiciones de iluminacion. Otra alternativa esla comunicacion basada en radiofrecuencia (RF)[1]. La comunicacion RF no se ve afectada por laturbidez del agua ni por las variaciones de ilumi-nacion. Sin embargo, la elevada conductividad delagua de mar limita el alcance de la comunicacionsubmarina a unos pocos metros. Ası, en aquellassituaciones en que no se requieran grandes dis-tancias cabe la posibilidad de emplear la comuni-cacion basada en RF o en VLC, que proporcionamejores tasas de transferencia que la comunicacionbasada en senales acusticas.

El presente trabajo se enmarca dentro de losexperimentos del proyecto Nacional Coodi-nado MERBOTS (http://www.irs.uji.es/merbots/), en el cual se pretende avanzaren el contexto de la robotica de intervencionsubmarina, como herramienta que facilite eltrabajo de estudio arqueologico a medias y altasprofundidades. En este proyecto se pretende,como demostracion de las tecnicas desarrolladas,experimentar la recuperacion de objetos delfondo del mar con el uso de dos robots, uno deintervencion y otro de apoyo visual, pudiendotener canales inalambricos (Sonar/RF/VLC) en

Actas de las XXXIX Jornadas de Automática, Badajoz, 5-7 de Septiembre de 2018

408

RF/VLC Link

Acou

stic

Link

Aco

ustic

Figura 1: Vision conceptual del proyecto MER-BOTS

funcion de la necesidad (ver Fig. 1).

Ademas de considerar el medio de comunicacion,es importante el protocolo de transporte em-pleado. Las aplicaciones de telerobotica requierende sistemas de comunicaciones en los que el re-tardo y su fluctuacion (i.e. jitter) sean reducidos.Es por ese motivo que requieren de protocolos detransporte dedicados, como puede ser el BilateralTransport Protocol (BTP) [8], o el Trinomial [3].En el campo de la manipulacion de drones es muyutilizado el protocolo Micro Air Vehicle Commu-nication Protocol (MAVLink). Es un protocolomuy ligero especialmente dedicado para aplica-ciones en las que el ancho de banda disponiblees muy limitado. En este trabajo se presenta unaarquitectura de teleoperacion wireless de un ROV(Remotely Operated Vehicle) basado en el soft-ware ArduSub (www.ardusub.com), que es unaadaptacion para drones subacuaticos del proyectoArduPilot (ardupilot.org).

En el presente trabajo se presenta la arquitec-tura de un sistema de teleoperacion inalambricaen entornos submarinos. En la seccion 2 se de-scribe el hardware y software utilizado para la re-alizacion de la experimentacion. En la seccion 3se describen los diferentes componentes softwarey el protocolo que componen la arquitectura wire-less desarrollada. Seguidamente, en la seccion 4se explican los experimentos realizados para opti-mizar el protocolo, y evaluar su rendimiento. Fi-nalmente, en la seccion 5 se resumen los princi-pales resultados y conclusiones que se extraen deeste trabajo.

2 La Plataforma deExperimentacion

El equipo de experimentacion ha consistido enun ROV basado en la version 1 de BlueROV, los

HROVController

Mavlink over UDP

Vision Based

Positioning

Mavproxy

ArduSub

Robot Operating System (ROS)

QGroundControl as Human-Robot-

Interface (HRI)

HROV’s side

TCP/IP Stack

Operator’s side

Figura 2: Arquitectura basica del sistema de tele-operacion de un BlueROV a traves de umbilical

modems de RF S100 de la empresa WFS (Wire-less For Subsea) y el UWSim [5] como interfaz deVR (Virtual Reality) y herramienta para la simu-lacion del protocolo de comunicacion desarrolladosobre un canal de comunicacion con errores.

El BlueROV utiliza una Pixhawk [4] como placadonde se ejecuta el software de ArduSub. En laarquitectura estandar (con umbilical), la teleop-eracion del BlueROV se realiza utilizando el pro-tocolo MAVLink, ver Fig. 2. Los mensajes deMAVLink se encapsulan en datagramas que sonenviados a una RaspberryPi 3B que se encuentraen el ROV. Una vez en el ordenador de abordo(Raspberry Pi), un programa llamado MAVProxydesencapsula los mensajes MAVLink de los pa-quetes UDP y los reenvıa a traves de un puertoserie donde se encuentra conectada la Pixhawk.La Pixhawk tambien envıa al MAVProxy men-sajes MAVLink que representan diferentes estadosdel robot o respuestas a comandos de alto niveldel operador, los cuales se encapsulan en data-gramas que son enviados al operador a traves delas restantes capas de la pila TCP/IP. Algunosde los mensajes de estado del robot pueden serel nivel de baterıa, informacion de la IMU o laposicion geodesica del ROV. Esta ultima esta fil-trada por un EKF (Extended Kalman Filter) quecombina los datos de la IMU (Intertial Measure-ment Unit), la brujula, sensor de profundidad ylas actualizaciones de posicion GPS (Global Posi-tioning System), las cuales pueden provenir tantode mensajes MAVLink como de un GPS directa-mente conectado a la placa. Existe un paquete deROS (Robot Operating System) llamado mavrosque se comunica con el MAVProxy con el fin deofrecer una interfaz de control del ROV a travesde topics y servicios de ROS. Este nodo en ROStambien puede actuar como un proxy de men-sajes MAVLink. Por otro lado, se suele utilizarQGroundControl como GUI (Graphical User In-terface), la cual envıa y recibe mensajes MAVLinken datagramas hacia un proxy, que puede ser el elpropio mavros o el MAVProxy. La Fig. 2 muestrauna aproximacion simple de la arquitectura de un

409

Main Battery

Watertight Enclosure

S100 Modem

Main electronics:

Camera, RaspberryPi

3B

Payload or additional batteries

Figura 3: Integracion del modem S100 en elBlueROV v1

BlueROV.

Para conseguir una comunicacion sin umbilical seha integrado un modem S100, de la empresa WFS(Wireless For Subsea) en el BlueROV (ver Fig. 3).Estos modems habilitan un canal half-duplex decomunicacion por RF con una velocidad de trans-mision de hasta 2,4 kbps. Estos dispositivos trans-miten los bytes que el programador envıa a travesdel puerto serie encapsulandolos en pequenos pa-quetes con un overhead determinado. Tambienpermiten elegir entre usar una codificacion Manch-ester o normal (de esta ultima, no se especıfica eltipo). La primera protege mejor contra erroresde transmision aunque consume mucho mas an-cho de banda. Tambien permiten configurar otrosparametros como la activacion de reenvıo de pa-quetes ante perdidas, lo cual requiere el envıo depaquetes de reconocimiento automaticos por partedel modem (ACK o Acknowledgment) aumen-tando, en consecuencia, el retardo de los datos.

Se ha utilizado un modulo de UWSim para simularla red (ver https://github.com/dcentelles/

underwater_simulation) con el fin de poder ex-perimentar el protocolo en diferentes condicionesdel canal y cuando no se dispone de los modemsreales. Aunque todavıa esta en una fase tempranade desarrollo, este modulo ya permite simular dis-positivos de comunicacion mediante un modelo es-tadıstico simple de los mismos. Durante la eje-cucion de un escenario de UWSim se simulan tiem-pos de transmision, propagacion y errores en lospaquetes. Los errores pueden ser debidos a laatenuacion de la senal, una colision, o por no haberespacio suficiente en el buffer de transmision. Estemodulo para UWSim realiza llamadas al planifi-cador de eventos en tiempo real y a otras utili-dades de la biblioteca de NS3 (Network Simulator3) para realizar la simulacion de la red. Realizar

ROS

HROVController

Mavlink over UDP

Vision Based Positioning

Mavproxy

ArduSub

Mavlink Bridge

S2CR (Acoustic)

modem

Transport Protocol for Teleoperation

Robot Operating System (ROS)

VR based Human-Robot-Interface (HRI)

Generic Physical Communication Layer Interface

UWSim NetworkSimulator

Cro

ssLa

yer

S100 (RF)modem

VLCmodem

MAC Layer

Operator’s SideHROV’s side

Figura 4: Arquitectura Wireless

simulaciones de la red ha sido facilmente abord-able gracias a una interfaz de abstraccion de lacapa fısica para el envıo y recepcion de paquetes.Esta capa de abstraccion se ha implementado me-diante IPC (Inter-Process-Communication) y seencuentra representada en la Fig. 4 como GenericPhysical Communication Layer Interface o GP-CLI).

3 Arquitectura Software delSistema de TeleoperacionInalambrica Submarina

Debido al ancho de banda tan limitado que ofre-cen los modems S100 serıa impossible retransmi-tir todos los mensajes de MAVLink a traves delcanal de RF. Por esta razon se ha implementadoun protocolo minimalista que no depende de lapila TCP/IP para la comunicacion wireless. Unprograma en la Raspberry Pi del ROV, mostradoen la Fig. 4 como HROV Controller, interpretalos mensajes de este protocolo para luego interco-municarse con la Pixhawk mediante MAVLink, atraves del MAVProxy.

La mision del protocolo desarrollado es hacer lle-gar las ordenes del operador al robot y el estadodel mismo al operador en forma de odometrıa eimagen. Sobre este protocolo se ha implemen-tado un HRI combinando el UWSim y una in-terfaz de controles dedicada para la teleoperacion.El sistema completo habilita al operador el controldel robot tanto por velocidades como por coman-dos de posicion usando coordenadas NED (North-East-Down). El control por velocidades se realizamediante un joystick conectado al computador deloperador. Para el control por posicion, el operadormueve un marcador interactivo en UWSim repre-sentado por un BlueROV semi-transparente haciala posicion deseada. Una vez obtenida, el usuarioenvıa una orden de posicion a traves de la interfazde controles. La interfaz notifica al usuario cuandoel robot ha recibido la orden y cuando la ha com-pletado, siendo capaz de cancelar dicha orden (verFig. 5). Mediante ordenes de alto nivel, el oper-

410

Figura 5: Interfaz de Realidad Virtual conUWSim, controles de operador y feedback visualcon ROI (Region Of In).

ador actualiza los parametros de compresion. Unode estos parametros es el tamano fijo de la ima-gen en terminos de numero de paquetes necesariopara transmitir la imagen en su totalidad. Otroes una region de interes (ROI) en la imagen dondese desea mayor calidad sin aumentar el tamano dela misma. Esta region de interes la selecciona eloperador dibujando una forma rectangular sobrela imagen.

Para maximizar la tasa de envıo y minimizar losretardos es necesario que el protocolo de trans-porte tenga conocimiento del estado del canal decomunicacion y no delegar el control de acceso almedio a una capa inferior. Teniendo en cuentala naturaleza half-duplex del canal inalambrico, elenvıo de una orden al robot debe realizarse cuandohaya certeza de que dicho paquete no va a almace-narse en un buffer de la capa inferior para esperara que el canal este libre para realizar la trans-mision. Por ello, el protocolo desarrollado enviarauna peticion de envio de paquete directamente ala capa fısica cuando exista la seguridad de que elcanal esta libre y que, por lo tanto, no se producirauna colision o un apilamiento del paquete. El pro-tocolo propuesto se basa en un sistema maestro-esclavo, donde el operador es el maestro y el robotel esclavo. El operador (maestro) envıa paquetesal ROV (esclavo) a una cadencia constante. Estospaquetes transportan el estado deseado del roboty ordenes de alto nivel. El tiempo de envıo en-tre un paquete y el siguiente se denomina IPG

0x55 Length Payload CRC16

1 B 1 B 2 B

Figura 6: Formato de las tramas

flags x y z orientation

0 1 2 3 4 5-7

RD Nav. Mode

EOID

LOC HH

ARM

0-8 9-17 18-26 27-31

not used

not used

roll pitch yaw

1 B

2 B 2 B 2 B 4 B 1 B

Image Trunk2-7 STATE10

FT LT ST

Figura 7: Mensaje que transmite el ROV

(Inter-Packet-Gap). Este tiempo ha de ser el su-ficiente para que el ROV transmita un paqueterespuesta con su estado actual, sin colisionar conel siguiente paquete enviado por el operador. Esdecir, el ROV solo lanzara la transmision de unpaquete inmediatamente despues de la recepcionde uno del operador. Se trata pues, de un TDMA(Time Division Multiple Access) controlado por eloperador. La Fig. 6 muestra el formato de tramadonde se encapsulan los paquetes del protocolo.

El protocolo integra el algoritmo de compresionprogresivo DEBT (Depth Embedded Block Tree)[7], lo cual habilita al operador el poder especi-ficar un tamano fijo de la imagen comprimida. Encada paquete enviado por el ROV se transmitela odometrıa del mismo, unas flags de estado yde informacion del paquete, y una porcion de laimagen codificada (ver Fig. 7). Por el otro lado,el operador envıa paquetes con el estado deseadodel robot. Estos paquetes contienen unas flags decontrol y una orden para el robot (ver Fig. 8a).

Mientras no se produzca una orden de alto nivelpor parte del usuario, los paquetes enviados porel operador (ver Fig. 8a) transportan una ordende control de bajo nivel con el estado actual de loscontroles del joystick (ver Fig. 8b). Algunas de lasordenes de alto nivel pueden ser la actualizacionde los parametros de la imagen (ver Fig. 8c) o unaorden de posicion para el ROV (ver Fig. 8d).

A continuacion se detalla cada uno de los camposque contiene el mensaje enviado por el ROV (verFig. 7):

• FT (First Trunk): Indica que el trozo de laimagen comprimida contenido en el mensajees el primero de la imagen.

• LT (Last trunk flag): Indica que el trozo dela imagen comprimida contenido en el men-saje es el ultimo de la imagen. En caso deque toda la imagen este contenida en el men-

411

flags Order

0 1 2-3 4-7

OT

OID

CLO

1 B

not used

(a)

X

0

nav. mode

arm not

used

Y Z flags

5-71-4

Yaw

1 B 1 B 1 B 1 B 1 B

(b)

X0 Y0 X1 ...Y1 ROIlevel

0-39 40-42 43-47

Imagesize

48-63

43-46 47

not used

RGB

/ 8 b

its

(c)

X Y Z not usedYaw2 B 2 B 2 B 1 B 1 B

(d)

Figura 8: Formatos de los mensajes enviados porel operador. (a) Formato del mensaje. (b) Co-mando de velocidades. (c) Comando de com-presion de imagen. (d) Comando Go To.

saje, se activa tanto FT como LT. Cuando serecibe este paquete, se ensamblan todos lostrozos recibidos y se comprueba la integridadde la imagen mediante el codigo CRC (Com-probacion de Redundancia Cıclica) contenidoen los dos ultimos bytes del ensamblado.

• ST (State Type): Este campo de 6 bits sereserva para posibilitar el envıo de otros men-sajes de estado. El estado del robot se rep-resenta en los campos que hay entre este y elcampo IT.

• IT (Image Trunk): Campo que contiene untrozo de la imagen comprimida. El tamanode este campo se calcula haciendo la diferen-cia entre el tamano del payload de la tramadonde se encapsula el mensaje (ver Fig. 6) yla suma de tamanos del resto de campos delmensaje.

• RD (Ready): Indica al operador si el robotesta actualmente ocupado o no ejecutandouna tarea de alto nivel.

• EOID (Expected Order ID): Codifica en unsolo bit el identificador o numero de secuen-cia de la siguiente orden de alto nivel que es-pera recibir del operador. El ROV solo eje-cutara una orden si su numero de secuenciao OID (Order ID) es el mismo que el EOID.Este campo sirve tambien como ACK de larecepcion de la ultima orden.

• LOC (Last order cancelled): Indica si se hacancelado la ultima orden. Es decir, aquellacon OID igual al complemento del EOID.

• HH (Holding Heading): Indica si el robotesta manteniendo una orientacion Yaw deter-minada. La activacion/desactivacion de este

estado se realiza mediante una orden de altonivel.

• ARM (Armed): Indica si el ROV esta ar-mado. Esto es, los motores estan activadospara ejecutar las ordenes del usuario.

• Navigation Mode: Indica el modo de nave-gacion actual del ROV codificado en 3 bits.Los modos de navegacion corresponden a lossoportados por el software ArduSub: Man-ual, Estabilize, Depth Hold, Hold Position, yGuided.

• Posicion NED: Se codifica la posicion NEDcon dos bytes para cada eje.

• Orientacion: Se dedican 9 bits para cadauno de los angulos de navegacion: roll, pitchy yaw.

Por otro lado, el operador (master) envıa paquetescon el formato mostrado en la Fig. 8a. A contin-uacion se detallan los campos de este mensaje:

• OID (Order ID): Codifica en un bit el iden-tificador o numero de secuencia de la orden.El ROV solo tiene en cuenta este campo si setrata de una orden de alto nivel.

• CLO (Cancel Last Order): Un bit para so-licitar la cancelacion de la ultima orden. ElROV realizara la cancelacion si el OID de estepaquete es igual al OID que espera el ROV,es decir, el EOID que envıa en sus mensajes(ver Fig. 7).

• OT (Order Type): Codifica en 4 bits el tipode orden que transporta el mensaje. Depen-diendo del tipo de orden el ROV considerarala orden de alto nivel o de bajo nivel.

Para habilitar el control por posicion es necesarioque se este ejecutando un sistema de localizacionautonomo en el propio ROV. En la Fig. 4 se repre-senta un sistema de localizacion por vision sobreROS. Este programa publica la posicion del ROVrelativa a un punto del escenario, la cual es trans-formada por el HROV Controller a coordenadasgeodesicas que son enviadas a la Pixhawk a travesde mensajes de MAVLink de tipo GPS INPUT.Por lo tanto, es imprescindible que el sistema decoordenadas del escenario virtual (ver Fig.5) cor-responda exactamente con la realidad. Tambienes necesario realizar una buena calibracion tantode la brujula como de los acelerometros de la Pix-hawk, ademas de estar aislados lo mejor posiblede cualquier campo magnetico artificial. Con todoesto funcionando, el software ArduSub habilita el

412

1000

22000

350

End t

o E

nd (

s)

InterpolationSamples

App. data rate (bps)

Packe

t Length

(Byte

s)

50

0

(a)

InterpolationSamples

App. data rate (bps)

Packe

t Length

(Byte

s)

1000 1200 1400 1600 1800 2000 22000

50

100

150

200

250

300

350

0

350

(b)

Figura 9: Estudio de los modems S100. (a) Re-tardo de extremo a extremo. (b) Tasa de envıo.

modo de navegacion Guided, el cual, una vez ac-tivado por el operador permite la navegacion delrobot mediante comandos de posicion.

4 Resultados

En primer lugar se ha ajustado el IPG (Inter-Packet-Gap) de los paquetes enviados por el mas-ter u operador para que el protocolo funcione sinproblemas con los modems de RF S100. Para ellose ha lanzado la transmission de 2000 paquetes dediferentes tamanos y a diferentes velocidades deenvıo, desde 1 hasta 2.3 kbps. El punto donde em-pieza a aumentar el retardo (ver Fig. 9a) y a dis-minuir la tasa de envıo (ver Fig. 9b) correspondecon la maxima tasa de envıo de los modems que,en nuestro caso ha sido sobre los 1.9 kbps. Ha-ciendo una regresion lineal del retardo de extremoa extremo se ha obtenido el retardo intrınseco delmodem. Esta constante coincide con la ordenadaen el origen del retardo de extremo a extremo, lacual ha sido de unos 85 ms.

Teniendo en cuenta el tamano de los paquetesque envıan tanto el robot como el operador, elretardo intrınseco del dispositivo y velocidad detransmision y de propagacion se ha ajustado elIPG de forma experimental para evitar la colisionde los paquetes del operador con los del ROV.

En los siguientes dos apartados se muestran re-sultados de una misma teleoperacion ejecutadacon modems reales en un entorno optimo y unarepeticion de la misma simulando el canal de co-municacion con errores.

4.1 Simulacion HIL con Modems de RF

En este apartado se muestran los resultados deuna simulacion HIL (Hardware In The Loop) deuna teleoperacion con los modems S100. En esteexperimento se ha realizado la teleoperacion deun BlueROV simulado utilizando el simuladorSITL (Software In The Loop) de ArduPi-

00:54:02:000

00:54:03:000

00:54:04:000

00:54:05:000

00:54:06:000

00:54:07:000

00:54:08:000

00:54:09:000

00:54:10:000

00:54:11:000

00:54:12:000

Time

0

50

100

150

200

PD

U s

ize

(byt

es)

op-tx

rov-rx

rov-err

rov-tx

op-rx

op-err

img-tx

img-rx

img-err

Figura 10: Lapso de tiempo de las comunicacionesa traves de los S100.

18:25:000

18:30:000

18:35:000

18:40:000

18:45:000

18:50:000

18:55:000

19:00:000

19:05:000

19:10:000

19:15:000

19:20:000

19:25:000

19:30:000

19:35:000

19:40:000

19:45:000

19:50:000

19:55:000

20:00:000

20:05:000

20:10:000

20:15:000

20:20:000

20:25:000

20:30:000

20:35:000

20:40:000

20:45:000

20:50:000

20:55:000

Time

-100

-50

0

50

100

X r

ate

Operator

ROV

(a)

18:25:000

18:30:000

18:35:000

18:40:000

18:45:000

18:50:000

18:55:000

19:00:000

19:05:000

19:10:000

19:15:000

19:20:000

19:25:000

19:30:000

19:35:000

19:40:000

19:45:000

19:50:000

19:55:000

20:00:000

20:05:000

20:10:000

20:15:000

20:20:000

20:25:000

20:30:000

20:35:000

20:40:000

20:45:000

20:50:000

20:55:000

Time

-100

-50

0

50

100

Y r

ate

Operator

ROV

(b)

18:25:000

18:30:000

18:35:000

18:40:000

18:45:000

18:50:000

18:55:000

19:00:000

19:05:000

19:10:000

19:15:000

19:20:000

19:25:000

19:30:000

19:35:000

19:40:000

19:45:000

19:50:000

19:55:000

20:00:000

20:05:000

20:10:000

20:15:000

20:20:000

20:25:000

20:30:000

20:35:000

20:40:000

20:45:000

20:50:000

20:55:000

Time

-100

-50

0

50

100

Z ra

te

Operator

ROV

(c)

18:25:000

18:30:000

18:35:000

18:40:000

18:45:000

18:50:000

18:55:000

19:00:000

19:05:000

19:10:000

19:15:000

19:20:000

19:25:000

19:30:000

19:35:000

19:40:000

19:45:000

19:50:000

19:55:000

20:00:000

20:05:000

20:10:000

20:15:000

20:20:000

20:25:000

20:30:000

20:35:000

20:40:000

20:45:000

20:50:000

20:55:000

Time

-50

-25

0

25

50

75

Yaw

rat

e

Operator

ROV

(d)

Figura 11: Control de velocidad con los modemS100. (a) Eje x. (b) Eje y. (c) Eje z. (d) Yaw.

lot (ver http://ardupilot.org/dev/docs/

sitl-simulator-software-in-the-loop.

html). Durante el control todo el trafico depaquetes se ha realizado a traves de los modemsde RF sumergidos medio metro de profundidad ysituados uno del otro a una distancia de metro ymedio en un tanque de agua dulce.

La Fig. 10 muestra un lapso de tiempo de los flujosde paquetes y los eventos de captura y recepcionde cada imagen. Como se puede observar, no ex-iste solapamiento entre la transmision de los pa-quetes del ROV y del operador. Debido a que nose han producido perdidas de paquetes duranteel experimento ha sido facilmente posible enlazargraficamente los eventos de transmision con loseventos de recepcion de paquetes y los eventosde captura de imagen con los de su recepcion.La figura tambien muestra como son necesarios elenvıo de varios paquetes para completar la trans-mision de una imagen.

413

01:01:27:500

01:01:30:000

01:01:32:500

01:01:35:000

01:01:37:500

01:01:40:000

01:01:42:500

Time

10

20

30

40

50

60

70

PD

U s

ize

(byt

es)

op-tx

rov-rx

rov-err(PROP)

rov-err(COL)

rov-err(MULT)

rov-tx

op-rx

op-err(PROP)

op-err(COL)

op-err(MULT)

Figura 12: Lapso de tiempo durante comunicacionsimulada con una probabilidad de error por bital 0.07%, un bit-rate de 1.9 kbps y un retardointrınsico del dispositivo de 85 ms.

La Fig. 11 muestra el resultado del control delrobot con comandos de bajo nivel. En ella semuestra, en azul, el estado de los controles de ve-locidad del joystick para cada uno de los ejes dedesplazamiento x, y, z, y la rotacion en Yaw. Lalınea verde de cada grafico muestra la reaccion delrobot, la cual es una aproximacion de la primera,aunque ligeramente desplazada debido al retardode la comunicacion. Se puede observar como esposible realizar un control en tiempo real, aunqueel feedback visual no lo sea. Por este motivo es im-prescindible visualizar el robot en un escenario vir-tual usando la informacion de odometrıa del ROV,la cual sı se recibe en tiempo real.

4.2 Simulacion del Protocolo sobre unCanal con Errores

En los resultados mostrados en el apartado ante-rior no se han detectado errores por atenuacion de-bido a la proximidad de los modems durante el ex-perimento. Las limitadas dimensiones del tanquede agua disponible no nos han permitido experi-mentar a mayores distancias. Por lo tanto, paraponer a prueba el protocolo, en este apartado seha realizado una teleoperacion SITL (Software InThe Loop) simulando el canal de comunicacioncon perdidas usando el modulo de comunicacionesde UWSim. De esta manera se pretende simularel canal de comunicacion que se tendrıa, por ejem-plo, en los lımites del alcance de los modems.

Se ha realizado la misma teleoperacion delapartado anterior de un ROV simulado, pero es-tableciendo una probabilidad de error por bit del0.07%. Concretamente, se ha utilizado el modelode error de NS3 RateErrorModel y el bit comounidad de error. La Fig. 12 muestra la capturade eventos de transmision y recepcion de paque-tes en un lapso de tiempo durante la simulacion.En ella se observa como son mas frecuentes loserrores en los paquetes enviados por el robot queen los enviados por el operador. Esto es debidoa que los paquetes enviados por el robot tienenun tamano bastante mayor. Debido a esto, re-sulta complicado recibir sin errores todos los pa-quetes necesarios para ensamblar la imagen. Noobstante, la frecuencia de llegada de la odometrıa

49:40:000

49:45:000

49:50:000

49:55:000

50:00:000

50:05:000

50:10:000

50:15:000

50:20:000

50:25:000

50:30:000

50:35:000

50:40:000

50:45:000

50:50:000

50:55:000

51:00:000

51:05:000

51:10:000

51:15:000

51:20:000

51:25:000

51:30:000

51:35:000

51:40:000

51:45:000

51:50:000

51:55:000

52:00:000

52:05:000

52:10:000

Time

-100

-50

0

50

100

X r

ate

Operator

ROV

(a)

49:40:000

49:45:000

49:50:000

49:55:000

50:00:000

50:05:000

50:10:000

50:15:000

50:20:000

50:25:000

50:30:000

50:35:000

50:40:000

50:45:000

50:50:000

50:55:000

51:00:000

51:05:000

51:10:000

51:15:000

51:20:000

51:25:000

51:30:000

51:35:000

51:40:000

51:45:000

51:50:000

51:55:000

52:00:000

52:05:000

52:10:000

Time

-100

-50

0

50

100

Y r

ate

Operator

ROV

(b)

49:40:000

49:45:000

49:50:000

49:55:000

50:00:000

50:05:000

50:10:000

50:15:000

50:20:000

50:25:000

50:30:000

50:35:000

50:40:000

50:45:000

50:50:000

50:55:000

51:00:000

51:05:000

51:10:000

51:15:000

51:20:000

51:25:000

51:30:000

51:35:000

51:40:000

51:45:000

51:50:000

51:55:000

52:00:000

52:05:000

52:10:000

Time

-100

-50

0

50

100

Z ra

te

Operator

ROV

(c)

49:40:000

49:45:000

49:50:000

49:55:000

50:00:000

50:05:000

50:10:000

50:15:000

50:20:000

50:25:000

50:30:000

50:35:000

50:40:000

50:45:000

50:50:000

50:55:000

51:00:000

51:05:000

51:10:000

51:15:000

51:20:000

51:25:000

51:30:000

51:35:000

51:40:000

51:45:000

51:50:000

51:55:000

52:00:000

52:05:000

52:10:000

Time

-100

-50

0

50

100

Yaw

rat

e Operator

ROV

(d)

Figura 13: Control de velocidad simulando losmodems con una probabilidad de error de bit fi-jada al 0.07%, un bit-rate de 1.9 kbps y un retardointrınsico del dispositivo de 85 ms. (a) Eje x. (b)Eje y. (c) Eje z. (d) Yaw.

sigue siendo suficiente como para permitir al oper-ador posicionar el robot en una escena de UWSim.Ademas, como se puede observar en los gaficos dela Fig. 13, el control del robot mediante el joysticksigue puediendose realizar en tiempo real.

5 Conclusiones

En el presente artıculo hemos presentado el estadoactual del sistema de comunicaciones inalambricopara el control remoto de un robot submarino. Enconcreto, se han presentado resultados relaciona-dos con el protocolo de comunicaciones, utilizandocomo base un modem de radiofrecuencia, en elcontexto del proyecto MERBOTS.

Teniendo en cuenta los resultados de los ex-perimentos concluimos que es posible controlarremotamente un vehıculo submarino de formainalambrica. No obstante, debido a la baja fre-cuencia de recepcion de las imagenes sera nece-sario el uso de de un modulo de realidad virtual ola implementacion de un control supervisado (me-diante comandos de alto nivel) y no teleoperado.Por lo tanto, se requerira la integracion de unsistema de localizacion inalambrico para el ROVy, debido a las limitaciones del canal de comuni-

414

cacion, tambien sera necesario el uso de un pro-tocolo de red cross-layer dedicado fuera de la pilaTCP/IP. El sistema presentado permite tanto lateleoperacion en tiempo real como un control su-pervisado del robot visualizando el resultado delos comandos antes de ser enviados. Ademas, per-mite la realimentacion visual con region de interesy a una cadencia constante gracias a la integraciondel algoritmo de compresion progresivo DEBT.

Como trabajo futuro se plantea mejorar la in-teligencia de los sensores de vision, con el obje-tivo de no solamente controlar el sistema de com-presion de imagenes, sino tambien extraer infor-macion semantica (e.g. reconocimiento de obje-tos), a ser transmitida a mayor frecuencia, con elobjetivo de mejorar la interaccion con el ususariosupervisor de las tareas roboticas.

Agradecimientos

Los autores agradecen el soporte del GobiernoEspanol, a traves de los proyectos DPI2014-57746-C3 (MERBOTS) y DPI2017-86372-C3-1-R(TWINBOTS), y la ayuda predoctoral BES-2015-073112, la Universidad Jaume I de Castellon conel proyecto P1-1B2015-68 (MASUMIA), y la Gen-eralitat Valenciana (PROMETEO/2016/066).

English summary

Wireless Teleoperation Architecturefor ArduSub based ROVs with VisualFeedback

Abstract

An upgrade of the BlueROV architech-ture is introduced in this work, so thatit enables wireless teleoperations using achannel with extremelly narrow bandwith.A cross layer protocol, appart from theTCP/IP stack is proposed. An progres-sive image compression algorithm, namedDEBT (Depth Embedded Block Tree), isintegrated within the teleoperation system.Thus, providing visual feedback. UWSim-simulator was used as a human-robot in-terface (HRI) virtual reality extension.

Keywords: Underwater robotics, wirelesscommunications, sonar, radio frequency,network protocols, image compression, su-pervised control

Referencias

[1] X. Che, I. Wells, G. Dickers, P. Kear, andX. Gong. Re-evaluation of rf electromag-netic communication in underwater sensornetworks. IEEE Communications Magazine,48(12):143–151, 2010.

[2] H. Kaushal and G. Kaddoum. Underwater op-tical wireless communication. IEEE Access,4:1518–1547, 2016.

[3] P. X. Liu, M. Q. H. Meng, P. R. Liu, and S. X.Yang. An end-to-end transmission architecturefor the remote control of robots over ip net-works. IEEE/ASME Transactions on Mecha-tronics, 10(5):560–570, Oct 2005.

[4] L. Meier, P. Tanskanen, L. Heng, G. H. Lee,F. Fraundorfer, and M. Pollefeys. Pixhawk:A micro aerial vehicle design for autonomousflight using onboard computer vision. Au-tonomous Robots, 33(1-2):21–39, 2012.

[5] M. Prats, J. Perez, J. Fernandez, and P. Sanz.An open source tool for simulation and super-vision of underwater intervention missions. InIntelligent Robots and Systems (IROS), 2012IEEE/RSJ International Conference on, pages2577–2582, 2012.

[6] J. Ribas, D. Dura, and M. Stojanovic. Under-water video transmission for supervisory con-trol and inspection using acoustic ofdm. InOCEANS 2010, volume 1, pages 1–9, NewYork, NY, Sept. 2010.

[7] E. M. Rubino, D. Centelles, J. Sales, J. V.Martı, R. Marın, P. J. Sanz, and A. J. Alvares.Underwater radio frequency image sensor us-ing progressive image compression and regionof interest. Journal of the Brazilian Societyof Mechanical Sciences and Engineering, Aug2017.

[8] R. Wirz, R. Marin, M. Ferre, J. Barrio, J. M.Claver, and J. Ortego. Bidirectional transportprotocol for teleoperated robots. IEEE Trans-actions on Industrial Electronics, 56(9):3772–3781, Sept 2009.

c© 2018 by the authors.Submitted for possibleopen access publication

under the terms and conditions of the CreativeCommons Attribution CC-BY-NC 3.0 license(http://creativecommons.org/licenses/by-nc/3.0/).

415