Escola Politécnica Superior

ROBÓTICA INDUSTRIAL
CURSO 2020/21

PROYECTO DE CURSO CON EL ROBOT

EDUCATIVO

Grado en Ingeniería en Tecnologías Industriales

ALUMNO

FECHA
DICIEMBRE 2020
ÍNDICE GENERAL
INTRODUCCIÓN...............................................................................................2
OBJETIVOS.....................................................................................................2
FUNDAMENTOS TECNOLÓGICOS......................................................................3
HARDWARE: DESCRIPCIÓN DE LOS ROBOTS UTILIZADOS..........................................3
SOFTWARE: ROS Y PYTHON..................................................................................7
DESCRIPCIÓN DEL PROBLEMA A RESOLVER..................................................10
DESARROLLO DE LA SOLUCIÓN.....................................................................12
PRUEBAS Y RESULTADOS.............................................................................14
CONCLUSIONES............................................................................................15

1
INTRODUCCIÓN
En esta memoria pretendo explicar el ejercicio inventado por mí y su
resolución mediante un programa que ha sido realizado en el lenguaje de
programación ROS.
Este proyecto simula un almacén de productos perteneciente a una empresa
de ventas como podría ser Amazon, Zara o Ebay.
Además, se explicará cuáles son los sensores y actuadores tanto de los robots
empleados como de los smartphones conectados a ellos.
A su vez, también se explicarán algunos de los fallos que se han ido
observando a lo largo del desarrollo tanto de los sensores como de los actuadores y
se comentará la solución que se ha buscado para solucionarlos o minorizarlos.

OBJETIVOS
El objeto de este proyecto es simular dicho almacén mediante el uso de 2
robots educativos “Robobo”, 4 pelotas de colores con sus 4 soportes, 2 cajas que
harán de obstáculos y de 13 códigos QR de los cuales: 2 están sobre unas señales, 10
pegados a las 2 cajas y 1 a los bordes del recinto.
Para esta simulación, los Robobos han sido programados de tal forma que
tengan que optimizar recorridos, eligiendo si sale un Robobo u otro en función de la
cercanía al color deseado, siempre y cuando ambos Robobos estén libres; si uno de
ellos está ocupado, el otro Robobo deberá encargarse de la misión sea del color que
sea.
A su vez, los Robobos que ya hayan llevado las pelotas a la zona de recogida,
que nosotros simularemos mediante el Baxter, deberán volver a su lugar de reposo al
que nos referiremos como garaje.

2
FUNDAMENTOS TECNOLÓGICOS
HARDWARE: DESCRIPCIÓN DE LOS ROBOTS UTILIZADOS
Para este proyecto se han empleado dos robots formativos Robobo, los cuales
harán un circuito intercambiando información para conocer datos el uno del otro como
su ocupación. En principio se iba a emplear también el robot Baxter, pero debido a
fallos inesperados hubo que eliminarlo del proyecto, o como es en este caso, simularlo
con un brazo humano.
SENSORES :
Los sensores del Robobo los podemos dividir en dos grandes grupos:
sensores internos y externos. Los externos nos dan información sobre el entorno del
robot mientras que los internos nos la dan sobre el propio robot. A su vez, los sensores
también se pueden clasificar en sensores activos (los que producen un estímulo y
miden su interacción en el entorno) y sensores pasivos (miden señales del entorno).
En el caso del Robobo todos sus sensores son pasivos.
Los sensores externos del Robobo son:
 Sensores Infrarrojos (IR): Estos nos dirán la proximidad o lejanía a un
elemento. El Robobo dispone de 5 frontales y 3 traseros.
 Pantalla Táctil: La app del Robobo cuenta con una funcionalidad de
detección de toques o taps.
 Detector de Colores: Esta función de la app permite que el Robobo sea
capaz de diferenciar entre 4 colores distintos (rojo, azul, verde y uno a
elección), antes de usar esta función debemos calibrar la cámara.
 Detector de QR: Esta es otra de las funciones de la app, la cual le
permite al Robobo detectar un QR, conocer el contenido del mismo y
conocer la distancia al QR detectado.
 Micrófono: La app del Robobo tiene detectores que le permiten
reconocer palmadas.

3
 Figura 1: Sensores de infrarrojos (IR) del Robobo

