Tesis
Temas abordados
Tesis
Temas abordados
Facultad de Ingenierı́a
T E S I S
QUE PARA OBTENER EL TÍTULO DE:
INGENIERO MECATRÓNICO
PRESENTA:
Eduardo Daniel Ruiz Libreros
DIRECTOR DE TESIS:
Dr.Vı́ctor Javier González Villela
2013
Dedicatorias
A la DGAPA por el apoyo brindado para la realización de este trabajo, a través del
proyecto PAPIIT IN115811 con Tı́tulo: “Investigación y desarrollo en sistemas
mecatrónicos: robótica móvil, robótica paralela, robótica hı́brida y teleoperación”.
Resumen
1. Introducción 5
1.1. Apectos Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Trabajo Previo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1
5.2.3. Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A. Adquisición de Datos 81
B. Código Arduino 83
2
Índice de figuras
2.1. Taxonomı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3
6.1. Funcionamiento general de la Simulación . . . . . . . . . . . . . . . . . . . 50
6.2. Condiciones iniciales en la Simulación . . . . . . . . . . . . . . . . . . . . . 52
6.3. Navegación y aproximación al objetivo . . . . . . . . . . . . . . . . . . . . 53
6.4. Trayectoria del robot 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.5. Postura del robot 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.6. Trayectoria del robot 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.7. Postura del robot 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.8. Transporte evadiendo obstáculos . . . . . . . . . . . . . . . . . . . . . . . . 58
6.9. Variación en el radio de campos repulsivos . . . . . . . . . . . . . . . . . . 59
6.10. Postura del objeto durante el transporte . . . . . . . . . . . . . . . . . . . 60
6.11. Orientación de los robots durante el transporte . . . . . . . . . . . . . . . . 61
6.12. Entorno de trabajo con condiciones adversas para el transporte . . . . . . . 62
6.13. Transporte sin considerar orientación . . . . . . . . . . . . . . . . . . . . . 62
6.14. Transporte considerando orientación . . . . . . . . . . . . . . . . . . . . . 63
6.15. Ajuste de posición para enganche . . . . . . . . . . . . . . . . . . . . . . . 64
6.16. Ajuste de posición por deformación . . . . . . . . . . . . . . . . . . . . . . 65
6.17. Correción de coordenadas de cámara plano XZ . . . . . . . . . . . . . . . . 65
6.18. Correción de coordenadas de cámara plano XY . . . . . . . . . . . . . . . 66
6.19. Funcionamiento Control en Tiempo Real . . . . . . . . . . . . . . . . . . . 67
6.20. Condiciones iniciales experimento 1 . . . . . . . . . . . . . . . . . . . . . . 68
6.21. Simulación de la configuración del experimento 1 . . . . . . . . . . . . . . 68
6.22. Experimento 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.23. Trayectoria robot 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.24. Trayectoria robot 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.25. Velocidades de motores en robot 1 . . . . . . . . . . . . . . . . . . . . . . . 72
6.26. Velocidades de motores robot 2 . . . . . . . . . . . . . . . . . . . . . . . . 72
6.27. Condiciones iniciales experimento 2 . . . . . . . . . . . . . . . . . . . . . . 73
6.28. Simulación del entorno para experimento. . . . . . . . . . . . . . . . . . . . 74
6.29. Experimento 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.30. Trayectoria del objeto durante el transporte . . . . . . . . . . . . . . . . . 75
6.31. Postura del objeto durante el transporte . . . . . . . . . . . . . . . . . . . 75
6.32. Orientación de los robots durante el transporte . . . . . . . . . . . . . . . . 76
6.33. Radio de campo repulsivo de los objetos durante el transporte . . . . . . . 77
4
Capı́tulo 1
Introducción
5
El diseño de hardware sofisticado capaz de realizar tareas demandantes
El diseño de software de control inteligente que permite a los robots lograr resultados
globales coherentes basados en acciones de control locales.
La robótica colaborativa estudia las ventajas que representa tener equipos formados por
múltiples robots para la realización de tareas y como mejorar el desempeño en la realiza-
ción de estas.
Inspiraciones Biológicas
Comunicaciones
Coordinación de movimientos
Robots reconfigurables
6
en [3] Fukuda y Nakagawa proponen una arquitectura jerárquica y descentralizada inspi-
rada en la organización celular de algunos seres vivos llamada CEBOT (Cellular roBOTics
system). Beni en [4] hace un análisis de la estructura de los sistemas celulares, resaltando
las diferencias con los autómatas y las redes neuronales. En [5], Asama et al. proponen un
sistema descentralizado de agentes heterogéneos capaces de comunicarse, asignar tareas y
planear movimientos llamado ACTRESS (ACTor-based Robot and Equipments Sythetic
System). Caloud et al. en [6] desarrollan una arquitectura orientada a resolver problemas
como tolerancia ante contingencias, planeación y control de movimientos y planeación de
tareas.
Dentro del área de Transporte y Manipulación se han hecho varios acercamientos desde
diferentes enfoques; por ejemplo en [7], Parker se enfoca en tolerancia a fallas, aprendizaje
y asignación de tareas. Por otro lado Donald et al. en [8], analiza dos protocolos diferentes
para empujar cajas enfocándose en las comunicaciones y los requerimientos de hardware.
La tarea de empujar objetos mediante múltiples robots es quizás de las tareas más estu-
diadas, por ejemplo [9] y [10]. Otra propuesta es cuando los robots cargan o agarran los
objetos para llevarlos hasta su posición final como en [11], [12] y un variante con sogas en
[13].
En el año 2002, Asama et al. en [14] muestran una propuesta que permite a los robots
mover obstáculos que interfieran durante el transporte. Además de las respectivas simu-
laciones, implementan fı́sicamente su sistema con dos robots navegando en un ambiente
estático. También en ese año Kumar et al. en [15], hacen un acercamiento a la manipula-
ción colaborativa basándose en el control de la formación de tres robots. En su propuesta
los objetos a manipular son rodeados o “encerrados” por la formación de los robots.
Entre los acercamientos más importantes a la robótica móvil colaborativa más recientes
está [16] y [17] , ambas propuestas hacen el transporte de cajas cargándolas con un par de
robots. Los robots cuentan con una plataforma con rotación libre que les permite alinearse
en todo momento para soportar mejor la caja. Ambos trabajos utilizan sensores ópticos,
mientras que en [16] utilizan sensores infrarrojos, en [17] utilizan laser.
En 2008 Fink et al. en [18], proponen una sistema de transporte descentralizado en un
ambiente con obstáculos, el transporte se realiza rodeando el objeto a transportar (Caging
en ingles). El sistema descentralizado se basa en que los robots no comparten ninguna
información, la tarea se realiza con la información local de cada robot y se confı́a en
ella. Finalmente en 2011 en [19] proponen un modelo difuso de control para transportar
objetos empujándolos (box pushing).Entre las ventajas del modelo es que se adapta a
prácticamente cualquier número de robots que participen en el transporte.
7
la robótica colaborativa; realizar una tarea compleja con múltiples robots de arquitectu-
ra simple. La necesidad de contar con un sistema colaborativo de robots tiene grandes
aplicaciones en la industria, ejemplo de ellas son el transporte de sustancias peligrosas,
pesadas o muy grandes.
Tomando en cuenta que los sistemas multi-robot brindan redundancia y contribuyen a
resolver las tareas de una forma más confiable, rápida e incluso de menor costo, es impor-
tante desarrollar algoritmos y modelos para el control sistemas multi robot, en especı́fico
del transporte colaborativo. En el ámbito local, existen importantes teorı́as en el campo
de la robótica móvil como [20]; resulta interesante verificar la aplicación de estas teorı́as
al ámbito del transporte colaborativo y desarrollar nuevos algoritmos en está importante
área.
1.4. Objetivo
El objetivo de este trabajo es desarrollar un sistema de transporte de objetos con
formas geométricas regulares, utilizando robots móviles colaborativos capaces de planear
y seguir trayectorias,ası́ como de evadir obstáculos. Se utilizará la teorı́a unificadora de
Gonźalez Villela en [20] ası́ como el desarrollo planteado en [21]. Se desarrollará una
algoritmo capaz de coordinar y planear la trayectoria de dos robots móviles de forma
que estos puedan: navegar hasta el objeto a transportar, orientarse correctamente para la
toma o enganche de este objeto y finalmente transportarlo hasta una meta final.
1.5. Organización
Para el desarrollo de esta tesis, el trabajo se ha organizado en 7 capı́tulos. A conti-
nuación se hace una breve descripción de su contenido:
8
Capı́tulo 5: Aquı́ se describe como funciona la simulación generada para comprobar el
algoritmo de coordinación y navegación. Se detallan las consideraciones necesarias
para el funcionamiento correcto del software. Además se describen los elementos del
modelo funcional con el que se harán experimentos.
Capı́tulo 6: En esté capı́tulo se especifican las pruebas realizadas y los resultados arro-
jados por estas. Se presentan gráficas y datos útiles para la documentación de las
pruebas tanto hechas en simulación como experimentales.
9
Capı́tulo 2
Construir varios robots con recursos limitados es más fácil que un solo robot muy
complejo.
Múltiples robots pueden resolver los problemas más rápido utilizando paralelismo.
De una forma muy general general, [22] hace una aproximación que solo considera
principalmente dos categorı́as: Enjambre (swarm en ingles) o sistema colectivo y sistemas
intencionalmente colectivos. Los primeros están basados en robots que ejecutan sus tareas
con la mı́nima necesidad de información sobre el resto de los miembros de sistema(también
llamado comportamiento eusocial). En cambio, en los sistemas intencionalmente colectivos
los robots se basan en el estado, las acciones y las capacidades de los demás miembros
para ejecutar sus tareas(llamado comportamiento cooperativo).
Otra clasificación se basa en el mecanismo de interacción, el cual dará caracterı́sticas
y capacidades particulares al sistema. Según [1] los principales mecanismos de interacción
en estos sistemas multi-robot son:
Colectivo: Involucra robots simples que no están al tanto del resto de los integrantes
del sistema, a pesar de compartir metas comunes. En estos sistemas las acciones
individuales resultan en el beneficio del sistema.
10
Cooperativo: Involucra robots que están “conscientes” de los demás integrantes. Las
acciones individuales de los robots se traducen en un beneficio para el equipo.
2.2. Taxonomı́a
Para aclarar las variantes que existen dentro los SMR se hará una breve clasificación
de las arquitecturas, comunicación y localización existentes. De esta forma será más fácil
comprender el tipo de sistema a desarrollar y sus caracterı́sticas, limitaciones y aplicacio-
nes.
2.3. Arquitecturas
Se refiere a la forma que interactuan, funcionan y están organizados los distintos com-
ponentes del robot, tanto en hardware como software. De modo que podemos identificar
tres distintas:
11
Reactiva: A partir de la información de los sensores mide o adquiere las caracterı́sti-
cas del entorno, de forma que no es necesario contar con una representación del
entorno.
Hı́brida: Como su nombre lo indica, representa una combinación entre los casos
anteriores. Combina la capacidad de respuesta de la arquitectura reactiva con la
representación de la deliberativa.
Ahora bien, con base en las arquitecturas mencionadas los SMR presentan arquitecturas
más complejas, que en un nivel más alto le permitirán a un conjunto de robots organizarse
para desempeñar sus tareas. Estas dos arquitecturas son:
2. Descentralizada: Aquı́ los robots perciben el entorno y toman sus propias decisiones
sin necesidad de un control o agente central. Esta arquitectura presenta dos subtipos:
Cabe mencionar que no todos los sistemas multi robot son completamente centralizados
o descentralizados.
2.4. Comunicación
Gracias a la comunicación los elementos del SMR pueden intercambiar información
sobre el entorno, el estado de la tarea o información especı́fica para algún robot. En este
rubro la SMR se pueden clasificar como:
12
2.5. Localización
La localización se refiere a estimar la posición de un robot dentro de un área de tra-
bajo. Ya sea ambientes internos o externos los robots necesitan conocer su posición para
completar de manera satisfactoria su objetivo. Existen diferentes técnicas para realizar
dicha medición, la mayorı́a se basan en la información proveniente de los sensores, por
ejemplo la odometrı́a. También puede ser que los sensores reconozcan marcas en el en-
torno que permitan hacer algún tipo de triangulación para conocer la posición del robot.
Podemos clasificar la localización como:
Local: Consiste en hacer un seguimiento del movimiento del robot a partir del cono-
cimiento de la posición inicial del mismo. Una de las técnicas más empleadas es la
odometrı́a. Este tipo de localización genera una buena cantidad de errores y existen
diferentes técnicas para corregir la información generada, dichas técnicas pueden ser
el uso de marcas.
Global: Este tipo de localización permite determinar la posición del robot sin tener
la referencia de la posición inicial. En este caso se utilizan enfoques probabilı́sticos
como teorı́a de Bayes, filtro de Kalman o cadenas de Markov.
13
Capı́tulo 3
14
Figura 3.1: Campos potenciales Artificiales
El robot es llevado de su posición inicial hasta la meta bajo las siguientes reglas:
(
vmax si |dg | > kr
v = vmax (3.1)
kr
dg si |dg | ≤ kr
15
del mismo ρr . La función de campo potencial que modela entonces a los obstáculos es:
(
1
η( 1 − 1 ) si ρc ≤ ρo + ρr
Uo = 2 ρc −ρr ρo (3.3)
0 si ρc > ρo + ρr
16
Figura 3.2: Puntos de predocking
17
Figura 3.3: Algoritmo para navegación predocking
Cabe destacar que las velocidades calculadas se generan con el método de campos
potenciales, con la única condición de que el robot primero corrige su orientación antes
de avanzar al siguiente nodo. Esto se debe a que el espacio de trabajo es reducido y las
18
velocidades de desplazamiento del robot no permitirı́an un movimiento más natural.
19
(a)
(b)
(c)
Recordando que el control por campos potenciales trata al robot como una partı́cula
20
transfiriendo las dimensiones a los obstáculos. La forma de calcular el radio de influencia
del obstáculo es la siguiente:
1. Se traza una recta hacia el centro del obstáculo.
3. La distancia del centro del robot a la intersección es el valor del radio de influencia
del obstáculo
En la siguiente figura se ilustra un ejemplo de distintos radios de influencia para obstáculos
de iguales dimensiones.
21
En donde:
El caso expuesto representa el de mayor complejidad a tratar, pues los casos de figuras
geométricas como cuadrados o triángulos, se pueden considerar dentro de un circulo de
radio igual a la longitud de total de la configuración. Esto hace que el radio de influencia
de los obstáculos se mantenga constante.
22
(a)
(b)
23
Capı́tulo 4
Una vez planeada la trayectoria a seguir es necesario tener una representación ma-
temática de los robots a utilizar para poder controlar su movimiento de manera idónea.
Para este trabajo se utilizaron dos robots del tipo (2,0), los cuales son bien descritos en
[20].
Como se comentó anteriormente, la tarea se divide en dos casos: el primero es cuando los
robots necesitan llegar y sujetar al objeto, el segundo cuando lo transportan al destino
final.
Para hacer el análisis de un robot móvil se toman en cuenta dos sistemas de [Link]
primero es el sistema inercial o base sobre el cuál se mueve el robot (X,Y) y el segundo
esta centrado en la posición del robot (X1 , Y1 ).
24
Figura 4.1: Postura de un robot móvil
ξ = [x, y, θ]0
Lo más importante es que también nos permite trasladar vectores de velocidad. Ahora
podemos obtener el modelo del robot móvil diferencial representado en variables de estado
x˙1 cos θ1 d ∗ sin θ1
y˙1 = − sin θ1 −d ∗ cos θ1 v1 (4.1)
ω1
θ˙1 0 1
Para el segundo robot se sigue el mismo análisis por lo que se presenta el mismo modelo
ahora con el sistema (X2 , Y2 )
x˙2 cos θ2 d ∗ sin θ2
y˙2 = − sin θ2 −d ∗ cos θ2 v2 (4.2)
˙ ω2
θ2 0 1
25
4.1.2. Modelo Cinemático
De igual forma que el desarrollo anterior se toma en cuenta el trabajo realizado en [20]
para obtener el modelo cinématio del robot diferencial tipo (2,0).
nT = 3 + NT + Nc + Noc (4.3)
En donde:
26
alrededor de su eje.
Haciendo el desarrollo matemático necesario se puede obtener la representación en varia-
bles de estado del modelo cinemático, quedando:
cos θ d ∗ sin θ
sin θ −d ∗ cos θ
v
q̇ =
1 0 1
ω (4.4)
b
r r
1 b
r
− r
En donde el vector de velocidades generalizadas q̇ esta dado por la ecuación 4.3 y para el
caso de un robot diferencial tipo (2,0) es:
T
q̇ = ẋ1 ẏ1 θ̇1 φ̇1l φ̇1r
27
Figura 4.3: Configuración propuesta para el transporte
En dónde a2 será la longitud del objeto a transportar divida entre dos y b el la pro-
fundidad o ancho del objeto. El resto de las dimensiones especificada en la figura 4.3 ya
se vieron anteriormente y están relacionadas con las dimensiones de cada robot móvil de
tracción.
Para realizar la cinemática inversa de la configuración se utilizan el método de la propa-
gación de velocidades. El desarrollo matemático completo es tomado de [21].
Este método nos permite hacer la propagación de los diferentes subsistemas que encontra-
mos en la configuración propuesta. Lo que el método sugiere es que la velocidad angular
del eslabón i+1 relativa a su propio sistema de referencia es igual a la velocidad angular
del eslabón i con respecto al sistema i+1 más una componente propia del eslabón i+1.
i+1
i+1 ω = i+1 i i
i R × i ω + i θ̇ (4.6)
Por otro lado la velocidad lineal del eslabón i+1 en relación con sigo mismo es igual a la
velocidad lineal del eslabón i más la velocidad lineal provocada por el brazo de palanca
i
i+1 P y la velocidad angular de ip . Todo referenciado al sistema i+1
i+1
i+1 v = i+1 i i i
i R × (i v + i ω × i+1 P ) (4.7)
28
Figura 4.4: Metodo de propagación de velocidades del eslabón i al i+1
Ahora bien, el punto de análisis será el centro del objeto a mover Pp , por lo que se procede
a hacer la propagación de velocidades desde Pp a cada una de las ruedas.
En la siguiente figura podemos observar los diferentes sistemas de referencia considerados
para el análisis cinemático.
29
Figura 4.5: Postura de la configuración para el transporte
30
4.2.2. Modelo cinemático
Con la nueva configuración se tienen tres grados de libertad, es pertinente seleccionar
tres variables para el control por retroalimentación de estados. Es evidente seleccionar
las velocidades lineales Vxp , Vyp y la angular ωp . Estas velocidades serán las variables de
estado del sistema y de acuerdo con la teorı́a unificadora de González Villela V. se deben
expresar como: P
ξ (αs ) P
0
0 c (αs ) η
q˙1 =
P (4.9)
Poc (αs , αoc ) 0 ζ
φ (αs , αoc ) 0
P P
Donde ξ es la matriz asociada a las coordenadas P de postura; oc es la matriz asociada
a las coordenadas de ruedas P descentradas; φ la matriz asociada a las coordenadas de
rotación de las ruedas y c la matriz de ruedas centradas. Además de η y ζ que corres-
ponden a la movilidad y direccionabilidad respectivamente. P P
En el caso de esta configuración de robots los elementos de la ecuación 4.9 oc , c y ζ
no existen, y η es el vector de estado [vxp vyp ωp ]T .
Ahora podremos obtener la cinemática interna de la configuración, pero si recordamos el
análisis se hizo a partir del punto Pp por lo que es necesario multiplicar por la matriz de
rotación de la configuración (Xp , Yp ) para expresar la cinemática referenciada a nuestro
universo o sistema (X,Y) 0
p R(θp ) 0 0
Rq = 0 INDR 0
0 0 INC
En donde Rq R(3+NDR +NC )×(3+NDR +NC ) y tanto INDR RNDR ×NDR como INC RNC ×NC
son matrices identidad. Esta matriz de rotación esta definida en el trabajo desarrollado
en [20].
Una vez multiplicada la ecuación 4.9 con la matriz de rotación obtenemos las velocidades
generalizadas de la configuración propuesta en términos de las variables de estado. Para
obtener dicha expresión seguimos la forma:
˙
ξ
q̇ = Sτ (q)u ≡ θDR
˙ ≡ Rq q˙1
φ̇
31
bilidad de este sistema se encuentra demostrada con álgebra de Lie en [21].
cos θp − sin θp 0
sin θp cos θp 0
0 0 1
− sin θ1 cos θ1 a 1 cos θ 1 +b sin θ 1
vxp
c c c
− sin θ2 cos θ2 a2 cos θ2 +b sin θ2
q̇ = vyp (4.10)
c c c
c cos θ1 +d sin θ1 c sin θ1 −d cos θ1 (a1 c−bd) sin θ1 −(bc−a1 d) cos θ1
ωp
c cos θ1cr cr cr
−d sin θ1 c sin θ1 +d cos θ1 (a1 c+bd) sin θ1 +(−bc+a1 d) cos θ1
c cos θ2cr cr cr
+d sin θ 2 c sin θ2 −d cos θ2 (a2 c−bd) sin θ2 −(bc−a2 d) cos θ2
cr cr cr
c cos θ2 −d sin θ2 c sin θ2 +d cos θ2 (a2 c+bd) sin θ2 +(−bc+a2 d) cos θ2
cr cr cr
Los valores de las velocidades que se utilizan en ambos modelos (caso 1 y caso 2) son
calculados con la aproximación por campos potenciales explicada un capitulo atrás.
32
Capı́tulo 5
Descripción de la simulación e
implementación del sistema
5.1. Simulación
Para probar el funcionamiento del sistema de transporte colaborativo se realizan las
simulaciones y pruebas pertinentes. Es importante verificar antes de implementar con un
modelo funcional el control, la planeación de trayectorias y el algoritmo de coordinación;
es por esto que se desarrolla una simulación que permita comprobar gráficamente el fun-
cionamiento del sistema. El software elegido para realizar esta simulación es Simulink R .
Simulink R es un ambiente gráfico que permite hacer simulaciones y diseño basado en
modelos. También cuenta con una gran cantidad de herramientas de control, funciones
embebidas y generación automática de código; además de ser software ya conocido y usa-
do con anterioridad por el autor de este trabajo. Otra gran ventaja de Simulink es que
también permite controlar en tiempo real a los robots móviles, siendo una opción ideal
para el planeador global; solo será necesario acondicionar las señales de entrada y salida
necesarias para el modelo cinemático, es decir, señales del sistema de visión y señales para
los motores de los robots.
El primer componente de la simulación es un programa hecho con Matlab que permi-
te establecer todos los parámetros iniciales necesarios, parámetros de los robots móviles
como:
Dimensiones
Velocidades máximas
33
Dimensiones y ubicación del objeto a transportar
34
Esto gracias a que en la programación del modelo cinemático y los campos potenciales se
implementaron funciones simples compatibles con lenguaje C.
El bloque graficador permite ver la posición de obstáculos, el objeto a mover y los robots
en todo momento. También gracias Simulink R es posible obtener por separado el gráfico
correspondiente a las velocidades tanto del robot como de las llantas de cada uno de ellos.
A continuación se muestra un ejemplo del gráfico generado:
35
para el sistema de visión es reacTIVsion, que es una plataforma de software libre utilizado
para rastreo de sı́mbolos fiducials colocados en objetos.
ReacTIVision surgió como el componente de censado base de Reactable, un sintetizador
modular y tangible. ReacTIVision es una aplicación que emite mensajes TUIO utilizando
el protocolo UDP (User Data Protocol ) en el puerto 3333 a cualquier cliente que se en-
cuentre habilitado. Este framework funciona bajo plataformas Windows, Linux y MacOS
X, lo cual representa una gran ventaja para su utilización. Otra de las caracteristicas
importantes de reacTIVision es que se puede implementar con gran variedad de lenguajes
de programación como: JAVA, C++, C# y Processing. De forma que dependiendo del
lenguaje empleado se contará con un conjunto de funciones(métodos), objetos y clases
que mediante el protocolo TUIO, hacen peticiones sobre información especifica de los fi-
ducials como puede ser su posición, orientación, velocidad, identificador (ID),etc. Todos
ellos de vital importancia para el rastreo de los robots y demás elementos involucrados
en el sistema de transporte.
ReacTIVision puede funcionar con cámaras USB, USB2 y FireWire, siempre y cuando el
sistema operativo cuente con el controlador correcto. La cámara utilizada para las pruebas
es una webcam USB LifeCam Studio.
Para el rastreo de los fiducials se coloca la cámara en la parte superior del espacio de tra-
bajo, de forma que pueda captar todo lo que acontezca en el entorno (visión global). Todo
elemento del cual se requiera su información deber tener un fiducial para que reacTIVision
lo pueda localizar. Ejemplos de estos sı́mbolos se pueden observar a continuación:
Una vez colocados los sı́mbolos en el espacio de trabajo se puede obtener información
sobre ellos. Lo primero es lanzar la aplicación reacTIVision, para este caso será suficiente
con introducir en la terminal el comando reacTIVision y presionar la tecla Enter. La
aplicación será llamada a ejecutar y se hará la detección de la(s) cámara(s) conectada(s),
la preferencias de la cámara, el número de cámara o dispositivo a utilizar, resolución y
demás se pueden editar en el archivo [Link]
36
Figura 5.4: Archivo de configuración de cámara
37
Figura 5.5: Comandos para aplicación reacTIVision
Al mismo tiempo se genera y se muestra la ventana con la imagen que capta la cámara,
es decir el entorno de trabajo reacTIVision.
38
Figura 5.6: Entorno de trabajo reacTIVision
Para poder acceder a la información de los sı́mbolos es necesario, como se mencionó an-
teriormente, contar con un cliente que pida dicha información. Debido a qué el sistema
colaborativo se implementó con SIMULINK/Matlab se deberá utilizar un cliente capaz
de correr en este software. Para solucionar esta situación se hace uso del soporte que
tiene Matlab para código en JAVA. Los pasos para establecer el cliente Java en SIMU-
LINK/Matlab son los siguientes:
1. Descargar de la página del proyecto reacTIVision el cliente TUIO [Link]
2. Descomprimir la carpeta en una ubicación que no deberá cambiar a lo largo del
trabajo.
3. En la ventana de comandos de Matlab escribir el comando “edit [Link]”para
editar el path de Matlab.
4. Una vez abierto el archivo, agregar la ruta del archivo “[Link]”que se encuentra
en la carpeta del punto 2.
5. Guardar y cerrar el archivo.
Ya con estos pasos será posible implementar funciones de reacTIVision escritas en Java.
Para tener funcionalidad completa ahora se deberá indicar a Matlab que utilizaremos la
biblioteca de funciones TUIO, crear y conectar al cliente. Lo anterior se traduce en agregar
al inicio del código las siguientes lineas:
39
import TUIO.*;
tc=TuioClient();
[Link]();
Acciones similares se deberán realizar en caso de utilizar cualquier otro lenguaje de pro-
gramación, por supuesto respetando la sintaxis adecuada.
Es importante mencionar que reacTIVision trabaja con una imagen con resolución de
AxB pixeles(dependiendo del archivo [Link] y las caracterı́sticas del dispositivo),
entonces excluyendo la orientación de los sı́mbolos, la información que nos brinda tiene
como unidad pixeles y como referencia la esquina superior izquierda de la imagen.
En donde los valores máximos de (X,Y) son (1,1). Por lo tanto necesitamos convertir
este sistema de coordenadas a uno que represente de mejor forma al entorno de trabajo,un
sistema coordenado común es el cartesiano en dos dimensiones. Para este trabajo solo se
contempla el primer cuadrante.
Para esta conversión hacemos uso de una aproximación lineal. En principio se podrı́an
asignar valores máximos y mı́nimos para X e Y y hacer la conversión de coordenadas, sin
embargo para este trabajo se procede de la siguiente forma:
1. Se colocan tres fiducials en posiciones conocidas del entorno de trabajo.
2. Se obtiene la información de posición mediante reacTIVision de estos fiducials.
3. Debido a que los fiducials se encuentran en posiciones conocidas, se procede a hacer
la conversión o equivalencia pixeles-metros, esto mediante la aproximación lineal.
Con este procedimiento se evita tener que verificar cuál es el campo de visión de la cámara
(en metros) para hacer la conversión de coordenadas. En este caso la aproximación lineal
queda como lo siguiente.
X[cm] = 234.94X[px] − 112.77
Y [cm] = −197.23Y [px] + 100.64
Estos valores corresponden a una resolución de 640x480 pixeles con la cámara colocada a
aproximadamente 2.48 metros de altura.
40
5.2.2. Robots Móviles
El sistema de transporte colaborativo propuesto está compuesto por dos robots dife-
renciales: Estos robots diferenciales están conformados principalmente de acero, placas de
acrı́lico y los elementos que le dan movilidad los motores y llantas.
Del capitulo anterior se sabe que las dimensiones importantes para el modelo ma-
temático son la distancia entre las llantas, la distancia entre el eje de las llantas y el punto
P de análisis ası́ como el radio de las llantas. Para esta caso dichas dimensiones son:
Las placas de acrı́lico funcionan como entrepaños para colocar la circuiterı́a utilizada,
ası́ como algunos otros elementos indispensables para el experimento como el fiducial y el
motor del sinfin.
Mecanismo de ensamble
Una vez que los robots han llegado al punto de docking deben engancharse al objeto
para poder llevarlo al punto final. Para este caso se utilizó un perno que se engancha
en una argolla, la argolla es capaz de moverse verticalmente para enganchar o liberar el
perno gracias al giro de un tornillo sinfin, este tornillo sinfin gira con un motorredutor de
CD.
41
Figura 5.9: Mecanismo de ensamble
42
Figura 5.11: Xbee shield
Otra función del microcontrolador es la de activar el motor del sin fin una vez que el
robot se localiza en la posición correcta para enganchar al objeto. Esto se hace mediante
uno de los puertos digitales de la tarjeta Arduino UNO. Esta salida digital funciona como
trigger para un temporizador que activa el motor durante seis segundos. Este temporizador
se implemento de manera externa ya que el microcontrolador necesita escuchar todo el
tiempo los comandos remotos, lo que no permite implementar una rutina dentro el mismo
para activar o desactivar el motor.
Tarjeta MD25
Una vez que el microcontrolador recibe la información sobre las velocidades que deben
tener los motores, estas velocidades se deben enviar a los motores. Los motores utilizados
son de CD modelo EMG30 que pueden ser controlados de manera práctica con la tarjeta
MD25. Esta tarjeta es una tarjeta de doble puente H y esta diseñada para controlar
especı́ficamente dos motores de modelo mencionado. Algunas de las caracterı́sticas de la
tarjeta MD25 son:
Comunicación serial e I2 C
43
Figura 5.12: Tarjeta MD25
Por otro lado el microcontrolador empleado también posee comunicación serial e I2 C, sin
embargo el puerto serial ya se emplea para comunicarse con el modulo XBee, por lo que la
comunicación entre la tarjeta MD25 y el microcontrolador es mediante el protocolo I2 C.
El microcontrolador enviará las velocidades de cada motor a la tarjeta MD25 mediante
este protocolo y la tarjeta será encargada de escribir esas velocidades en cada motor. La
tarjeta MD25 cuenta con varios registros internos en dónde se escriben las operaciones a
realizar. La forma básica de funcionamiento es:
1. Indicar que se establecerá comunicación.
2. Escribir la velocidad de cada motor en el registro correspondiente.
3. Indicar que se cierra la comunicación.
La tarjeta puede trabajar en 4 modos diferentes, se emplea el determinado modo 0. En
este modo los motores de controlan de forma independiente: un valor de 0 representa la
máxima velocidad en un sentido, con 128 el motor se detiene y 255 es la máxima velocidad
en el otro sentido. Información sobre los otros modos de operación se puede encontrar en
[24].
Ahora bien un valor de 255 escrito sobre el motor corresponde a 190 RPM y un valor
de 0 corresponde a 50 RPM en sentido contrario. Nuestro modelo cinemático arroja las
velocidades de los motores en radianes por segundo, por lo que resulta necesario establecer
una relación entre ellas
44
Utilizando un aproximación lineal se pude obtener la función que convierte los radianes
por segundo arrojados del modelo en un número entre 0 y 255, que a su vez se traducirá en
RPMs escritas sobre los motores.
5.2.3. Comunicación
La comunicación es un parte importante del sistema colaborativo, al tratarse de ro-
bots móviles resulta adecuado utilizar un sistema inalámbrico para no limitar el espacio
de trabajo y no entorpecer el movimiento de los robots. Para el modulo de comunicación
inalámbrica se decide utilizar módulos de radiofrecuencia XBee Serie 2 de Digi [25]. Estos
módulos están diseñados para trabajar bajo el protocolo ZigBee y representan una opción
de bajo costo y bajo consumo de potencia para redes inalámbricas.
ZigBee es una plataforma estandarizada abierta bajo la norma 802.15.4 de la IEEE. Provee
comunicación en ambientes hostiles de radiofrecuencia que son comunes hoy en dı́a, tanto
en ambientes comerciales como industriales. Además de que posee soporte para diversas
topologı́as de red como: punto a punto, punto a multi-punto e incluso redes de malla.
En esta plataforma se definen tres tipos de dispositivos: coordinador, router y dispositivo
final(coodinator,router,end device) con las siguientes caracterı́sticas:
Coordinador
45
• Puede enrutar datos.
• Selecciona el canal y PAN ID para comenzar la red.
Router
Dispositivo Final
En toda red ZigBee debe haber por lo menos un coordinador para que los nodos se
puedan comunicar. Por lo tanto una red personal (PAN) consiste de un coordinador y
uno o más routers o dispositivos finales. La red se crea cuando el coordinador elige un
canal y un identificador de red (PAN ID). Una vez creada la red se puede dar permiso a
otros dispositivos para unirse a ella.
En la siguiente figura se puede ver un ejemplo de topologı́a ZigBee:
46
es que en primera instancia parecerı́a adecuada una comunicación punto-multipunto, sin
embargo en los módulos Xbee Series 2 este tipo de comunicación solo permite tasas de
transferencia de .5 [Hz] por lo que no resulta conveniente. La solución consiste entonces en
una red punto a punto, en donde el coordinador enviará información al dispositivo final 1
y este a su vez le enviará la información al dispositivo final 2. A continuación se describen
los pasos necesarios para configurar los módulos de radiofrecuencia.
1. Como primer paso descargar e instalar el software X-CTU de la página del fa-
bricante. Este software permite de manera gráfica y sencilla configurar todos los
parámetros de la red.
Puede generarse un error en caso de que el Baud Rate este mal configurado, intentar
con otro hasta tener éxito.
47
5. Elegir y escribir un PAN ID arbitrario en la opción correspondiente.
Este número está escrito en dos partes y deberá ser introducido en las opciones
Destination Address High - DH y Destination Address Low -DL correspondientes.
8. Una vez que se ha guardado la información, presionar el botón Read y poner atención
en el canal generado pues este número nos permitirá unir después a los otros dos
dispositivos en la red.
48
Figura 5.18: Configuracion del modem
Después para configurar los dispositivos finales se realizan los mismos pasos con los si-
guientes cambios para el dispositivo final 1:
Para el último modulo (dispositivo final 2) solo se deberá configurar el PAN ID y el canal.
Es de gran importancia asegurarse que los tres módulos tengan el mismo PAN ID, canal
y BaudRate para lograr la comunicación entre ellos.
49
Capı́tulo 6
Resultados de Simulaciones y
Pruebas
6.1. Simulación
Se presenta los resultados divididos en las partes que se han mencionado a lo largo
de este trabajo. En una primera prueba se observa el comportamiento del sistema antes
de tomar el objeto a transportar; aquı́ se pretende evaluar el algoritmo de navegación y
aproximación al objeto.
Por otro lado también se evalúa el comportamiento del sistema al transportar el objeto
evadiendo obstáculos; con esta prueba se pretende evaluar el algoritmo de transporte, es
decir, la modificación hecha al control por campos potenciales.
50
cuales se harán las pruebas. Esto se refiere, por ejemplo, a las restricciones del espacio
de trabajo en cuanto a la ubicación o configuración de obstáculos y objetos a trans-
[Link]ı́ una restricción importante es que no puede haber obstáculos dentro de las
trayectorias de aproximación al objetivo, es decir entre los 6 nodos que se generan alrede-
dor del objeto a transportar. A pesar de que los robots cuentan con la capacidad de evadir
obstáculos, una vez que empieza a trabar el algoritmo de aproximación, no es posible eva-
dirlos. La segunda restricción importante es que el obstáculo más cercano al destino final
del transporte, debe estar a por lo menos una distancia igual a la longitud máxima del
objeto a transportar. De lo contrario el objeto podrı́a nunca llegar a su destino por la
presencia de un campo repulsivo.
Estos valores se introducen en el código que genera condiciones iniciales de postura para
los robots y el objeto a transportar, la ubicación de los obstáculos y la meta final, se
genera un espacio de trabajo como el siguiente:
51
Figura 6.2: Condiciones iniciales en la Simulación
Con esta configuración del espacio de trabajo se busca ilustrar el funcionamiento del
algoritmo para llevar a cada robot hasta su punto de ensamble y orientarlo correctamente.
En la siguiente secuencia se aprecia el funcionamiento de buena forma:
52
(a) (b) (c)
Se puede apreciar en la figura 6.3e como el robot 2 (azul oscuro) evita chocar con el
robot 1 (cyan) y sigue con su camino. También se aprecia como, a pesar de que ambos
tienen como punto de ensamble el nodo 1 (esquina inferior izquierda del objeto), se coordi-
nan para ir a diferentes puntos. Esto demuestra el comportamiento efectivo de algoritmo
de coordinación diseñado. A continuación se presentan algunos gráficos que se generan
también la simulación. Para el robot 1:
53
Figura 6.4: Trayectoria del robot 1
54
Figura 6.5: Postura del robot 1
55
Figura 6.6: Trayectoria del robot 2
56
Figura 6.7: Postura del robot 2
57
(a) (b) (c)
Gracias al graficador en tiempo real, de donde se han obtenido las imágenes mostradas
hasta ahora, es posible observar la variación en el radio de influencia del campo repulsivo
de los objetos. Esta variación, como se comentó con anterioridad, depende del ángulo
del objeto y del ángulo de este respecto a los obstáculos. Se presenta a continuación la
información la variación de los campos repulsivos de cada objeto a lo largo del transporte.
58
Figura 6.9: Variación en el radio de campos repulsivos
59
Figura 6.10: Postura del objeto durante el transporte
60
Figura 6.11: Orientación de los robots durante el transporte
61
Figura 6.12: Entorno de trabajo con condiciones adversas para el transporte
62
(a) (b) (c)
6.2.2. Instrumental
Sin considerar a los robots móviles y a lo descrito en el capı́tulo anterior, consiste en
la computadora sobre la que corre el planeador global, la cámara para el sistema de visión
y el cable con extensión para conectar estos elementos. La computadora utilizada es un
computadora Laptop, modelo Sony Vaio VPCEG23EL corriendo un sistema operativo
Ubuntu 12.04 (Precise Pangolin). Este equipo cuenta con un procesador Intel Core i3-
2330M (2.20 GHz) y una memoria RAM DDR3 de 4 GB.
Por otro lado la cámara de video utilizada para el sistema de visión(reacTIVision) es una
cámara web LifeCam Studio de Microsoft R , la cual cuenta con una conexión USB 2.0 y
una resolución máxima de 1920x1080 pixeles. No obstante debido al controlador de video
utilizado por el sistema operativo se utiliza la resolución de 640x480. Finalmente, también
63
se utiliza una extensión USB para conectar la cámara a la computadora, pues al colocar
la cámara a la altura mencionada resulta necesario más cable.
XR = XV + di cos(θR )
YR = YV + di sin(θR )
En donde (XR , YR ) son las coordenadas de posición del dispositivo de enganche y (Xv , Yv )
es la posición del robot obtenida del sistema de visión.
Un segundo aspecto a considerar es que, debido a que el fiducial para reconocer a los
robots y al objeto a transportar se encuentra en la parte superior de estos; los datos
provenientes de la visión corresponden a un plano paralelo al piso, siendo este último
donde se realiza la calibración. Además, debido al funcionamiento de la cámara, entre
más lejos se encuentren los fiducuals del foco mayor distorsión tendrán. Lo anterior se
traduce en un valor erróneo de posición y se observa en la siguiente figura
64
Figura 6.16: Ajuste de posición por deformación
Se aprecia que la posición real del fiducial es una proyección del dato obtenido de
reacTIVision sobre el plano del piso. Este ajuste se realiza de la siguiente forma:
65
Figura 6.18: Correción de coordenadas de cámara plano XY
También es pertinente aclarar que el planeador global que corre sobre SIMULINK fun-
ciona igualmente que la simulación, con la diferencia de que los datos de postura de los
robots no se realimenta del modelo; se obtiene a partir del sistema de visión. Por otro
lado se elimina el bloque graficador pues alenta el funcionamiento del programa.
66
Figura 6.19: Funcionamiento Control en Tiempo Real
6.3. Experimentos
Para corroborar el funcionamiento y observar el comportamiento del sistema de trans-
porte colaborativo se realizan los experimentos pertinentes. Además es importante men-
cionar que, dadas las dimensiones del entorno para pruebas, no es posible realizar con-
figuraciones como las que se reportan en las simulaciones. Debido al sistema de visión
empleado no se prueba el caso de ambos robots desplazándose al mismo tiempo, en el
siguiente capı́tulo parte de este trabajo se discutirá más al respecto. Es ası́ que son dos
los experimentos a reportar:
En el segundo, se colocan dos objetos que fungirán como obstáculos. En esta prueba
se podrá observar el comportamiento de los robots ante la presencia de obstáculos
en el camino antes y después de tomar el objeto.
67
Figura 6.20: Condiciones iniciales experimento 1
Para tener una referencia se ejecuta la simulación con las condiciones iniciales del ex-
perimento antes de llevarlo a cabo con el sistema funcional. Estás condiciones iniciales son:
68
Una vez que se ha observado el comportamiento de los algoritmos de navegación y
aproximación se procede a llevar a cabo el experimento. A continuación se presentan los
resultados obtenidos.
Los robots siguen la trayectoria adecuada para cada caso. Las trayectorias seguidas
por los robots son:
69
Figura 6.23: Trayectoria robot 1
70
Figura 6.24: Trayectoria robot 2
También se muestran los datos de velocidad enviada a los motores de los robots. En
las gráficas se aprecia el correcto escalamiento de los datos y la transformación de rad/s
a números enteros de 0 a 255 entendidos por la tarjeta MD25.
71
(a) Derecha (b) Izquierda
Durante la realización del experimento se notó que habı́a problemas cuando ambos
robots se movı́an simultáneamente. En prácticamente todas las ocasiones habı́a saltos o
valores erróneos en la información, haciendo que reacTIVision no viera a los robots y esto
a su vez provocaba el envió de valores equı́vocos de velocidad para los motores. Por esta
razón se realizó el experimento moviendo un robot a la vez. Esto no es problema para el
algoritmo, pues este tipo de coordinación tenia considerada como opcional en el algoritmo
desarrollado. Aquı́ el robot 1 hace su recorrido y una vez que ha llegado a su meta envı́a
la señal de inicio al robot 2.
72
6.3.2. Segundo Experimento: Transporte evadiendo obstáculos
El segundo experimento a realizar será la tarea de transporte en si, es decir, desde el
momento en que los robots se encuentran ensamblados al objeto hasta que lo llevan a su
meta final. Como en el experimento anterior se restringen las condiciones del espacio de
trabajo. Además, el mecanismo de ensamble empleado limita en gran medida el movimien-
to de los robots, por lo que el experimento realizado en para observar el comportamiento
del sistema se limita un transporte simple con dos obstáculos. Las condiciones iniciales
de este experimento son:
73
(a) (b) (c)
Los fiducials con ID 1 y 2 son empleados como obstáculos. El fiducial con ID 5 se utiliza
como meta final del objeto. Al igual que el caso anterior los fiducial 6 y 7 representan a
los robots y el número 0 al objeto a transportar.
74
Figura 6.30: Trayectoria del objeto durante el transporte
75
Figura 6.32: Orientación de los robots durante el transporte
76
Figura 6.33: Radio de campo repulsivo de los objetos durante el transporte
Una observación de los resultados de este experimento es que el giro de los robots
está limitado por el mecanismo de enganche. Para ejecutar el transporte con cierta orien-
tación el robot debe tomar ángulos que el modelo fı́sico no permite. Por otro lado, a pesar
de que el sistema calcula de forma correcta los valores del campo repulsivo en el control
por campos potenciales, en la implementación fı́sica del sistema es necesario sintonizar
algunas ganancias correctamente, pues a pesar de que el cálculo de campos repulsivos y
atrayentes es correcto no se logra la evasión esperada.
Desde luego que la comparación se hace con la simulación en dónde todos los parámetros
son ideales. En cambio con el modelo funcional existen diversos factores que alteran el
comportamiento esperado del sistema. Dentro de los factores más importantes están las
condiciones mecánicas (ensamble) y la adquisición de datos (visión).
77
Capı́tulo 7
7.1. Conclusiones
Con este trabajo, se probó que la teorı́a desarrollada por González Villela en [20]
junto con el trabajo desarrollado en [21] funcionan efectivamente para desarrollar sistemas
robóticos colaborativos. Se comprobó que el modelo cinemático es suficiente para planear
y ejecutar las trayectorias en el transporte de objetos con formas geométricas regulares
ponderando su orientación. El algoritmo implementado en los robots les permite, gracias
a los puntos de pre-docking, navegar y orientarse correctamente para tomar al objeto a
transportar. El modelo de evasión y transporte funciona correctamente cuando hay un
cálculo correcto de los datos de entrada.
Gracias al sistema diseñado es posible simular diferentes situaciones o configuracio-
nes del entorno de trabajo y ver como el algoritmo resuelve el transporte. Además, con
el programa generado para establecer las condiciones iniciales, es posible tomar estos
parámetros de una configuración real o experimental. Esto trae beneficios como el poder
observar el comportamiento del sistema antes de realizar experimentos, incluso tener una
referencia para hacer comparaciones de desempeño.
78
En el primer experimento se corroboró, a pesar de los problemas con el sistema de vi-
sión y las restricciones del espacio de trabajo, que el algoritmo de navegación junto con el
de aproximación al objetivo funcionan correctamente. Dicho algoritmo es capaz coordinar
y planear las trayectorias de ambos robots para llegar a los puntos de enganche con la
orientación adecuada. A partir de los resultados de la primera prueba se observa como los
robots se aproximan al punto de pre-docking más cercano, a partir de ahı́ navegan hacia
el punto libre para ensamble más cercano si este se encuentra libre.
79
una metodologı́a de diseño para obtener especificaciones como materiales, dimensiones
y componentes idóneos para transportar determinados objetos o materiales. Un ejemplo
de esto serı́a obtener el par necesario (motores) para transportar una masa o volumen
especı́fico. Resalta también, de manera especial, diseñar el mecanismo de ensamble o en-
ganche ideal para cada caso.
Como se planteó en un principio, los sistemas multi robot tiene como uno de sus
fundamentos, el repartir o delegar las tareas para poder desarrollarlas con robots de ar-
quitecturas simples. Entonces, seria conveniente desarrollar un algoritmo que contemplara
más robots participando en la tarea. Incluso contemplar un algoritmo que permita adap-
tar o variar el número de participantes para diferentes condiciones.
Por otro lado, como se comenta en las conclusiones, serı́a pertinente implementar otro
sistema de visión que permitiera una mayor libertad respecto al uso de hardware. Además,
que tenga una mayor resolución que posibilite localizar mejor a los elementos del sistema,
ası́ como realizar movimientos más precisos. Ejemplos de estos son los sistemas de captura
de movimientos como OptiTrack o Vicon.
80
81
Apéndice A
Adquisición de Datos
%Datos de Reactivision
%ID 0: objeto a transportar
%ID 1 al 4: Obstaculos
%ID 5: Destino del objeto a transportar
%ID 6: Robot 1
%ID 7: Robot 2
global t_1 x_1 y_1 t_2 x_2 y_2 x_P y_P t_P x_ob y_ob x_t y_t;
di=13;
x_ob=zeros(1,4);
y_ob=zeros(1,4);
import TUIO.*;
tc = TuioClient();
[Link]();
for i = 1 : 10
fiducials=[Link]();
for j=1 : [Link]
fid=TuioObject([Link](j-1));
id=[Link]();
switch id
case 0
t_P = 2*pi-([Link]());
x_P = ([Link]())*234.9415-112.7782;
y_P = ([Link]())*-197.2313+100.64;
case 5
x_t = ([Link]())*234.9415-112.7782;
y_t = ([Link]())*-197.2313+100.64;
case 6
t_1 = 2*pi-([Link]());
x_1 = ([Link]())*234.9415-112.7782;
y_1 = ([Link]())*-197.2313+100.64;
case 7
t_2 = 2*pi-([Link]());
x_2 = ([Link]())*234.9415-112.7782;
y_2 = ([Link]())*-197.2313+100.64;
otherwise
x_ob(id) = ([Link]())*234.9415-112.7782;
y_ob(id) = ([Link]())*-197.2313+100.64;
end
end
pause(.01)
end
[Link]();
82 x_2+cos(t_2)*di y_2+sin(t_2)*di t_2 x_t y_t x_P y_P t_P x_ob
sys = [x_1+cos(t_1)*di y_1+sin(t_1)*di t_1
Apéndice B
Código Arduino
Robot 1
#include <Wire.h>
#define CMD (byte)0x00
#define MD25ADDRESS 0x58
#define SOFTWAREREG 0xOD
#define SPEED1 (byte)0x00
#define SPEED2 0x01
#define ENCODERONE 0x02
#define ENCODERTWO 0x06
#define VOLTREAD 0x0A
#define RESETENCOD 0x20
void loop(){
digitalWrite(led,LOW);
if([Link]()==7){
for(int i=0;i<7;i++){
datos[i]=[Link]();
}
if (datos[4]==1){
contador+=1;
if (contador<100){
analogWrite(led,255);
delay(40);
}
else
analogWrite(led,0);
}
if (datos[5]==1){
contador2+=1;
83
if (contador<50){
datos[1]=128;
datos[0]=128;
}
}
int chksum= datos[0]^datos[1]^datos[2]^datos[3]^datos[4]^datos[5];
if(chksum==datos[6]){
[Link](MD25ADDRESS);
[Link](SPEED2);
[Link](datos[1]);
[Link]();
[Link](MD25ADDRESS);
[Link](SPEED1);
[Link](datos[0]);
[Link]();
}
[Link]();
}
}
void encodeReset(){
[Link](MD25ADDRESS);
[Link](SPEED2);
[Link](128);
[Link]();
[Link](MD25ADDRESS);
[Link](SPEED1);
[Link](128);
[Link]();
}
84
Robot 2
#include <Wire.h>
#define CMD (byte)0x00
#define MD25ADDRESS 0x58
#define SOFTWAREREG 0xOD
#define SPEED1 (byte)0x00
#define SPEED2 0x01
#define ENCODERONE 0x02
#define ENCODERTWO 0x06
#define VOLTREAD 0x0A
#define RESETENCOD 0x20
void loop(){
digitalWrite(led,HIGH);
if([Link]()==7){
for(int i=0;i<7;i++){
datos[i]=[Link]();
}
if (datos[5]==1){
contador+=1;
if (contador=10){
digitalWrite(led,LOW);
delay(10);
}
}
85
if (datos[4]==1){
int chksum= datos[0]^datos[1]^datos[2]^datos[3]^datos[4]^datos[5];
if(chksum==datos[6]){
digitalWrite(led,HIGH);
[Link](MD25ADDRESS);
[Link](SPEED2);
[Link](datos[3]);
[Link]();
[Link](MD25ADDRESS);
[Link](SPEED1);
[Link](-datos[2]+255);
[Link]();
digitalWrite(led,LOW);
}
}
else
encodeReset();
}
[Link]();
}
void encodeReset(){
[Link](MD25ADDRESS);
[Link](SPEED2);
[Link](128);
[Link]();
[Link](MD25ADDRESS);
[Link](SPEED1);
[Link](128);
[Link]();
}
86
87
Apéndice C
function sys=mdlOutputs(t,x,u)
function sys=mdlOutputs(t,x,u)
global xR yR xR2 yR2 tR tR2 xt1 yt1 xt2 yt2 kr1 xo1 xo2 yo1 yo2 rho01
global rhor1 rhoc1 n1 tkn1 rho02 rhor2 rhoc2;
xR = u(1);
yR = u(2);
tR = u(3);
xo1 = u(4);
yo1 = u(5);
rhor1 = u(7);
rho01 = u(6);
n1 = u(8);
xt1 = u(9);
yt1 = u(10);
kr1 = u(11);
vxmax = u(12);
vymax = u(13);
wmax = u(14);
% Dimensiones de la plataforma
b1 = u(17);
d1 = u(15);
r1 = u(16);
tkn1 = u(18);
xR2=u(19);
yR2=u(20);
tR2=u(21);
xo2=u(22);
yo2=u(23);
rhor2=u(25);
rho02=u(24);
xt2=u(26);
yt2=u(27);
dt=u(28);
dt2=u(29);
xobjeto=u(30);
yobjeto=u(31);
% Aqui cambio la bandera de tkn, si el robot ya se encuentra en posicion
% para tomar el objeto.
tknU=tkn1;
tknU2=tkn1;
if ((abs(xR-xt1)<1) && (abs(yR-yt1)<1))
if dt<5
if dt~=1
ready=dt-1;
else
tknU=1;
ready=1;
nodo1=1;
nodo8=0;
end
else
if dt~=8
ready=dt+1;
else
tknU=1;
nodo8=1;
89
nodo1=0;
ready=8;
end
end
else
ready=dt;
end
if tknU~=1
% Calculo de las velocidades de entrada para un Robot
dg = sqrt((xt1-xR)^2 + (yt1-yR)^2);
rhoc1 = sqrt((xo1-xR)^2 + (yo1-yR)^2);
if yt1==yR && xt1==xR
tg = tR;
else
tg = atan2((yt1-yR),(xt1-xR));
end
if rhoc1 > rho01+rhor1
drep = 0;
to = 2*tg;
else
drep = (n1/2)*((1/(rhoc1-rhor1))-(1/rho01))^2;
to = atan2((yR-yo1),(xR-xo1));
end
dres = dg + drep;
te = (to-tg)-tR;
texx=abs(cos(abs(tg))-cos(abs(tR)));
dob = sqrt((xobjeto-xR)^2 + (yobjeto-yR)^2);
if dres > kr1
if (dob<55) && abs(texx)>.15
vxpp=0;
else
vxpp=vxmax;
end
else
vxpp=vxmax*dres/kr1;
end
wpp = wmax*sin(te);
U = [vxpp;wpp];
Sq=[cos(tR) d1*sin(tR);
sin(tR) -d1*cos(tR);
0 1;
1/r1 b1/r1;
1/r1 -b1/r1];
else
U=[1;0];
Sq=[0 0;
0 0;
0 0;
0 0;
0 0];
end
%%Robot 2
if ((abs(xR2-xt2)<1) && (abs(yR2-yt2)<1))
if dt2<5 && nodo1==0
if dt2~=1
ready2=dt2-1;
else
tknU2=1;
ready2=1;
end
else
90
if dt2~=8 && nodo8==0
ready2=dt2+1;
else
tknU2=1;
ready2=8;
end
end
else
ready2=dt2;
end
91
C.3. Obstáculo cercano
end
else
xo=0;
yo=0;
rho0=0;
rhor=0;
end
92
C.4. Modelo cinemático y campos potenciales robots
acoplados
function sys=mdlOutputs(t,x,u)
vxmax = u(1);
vymax = u(2);
wmax = u(3);
tP = u(4);
t1 = u(5);
t2 = u(6);
% Dimensiones de la plataforma
global a1 a2 b c d r;
a1 = u(7);
a2 = u(8);
b = u(9);
c = u(10);
d = u(11);
r = u(12);
xp = u(13);
yp = u(14);
xt = u(15);
yt = u(16);
kr = u(17);
xo = [u(18);u(19);u(20);u(21)];
yo = [u(22);u(23);u(24);u(25)];
rho0 = [u(26);u(27);u(28);u(29)];
rhor = [u(30);u(31);u(32);u(33)];
n = u(34);
tkn=u(35);
if tkn==1
% C�lculo de las velocidades de entrada
drep=zeros(1,4);
to=zeros(1,4);
dg = sqrt((xt-xp)^2 + (yt-yp)^2);
%fax=xt-xp;
%fay=yt-yp;
for co=1:length(xo);
rhoc(co) = sqrt((xo(co)-xp)^2 + (yo(co)-yp)^2);
93
end
if yt==yp && xt==xp
tg = tP;
else
tg = atan2((yt-yp),(xt-xp));
end
for co=1:length(rhoc)
if rhoc(co) > rho0(co)+rhor(co)
drep(co) = 0;
to(co) = 2*tg;
else
drep(co) = (n/2)*((1/(rhoc(co)-rhor(co)))-(1/rho0(co))^2);
to(co) = atan2((yp-yo(co)),(xp-xo(co)));
end
end
dres = dg + sum(drep);
te = (sum(to)-tg)-tP;
teg = tg-tP;
if dres > kr
vxpp = vxmax*cos(te);
vypp = vymax*sin(te);
else
vxpp = vxmax*dres*cos(te)/kr;
vypp = vymax*dres*sin(te)/kr;
end
wpp = wmax*sin(teg-(pi/2));
%wpp = wmax*sin(teg);
%wpp = wmax*sin(-tP); %Orientado a 0
Sq=[cos(tP),-sin(tP),0;
sin(tP),cos(tP),0;
0,0,1;
-sin(t1)/c,cos(t1)/c,a1*cos(t1)/c+b*sin(t1)/c;
-sin(t2)/c,cos(t2)/c,a1*cos(t2)/c+b*sin(t2)/c;
(c*cos(t1)+d*sin(t1))/(c*r),-d*cos(t1)/(c*r)+sin(t1)/r,-b*cos(t1)/r-
a1*d*cos(t1)/(c*r)+a1*sin(t1)/r-b*d*sin(t1)/(c*r);
(c*cos(t1)-d*sin(t1))/(c*r),d*cos(t1)/(c*r)+sin(t1)/r,-
b*cos(t1)/r+a1*d*cos(t1)/(c*r)+a1*sin(t1)/r+b*d*sin(t1)/(c*r);
(c*cos(t2)+d*sin(t2))/(c*r),-d*cos(t2)/(c*r)+sin(t2)/r,-b*cos(t2)/r-
a2*d*cos(t2)/(c*r)+a2*sin(t2)/r-b*d*sin(t2)/(c*r);
(c*cos(t2)-d*sin(t2))/(c*r),d*cos(t2)/(c*r)+sin(t2)/r,-
b*cos(t2)/r+a2*d*cos(t2)/(c*r)+a2*sin(t2)/r+b*d*sin(t2)/(c*r)];
else
Sq=zeros(9,3);
U=ones(3,1);
end
sys = Sq*U;
94
C.5. Graficador en tiempo real
sys = [];
if (ON==0)||(t==0)
hold off;
end
figure(1)
set(1,'Position', [490 150 500 500]);
% Fijacion de ejes
xlabel('x [cm]')
ylabel('y [cm]')
title('Figure 3: Sequence of posture')
% Entradas
xP = u(1);
yP = u(2);
thetaP = u(3);
theta1 = u(4);
theta2 = u(5);
a1 = u(6);
a2 = u(7);
b = u(8);
c = u(9);
d = u(10);
r = u(11);
x1 = u(38);
y1 = u(39);
x2 = u(40);
y2 = u(41);
xobjetos = [u(15);u(16);u(17);u(18)];
yobjetos = [u(19);u(20);u(21);u(22)];
rhobjetos = [u(23);u(24);u(25);u(26)];
robjetos = [u(27);u(28);u(29);u(30)];
xt = u(12);
yt = u(13);
kr = u(14);
xot = u(31);
yot = u(32);
kor = u(33);
tot = u(34);
largo = u(35);
alto = u(36);
tkn = u(37);
hayObjetos= u(42);
predockX=[u(43);u(44);u(45);u(46);u(47);u(48);u(49);u(50)];
predockY=[u(51);u(52);u(53);u(54);u(55);u(56);u(57);u(58)];
%radio=u(59);
% Dimensiones extra de la plataforma
95
extraP_x1=1.9;
extraP_x2=5;
extraP_x3=16.75;
extraP_x4=5.6;
extraP_y1=1.9;
extraP_y2=15.8;
a2=largo/2;
a1=-a2;
b=-alto/2;
% Dimensiones extra de las ruedas
wheel_y = 1;
% C�lculos �tiles
cos_thP = cos(thetaP);
sin_thP = sin(thetaP);
cos_th1 = cos(theta1);
sin_th1 = sin(theta1);
cos_th2 = cos(theta2);
sin_th2 = sin(theta2);
cos_tot = cos(tot);
sin_tot = sin(tot);
Point_Sides = 10;
Point_Sides_Angles = (0:1/Point_Sides:1-1/(2*Point_Sides))'*2*pi;
Point_Size = kr;
Point_Size_y = Point_Size*sin(Point_Sides_Angles);
Point_Size_x = Point_Size*cos(Point_Sides_Angles);
96
% Dibujo de predocking
hd_Point = fill(Point_x, Point_y, 'r');
set(hd_Point,'EraseMode','none');
end
end
Point_Sides = 15;
Point_Sides_Angles = (0:1/Point_Sides:1-1/(2*Point_Sides))'*2*pi;
Point_Size = rho0;
Point_Size_y = Point_Size*sin(Point_Sides_Angles);
Point_Size_x = Point_Size*cos(Point_Sides_Angles);
Point_Sides = 10;
Point_Sides_Angles = (0:1/Point_Sides:1-1/(2*Point_Sides))'*2*pi;
Point_Size = rhor;
Point_Size_y = Point_Size*sin(Point_Sides_Angles);
Point_Size_x = Point_Size*cos(Point_Sides_Angles);
97
% Realizaci�n del objetivo
Point_Sides = 10;
Point_Sides_Angles = (0:1/Point_Sides:1-1/(2*Point_Sides))'*2*pi;
Point_Size = 1;
Point_Size_y = Point_Size*sin(Point_Sides_Angles);
Point_Size_x = Point_Size*cos(Point_Sides_Angles);
ob_pos_x = (cos_tot*ob_contour_x-sin_tot*ob_contour_y)+xot;
ob_pos_y= (sin_tot*ob_contour_x+cos_tot*ob_contour_y)+yot;
else
% Realizaci�n del robot de traccion 1
wmr1_pos_x = xP + cos_thP*(a1 + cos_th1*wmr1_contour_x - sin_th1*wmr1_contour_y) -
sin_thP*(b + sin_th1*wmr1_contour_x + cos_th1*wmr1_contour_y);
wmr1_pos_y = yP + sin_thP*(a1 + cos_th1*wmr1_contour_x - sin_th1*wmr1_contour_y) +
cos_thP*(b + sin_th1*wmr1_contour_x + cos_th1*wmr1_contour_y);
98
wmr2_pos_x = xP + cos_thP*(a2 + cos_th2*wmr2_contour_x - sin_th2*wmr2_contour_y) -
sin_thP*(b + sin_th2*wmr2_contour_x + cos_th2*wmr2_contour_y);
wmr2_pos_y = yP + sin_thP*(a2 + cos_th2*wmr2_contour_x - sin_th2*wmr2_contour_y) +
cos_thP*(b + sin_th2*wmr2_contour_x + cos_th2*wmr2_contour_y);
ob_pos_x = (cos_thP*ob_contour_x-sin_thP*ob_contour_y)+xP;
ob_pos_y= (sin_thP*ob_contour_x+cos_thP*ob_contour_y)+yP;
Point_Sides = 10;
Point_Sides_Angles = (0:1/Point_Sides:1-1/(2*Point_Sides))'*2*pi;
Point_Size = 1;
Point_Size_y = Point_Size*sin(Point_Sides_Angles);
Point_Size_x = Point_Size*cos(Point_Sides_Angles);
99
% Dibujo del punto P
100
else
% Realizaci�n del punto P1
Point_Sides = 10;
Point_Sides_Angles = (0:1/Point_Sides:1-1/(2*Point_Sides))'*2*pi;
Point_Size = 1;
Point_Size_y = Point_Size*sin(Point_Sides_Angles);
Point_Size_x = Point_Size*cos(Point_Sides_Angles);
Point_Sides = 10;
Point_Sides_Angles = (0:1/Point_Sides:1-1/(2*Point_Sides))'*2*pi;
Point_Size = 1;
Point_Size_y = Point_Size*sin(Point_Sides_Angles);
Point_Size_x = Point_Size*cos(Point_Sides_Angles);
end
101
C.6. Acondicionamiento de velocidades
function sys=mdlOutputs(t,x,u)
vel(1)=8.14*u(1)+128;
vel(2)=8.14*u(2)+128;
vel(3)=8.14*u(3)+128;
vel(4)=8.14*u(4)+128;
vel(5)=u(5);
vel(6)=u(6);
if vel(1) < 0
vel(1)=0;
elseif vel(1) > 255
vel(1)=255;
end
if vel(2) < 0
vel(2)=0;
elseif vel(2) > 255
vel(2)=255;
end
if vel(3) < 0
vel(3)=0;
elseif vel(3) > 255
vel(3)=255;
end
if vel(4) < 0
vel(4)=0;
elseif vel(4) > 255
vel(4)=255;
end
vel(1)=uint8(u(1));
vel(2)=uint8(u(2));
vel(3)=uint8(u(3));
vel(4)=uint8(u(4));
vel(5)=uint8(u(5));
vel(6)=uint8(u(6));
checksumB=bitxor(vel(1),bitxor(vel(2),bitxor(vel(3),bitxor(vel(4),bitxor(vel(5),vel(6))))));
sys = [vel checksumB];
102
C.7. Envı́o de datos vı́a serial
function sys=mdlUpdate(t,x,u)
v(1)=u(1);
v(2)=u(2);
v(3)=u(3);
v(4)=u(4);
v(5)=u(5);
v(6)=u(6);
chksum=u(7);
delete(instrfindall)
s=serial('/dev/ttyS101','BaudRate',57600);
fopen(s);
fwrite(s,v(1),'uint8');
fwrite(s,v(2),'uint8');
fwrite(s,v(3),'uint8');
fwrite(s,v(4),'uint8');
fwrite(s,v(5),'uint8');
fwrite(s,v(6),'uint8');
fwrite(s,chksum,'uint8');
fclose(s);
pause(.05);
delete(instrfindall)
sys = [ ];
103
104
D.1.
x1 xo1
y1 yo1 x1_v
x2 x1
s rho1 y1_y
y2
xobstaculos rhor1 t1
y1
yobstaculos xo2 x_obs1
robstaculos
tos yo2 y_obs1
rIobstaculos x2
0 Tomado? rho2 rho_01
x_obs2
y_obs2
rho_02
wi1
rho_r2
N
n
KOR wd1
kro
VX
vx_max
VY wi2
Diagrama General
vy_max
WMAX
w_max
D1 wd2
d1
R
r
105
D vxP
d
X1_0
x1o
Y1_0 vyP
y1o
T1_0
A1
t1o A2
X2_0 wP
B
x2o C
Y2_0
D
y2o R
T2_0 xP
XT
t2o YT
dockinX
RT
xt1 objetosX
dockinY yP
objetosY
yt1 objetosRH
es Sistema objetosRO
dotR1 XO
predocking thetaP
YO
xt2 KO Real_Time_Plotting_Obstacle
Caluclos predock TO
yt2 LONG
Bandera S-Function
TALL
dotR2 hayObstacles?
Taken Constantes Ploting
readyR1
xp
yp
readyR2 DocX
thetap
predockingsX
[C] DocY
Subsystem
Goto2 predockingsY
Diagramas de bloques de Simulink
D.2. Diagrama Subsistema Modelos Cinemáticos
106
9
vxP
vxmax 10
vyP
vymax vxmax 11
3
thetap vymax 1 wP
wmax xos 12
xP
xP
Goto3 wmax 1
xos 13
[H] yP
yP
4 w1 1
th1 5 xos 14
w2 tP
th2 thetaP
largo −.5 1
wP
Kinematic Model xos 1
d3 Gain
theta1
Demux
kinematic_model_obstaclePlatformFINAL 1
.5
xos 2
Gain1 theta2
alto −.5
3
d4 Gain2 wi1
1
xp d1 −1 4
wd1
2
d2 Gain3
yp xt d 5
107
xP_0 wi2
xt d5
r Constant3 6
yt wd2
r1
yP_0
obstacles yt
kr
xt3 Constant4
rt xp
xo tP_0
yp
xobjetos
x Constant5
15
xo y yo
Taken
yobjetos 6 tkn ObstacleUpdate
taken? tP
t1_0 inHand 7
y0
rho0 tkn1
obstacles Constant10 Constant1
8
Actualizar a obstaculo cercano
[H] tk2
From4 n t2_0
r2 Constant11
robjetos(1)
rho_r
Bibliografı́a
[2] T. Arai, E. Pagello, and L.E. Parker. Guest editorial advances in multirobot systems.
Robotics and Automation, IEEE Transactions on, 18(5):655 –661, oct. 2002.
[3] T. Fukuda, S. Nakagawa, Y. Kawauchi, and M. Buss. Self organizing robots based
on cell structures - ckbot. In Intelligent Robots, 1988., IEEE International Workshop
on, pages 145 –150, oct-2 nov 1988.
[4] G. Beni. The concept of cellular robotic system. In Intelligent Control, 1988. Pro-
ceedings., IEEE International Symposium on, pages 57 –62, aug 1988.
[6] P. Caloud, Wonyun Choi, J.-C. Latombe, C. Le Pape, and M. Yim. Indoor auto-
mation with many mobile robots. In Intelligent Robots and Systems ’90. ’Towards a
New Frontier of Applications’, Proceedings. IROS ’90. IEEE International Workshop
on, pages 67 –72 vol.1, jul 1990.
[7] Parker L.E. Heterogeneous multi-robot cooperation. PhD thesis, MIT, 1994.
[8] B.R. Donald, J. Jennings, and D. Rus. Analyzing teams of cooperating mobile ro-
bots. In Robotics and Automation, 1994. Proceedings., 1994 IEEE International
Conference on, pages 1896 –1903 vol.3, may 1994.
[9] D. Rus, B. Donald, and J. Jennings. Moving furniture with teams of autonomous
robots. In Intelligent Robots and Systems 95. ’Human Robot Interaction and Coope-
rative Robots’, Proceedings. 1995 IEEE/RSJ International Conference on, volume 1,
pages 235 –242 vol.1, aug 1995.
108
[10] D.J. Stilwell and J.S. Bay. Toward the development of a material transport system
using swarms of ant-like robots. In Robotics and Automation, 1993. Proceedings.,
1993 IEEE International Conference on, pages 766 –771 vol.1, may 1993.
[12] Zhi Dong Wang, Y. Kimura, Takayuki Takahashi, and Eiji Nakano. A control method
of a multiple non-holonomic robot system for cooperative object transportation. In
DARS’00, pages 447–456, 2000.
[14] N. Miyata, J. Ota, T. Arai, and H. Asama. Cooperative transport by multiple mobile
robots in unknown static environments associated with real-time task assignment.
Robotics and Automation, IEEE Transactions on, 18(5):769 – 780, oct 2002.
[15] A.K. Das, R. Fierro, V. Kumar, J.P. Ostrowski, J. Spletzer, and C.J. Taylor. A vision-
based formation control framework. Robotics and Automation, IEEE Transactions
on, 18(5):813 – 825, oct 2002.
[17] Chia Choon Loh and A. Trachtler. Laser-sintered platform with optical sensor for
a mobile robot used in cooperative load transport. In IECON 2011 - 37th Annual
Conference on IEEE Industrial Electronics Society, pages 203 –208, nov. 2011.
[18] J. Fink, M.A. Hsieh, and V. Kumar. Multi-robot manipulation via caging in en-
vironments with obstacles. In Robotics and Automation, 2008. ICRA 2008. IEEE
International Conference on, pages 1471 –1476, may 2008.
[19] Yifan Cai and S.X. Yang. Fuzzy logic-based multi-robot cooperation for object-
pushing. In Information and Automation (ICIA), 2011 IEEE International Confe-
rence on, pages 273 –278, june 2011.
[20] González Villela V.J. Research on a semiautonomous mobile robot for loosely struc-
tures environments focused on transporting mail trolleys. PhD thesis, Loughborough
University, 2006.
109
[21] Martinez Carrillo A. Plataforma móvil omnidireccional a partir de dos robots móviles
diferenciales, 2011.
[22] Oussama Khatib Bruno Siciliano, editor. Handbook of robotics. Springer, 2008.
[23] O. Khatib. Real-time obstacle avoidance for manipulators and mobile robots. In
Robotics and Automation. Proceedings. 1985 IEEE International Conference on, vo-
lume 2, pages 500 – 505, mar 1985.
110
The experimental evaluation involved trials where robots were positioned arbitrarily to test their ability to approach, orient, and secure the transport object. Another test placed obstacles to observe the robots' behavior in obstacle-laden scenarios. These trials were aligned with initial simulation conditions to provide comparative performance analysis . The findings showed that the navigation algorithms enabled the robots to successfully complete tasks involving object engagement and obstacle avoidance, albeit at slower speeds due to environmental and sensor limitations . The system's control algorithms proved effective, accurately steering the robots in simulated tasks but required adjustment during real-world applications .
Trajectory planning in collaborative robot systems is crucial for ensuring precise object transport and obstacle avoidance. It involves calculating optimal paths that the robots should follow to complete tasks efficiently while maintaining spatial awareness to avoid collision . This planning is supported by simulation software like Simulink, which allows users to model, simulate and visualize complex dynamic systems, enabling iterative optimization of trajectory paths and testing various scenarios before physical implementation . The software assists in validating control strategies and fine-tuning algorithms under various simulated conditions, reducing the risk of failures during real-world operations .
The collaborative transport system ensures coordination between multiple robots through an integrated algorithm that regulates path planning and object engagement. This system uses pre-docking points and trajectory planning based on shared goals to synchronize the robots' movements even when moving to the same location . The coordination algorithm assesses potential paths and dynamically allocates alternate nodes to prevent collisions, effectively distributing the task across each robot . The use of algorithms such as trajectory planning and feedback control reinforces this coordination by continuously adjusting paths in response to real-time environmental data .
In the simulation of robot navigation, critical parameters include wheel rotation angles (φl, φr), orientation angles (θ), and robot velocity (v, ω). These are adjusted to simulate realistic movement dynamics and environmental interactions . In real-world applications, tuning focuses on matching these parameters to the physical robot's mechanical constraints and sensor data precision, refining them through calibration to account for discrepancies such as wheel slippage or sensor noise . Ensuring the simulation accurately mimics the actual performance involves iterative testing until the simulated responses align with observed behaviors in physical tests .
Transitioning from simulation to real-world implementation presents challenges primarily in data acquisition and integration due to discrepancies between idealized models and physical constraints. In simulations, ideal parameter conditions are assumed, such as perfect sensor data and immediate processing . In contrast, real-world applications must contend with data noise, delays, and inaccuracies inherent in sensor readings and mechanical functions. This necessitates additional calibration, algorithmic adjustments, and compensations, such as filtering to manage data inconsistency and applying control feedback mechanisms . Moreover, external factors like lighting affect the vision system, further complicating precise integration .
The potential field approach enhances obstacle avoidance by creating a virtual field where attractive forces pull the robot towards the goal, while repulsive forces push it away from obstacles. This dual-force system guides the robot along a path that avoids collisions while navigating through a dynamic environment . The algorithm calculates the influence radius of the repulsive field, allowing the robot to adjust its orientation and trajectory smoothly to sidestep obstacles . This dynamic replanning capability makes it effective for real-time navigation and collision avoidance .
The implementation of repulsive field algorithms contributes significantly to a mobile robot's ability to navigate complex environments by dynamically adjusting the path to avoid obstacles. These algorithms define virtual repulsive zones around obstacles, enhancing the robot's capability to maneuver through challenging spaces without collision . The algorithms calculate repulsion intensity based on the distance and orientation of obstacles relative to the robot, adjusting the trajectory to maintain safe distances while progressing towards the goal . This adaptability ensures that robots can navigate irregular terrains and execute tasks efficiently, maintaining high levels of autonomy and decision-making relevance in complex settings .
The state variables model for a differential mobile robot is detailed using generalized coordinates which differ based on the presence of centered and offset wheels. If a robot has centered wheels (Nc) or offset wheels (Noc), the configuration space, given by nT = 3 + NT + Nc + Noc, expands to accommodate angles and rotations specific to those wheel types . Without centered or offset wheels, the model focuses only on the basic position and orientation, denoted as q = [x y θ φl φr]T when centered and offset components (αc, αoc) are not present . For centered and offset wheels, the extended variables, such as αc and αoc, would be included to account for additional degrees of freedom such as wheel rotation .
The vision system used for mobile robot navigation faced limitations related to sampling times and environmental lighting. The system's performance was impacted because increased numbers of mobile fiducials and poor lighting conditions slowed down the camera's ability to accurately capture and process positional data . These constraints led to longer response times and in some cases, data inaccuracies or losses, necessitating reduced speeds and simplified environmental configurations during trials . Consequently, the overall functionality and responsiveness of the navigation system were negatively affected under these suboptimal conditions .
The primary role of the rotation matrix in the kinematic control of mobile robots is to transform velocity vectors from the robot's body frame to the world frame and vice versa. It ensures that the robot maintains the correct orientation relative to the global coordinates. Mathematically, the rotation matrix is structured as R(θ) = [cos θ sin θ 0; -sin θ cos θ 0; 0 0 1]. This matrix rotates vectors by the angle θ, aligning velocities and trajectories with global coordinates .