A su vez, el Robobo también dispone de sensores internos los cuales le

aportan información sobre el Robobo en sí. Los sensores internos de los que dispone
el Robobo son todos pasivos y son:
 Nivel de Batería: Este nos proporciona el porcentaje de batería que le
queda al Robobo. También existe una instrucción al programar que nos
da el nivel de batería del smartphone conectado.
 4 Codificadores (Encoders) de Motor: Disponemos de 2 en las ruedas
del motor (1 en el motor del Pan y 1 en el motor del Tilt). Estos nos
darán información acerca de la posición o velocidad del Robobo en un
momento concreto. Esto es útil por ejemplo, puesto que si hemos
movido el Pan y queremos volver a moverlo, sin conocer la posición en
la que está, deberíamos indicarle cuánto queremos movernos respecto
a su posición actual. Pero como disponemos de un elemento que nos
diría la posición actual, el Robobo se encargará de saber cuánto debe
girar para ponerse en la posición absoluta especificada. Esto es
aplicable a los otros 3 encoders.
 Sensor de Luz Ambiental: La app dirá el nivel de luz que hay en el
ambiente en el que se encuentre.
 El Robobo también dispone de otros sensores como giroscopio,
acelerómetro y magnetómetro.

4
 ACTUADORES :
El hardware del Robobo se compone principalmente de dos elementos: la
base móvil y el smartphone que va colocado en un soporte móvil. Dicho soporte,
podríamos considerarlo como un eslabón con movimientos giratorios (el Robobo no
posee movimientos prismáticos) siendo su unión con la base una articulación rotoide.
El Smartphone y la base se conectan entre sí vía bluetooth.
La base del Robobo cuenta con 3 ‘tipos’ actuadores: 2 motores para las
ruedas, otros 2 que permiten los movimientos de la base del smartphone y las 7 luces
LED (5 frontales y 2 traseras).

Figura 2: Elementos del Robobo

Los motores servo de las ruedas están dispuestos uno a cada lado. Dichos
servos comprenden velocidades entre -100 y 100, siendo los valores positivos
movimientos hacia delante, los negativos movimientos hacia atrás y el valor 0 sería el
reposo. A su vez, cada rueda puede ir hacia un sentido de forma que gire.
El Robobo también dispone de otros dos motores que son los que permiten el
movimiento de la base del Smartphone hacia los lados y hacía arriba o abajo (Pan y
Tilt).
Los valores de movimientos permitidos del Pan (movimiento horizontal) varía
de programar en Python a programar en ROS, puesto que en Python el centro es 0 y
va desde -160 a 160, pero en ROS el centro es 180 y varía de 11 a 343. A su vez, la
velocidad permitida para dicho movimiento va desde 0 a 100 en ambos.
El Tilt, permite movimientos desde 5 a 105 y con velocidades de 0 a 100. En
ROS el ángulo va desde 26 a 109 y el rango de velocidades es el mismo.

5
 Figura 3: Ejes Pan-Tilt del Robobo

La base, como ya se dijo, dispone de 5 luces LED delanteras y 2 luces LED

traseras, estas pueden ponerse de colores como: rojo, verde, azul, cian, magenta,
blanco, naranja y amarillo, o pueden estar apagadas. Estos LEDs son independientes
unos de otros de forma que cada LED puede ir de un color distinto, tener varios
iguales y otros distintos o ser todos del mismo color.
A su vez la app permite que el Robot emplee actuadores dependientes del
smartphone al que esté conectado, estos son:
 Emitir Sonidos: Puede emitir sonidos entre 12 posibles.
 Decir Frases: Puede decir una frase pasándosela como cadena de
caracteres.
 Poner Caras: Puede estar feliz, triste, enfadado, dormido, etc.
 Emitir Notas Musicales: Debemos especificar la nota y su duración.

6
SOFTWARE: ROS Y PYTHON
ROS (Robot Operating System):
Este proyecto está realizado en ROS, el cual es un framework de código
abierto empleado en el desarrollo de aplicaciones robóticas. ROS debe ejecutarse en
plataformas basadas en UNIX como Ubuntu. Aunque en los últimos años algunos
usuarios están haciendo contribuciones de forma que este pueda ser soportado en
otras plataformas de Linux como Fedora o Gentoo, pero también en Windows o Max
OS.
ROS os permite de una forma más o menos “sencilla” emplear sistemas de
multirobot, en el cual un conjunto de robots opera en un mismo entorno real. La idea
del multirobot surge de la idea de que algunas tareas se realizan de forma más
eficiente cuando son realizadas por un grupo. En este entorno las comunicaciones son
mucho más complejas que en el caso de un único robot.
En este caso emplearemos el sistema multirobot para el transporte de objetos
de forma que cooperen intercambiándose datos (su ocupación mediante un True o un
False) para saber que robot debe acudir al trabajo solicitado. Ambos Robobos también
conocen el valor del tap en la pantalla del smartphone el cual indica que objeto
recoger, y en función de estos dos datos acudirá al trabajo uno u otro Robobo. Esto lo
ilustraremos con una tabla de decisiones (hecha en el programa mediante
condicionales) y el diagrama del proyecto.

Figura 4: Plano Proyecto

Caso 1 Caso 2 Caso 3 Caso 4

Robobo Robobo Robobo Robobo Robobo Robobo Robobo Robobo

Izquierdo Derecho Izquierdo Derecho Izquierdo Derecho Izquierdo Derecho
Libre Libre Libre Ocupado Ocupado Libre Ocupado Ocupado

ROJO

VERDE

AZUL

CUSTOM

Tabla 1: Tabla de Decisiones

7
 En este caso hablamos de un equipo de hardware homogéneo puesto que el
proyecto se basa en 2 Robobos idénticos, aunque si hubiésemos podido emplear el
Baxter ya hablaríamos de un equipo de hardware heterogéneo. Dichos Robobos son
conscientes de datos de su compañero (pueden saber si está trabajando o a la
espera) y coordinarse en función de dicha información.
El sistema organizativo del proyecto podríamos decir que es distribuido ya que
no hay un Robobo líder.
Algunas de las principales características de ROS son:
 Computación Distribuida: La mayoría de los robots actuales
requieren software que ejecute diferentes procesos en diferentes
ordenadores. Una práctica común es dividir el software en pequeñas
partes independientes que cooperan para lograr un objetivo propuesto
como es este caso.
 Reutilización de Software: Los avances en robótica de los últimos
años han permitido crear una serie de algoritmos los cuales resuelven
tareas como la navegación, la planificación de tareas, etc. El hecho de
que existan dichos algoritmos nos permite utilizarnos a nuestro antojo
sin tener que volver a programarlos nosotros desde el principio. Lo
mejor de esto es que es independiente del lenguaje de programación
en el que se programe, a día de hoy ROS se implementa en Python,
C++ y Lisp, con bibliotecas existentes en Java y Lua.
 Facilidad de Realización de Pruebas: Esto es así ya que ROS
permite tanto ejecutar los programas tanto en la realidad como en
simuladores, como es el caso de Gazebo. ROS también proporciona
una manera fácil de grabar y reproducir datos de sensores u otros tipos
de mensajes. Esto permite hacer un uso más eficiente del tiempo
invertido en la realización de pruebas que si se trabajase directamente
tomando medidas del robot físico.
 Popularidad: Uno de sus principales puntos fuertes es el elevado
número de personas que emplean ROS en el campo de la robótica.
Esto implica que tiene una gran "masa crítica" que se encarga de
actualizar constantemente los repositorios, poniendo a disposición de
cualquiera nuevos algoritmos o funcionalidades como resultado de
algún proceso de investigación.

8
 Los componentes principales de las comunicaciones en ROS son:
 Nodos: Es la unidad de procesamiento. Normalmente se usan varios.
Un nodo es un ejecutable dentro de un paquete ROS. Para la
construcción de nodos se utilizan librerías cliente: rospy, rosoct, etc.
 Temas (Topics): Son nombres que identifican el contenido de un
mensaje. Los nodos son quienes pueden enviar y recibir mensajes. Se
diseñan en base a dos ideas el ’Publisher’ que es el encargado de
publicar mensajes en un determinado ’topic’, y el ‘Suscriber’ que es el
encargado de suscribirse a dicho ’topic’ y recibirá los mensajes
publicados por el ’Publisher’.
 Mensajes: Los mensajes son estructuras de datos simples que se
pasan entre los distintos nodos. Los mensajes son el contenido de los
‘topics’. Algunos de los tipos más comunes de datos son los ‘integers’
(1, 2, 50, -100, …), los ‘floats’ (2’4, 5’69, -103’8, …) y los ‘booleans’
(True o False), además podemos crear tipos personalizados.
 Servicios: Están diseñados en una arquitectura cliente/servidor entre
nodos. Utilizan dos mensajes uno de solicitud y otro en la respuesta a
dicha solicitud. El nodo servidor se mantiene a la espera de las
solicitudes y cuando el nodo cliente realiza una solicitud el nuevo
servidor realiza un procesamiento y responde al cliente.
 Master: Es una colección de nodos y programas que deben lanzarse
antes de cualquier otro elemento. Sirve de punto de unión entre nodos.
 Bolsas (Bags): Las bolsas son archivos para guardar y volver a
ejecutar datos de comunicación en ROS. Sirven para memorizar una
serie de órdenes y después volver a repetirlas secuencialmente.
Permiten la reutilización de datos que son difíciles de recopilar pero
útiles para el desarrollo y las pruebas.

Nodo

Nodo Nodo

Roscore

Nodo Nodo

Nodo

Figura 5: Unión entre Nodos

Python:
Python es un lenguaje de programación diseñado por Guido Van Rossum a
finales de la década de los 80. La primera versión de Python se publicó en Febrero de
1991 en Ámsterdam.
Python es un lenguaje orientado a objetos. Es un lenguaje simple por su
sencillez en la sintaxis, es un lenguaje interactivo lo que significa que se puede
interactuar directamente con el intérprete para escribir programas. En ROS existe
‘rospy’ que es una librería de cliente en Python para ROS.

9
DESCRIPCIÓN DEL PROBLEMA A RESOLVER
El objetivo de este proyecto es el de simular un almacén de una empresa de
ventas tipo Amazon, Zara, Ebay, etc. En este almacén habrá productos que se querrán
llevar desde su lugar de almacenamiento a una zona de recogida.
Los productos serán transportados por 2 robots educativos Robobo
controlados por 2 scripts programadas en ROS. El hecho de elegir este lenguaje de
programación en lugar de Python es debido a que mi intención es que ambos Robobos
se muevan simultáneamente.
Los productos de la realidad, los representaremos mediante bolas de colores
(Rojo, Azul, Verde y Amarillo) las cuales deberán ser llevadas a la zona de recogida
que hemos llamado “Zona Baxter” mediante el uso de un “Pusher”. A su vez, los
Robobos deberán salir y volver de una zona llamada Garaje (Izquierda o Derecha en
función del Robobo) después de haber recorrido el camino indicado en función del
color elegido.

Figura 6: Plano en Planta de Proyecto con y sin Robobos

Al iniciar el programa el Robobo se subscribirá a los distintos topics elegidos y

publicará en los indicados (esto se explicará más en detalle en el siguiente punto).
Después, se pondrá en su posición inicial, mirando hacia delante y con el Tilt recto.
A continuación, dirá el porcentaje de batería que tiene y pedirá el color que se
desee recoger. Nosotros le indicaremos el color tocando en las distintas zonas de la
pantalla de la forma en la que se indica en la figura inferior. Aunque antes de esto, el
Robobo ya habrá puesto los LEDs delanteros de la forma que se ve abajo indicando
así qué color corresponde a cada zona.

10
 Figura 7: Selección de Color en Función del TAP

Una vez seleccionado el color, y estando los dos Robobos en el garaje, el

Robobo más cercano al color escogido se pondrá en camino. Es decir, si se elige el
color ‘VERDE’, acudirá el Robobo de la derecha por estar más cerca, pero si se
selecciona el color ‘AMARILLO’, irá el Robobo de la izquierda independientemente de
en que Robobo se haya solicitado el color.
Después el Robobo más cercano a la pelota empezará su recorrido guiándose
por señales QR hasta llegar al color. Una vez esté delante del color, lo detectará con
los sensores infrarrojos y dirá una frase informando que lo ha encontrado. Al hacerlo
en ROS no hay forma de comprobar si el color que ha encontrado es el correcto o no,
puesto que la app “Robobo Developer” aún no dispone de la función de detección de
colores.
Cuando finalice la frase de confirmación de haber encontrado el color, irá
hasta el fondo si no está ya en él y girará a la izquierda o derecha dependiendo de
dónde esté hasta llegar a la “Zona Baxter”. Allí esperará 8 segundos, tiempo en el cual
el Baxter recogería la pelota. Esto en la demostración lo hubo que cambiar puesto que
el Baxter ha sufrido algunos problemas y no podemos hacer uso de él.
En este punto el Robobo ya no transporta mercancía y deberá volver al garaje
donde esperará el siguiente pedido. Este trayecto hasta el garaje lo hará guiándose
por señales QR hasta llegar de nuevo a la zona de espera de pedidos donde leerá un
QR que le indicará que pare.

11
DESARROLLO DE LA SOLUCIÓN
Este proyecto ha ido evolucionando en función de mi aprendizaje de ROS
puesto que algunas de las funciones no están disponibles en la app para ROS
“Robobo Developer” como pueden ser el “setEmotionTo” o la detección de colores.
Por algún motivo que a día de hoy sigo sin conocer, el método “setEmotionTo”
hace que la aplicación “Robobo Developer” se cierre instantáneamente. Aunque hay
que decir que no es la app publicada en el Play Store la cual es estable pero no
dispone del detector de QRs. A lo largo de todo el proyecto he usado una versión de la
app más avanzada pero que aún está en desarrollo y por ello tiene algunos fallos
como ese.
Como ya he dicho uno de los factores que han afectado a los cambios que ha
ido sufriendo el proyecto es el hecho de que las detecciones de QRs y de otros
sensores, como el de la batería, funcionan distinto en ROS que en Python. Esto lo he
ido descubriendo según aprendía a programar en este framework.

Figura 8: Idea Original

La principal diferencia es que en ROS solo publica cambios, es decir, cuando

detecta un código QR, indica la distancia al mismo, pero solo esa vez. Una vez que lo
ha detectado no lo vuelve a actualizar, siendo así mi idea original de que se fuese
acercando a algunos QR y parase cuando la distancia fuese menor a X valor, esto es
algo imposible puesto que como ya he dicho solo va a devolver el valor de la distancia
del momento en que detecte el QR. Esto mismo ocurre con la batería, en mi programa
el Robobo nada más arrancar dice: “Hola me queda un X % de batería. ¿Qué color
Quieres Que Coja?” y solo dirá el valor correcto si cuadra que justo en ese momento
haya cambiado el porcentaje por el hecho de descargarse al usarlo.
Para salvar la diferencia con Python de los QR simplemente tuve que cambiar
la ubicación de los mismos y la forma en la que los Robobos verían dichos QR. Lo que
hice fue mover los QR del fondo, excepto el del Baxter, y girarlos 90º, a su vez el
Robobo debería ir mirando a la izquierda o derecha en función del QR.

12
 Figura 9: Idea Original Modificada

La evolución de la idea del proyecto también ha ido cambiando según he ido

descubriendo los puntos débiles del Robobo. En este aspecto solo tengo una cosa que
destacar y vuelve a tener que ver con la detección de QRs, la cual a veces no es del
todo perfecta. Esto creo que es debido a ‘ruido’, es decir, algunos factores como los
cambios de luz, brillos extraños o sombras, provocan que la lectura de dichos QR no
sea todo lo buena que se espera. Esto me ha hecho intentar reducir el número de QRs
al mínimo posible, para evitar así el mayor número de fallos.

Figura 10: Idea Final

El siguiente problema al que me he tenido que enfrentar es el hecho de que

uno de los Robobos, concretamente el de la izquierda, no se mueve en línea recta, se
desvía hacia la izquierda de 10 a 20 centímetros por cada metro que avanza. Para
solucionar esto he ido observando a base de prueba y error, cuánto más debe girar la
rueda izquierda que la derecha para evitar ese desvío.
13
PRUEBAS Y RESULTADOS
En este punto plantearé cómo han sido las pruebas del programa hasta lograr
que este funcione correctamente. Las pruebas se realizaron en 3 ubicaciones distintas:
el aula de vídeo IV del edificio de talleres, el laboratorio del Baxter y mi casa.
Los resultados obtenidos han sido muy distintos según el lugar de elaboración
de las pruebas, siendo el laboratorio del Baxter el más problemático donde la tasa de
lectura de códigos QR rondaba el 25%. En el aula de vídeo IV, dicha tasa subía
aproximadamente hasta un 50% y en mi casa esta cifra aumenta hasta el 80%.
Todavía no sé el motivo por el cual la tasa de lectura es tan variable puesto que el
código es el mismo.
Para la realización de las pruebas hay que ejecutar cada script desde un
terminal distinto. Una vez en el terminal debemos ejecutar los siguientes comandos:

Figura 11: Terminal Donde se Ejecuta el Script del Robobo Derecho

En la primera línea entro a la carpeta ‘ros_ws’, en la segunda, ejecuto el

archivo ‘[Link]’ el cual está almacenado en la carpeta ‘devel’. En la tercera línea
exporto el master con la IP del mismo e indico el puerto. En mi caso, el master será el
smartphone del Robobo de la derecha. Y, por último, en la cuarta línea, ejecuto el
script del Robobo de la derecha, el cual está guardado en la carpeta
‘robobo_examples’. En otro terminal tendré que hacer lo mismo, pero cambiando el
nombre del script al de la izquierda.
Si quisiéramos saber si nos hemos conectado correctamente al master, antes
de ejecutar el programa, podríamos ejecutar el comando ‘rostopic list’, este nos
debería de devolver la lista de topics de cada Robobo. Esto también sirve listando los
servicios con ‘rosservice list’.
En este momento ya se ejecutaría el programa y el Robobo estaría solicitando
el color a recoger.

14
CONCLUSIONES
Considero que el robot educativo Robobo es un elemento muy útil a la hora de
aprender a programar en lenguajes como Python y ROS, que son los que yo he
utilizado. Es una buena forma de aprender a programar con elementos reales
sustituyendo a los clásicos ejercicios matemáticos con los que aprendimos a
programar en C. De las dos formas se aprende, pero se hace mucho más ameno, es
más aclaratorio y lo más importante es que estás viendo en un caso real lo que estás
programando.
No todo es bueno puesto que como ya se mencionó, algunos de los sensores
como la detección de QR falla bastante independientemente de cómo esté construido
el programa y provoca que todo falle. Esto lo digo después de hacer más de 50
pruebas en total y ver que el funcionamiento del mismo es altamente dependiente de
los factores externos a los que está sometido.
A veces ejecutando el programa, y una vez que finalizó volviéndolo a ejecutar,
comete fallos que en la primera vez no ocurrieron. Estos fallos a los que me refiero
están asociados a 2 elementos del programa:
 Porcentaje de Batería
 Detección de QRs
El principal de todos estos problemas es la detección de QR puesto que, con
el otro fallo, aunque estropeen la exposición al no decir el porcentaje correcto, no
provocan que todo el proyecto fracase, que es lo que ocurre con la mala sensorización
de los QR.
En el momento en que no detecte uno de los códigos QR que hay repartidos
por todo el plano, el Robobo no solo estará perdido yendo recto hacia el horizonte, si
no que hay riesgo de que colisione con el otro Robobo si se cruzan. De esta forma no
solo perdería su propio camino si no que provocaría que su compañero robótico
perdiese su trayectoria e incluso dependiendo de la colisión alguno de los robots
podría deteriorarse.
Como ya se ha mencionado, he intentado minorizar los errores de muchas
formas, haciendo que el Robobo avance yendo más despacio y con pausas. De esta
forma hago que el QR siempre quede dentro del ángulo de visión de la cámara.
Aunque esto no fue suficiente puesto que aproximadamente el 80% de las veces
pasaba de largo el QR. Por ello reduje el número de QR y empleé los infrarrojos que
funcionan mucho mejor.
Si hubiese tenido más tiempo y la app incluyese la opción de detección de
colores me habría gustado hacer un proyecto más complejo. En dicho caso cuando el
robot llegase al color deseado, identificaría si es el correcto o no, si no fuese el
correcto, lo recogería y lo llevaría a su ubicación adecuada. También me habría
gustado poder usar el robot Baxter que por ciertas complicaciones no pudimos usar.
Pero en el cómputo global creo que el trabajo y la asignatura han sido muy
útiles a la hora de acercarnos el mundo de la robótica industrial, algo que no habíamos
visto en toda la carrera, además de que aprendimos a programar en Python y ROS lo
que puede sernos muy útil en un futuro.

15