UNIVERSIDAD POLITECNICA DE MADRID
ESCUELA TECNICA SUPERIOR DE INGENIERIA Y
DISENO INDUSTRIAL
Grado en Ingenierıa Electronica y Automatica Industrial
TRABAJO FIN DE GRADO
Diseno y desarrollo de un robot esferico.
Integracion electromecanica y programacion del
software de control.
Jorge Barrientos Dıez
Cotutor: Leandro Cancar Tutor: Roberto Gonzalez
Abril 2014
ii
Agradecimientos
Para empezar, quiesiera agradecer a mi tutor Roberto Gonzalez, a
Leandro Cancar y a Jaime del Cerro por su apoyo y ayuda a lo largo
de la realizacion de este Trabajo Fin de Grado.
Ası mismo, me gustarıa agradecer a los profesores y los companeros
que han hecho posible mi formacion como ingeniero.
Tambien a los integrantes del grupo de Robotica y Cibernetica, por
su acogida y companerismo durante estos meses.
A mis amigos, concretamente Nerea, los miembros los de Off Topic
por su tough love, los miembros de Compılame esta! y Sandra, por
estar siempre ahı.
Por ultimo, quisiera mostrar mi mas sincero agradecimiento a mi fa-
milia, por soportarme, ayudarme y acompanarme durante todos estos
anos.
Resumen
Este Trabajo Fin de Grado tiene como objetivo el diseno y desarrollo
mecatronico de un robot esferico. Estos robots moviles se plantean
como una alternativa de locomocion a las mas comunmente utilizadas,
y se justifica su uso debido a las ventajas que presenta frente a estas,
tales como el aislamiento del exterior, la imposibilidad de situarlos
en posiciones de las que no se pueda recuperar, o la versatilidad de
terrenos en los que puede desempenar sus misiones con normalidad.
El robot en cuestion, al que se le ha llamado Rosphere - RObotic
SPHERE -, esta enmarcado dentro de diferentes proyectos del Grupo
de Robotica y Cibernetica de la Universidad Politecnica de Madrid,
y consiste en un sistema electromecanico del que se han desarrollado
los siguientes aspectos:
Mecanica: Al ser un tipo de robot no convencinal, no existen
modelos comerciales que esten en predisposicion de realizar desa-
rrollos sobre ellos. Es por esto que en este trabajo se han disenado
por completo y construido tres versiones diferentes de robots
esfericos, habiendole prestado especial atencion ya que su confi-
guracion mecanica condiciona enormemente las prestaciones y la
dinamica del robot.
Arquitecturas Hw y Sw: Como el robot construido es de di-
seno propio, se han establecido una serie de requisitos por un
lado propios de este proyecto, y por otro lado impuestos por las
necesidades de los proyectos que realiza el RobCib, y, basandose
en estos, se han establecido e implementado unas arquitectu-
ras hardware y software que han dado como resultado un robot
independiente capaz de ser integrado en Sistemas Multi-Robot
(MRS).
Control: Al disponer de un metodo de locomocion basado en
la inestabilidad, las esferas roboticas poseen unas caracterısticas
dinamicas con tal de mejorar dichas caracterısticas, se ha llevado
a cabo un modelado del robot, analizandolo y disenando e im-
plementando las tecnicas de control necesarias para hacer de el
un sistema manejable.
Como resultado, se ha obtenido un robot esferico funcional de al-
tas prestaciones, con un control de aptitud y una interfaz tales que
permiten ser utilizado sin la necesidad de conocer sus caracterısticas
concretas.
vi
Indice general
Indice de figuras V
Indice de tablas IX
1. Introduccion 1
1.1. Motivacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Estructura de la memoria. . . . . . . . . . . . . . . . . . . . . . . 4
2. Estado del arte 7
2.1. Metodos de locomocion. . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Rueda motriz con muelle. . . . . . . . . . . . . . . . . . . 8
2.1.2. Coche interno. . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Masa pendular con eje fijo. . . . . . . . . . . . . . . . . . . 10
2.1.4. Masas moviles. . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Modelado y control. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
i
INDICE GENERAL
3. Diseno mecanico. 13
3.1. Principios fısicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Eleccion del medio de locomocion escogido y caracterısticas. . . . 15
3.3. Desarrollos mecanicos de la Rosphere. . . . . . . . . . . . . . . . . 18
3.3.1. Rosphere V0.1. . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. Rosphere V0.2. . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3. Rosphere V0.3. . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Comparativa de disenos mecanicos. . . . . . . . . . . . . . . . . . 26
4. Modelado y Control. 29
4.1. Velocidad de rodadura. . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1. Modelado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2. Experimentos para la identificacion del modelo de la velo-
cidad de rodadura. . . . . . . . . . . . . . . . . . . . . . . 37
4.1.3. Control de la velocidad de rodadura. . . . . . . . . . . . . 40
4.2. Angulo de inclinacion de la esfera. . . . . . . . . . . . . . . . . . . 41
4.2.1. Modelado del sistema fısico. . . . . . . . . . . . . . . . . . 41
4.2.2. Metodologıa de identificacion. . . . . . . . . . . . . . . . . 43
4.2.3. Control para un sistema agregado. . . . . . . . . . . . . . 44
4.2.3.1. Modelado e identificacion. . . . . . . . . . . . . . 44
4.2.3.2. Control PID. . . . . . . . . . . . . . . . . . . . . 45
4.2.3.3. Implementacion. . . . . . . . . . . . . . . . . . . 45
ii
INDICE GENERAL
4.2.4. Control para un sistema desagregado. . . . . . . . . . . . . 45
4.2.4.1. Modelado e identificacion. . . . . . . . . . . . . . 46
4.2.4.2. Control PID. . . . . . . . . . . . . . . . . . . . . 46
4.2.4.3. Realimentacion taquimetrica. . . . . . . . . . . . 48
4.2.4.4. Control en cascada con realimentacion taquimetrica. 50
4.2.5. Implementacion y pruebas. . . . . . . . . . . . . . . . . . . 55
4.3. Modelo cinematico. . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1. Cinematica directa. . . . . . . . . . . . . . . . . . . . . . . 58
4.3.2. Cinematica Inversa. . . . . . . . . . . . . . . . . . . . . . . 59
5. Arquitectura Hardware y Software. 61
5.1. Seleccion de componentes Hardware. . . . . . . . . . . . . . . . . 61
5.1.1. Requisitos de los actuadores: . . . . . . . . . . . . . . . . . 62
5.1.2. Requisitos de elementos de potencia. . . . . . . . . . . . . 64
5.1.3. Requisitos de sistemas de instrumentacion y control. . . . 64
5.1.4. Componentes seleccionados. . . . . . . . . . . . . . . . . . 65
5.2. Arquitectura Hardware. . . . . . . . . . . . . . . . . . . . . . . . 69
5.3. Arquitectura Software. . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.1. Distribucion de tareas. . . . . . . . . . . . . . . . . . . . . 71
5.3.1.1. Controladora OpenCM9.04. . . . . . . . . . . . . 71
5.3.1.2. ArduPilot Mega 2.6. . . . . . . . . . . . . . . . . 73
5.3.2. Algoritmia. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
iii
INDICE GENERAL
5.3.3. Comunicaciones. . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.3.1. Protocolo. . . . . . . . . . . . . . . . . . . . . . . 76
5.3.3.2. Implementacion. . . . . . . . . . . . . . . . . . . 76
6. Conclusiones y trabajos futuros. 79
6.1. Conclusiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2. Lıneas futuras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Bibliografıa 83
iv
Indice de figuras
2.1. Primer robot esferico conocido. . . . . . . . . . . . . . . . . . . . 8
2.2. Esquema de un robot esferico del tipo rueda motriz con muelle. . 9
2.3. Prototıpo de robot esferico con coche interno. . . . . . . . . . . . 10
2.4. Partes de un robot esferico de tipo masa pendular con eje fijo. . . 10
2.5. Esquema de un robot esferico de masas moviles. . . . . . . . . . . 11
3.1. Principio basico de locomocion . . . . . . . . . . . . . . . . . . . . 14
3.2. Grados de Libertad . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Partes de un robot esferico de tipo masa pendular con eje fijo . . 18
3.4. Elementos de Rosphere v0.1 . . . . . . . . . . . . . . . . . . . . . 19
3.5. Rosphere v0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Centro de masas de Rosphere v0.1 . . . . . . . . . . . . . . . . . . 22
3.7. Centro de masas de Rosphere v0.2 . . . . . . . . . . . . . . . . . . 23
3.8. Elementos de Rosphere v0.3 . . . . . . . . . . . . . . . . . . . . . 25
3.9. Centro de masas de Rosphere v0.3 . . . . . . . . . . . . . . . . . . 26
v
INDICE DE FIGURAS
4.1. Modelo de un pendulo simple . . . . . . . . . . . . . . . . . . . . 31
4.2. Modelo de la carcasa esferica de la Rosphere . . . . . . . . . . . . 32
4.3. Lugar de las raices del modelo de la velocidad de rodadura. . . . . 35
4.4. Respuesta al escalon del modelo de velocidad total y su simplificacion. 36
4.5. Efectos de la no linealidad del pendulo. . . . . . . . . . . . . . . . 38
4.6. Identificacion de la velocidad de rodadura. . . . . . . . . . . . . . 40
4.7. Diagrama de la dinamica de direccion de la Rosphere . . . . . . . 42
4.8. Esquema de control del primer regulador PID en Simulink. . . . . 45
4.9. Identificacion de los sistemas . . . . . . . . . . . . . . . . . . . . . 47
4.10. Lugar de las raices incluyendo los polos del actuador y de la planta. 48
4.11. Esquema basico de alimentieren taquimetrica. . . . . . . . . . . . 49
4.12. Lugar de las raices al anadir una realimentacion taquimetrica. . . 50
4.13. Diagrama de bloques del lazo de realimentacion del motor . . . . 51
4.14. Respuesta del motor realimentado . . . . . . . . . . . . . . . . . . 52
4.15. Esquema de control total . . . . . . . . . . . . . . . . . . . . . . . 53
4.16. Lugar de las raices final con realimentacion taquimetrica . . . . . 54
4.17. Diagrama de bloques del sistema total listo para ser implementado 55
4.18. Respuesta al escalon del sistema con diferentes valores de histeresis. 56
4.19. Respuesta a un escalon de valor pequeno. . . . . . . . . . . . . . . 57
4.20. Respuesta a un escalon de gran valor. . . . . . . . . . . . . . . . . 57
4.21. Movimiento de la esfera en el plano. . . . . . . . . . . . . . . . . . 59
vi
INDICE DE FIGURAS
5.1. Actuador Dynamxel AX-12A. . . . . . . . . . . . . . . . . . . . . 66
5.2. Bateria LiPo 3S-1.3 Turnigy. . . . . . . . . . . . . . . . . . . . . . 66
5.3. Regulador Stepdown D15V35F5S3. . . . . . . . . . . . . . . . . . 67
5.4. Raspberry Pi B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5. ArduPilot Mega 2.5. . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6. OpenCM 9.04. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7. Esquema de arquitectura Hardware. . . . . . . . . . . . . . . . . . 70
vii
INDICE DE FIGURAS
viii
Indice de tablas
3.1. Situacion del CM con respecto al CG . . . . . . . . . . . . . . . . 27
3.2. Caracterısticas en los angulos lımite . . . . . . . . . . . . . . . . . 27
3.3. Caracterısticas de masa . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Requisitos Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . 65
ix
INDICE DE TABLAS
x
1
Introduccion
Desde su primera aparicion en la industria, la robotica se ha desarrollado e im-
plantado ampliamente en este sector, siendo una parte indispensable en cualquier
proceso en el que se realice una tarea demasiado repetitiva, peligrosa o difıcil. Es
por su gran aceptacion en este mundo que los robots industriales (generalmente
brazos roboticos o AGVs) han llegado a una estabilizacion de desarrollo en la
que los nuevos equipos von respecto a los anteriores no suelen suponer un gran
cambio, si no que mejoran poco a poco debido a los pequenos avances que sufre
la tecnologıa que usan.
En las ultimas decadas se ha producido un diversificacion de la robotica a
campos mas alla del industrial, tales como el sector militar y los servicios. A
diferencia de las fabricas, donde se conoce a la perfeccion tanto la tarea a realizar
como el lugar en el que se desenvuelven, la mayorıa de nuevos entornos en los
que es interesante introducir la robotica, son entornos no estructurados. Estos
ambientes se caracterizan por la presencia de elementos cuyo comportamiento
no conocemos, tales como objetos moviles sobre cuyo movimiento no tenemos
control, terrenos no estables, etcetera.
Para la automatizacion de tareas en estos entornos, surgen los robots moviles,
dotados de las capacidades sensoricas, de accion y de reaccion necesarias para
1
1. INTRODUCCION
poder completar sus misiones con exito. Uno de los principales ambitos de estudio
de la robotica movil es su modo de locomocion ya que la capacidad de moverse
es la principal caracterıstica que les diferencia del resto de robots no aptos para
este tipo de tareas.
Dentro de los ambientes en los que se pueden desenvolver, tierra, mar o aire, los
robots moviles terrestres o UGVs (Unmanned Ground Vehicles) ocupan una gran
parte del desarrollo, habiendo diferentes tecnicas para lograr el movimiento. Se
pueden clasificar los robots segun dichas tecnicas en: robots con ruedas u orugas
de deslizamiento, robots con patas, reptiles y robots terrestres con tecnicas de
movimiento alternativas.
Incluidas en los tipos de robots con tecnicas de movimiento alternativas se
encuentran las esferas roboticas, ya que pese a que la traccion sobre el terreno se
realiza de una forma similar a una rueda, el principio fısico utilizado para generar
esta traccion se basa en la inestabilidad del robot. Dicho principio fısico se explica
mas detalladamente en el capıtulo 3.
Este trabajo recorre el diseno y desarrollo mecatronico de un robot esferico,
desde su diseno mecanico, contemplado en el capıtulo 3; la seleccion de los compo-
nentes hardware y la programacion de las microcontroladoras de dicho hardware,
detallado en el capıtulo 5; y el analisis, diseno e implementacion de las tecnicas
de control implementadas en el sistema, explicados en el capıtulo 4.
1.1. Motivacion.
En el desarrollo tecnico de robots esfericos no se dispone de una amplia bi-
bliografıa, a diferencia que otros tipos de UGVs como pueden ser los caminantes.
Ademas, dicha bibliografıa tratan la tematica de los robots esfericos de forma
parcial, centrarndosee en algun aspecto de este tipo de robots y descuidando el
resto, dando como resultado modelos dinamicos y cinematicos solo llevados a
2
1.2 Objetivos.
cabo en simulacion como Sang et al(1), implementacion de tecnicas de control en
prototipos de poca calidad de diseno mecanico como Laplante et al(2), etcetera.
Es por ello que en este proyecto se ha querido prestar una atencion especial a
cada aspecto de los robots esfericos, consiguiendo una sinergia entre estos que de
lugar a un prototipo no unicamente util para llevar a cabo investigaciones en el
ambito de robots esfericos, si no que tambien para contar con un robot funcional
con el que llevar a cabo misiones, ya que este tipo de robots presenta ciertas
ventajas frente a otros tıpos de UGVs.
Dentro de las lıneas de trabajo del Robcib - grupo de Robotica y Cibernetica de
la Universidad Politecnica de Madrid - existen proyectos referentes a la realizacion
de tareas de vigilancia y seguridad, como el proyecto ROTOS - Sistema Multi
Robot para proteccion de Grandes Infraestructuras Exteriores - financiado por el
Ministerio de Economıa y Competitividad (DPI 2010-17998 ) o de agricultura de
precision como el proyecto RHEA - Robot Fleets for Highly Effective Agriculture
and Forestry Management - (NMP-CP-IP 245986-2 ). En ambos proyectos, el
robot desarrollado en este proyecto tiene una aplicacion directa, en la que la carga
de pago concreta realiza la tarea requerida, mientras el robot sirve de medio de
locomocion para dicha carga de pago.
El primer contacto del Robcib con los robots esfericos se dio en el Trabajo
Fin de Master ROSPHERE: Diseno, Construccion y Aplicacion de una Esfera
Robotica (3), en el que este Trabajo Fin de Grado contribuyo directamente con
la realizacion de los dos primeros prototipos, y tenıa como objetivo el validar la
utilidad de este tipo de robots. Este Trabajo de Fin de Grado se plantea por lo
tanto como un paso mas alla en esa direccion, pretendiendo crear un robot listo
para su uso.
1.2. Objetivos.
Como ya se ha explicado anteriormente el objetivo principal de este proyecto
es el crear un robot funcional para su uso en proyectos pertenecientes al Grupo de
3
1. INTRODUCCION
Robotica y Cibernetica de la Universidad Politecnica de Madrid, concretamente
persiguiendo las siguientes premisas:
Concebir y disenar pormenorizadamente el sistema mecanico de un robot
esferico.
Definir y desarrollar las arquitecturas Hardware y del Software de control.
Modelar, disenar e implementar las tecnicas de control de actitud y avance
necesarias.
Evaluar y analizar las prestaciones del robot realizado.
1.3. Estructura de la memoria.
Este documento muestra las etapas de realizacion de un robot esferico. Pri-
mero, en el capıtulo 2 se expone un breve estado del arte en el que se analiza la
situacion actual de este tipo de robots, mostrando sus caracterısticas y ejemplos
mas relevantes.
Posteriormente, se trata el aspecto mecanico de estos robots en el capıtulo 3,
explicando el principio basico de locomocion y detallando los diferentes prototipos
construidos, sus caracterısticas y las mejoras conseguidas tras cada iteracion
En el capıtulo 4 se proponen los modelos que caracterizan la dinamica del
robot construido, se identifican con dicho prototipo y se disenan e implementan
diferentes tecnicas de control. Por ultimo se explican las cinematicas tanto inversa
como directa.
El capıtulo 5 se establecen los requisitos del hardware, se explica la seleccion
de componentes realizada y se detalla el software implementado para el funcio-
namiento del robot.
4
1.3 Estructura de la memoria.
Por ultimo, el capıtulo 6 recopila las conclusiones a las que se han llegado
durante el desarrollo de este proyecto, y se proponen lineas futuras de desarrollo
que continuen con la mejora de las prestaciones del robot.
5
1. INTRODUCCION
6
2
Estado del arte
Este trabajo se centra en el area de robotica movil, concretamente en la apli-
cacion de un robot de cuerpo esferico. Concretamente, aborda la integracion de
los sistemas mecanicos, hardware, software y de control de un robot de este tipo.
La existencia de dichos robots es relativamente corta, habiendose econtrado
como primera referencia un artıculo de 1996 por Halme et al(4), en el que se da
a conocer el robot movil mostrado en la figura 2.1, con un metodo de locomocion
alternativo formado por una carcasa esferica y una Unidad Interna de Locomocion
(UIL). A partir de este artıculo, nuevas investigaciones han tenido como foco de
estudio los robots esfericos, proponiendose diferentes alternativas de Unidades
Internas de Locomocion a la propuesta inicialmente por Halme y tratando su
modelado y control, tanto dinamico como cinematico.
Ası pues, en este capıtulo se exponen los avances en esferas roboticas, centran-
dose en las alternativas de locomocion y los desarrollos en cuanto a su control.
7
2. ESTADO DEL ARTE
Figura 2.1: Primer robot esferico conocido.
2.1. Metodos de locomocion.
Como se detalla en el capıtulo 3, el movimiento de las esferas roboticas se con-
sigue mediante el posicionamiento controlado de su centro de masas con respecto
a su centro de gravedad. Para conseguir esto, existen diferentes tecnicas, siendo
las mas comunes descrıtas a continuacion.
2.1.1. Rueda motriz con muelle.
El primer prototipo, prouesto por Halme et al(4), consiste de un sistema
interno compuesto por una rueda de la que se controlan dos grados de libertad,
el de traccion y el de direccion. Dicha rueda actua sobre la superficie interna
de la carcasa esferica, haciendo que se mueva el cuerpo interno sobre esta y
desequilibrando ası el centro de masas.
Para asegurar que la rueda esta en continuo contacto con el interior de la
carcasa, se fija una rueda loca diamentralmente opuesta a la motriz, mediante
un cuerpo rıgido seguido de un muelle, que es el que origina la fuerza normal
entre la rueda motriz y la carcasa. El resto de componentes del robot se situa en
torno a este diametro formado entre las dos ruedas, procurando acercarse a uno
de los extremos para concentrar el centro de masas en un punto alejado al centro
8
2.1 Metodos de locomocion.
geometrico de la carcasa.
Figura 2.2: Esquema de un robot
esferico del tipo rueda motriz con
muelle. Rueda motriz (1), muelle de com-
presion (2), rueda libre (3), hardware de
control (4).
Como ventajas principales, tiene
la simplicidad de implementacion de
la rueda motriz, sin embargo, esta
configuracion tiene numerosas des-
ventajas tales como que, al tener que
situar un elemento atravesando la es-
fera con una rueda loca, las masas en
cada extremo de dicho elemento se
contrarrestan, antrayendo al centro
de masas hacia el centro de gravedad;
las perdidas energeticas que se pro-
ducen con el rozamiento y desliza-
miento de la rueda motriz con el inte-
rior de la carcasa esferica y la necesi-
dad de que este interior sea uniforme,
para que la rueda mueda moverse li-
bremente sin encontrarse obstaculos.
2.1.2. Coche interno.
El Sphericle, de Bicchi et al(5), es el primer robot esferico que propone este
metodo de locomocion, cuyo funcionamiento es muy simple. Como UIL de estos
robots, se situa un vehıculo con ruedas, que desplaza el centro de masas hacia sı,
y lo cambia de posicion desplazandose por la pared interior de la carcasa. Otro
ejemplo de esta configuracion es el Sphero1, modelo comercial planteado como un
juguete de radiocontrol manejable desde un smartphone.
La gran ventaja de este metodo es la facilidad de construccion, ya que la
complejidad de diseno reside en un robot con ruedas, que son los robots moviles
por excelencia.
1http://www.gosphero.com/
9
2. ESTADO DEL ARTE
Figura 2.3: Prototıpo de robot esferi-
co con coche interno. Construido por Al-
ves et al(6).
En contraposicion, tiene un gran
numero de desventajas. Por un lado,
el contacto entre las ruedas del robot
utilizado como UIL y la superficie in-
terior es provocado por la gravedad,
lo que puede provocar deslizamien-
tos o perdidas de contacto cuando la
esfera sufre perturbaciones tales co-
mo baches. Esto se traduce en una
ineficiencia energetica y una posible
perdida del control del robot preci-
samente en las situaciones en las que
este es altamente necesario.
2.1.3. Masa pendular con eje fijo.
Figura 2.4: Partes de un robot esferi-
co de tipo masa pendular con eje fijo.
(1)Carcasa esferica. (2)Eje fijo. (3)Cuerpo
central. (4)Pendulo.
Esta variante es la mas desarro-
llada desde su propuesta por Mi-
chaud et al(7) y a la que pertene-
ce el robot desarrollado en su traba-
jo fin de grado, por lo que este fun-
cinamiento se explica detalladamen-
te en el capıtulo 3. El primer robot
esferico comercial, Rotundus1, perte-
nece a esta subclase de robots esferi-
cos.Dicho robot esta destinado pa-
ra llevar a cabo labores de vigilancia
mediante teleoperacion, como expli-
ca Seeman et al(8) sobre su precur-
sor, GroundBot.
1http://www.rotundus.se/
10
2.1 Metodos de locomocion.
La UIL esta formada por un pendulo esferico que gira en torno a dos diametros
perpendiculares de la carcasa, estando formado uno de estos por un eje fısico que
sirve de soporte del pendulo dentro de la esfera.
Comparado con el resto de configuraciones, la complejidad de construccion
es media, ya que consiste en la fijacion de un pendulo al centro geometrico de la
esfera mediante un eje fijado a la carcasa y el control de los dos grados de libertad
de este dicho pendulo. Ademas, la posicion del centro de masas puede ser en todo
momento conocida debido a la simplicidad cinematica del pendulo.
Como gran ventaja diferenciadora con respecto a los metodos anteriormente
explicados, se encuentra la eficiencia energetica, ya que unicamente ha de ac-
cionar dos grados de libertad, que no sufren perdidas de energia por friccion ni
deslizamientos entre la UIL y la carcasa.
2.1.4. Masas moviles.
La ultima configuracion presentada es tal vez la peor de todas. La idea prin-
cipal, presentada por Mojabi et al(9), es la de disponer de radios que conecten el
centro geometrico con la carcasa esferica sobre los cuales se disponen de masas
que se pueden desplazar a lo largo de la direccion de los radios, modificando ası
la posicion del centro de masas.
Figura 2.5: Esquema de un robot
esferico de masas moviles.
Su gran ventaja es que, a diferen-
cia que el resto de configuraciones de
robots esfericos, los robots que utili-
cen esta tienen la capacidad de ser
holonomicos.
Sin embargo, esta ventaja queda
eclipsada debido a su gran numero de
desventajas tales como la gran com-
plejidad de diseno mecanico, la difi-
cil controlabilidad del sistema y una
11
2. ESTADO DEL ARTE
gran limitacion de distancia maxima entre el centro de masas y el centro geometri-
co.
Este tipo de robots esfericos se ha trabajado unicamente en simulacion, sin
haberse encontrado ningun prototipo fısico que demuestre su eficiencia.
2.2. Modelado y control.
Dado a sus caracterısticas, el control tanto dinamico como cinematico de los
robots esfericos ha sido objeto de estudio por diferentes autores. Aunque el prin-
cipio de movimiento es el mismo en todas las configuraciones, consistente en el
posicionamiento del centro de masas, debido a las caracterısticas de cada metodo
de locomocion el modelado dinamico y cinematico difieren entre si.
En la modalidad de masa pendular con eje fijo, Nagai(10) es el primero en
establecer un modelo dinamico, planteando como desacopladas la dinamica de
marcha y la dinamica de giro y haciendo uso de la mecanica lagrangiana para
modelarlas. Dicha separacion de las dinamicas es argumentada y demostrada por
Kayacan et al(11).
La unica formulacion que no se basa en la mecanica lagrangiana la realiza
Halme et al(4), haciendo uso de la mecanica newtoniana. Ademas, incluye con-
sideraciones de movimiento frente a pendientes y obstaculos. Sin embargo, este
modelo se basa en el metodo de rueda motriz con muelle, y analiza unicamente
la dinamica de marcha.
En cuanto a la planificacion de trayectorias, la aportacion mas importante es
la de Kayacan et al(11) que utiliza un control de realimentacion de estado para
cada dinamica. Otro aporte notable es el de Zhan et al(12), que planifica las
trayectorias minimizando tanto el tiempo como la energıa invertidos.
12
3
Diseno mecanico.
La principal caracterıstica diferenciadora de los robots esfericos frente a otros
tipos de robots es su estructura mecanica. Pese a que en todo robot la configura-
cion de sus elementos fısicos es un factor importante, en los robots esfericos este
aspecto cobra especial importancia ya que es tanto complicado en diseno como
crıtico a la hora de tener un robot suficientemente eficaz.
En este capıtulo se comienza detallando el principio basico de funcionamien-
to del movimiento de cualquier robot esferico, se explica el tipo de locomocion
escogido y finalmente se describe los diferentes prototipos desarrollados.
3.1. Principios fısicos.
La mayorıa de robots moviles tienen como uno de sus requisitos principales la
estabilidad. Cuando la pierden, muy pocos cuentan con la capacidad de recupe-
rarse y por lo tanto quedan inutilizados hasta que un agente externo les devuelva
a su posicion estable.
Las esferas roboticas, sin embargo, basan su movimiento en la inestabilidad.
Tomemos una esfera cuya masa esta uniformemente distribuida. Esto hace que el
13
3. DISENO MECANICO.
centro de masas se situe en el centro geometrico de la esfera. Partiendo de una
situacion de reposo y estando situada la esfera sobre una superficie plana horizon-
tal, la fuerza de la gravedad, aplicada sobre el centro de masas, estara contenida
en una recta vertical que pasa por el punto de contacto entre la superficie de la
esfera y el suelo. En esta situacion, tanto el sumatorio de fuerzas como el de pares
que sufre la esfera seran nulos, por lo que esta permanecera en reposo. Se puede
ver facilmente que esto pasara para cualquier distribucion de masas dentro de la
esfera que provoque que el centro de masas total se encuentre dentro de la recta
que une el punto de contacto entre las dos superficies y el centro geometrico de
la esfera como se puede ver en la figura 3.1a.
Por otra parte, si el centro de masas no estuviese situado en dicha recta, caso
representado en la figura 3.1b, la fuerza de gravedad aplicada sobre el provo-
carıa un par sobre el centro geometrico de la esfera, generando una situacion de
desequilibrio que harıa que la esfera experimentase un movimiento de rodadura,
hasta que el centro de masas se situase de nuevo en la vertical que pasa sobre el
punto de contacto.
(a) Estado de reposo (b) Estado de desequilibrio
Figura 3.1: Principio basico de locomocion. Mientras que en la figura (a) la
esfera permanece en reposo por que todas las fuerzas que sufre estan contenidas en
la vertical que pasa por el punto de contacto con el suelo, en la figura (b) el centro
de masas genera un par que se invierte en movimiento de la esfera.
14
3.2 Eleccion del medio de locomocion escogido y caracterısticas.
Las esferas roboticas cuentan por lo tanto con un mecanismo interno capaz
de controlar la posicion de su centro de masas, provocando inestabilidad y por lo
tanto movimiento.
3.2. Eleccion del medio de locomocion escogido
y caracterısticas.
Dentro de los diferentes tipos de configuracion de esferas roboticas, se ha
seleccionado para este trabajo el llamado Masa pendular con eje fijo, debido a
sus numerables ventajas.
El modelo ideal simplificado de este metodo de locomocion considera que
el robot esta compuesto por un cuerpo rıgido de geometrıa esferica de masa
inexistente en cuyo centro se situa el punto fijo de un pendulo esferico ideal cuyos
grados de libertad son controlables, siendo estos la entrada de nuestro sistema.
Se entiende por pendulo esferico aquel objeto compuesto por una masa puntual
que se mantiene a una distancia constante de un punto fijo y cuyo movimiento
tiene lugar en el espacio, en contraposicion al del pendulo simple que tiene lugar
en un solo plano. Se considera que el cuerpo que une a la masa con el centro es
un cuerpo rıgido carente de masa. Por lo tanto, la posicion del centro de masas
del conjunto total del robot coincide con el extremo del pendulo.
Por lo tanto, se tiene como resultado un robot esferico cuyo centro de masas
podemos resituar dentro de la superficie esferica de centro coincidente con el del
robot y de radio la longitud del pendulo. De esta maneta es posible hacer que el
robot se mueva debido al principio explicado anteriormente.
Fısicamente esto no es realizable, puesto que para mantener la distancia del
pendulo constante hace falta de un elemento fısico. Por ello, para asemejarlo mas
al modelo ideal, en el extremo del pendulo se coloca una masa de valor elevado de
tal manera que el resto de masas del robot sean despreciables. Gracias a esto, se
consigue que el centro de masas del conjunto total se situe en torno a la lınea que
15
3. DISENO MECANICO.
une el centro de la esfera con el extremo del pendulo, acercandose mas a dicho
extremo cuanto mas optimo sea el diseno.
Puesto que es necesario de otro elemento fısico que asegure el punto fijo del
pendulo con el centro geometrico de la esfera, se fija una barra o .eje fijocoincidente
con un diametro de esta. Esto entre otras cosas, provoca que el robot sea no-
holonomico, disponiendo de dos grados de libertad mostrados en la figura 3.2.
El principal grado de libertad del pendulo, es al correspondiente a generar la
traccion de la esfera y es un movimiento de rotacion de 360o en torno al eje fijo.
El segundo, encargado de cambiar la inclinacion del pendulo con respecto al
eje fijo, es otro movimiento de rotacion, en torno a un diametro perpendicular a
dicho eje. En este caso, el giro no es de 360◦ si no que idealmente es de ±90◦,
situando al pendulo sobre el eje fijo, y que en la practica se reduce enormemente
debido a las limitaciones mecanicas.
Figura 3.2: Grados de Libertad. Los dos grados de libertad de un robot esferico
de tipo masa pendular con eje fijo se corresponden con dos movimientos de rotacion
entorno a dos ejes perpendiculares cuyo punto de interseccion coincide con el centro
geometrico de la carcasa esferica.
Se define por lo tanto la configuracion del robot como un sistema formado
por 3 cuerpos rıgidos y dos grados se libertad, como se puede ver en la figura 3.3
16
3.2 Eleccion del medio de locomocion escogido y caracterısticas.
siendo dichos cuerpos los siguientes:
Cuerpo esferico externo: Como su nombre indica, se trata de una su-
perficie esferica cuyo exterior sera el que interactue con el medio, haciendo
las funciones equivalentes a las de las ruedas en aquellos tipos de robots
moviles que basen su metodo de locomocion en estas.
Por otro lado, en el interior de la esfera se situara el resto del mecanismo,
siendo en la mayorıa de los casos el eje fijo del robot solidario a dicha
cubierta esferica. Sin embargo, en la tercera version de Rosphere, este eje
puede rotar con respecto a el chasis externo en torno a su direccion principal.
IDU: Siendo acronimo de Internal Driving Unit (Unidad Interna de Loco-
mocion), es un cuerpo situado en el centro de la esfera encargado de generar
el movimiento del pendulo en torno al eje fijo. Ademas, se suele situar en
el los sensores inerciales (IMU) puesto que la inclinacion de la IDU indica
la posicion del pendulo, y por lo tanto del centro de masas con respecto al
eje fijo.
En las dos primeras versiones la IDU giraba entorno al eje fijo, mientras
que en la tercera el eje y la IDU eran solidarios entre si.
Pendulo: Este gira con respecto a la IDU en torno un eje perpendicular
al fijo, y en su extremo se situa un masa lo suficientemente grande como
para hacer que la de la IDU sea despreciable. Su objetivo fijo es desplazar
el centro de masas lo mas cercano a su extremo para que al accionar los dos
grados de libertad se pueda modificar la posicion de este facilmente.
Este sistema de locomocion tiene numerosas ventajas con respecto a las otras
configuraciones de robots esfericos como la simplicidad de la cinematica directa,
pudiendo obtener la posicion del centro de masas facilmente a partir del valor de
los dos GdL; la posibilidad de situar modulos externos en su eje fijo, puesto que
excepto en situaciones de colision este nunca entrara en contacto con el suelo o la
sencillez de diseno y viabilidad mecanica con respecto a las otras configuraciones.
17
3. DISENO MECANICO.
Figura 3.3: Partes de un robot esferico de tipo masa pendular con eje
fijo. (1)Carcasa esferica. (2)Eje fijo. (3)IDU. (4)Pendulo.
Por otro lado, tiene la desventaja de ser un sistema no-holonomico, pero esta
es una caracterıstica que comparte con todas las configuraciones de robots esferi-
cos construidos, solo se ha encontrado bibliografıa de robots omnidireccionales
referente a modelado y simulacion y en general, con los robots moviles terrestres.
3.3. Desarrollos mecanicos de la Rosphere.
Pese a haber investigaciones ya existentes e incluso modelos comerciales de
robots esfericos, siguen siendo un campo relativamente nuevo en el que se puede
seguir aportando continuas mejoras. Es por esto por lo que el objetivo de es-
te trabajo es disenar y construir un robot esferico por completo, incluyendo su
estructura mecanica. Al ser esta bastante complicada y decisiva en el resultado
final del funcionamiento del robot, se le presto especial atencion y se desarrollaron
un total de tres versiones diferentes de la rosphere, mejorando sus prestaciones
sustancialmente en cada iteracion.
18
3.3 Desarrollos mecanicos de la Rosphere.
3.3.1. Rosphere V0.1.
Para el primer prototipo, se propuso como principales objetivos comprobar el
principio de funcionamiento de este tipo de robots y tener un sistema fısico sobre
el que experimentar. Con tal fin, se construyo Rosphere V0.1, Utilizando una
esfera de ejercicio para mascotas como cubierta, un tubo de aluminio como eje
fijo, piezas fabricadas por una impresora 3D para la IDU, pendulo y union entre
el resto de elementos que lo componıan, la baterıa y tuercas de hierro a modo de
peso situadas en el pendulo para acercar el centro de masas a la superficie esferica
y servos de aeromodelismo de alto par para actuar sobre los dos GdL.
(a) IDU de la Rosphere v0.1 (b) Pendulo de la Rosphere v0.1
Figura 3.4: Elementos de Rosphere v0.1. En la figura (a) se puede ver la
IDU de la primera version de rosphere, con el servo que actua sobre el primer GdL
por encima del eje fijo. Esto es negativo para la localicacion final del centro de
masas. En la figura (b) se puede ver el pendulo de Rosphere v0.1 formado por una
horquilla y un cajetin que contiene la baterıa y piezas de hierro.
Este primer prototipo permitio validar el principio de funcionamiento de este
tipo de robots basado en la inestabilidad, pero resulto ser bastante ineficiente,
incontrolable y alejado del modelo ideal. Sus principales deficiencias eran:
Los dos ejes, tanto el fijo como el de direccion, no coincidıan en un mismo
19
3. DISENO MECANICO.
plano, por lo que la cinematica directa para hallar el lugar del centro de
masas era mas complicada, ası como que se alejaba del modelo ideal.
La velocidad de recuperacion del estado de reposo de la esfera era superior a
la velocidad del servo para sacar al centro de masas de la zona de equilibrio.
Esto era causa entre otras cosas de que el centro de masas estaba muy cerca
del centro geometrico de la esfera, haciendo necesario un angulo muy grande
para desplazarlo lo suficiente como para vencer al rozamiento estatico inicial
y comenzar su movimiento..
Las masas no estaban bien distribuidas de tal forma que el peso del cuerpo
central no era despreciable con respecto al del pendulo, haciendo que el
centro de masas no se mantuviese equidistante al centro geometrico de la
esfera para diferentes angulos del pendulo. Esta mala distribucion tambien
provocaba que en estado neutro de los actuadores, el eje fijo del robot
estuviese inclinado con respecto a la horizontal.
Las piezas estaban sobredimensionadas. Debido a la poca experiencia en
diseno mecanico y mas aun en este tipo de robots, todas las piezas disenadas
eran ineficaces tanto en cuanto a forma, como en cuanto a funcionalidad y
dimensiones.
3.3.2. Rosphere V0.2.
Teniendo en mente los defectos de la primera version, se rediseno la mecanica
de la Rosphere para un mejor funcionamiento. Las medidas tomadas fueron:
Situar ambos ejes de giro del pendulo en el mismo plano, haciendolos coin-
cidentes en el centro geometrico de la esfera.
Colocar el centro de masas de los motores por debajo de el plano formado
por los dos ejes mencionados, ayudando a que el centro de masas final se
situase mas cercano al extremo del pendulo.
20
3.3 Desarrollos mecanicos de la Rosphere.
Figura 3.5: Rosphere v0.1.
Alejar del centro geometrico de la esfera el centro de masas. Esto se puede
conseguir alargando el brazo del pendulo, disenando este en forma de cas-
quete esferico para adaptarse a la superficie interior del chasis de la esfera
y entonces poder acercarlo aun mas a dicha superficie. Tambien se sustitu-
yeron las tuercas utilizadas como masa por plomo, metal de gran densidad,
fundido con la forma del pendulo.
Disenar las piezas acorde con los requisitos, simplificandolas y aligerandolas
para que no afectasen al conjunto del centro de masas.
Este rediseno mejoro enormemente las prestaciones de la Rosphere, situando su
centro de masas mucho mas alejado del centro geometrico, haciendo falta un
incremento muy pequeno del angulo para vencer el rozamiento estatico para poder
comenzar su movimiento y haciendola mucho mas controlable y cercana al modelo
ideal.
Pese a esto, la nueva version de la Rosphere tambien tenıa defectos tales como
la debilidad de la pieza central, que flectaba debido al par provocado por el motor
que inducıa el movimiento de traccion y que termino por romperse. Tambien se
21
3. DISENO MECANICO.
Figura 3.6: Centro de masas de Rosphere v0.1. En la figura se observa que
el centro de masas de la primera version de Rosphere se encuentra mas cercano
al eje fijo que al pendulo y ligeramente a la izquierda. Ademas, dicho centro de
masas no realizaba una trayectoria circular ni simetrica al mover el segundo grado
de libertad.
quemaron dos servos debido a la falta de protecciones tanto mecanicas como
electricas y la dificultad de abrir la esfera para desconectar la alimentacion.
3.3.3. Rosphere V0.3.
Debido a los fallos mencionados de la Rosphere V0.2, se propuso una tercera
iteracion del diseno mecanico de la Rosphere que mejorase y aumentase las pres-
taciones de las versiones anteriores, cuyos principales objetivos eran los siguientes:
Subsanar los principales fallos de la version anterior, haciendo los calculos
pertinentes para asegurarse que tanto las piezas como los motores no se
rompiesen.
Mejorar en lo posible las caracterısticas generales del robot, eliminando
rozamientos innecesarios, alejando aun mas el centro de masas del centro
22
3.3 Desarrollos mecanicos de la Rosphere.
Figura 3.7: Centro de masas de Rosphere v0.2. En la segunda version, pese
a que se mantuvo la electronica, los actuadores y las baterıas de la anterior version,
se mejoro notablemente el diseno mecanico. En la figura se puede ver como el centro
de masas se situa mucho mas cercano al pendulo que en la Rosphere v0.1.
geometrico, aumentando el rango del angulo de direccion, etcetera.
Incluir nuevas funcionalidades tales como la posibilidad de disponer en un
futuro de unos modulos externos en los que se pudiesen incluir camaras
o sensores y la posibilidad de comunicar estos con el interior de la esfera
mediante cable.
Gracias a la experiencia adquirida tanto en diseno mecanico en general como
en robots esfericos, Rosphere V0.3 presenta grandes ventajas con respecto a sus
predecesoras. Para esta version se emplearon diferentes materiales, permitiendo
hacer mas resistentes aquellas piezas que estuviesen sometidas a los mayores es-
fuerzos comprobando con Inventor como respondıan ante estos a la vez que se
hacian mas ligeras aquellas cuya funcionalidad no exigiese propiedades mecanicas
23
3. DISENO MECANICO.
especıficas.En el diseno se ha tenido en cuenta que el resultado final es un com-
ponente electromecanico por lo que ha sido necesario ajustarlo para contener los
diferentes elementos electronicos que componen el sistema. Ası mismo, se opto
por un diseno modular, haciendo una pieza por cada funcionalidad, de tal manera
que si habıa algun fallo de calculos o se rompıa alguna con el uso, bastase con
redisenar y volver a fabricar esa pieza en concreto sin afectar al resto del conjunto.
Las caracterısticas de cada parte de la esfera son las siguientes:
Cubierta esferica: Mientras para esta se sigue utilizando una bola de
ejercicio para mascotas, se opta por permitir que rote con respecto al eje fijo
sobre la direccion principal de este mediante la inclusion de rodamientos.
De esta forma, se puede alargar el eje para que este salga al exterior de
tal manera que se puedan montar sobre el futuros modulos externos que
mantengan una posicion fija con respecto al suelo (interesante en ciertos
casos tales como en los que dichos modulos sean camaras) y que se pueda
abrir la esfera con facilidad.
IDU: Esta se hace solidaria al eje fijo, y contiene una porcion de engranaje
hecha en plancha de acero inoxidable de 2 mm de grosor que permite al
pendulo girar en torno al eje de direccion. Tambien contiene el motor que
genera el movimiento de rotacion entre la IDU y el eje fijo.
Pendulo: Para situar el extremo de este a una distancia constante del cen-
tro geometrico de la esfera se utilizan 4 varillas de acero inoxidable, mucho
mas resistentes a deformaciones que las piezas de plastico que cumplıan el
mismo fin en las versiones anteriores. Ademas, en el se situa el motor encar-
gado de controlar la direccion, que antes se situaba en la IDU, propiciando
que el peso de esta sea aun mas despreciable a la hora de calcular el centro
de masas y se sustituye todo el cuerpo por plomo, aprovechando mejor el
espacio.
Este ultimo diseno cumplio sus expectativas acercandose mucho mas que los
anteriores al modelo ideal. Esto se puede comprobar por ejemplo en que el tiempo
24
3.3 Desarrollos mecanicos de la Rosphere.
(a) IDU de la Rosphere v0.3 (b) Pendulo de la Rosphere v0.3
Figura 3.8: Elementos de Rosphere v0.3. En la figura (a) se puede ver la IDU
de la ultima version. En la figura (b) se puede ver el pendulo de Rosphere v0.3
formado, a parte de por el actuador, por plomo y varillas de acero inoxidable.
de establecimiento de angulo del eje fijo ante una entrada escalon del angulo de
direccion es mayor que en las otras versiones. Esto en aspectos de control puede
ser negativo ya que es un sistema muy oscilante como se puede ver mas detalla-
damente en el capıtulo 4. Sin embargo, es un punto a favor en cuanto a similitud
con el modelo, puesto que en este, en el que no se considera el rozamiento, el
pendulo se mantendrıa oscilando indefinidamente.
Todos los desarrollos de software y de control expuestos en este trabajo se han
hecho sobre el prototipo Rosphere V0.3.
25
3. DISENO MECANICO.
Figura 3.9: Mecanismo interno de Rosphere v0.3, mostrando su centro
de masas.
3.4. Comparativa de disenos mecanicos.
Pese ha tener una medida cualitativa bastante notable de la mejora de las
diferentes iteraciones de diseno mecanico de la Rosphere, tanto en funcionalidades
como en caracterısticas dinamicas y de acercamiento al modelo ideal, se ha optado
por recoger una serie de datos cuantitativos caracterısticos de las tres versiones
para poder compararlas de una forma mas realista.
Dichas caracterısticas son referentes a como de cercano es el prototipo al mode-
lo ideal por lo tanto intentan determinar la semejanza del conjunto IDU+Pendulo
al de un pendulo ideal.
La tabla 3.1 muestra la situacion del centro de masas con respecto al centro
26
3.4 Comparativa de disenos mecanicos.
Coordenada Rosphere V0.1 Rosphere V0.2 Rosphere V0.3
X 8, 31mm 1, 28mm 0, 40mm
Y 5, 51mm 1, 84mm 0, 29mm
Z 23, 38mm 94, 2mm 112, 3mm
Cuadro 3.1: Situacion del centro de masas con respecto al centro
geometrico El sistema de cordenadas se ha situado en el centro geometrico con
el eje Z perpendicular al plano del suelo y el eje X coincidente con la direccion del
eje fijo. Las medidas estan en valor absoluto
geometrico. Lo ideal es que la cordenada Z sea lo mas cercana al radio del cas-
quete esferico posible, ya que con pequenos cambios del angulo de inclinacion del
pendulo se consiguen mayores desplazamientos del centro de masas cuanto mayor
sea la longitud del pendulo.
Por otro lado, las distancias tanto en el eje X e Y en el modelo ideal son nulas,
ya que en estado neutral, el centro de masas se deberıa de situar en la vertical,
teniendo unicamente componente Z.
Se puede ver en dicha tabla la significante mejora entre versiones aumentando
casi 5 veces la distancia en el eje Z entre la V0.1 y la V0.3 y alcanzando unas
desviaciones de X e Y del orden de las decimas de milımetro en la Rosphere V0.3.
Caracterıstica Rosphere V0.1 Rosphere V0.2 Rosphere V0.3
Max. angulo destrogiro 34, 62◦ 42, 92◦ 45, 00◦
Max. angulo levogiro 32, 01◦ 23, 04◦ 45, 00◦
∆ | CM − CG |MAX 25, 1 % 90, 5 % 98, 4 %
Cuadro 3.2: Caracterısticas en los angulos lımite
La tabla 3.2 muestra por un lado el valor maximo alcanzable por el angulo de
inclinacion del pendulo del segundo grado de libertad en ambos sentidos y por
otro lado la relacion de la mınima distancia entre el centro geometrico y el centro
de masas y la maxima. Esta relacion idealmente tiene valor unitario, implicando
27
3. DISENO MECANICO.
que la maxima y la mınima distancia son iguales, y por lo tanto que el centro de
masas traza una trayectoria circular cuando el pendulo realiza todo su recorrido.
En la ultima version se puede ver que se ha aumentado el angulo maximo de
inclinacion del pendulo, ademas de hacerlo simetrico, cosa que no pasaba en la
Rosphere V0.2, teniendo casi el doble de recorrido en un sentido que en el otro.
Tambien se ha mejorado la relacion entre la maxima y a mınima distancia del
centro de masas al centro de la esfera, siendo muy cercana a la unidad.
Caracteristica Rosphere V0.1 Rosphere V0.2 Rosphere V0.3
Masa total 1352g 1400g 1586gMpendulo
Mtotal29, 3 % 71, 7 % 81, 5 %
Cuadro 3.3: Caracterısticas de masa
En la tabla 3.3 se puede ver por un lado la masa total del mecanismo interno,
formado por la IDU mas el pendulo, de las tres versiones y por otro lado la
relacion entre el peso del pendulo y dicho peso total. Esta relacion es importante
por que indica como de significativo es el peso del pendulo con respecto a todo el
conjunto. En el caso ideal, en el que la masa de la IDU es nula, la relacion sera
del 100 %. Se puede ver que aun que sea del 81, 5 % dicha relacion ha mejorado
enormemente a lo largo de las diferentes versiones.
28
4
Modelado y Control.
A fin de poder gobernar los movimientos de la Rosphere, tanto en modo tele-
operado como autonomo, es necesario modelar su comportamiento para establecer
alguna estrategia de control. Es por ello que se ha invertido gran parte del es-
fuerzo de este trabajo en esta tarea, tanto desde su punto de vista teorico como
en la implementacion en el prototipo.
En este capıtulo se proponen modelos que definen los movimientos del robot
esferico y se identifican los parametros concretos del prototipo, para poder final-
mente disenar algorıtmos de control, que son ajustados mediante simulacion y
comprobados en el modelo real, evaluando su efectividad en este. Por ultimo, se
explica el modelo cinematico tanto directo como inverso.
La configuracion de masa pendular con eje fijo dispone de dos grados de liber-
tad correspondientes a los de un pendulo esferico como se explica en el capıtulo
3. Al haberse considerado dichos grados de libertad independientes entre si en
la mayorıa de los desarrollos consultados como bibliografıa tales como Kayacan
et al(11) o Bicchi et al(13), en este trabajo tambien se plantean como desacopla-
dos y por lo tanto se modela y controla cada grado de libertad por separado.
29
4. MODELADO Y CONTROL.
4.1. Velocidad de rodadura.
Este grado de libertad es el encargado de inducir movimiento al robot. Mien-
tras que en el otro grado de libertad es necesario un control en posicion, en este
es necesario controlar la velocidad angular, ya que a partir de esta se deduce la
velocidad lineal del robot.
4.1.1. Modelado.
Existen ya estudios del modelado de este movimiento planteados por diferentes
investigadores que lo enfocan desde el punto de vista de la mecanica Lagrangiana
como por ejemplo Cameron et al(14). De todas formas, la mayorıa utilizan otros
tipos de configuraciones de robots esfericos, los resultados obtenidos no son con-
trastados con datos reales y cuando lo son, dichos resultados no son concluyentes.
Debido a esto, y con el objetivo de aportar un punto de vista diferente al control de
estos robots, se ha optado por desarrollar un modelo propio mediante la mecanica
newtoniana, identificando los parametros y validandolo experimentalmente con
el prototipo.
Se parte del modelo de un pendulo simple como se muestra en la figura 4.1
siendo la entrada un par motor Tm que realiza el actuador. Este par motor se
aplica en su totalidad al pendulo, y se invierte en generar una aceleracion angular
θp en el hasta que se iguale dicho par motor con el generado por la fuerza de
gravedad aplicada sobre el centro de masas de valor Mp, dando como resultado
en regimen permanente un angulo del pendulo constante θp y por lo tanto una
velocidad y una aceleracion angulares nulas. Estas tres variables coincidirıan con
sus homonimas del actuador.La ecuacion 4.1 define este sistema.
Tm = Mp · g · l · sen (θp) +B1 · θp +Mp · l2 · θp (4.1)
Por otro lado, para modelar el casquete esferico se puede asemejar este a una
30
4.1 Velocidad de rodadura.
Figura 4.1: Modelo de un pendulo simple.
rueda. Como la figura 4.2 muestra, al imprimir un par Tm sobre la rueda en torno
a su eje, se contrarresta con el par generado por la fuerza de rozamiento Fr entre la
superficie del suelo y la cubierta, y se produce una aceleracion angular α = ω = θr
de la rueda. Tambien en este caso la velocidad y la aceleracion angulares de la
rueda seran iguales a las del actuador.
Siendo la ecuacion 4.2 la ecuacion de equilibrio de pares.
Tm = Fr ·Re + B2 · θr +2
3·Mr ·R2
e · θr (4.2)
Sin embargo, en ambos casos se ha tenido en cuenta que tanto el eje fijo
del pendulo como el eje de giro de la rueda se encuentran anclados a un objeto
inamovible, y es por esto por lo que el par motor se invertıa en su totalidad en el
objeto que no estaba anclado, el pendulo en el primer caso y el casquete esferico
en el segundo.
Muchas de las simplificaciones llevadas a cabo por los modelos de el resto de
investigadores han tenido solo en cuenta uno de estos efectos. O consideran que
en regimen permanente el pitch de la IDU es constantemente nulo y por lo tanto
31
4. MODELADO Y CONTROL.
Figura 4.2: Modelo de la carcasa esferica de la Rosphere.
la velocidad angular del actuador es igual a la de la esfera o consideran que dicho
angulo puede modificarse y afecta de forma porporcional a la velocidad del robot.
Dado a las caracterısticas del robot, lo que sucede realmente es que hay un
par generado entre ambos cuerpos en torno al eje principal, invirtiendose en su
totalidad sobre cada uno, pero en sentido contrario y por lo tanto teniendo que
considerar ambos para hacer el computo total.
Teniendo esto en cuenta, la fuerza de rozamiento viscoso del motor cuyo coe-
ficiente se llamara Bm depende de la velocidad angular de este, que es la suma
algebraica de las velocidades angulares de ambos cuerpos θp y θr. Este termino, al
ser dependiente de ambos sistemas, solo ha de incluirse en una de las ecuaciones.
Ademas, en la ecuacion correspondiente al pendulo hay que tener en cuenta el
angulo entre este y el eje fijo θe, que es la variable controlada por el actuador de
direccion, ya que este afecta de dos formas diferentes al movimiento de traccion.
Por un lado, afecta a la distancia entre el extremo del pendulo y el eje fijo,
siendo esta distancia el brazo del par que genera el pendulo. Por otro lado, al
variar la inclinacion del eje principal con respecto a la horizontal, cambia el radio
del perımetro sobre el que se hace la rodadura, por lo tanto el brazo del par
32
4.1 Velocidad de rodadura.
correspondiente a la fuerza de rozamiento con el suelo.
Tm = Mp · g · (l · cos (θe)) · sen (θp) +Mp · (l · cos (θe))2 · θp (4.3)
− Tm = Fr · (Re · cos (θe)) +Bm ·(θr + θp
)+
2
3·Mr ·R2
e · θr (4.4)
cuyas linealizaciones, donde las variables a partir de ahora se tomaran como
incrementales, seran:
Tm = Mp · g · (l · cosθe) · θp +Mp · (l · cos (θe))2 · θp (4.5)
− Tm = Bm ·(θr + θp
)+
2
3·Mr ·R2
e · θr (4.6)
Para simplificar la notacion se agruparan las constantes siguiendo el siguiente
criterio:
A = Mp · g · (l · cosθe)
B = Bm
C = Mp · (l · cos (θe))2
D = 23·Mr ·R2
e
Aplicando dicha notacion y pasando las ecuaciones al dominio de Laplace, se
tienen las siguientes expresiones:
Tm =(A+ C · s2
)· θp (4.7)
− Tm = B ·(θp + θr
)· s+D · θr · s2 (4.8)
Despejando θp de la ecuacion 4.7, sustituyendo dicho valor en la ecuacion 4.8
y operando esta para sacar la funcion de transferencia que relacione la entrada,
33
4. MODELADO Y CONTROL.
que es el par motor Tm con la variable de salida, que es la velocidad angular de
la carcasa esferica θr se obtiene:
G =θrTm
= − A+B · s+ C · s2
A ·B + A ·D · s+B · C · s2 + C ·D · s3(4.9)
Sustituyendo los valores de las variables fısicas, siendo estos los siguientes:
Mp = 1, 586 Kg
l = 0, 112 m
Bm = 0, 009895 N · sm
Mr = 0, 4 Kg
Re = 0, 16 m
θe = 0,0 rad (Se supone que el angulo de direccion permanece en posicion
nula)
Se obtiene la siguiente funcion de transferencia:
G = −146,4844 · (s2 + 0,4974 · s+ 87, 5)
(s+ 1,449) · (s2 + 87,5)(4.10)
En el caso de haber incluido fricciones viscosas dependientes de la velocidad
correspondientes al rozamiento de el aire con los elementos, tanto el pendulo como
la cubierta esferica, se dispondrıa de un sistema aun mas complejo, pero se ha
desestimado ya que los valores son muy pequenos.
La ganancia unitaria negativa se debe al criterio de signos escogido, en el que
un valor de par positivo, provocara una velocidad angular negativa, que a su vez
se traduce en una velocidad lineal positiva en el eje X.
La figura 4.3 muestra que hay dos polos imaginarios puros. Los dos ceros del
sistema coinciden con sus coordenadas del eje imaginario y se situan a −0, 249 en
34
4.1 Velocidad de rodadura.
el eje real, en comparacion con la situacion del polo restante, situado a −1,45, se
ha optado por obtener un sistema equivalente reducido de primer orden, siendo
la funcion de transferencia de dicho sistema:
Gsimp =−146,5
s+ 1,449(4.11)
Ts = 2, 07s Ke = −101
Figura 4.3: Lugar de las raices del modelo de la velocidad de rodadura.
La figura 4.4 muestra la respuesta al escalon de ambos sistemas, el total y
el simplificado. Se puede ver que las caracterısticas principales del sistema no
cambian apenas, unicamente una oscilacion de poca amplitud que no se atenua.
35
4. MODELADO Y CONTROL.
(a) Respuesta al escalon del sistema total.
(b) Respuesta al escalon del sistema simplificado.
Figura 4.4: Respuesta al escalon del modelo de velocidad total y su
simplificacion. Se puede ver que la unica diferencia entre ambos sistema es una
oscilacion de alta frecuencia y pequena amplitud.
36
4.1 Velocidad de rodadura.
4.1.2. Experimentos para la identificacion del modelo de
la velocidad de rodadura.
La identificacion de esta variable no ha sido trivial ya que la unica entrada
permitida cuando el motor se encuentra en modo de giro continuo es el porcentaje
de par maximo debido a las caracterısticas del actuador utilizado. Por ello, se ha
supuesto como par maximo el indicado por la hoja de caracterısicas del motor,
de valor 1,83 N ·m.
Ademas, la variable de salida es la velocidad angular de la esfera, θe. Esta
no se puede medir directamente. Sin embargo, se puede obtener algebraicamente
ya que la velocidad del motor ˙θm es la velocidad angular relativa entre los dos
cuerpos principales que componen el robot: La carcasa esferica y el conjunto IDU-
pendulo. Mediante la medida de la velocidad angular del motor y la medida de
la velocidad de variacion del pitch θp, se puede obtener la velocidad angular de
la carcasa esferica segun la ecuacion θe = ˙θm − θp.
Calcular la velocidad angular del actuador no supondrıa un problema si se
pudiese leer la posicion del eje del motor en cualquier momento, pero puesto
a que no fue incluido ningun sensor de posicion ni de velocidad, aparte de los
incluidos en los propios actuadores, y que estos unicamente son capaces de leer la
posicion en un rango de 300◦, se tuvo que implementar un algoritmo que estimase
la velocidad angular en la zona ciega existente entre los 300 y los 360 grados. El
algoritmo utilizado se explica mas detalladamente en el capıtulo 5.
Ademas, pese a que en la zona util de medida de posicion del motor deberıa
de bastar con aplicar la aproximacion de la derivada para sistemas discretos,
consistente en dividir la diferencia de las medidas de la posicion actual y la
anterior entre el tiempo transcurrido entre la toma de estas, en la practica resulta
que este calculo presenta errores, habiendo ruido de alta frecuencia en la medida.
Una vez implementado dicho algoritmo, se realizaron un total de 10 experi-
mentos consistentes en entradas escalon de diferentes amplitudes al motor de giro
continuo, tomando medidas de la velocidad angular de dicho motor y el pitch del
37
4. MODELADO Y CONTROL.
conjunto IDU-pendulo. Se tomaron datos a una frecuencia de muestreo de 20Hz
durante 15 segundos.
Se ha de tener en cuenta que para realizar el modelado en Laplace del sistema,
se ha linealizado, descontando el par de rodadura generado por la friccion entre
la carcasa esferica y el terreno en el que se desplaza y suponiendo que el pitch del
conjunto IDU-pendulo no alcanza un angulo mayor a 14◦.
Figura 4.5: Efectos de la no linealidad del pendulo.En azul se muestra la
velocidad angular de la carcasa esferica, en rojo el pitch de la IDU multiplicado
por una escala de 10 : 1 y en verde la horizontal a partir de la cual el sistema no es
lineal(14◦ × 10 : 1). Las franjas sombreadas muestran en que momentos el sistema
no ha sido lineal.
La no linealidad correspondiente al angulo del conjunto IDU-pendulo se ha
hecho visible en el regimen transitorio, en el que para adquirir inercia y contra-
rrestar las fuerzas de rozamiento estatico, se eleva mas alla de 14◦. Ası pues, en
la figura 4.5 se puede ver que en los momentos en los que el sistema ha sido no
lineal, la variable de salida ha dejado de comportarse segun lo esperado de un
sistema de primer orden, cuyo regimen transitorio es siempre creciente.
La segunda no linealidad se corresponde con el par provocado por la fuerza
38
4.1 Velocidad de rodadura.
de friccion que aparece al haber un movimiento de rodadura. Esto se traduce en
una reduccion del par total aplicado, al que hay que descontarle el provocado por
dicha fuerza de rozamiento. El coeficiente de rozamiento del terreno en el que se
han realizado las pruebas (cemento seco) con el plastico es de νcem−plast = 0, 5
por lo que la fuerza de rozamiento sera:
Fr = (Mp +Mr) · 9,8 · νcem−plas = 9, 7 N (4.12)
Y por lo tanto, el par generado por esta fuerza:
Tr = Fr · (Re · cos (θe)) = 1, 56 N ·m (4.13)
Ya que para los experimentos realizados el angulo de inclinacion θe ha sido
nulo.
Aplicando dicho punto de trabajo, se ha realizado la identificacion del siste-
ma mediante las herramientas que ofrece Matlab alcanzando una similitud de la
identificacion del modelo real de un 70, 22 % cuya respuesta al escalon se muestra
en la figura 4.6.
Siendo su funcion de transferencia y sus caracterısticas:
Gsimp =−4593, 79
s+ 1,258(4.14)
Ts = 2, 38s Ke = −5779, 8
Se puede ver que con respecto al sistema modelado, el tiempo de estableci-
miento ha aumentado 0,31 segundos, probablemente debido a la no linealidad
provocada por el pendulo. Por otro lado hay que tener en cuenta que para la
identificacion se han hecho los calculos angulares en grados y para el modela-
do en radianes, por lo que, cambiando de unidades la ganancia estatica de la
identificacion:
39
4. MODELADO Y CONTROL.
Figura 4.6: Identificacion de la velocidad de rodadura.
− 5779, 8grad
s× 2 · π rad
360◦ = −100, 83 (4.15)
Coincidiendo con la del sistema modelado, de valor -101.
4.1.3. Control de la velocidad de rodadura.
Debido a las caracterısticas del sistema, de la instrumentacion y de la falta
de tiempo, se ha establecido un control en cadena abierta para este grado de
libertad.
Al tratarse de un primer orden, el sistema no tiene sobreoscilaciones importan-
tes, por lo que no es necesario anular estas mediante una realimentacion. Ademas,
resulta mas interesante hacer un control de la velocidad del robot en el control
referente a la navegacion y la generacion de trayectorias, ya que mediante la in-
40
4.2 Angulo de inclinacion de la esfera.
tegracion de sensores tales como la IMU y el GPS, se puede conocer la posicion
del robot y realimentar esta.
Se establece por lo tanto una constante de proporcionalidad que transforme la
velocidad angular deseada en una senal de porcentaje de par maximo del motor:
K =1
−101× 100 = −9, 9 (4.16)
4.2. Angulo de inclinacion de la esfera.
Debido a sus caracterısticas de no-holomicidad, para cambiar la orientacion
de la esfera con respecto al plano en el que se mueve, es necesario realizar una
trayectoria curvilinea, conseguida mediante una composicion de movimientos. Por
un lado es necesario hacer girar el eje principal de la esfera mediante el movimiento
explicado en la anterior seccion, provocando una velocidad en la esfera. Por el otro
lado, hay que modificar el angulo de inclinacion del eje fijo de la esfera, que es
el que determina el radio de curvatura de la trayectoria. Esto se explica mas
detalladamente en la Seccion 4.3 de este capıtulo.
Este movimiento es similar al que realiza un automovil con el mismo proposito.
Para cambiar de orientacion hay que girar las ruedas de direccion, equivalente a
cambiar el angulo de inclinacion del eje principal de la esfera. Ademas hay que
darle traccion al automovil para que este adquiera una velocidad y realice la
trayectoria, equivalente a imprimir una velocidad de rodadura a la esfera. En
esta seccion se hara por lo tanto el modelado del angulo de inclinacion de la
esfera.
4.2.1. Modelado del sistema fısico.
En el caso de la Rosphere, este segundo movimiento se compone de una ro-
tacion del pendulo simple en torno a su punto fijo describiendo una trayectoria
41
4. MODELADO Y CONTROL.
circular en el plano perpendicular al suelo que contiene al eje fijo de la esfera.La
variable de entrada por lo tanto es el angulo formado entre el pendulo y la perpen-
dicular al eje fijo θm y la salida el angulo formado entre el eje fijo y la horizontal
θe.
Figura 4.7: Diagrama de la dinamica de direccion de la Rosphere.
Tomando el angulo del motor que actua sobre este movimiento como el angulo
entre el eje fijo y el pendulo θm, el par generado por la actuacion de la gravedad
sobre el centro de masas de la esfera sera dependiente del angulo del eje de esta
mas el angulo del motor. Se puede ver una descomposicion mas detallada de las
variables dinamicas en la figura 4.7.
Suponiendo por lo tanto como entrada de este sistema el angulo de salida del
motor, la ecuacion fısica que describe la dinamica de este movimiento es la que
sigue:
Mp · g · l · sen (θm + θe) = −B · θe −Mp · l2 · θe (4.17)
Siendo l la distancia del centro de masas al centro geometrico de la esfera y
Mp la masa del pendulo. Se tiene por lo tanto un sistema de segundo orden.
42
4.2 Angulo de inclinacion de la esfera.
Al ser necesario un modelo en Transformada de Laplace, este sistema ha de
linealizarse. El unico elemento no lineal de la ecuacion es el seno, y esta demos-
trado que para valores menores de 14◦, el angulo y su seno difieren en menos de
un 1 %. Esto implica, que dicha linealizacion sera valida para valores de θm + θe
menores que 14◦. Una vez linealizado, se obtiene la funcion de transferencia en el
dominio de Laplace:
Ge =θeθm
=Mp · g · l
−Mp · l2 · s2 −B · s−Mp · g · l(4.18)
Se tiene por lo tanto un sistema de segundo orden con ganancia unitaria nega-
tiva. Sin embargo, para la implementacion se ha optado por alternar el criterio de
signos de ambos angulos para hacer la ganancia estatica positiva. Ademas, como
se puede ver mas adelante, dicha ganancia estatica no es unitaria en el sistema
real, debido principalmente a la superficie irregular de la carcasa esferica.
4.2.2. Metodologıa de identificacion.
Con objeto de validar y de identificar el modelo propuesto, se llevaron a cabo
experimentos con la Rosphere que permitiesen caracterizar su comportamiento.
La variable de entrada para este GdL es la posicion deseada del motor θm,
a la que aplicandole un factor de escala correspondiente al factor de transmision
entre los engranajes involucrados y al rango de entradas del motor, da lugar
a directamente el angulo entre el pendulo y el eje principal. Estos factores, al
ser constantes, no precisan de ser identificados, por lo que se han extraido de la
funcion de transferencia, incluyendolos en el software de control de los actuadores.
Ademas, la variable de salida, que es el angulo del eje principal de la esfera
con respecto a la horizontal θe, se obtiene directamente de la IMU, que ofrece una
medida ya filtrada.
Los experimentos llevados a cabo para la identificacion del sistema consistie-
ron en introducir como entrada un escalon de posicion de diferentes amplitudes
43
4. MODELADO Y CONTROL.
como consigna del motor manteniendo el otro actuador en reposo y en un terreno
totalmente plano. Los datos tomados fueron la senal de consigna del motor, a
la que se llamara θref , el angulo real del pendulo θm y el angulo de inclinacion
de la esfera θe. Se tomaron medidas del angulo real del pendulo θm ya que el
modelo planteado no incluye la dinamica del motor, y era necesario valorar si era
despreciable o por el contrario habıa que tenerla en cuenta a la hora de decidir el
orden del sistema total.
Se realizaron un total de 10 experimentos, de 15 segundos de duracion cada
uno y una frecuencia de muestreo de 20Hz. Siendo la frecuencia natural del
sistema de aproximadamente 1Hz, se cumple con creces el Teorema de Shannon.
Los datos obtenidos se introdujeron en Matlab para su analisis, debido a las
herramientas disponibles para identificacion de sistemas.
4.2.3. Control para un sistema agregado.
4.2.3.1. Modelado e identificacion.
Debido a la rapidez y la casi ausencia de oscilaciones del motor frente a las
entradas de control, como primera aproximacion se decidio obviar su dinamica y
tomar el sistema total como un segundo orden subamortiguado correspondiente
al del modelo explicado en el anterior apartado.
Tomando la senal de entrada como la consigna enviada al motor θref y como
salida el angulo de inclinacion de la esfera θe, se identifican los valores de un
sistema de segundo orden subamortiguado con una similitud del 74, 04 % mediante
el calculo de error hecho por la herramienta ident de Matlab, dando lugar a la
siguiente funcion de transferencia:
Ge =40,06
s2 + 0,62 · s+ 33,21(4.19)
Ts = 12,6s Mp = 84,4 % Ke = 1,21
44
4.2 Angulo de inclinacion de la esfera.
4.2.3.2. Control PID.
Debido a la simplicidad del sistema, se plantea como primera opcion la im-
plementacion de un regulador PID ajustandolo empıricamente ayudandose de
Simulink Dando lugar a los valores Kp = 0, 25, Ki = 1, 2, Kd = 0, 148. En todo
momento se han monitorizado las salidas del regulador para asegurarse de que
estas no saturen al actuador.
Figura 4.8: Esquema de control del primer regulador PID en Simulink.
4.2.3.3. Implementacion.
Una vez calculado dicho regulador se implemento en la Rosphere V0.3, e
inmediatamente se pudo comprobar que el resultado era un sistema altamente
inestable, comenzando a oscilar descontroladamente y cada vez con mayor am-
plitud.
4.2.4. Control para un sistema desagregado.
Puesto que con el anterior modelo la respuesta del modelo y la del sistema
real difieren enormemente, se opta por revisar el modelo, esta vez incluyendo la
dinamica del actuador. Se aprovecha para ello la capacidad de medir el valor de
θm, como se explico en la introduccion de esta seccion.
45
4. MODELADO Y CONTROL.
4.2.4.1. Modelado e identificacion.
Por un lado se tiene la planta, que como detalla la ecuacion (4.18), se modela
segun un sistema de segundo orden. Por el otro, se dispone de un motor, del que
no se tiene informacion al respecto de su funcion de transferencia, por lo que se
tanteara con las diferentes opciones de identificacion de Matlab y se escojera la
que mas se acerque a la respuesta real.
Probando la identificacion del motor con un sistema de primer, segundo o
tercer orden, se determina que el de segundo orden es el que mas se adapta, con
una similitud del 89, 12 % mediante los calculos realizador por Matlab. Para la
planta se vuelve a identificar como un segundo orden tomando como entrada la
salida del θm, llegando a un modelo con una similitud del 76, 6 %. La identificacion
de ambos sistemas se muestra en la figura 4.9 y sus funcionones de transferencia
son las siguientes:
Ge =41, 85
s2 + 0,43517 · s+ 35,1(4.20)
Ts = 17s Mp = 88,7 % Ke = 1,19
Gm =1
0,009895 · s2 + 0,1459 · s+ 1(4.21)
Ts = 0,583s Mp = 3,37 % Ke = 1
4.2.4.2. Control PID.
Con el nuevo modelo, se vuelve a probar un control PID llegando a unos
valores de Kp = 0, 02, Ki = 1, 4, Kd = 0, 08.
Implementando dicho regulador PID en el prototipo, se comprueba que este
si es efectivo ante entradas escalon, puesto que pese a que la accion proporcional
por si sola no alcanzase el valor final deseado, el alto valor de accion integral
46
4.2 Angulo de inclinacion de la esfera.
(a) Identificacion del actuador.
(b) Identificacion de la planta.
Figura 4.9: Identificacion de los sistemas. En rojo se muestran las respuestas
reales de cada sistema mientras que en azul se muestra la identificacion.
47
4. MODELADO Y CONTROL.
hace que el sistema tenga un error nulo en regimen permanente, ademas de hacer
al sistema mas rapido. Sin embargo, debido a las mismas razones, este sistema
responde muy mal ante perturbaciones.
4.2.4.3. Realimentacion taquimetrica.
Tomando las identificaciones del actuador y de la planta realizadas, se hace
un estudio de las caracterısticas del sistema. En el lugar de las raıces se puede
observar que, debido a los dos pares de polos imaginarios, las asıntotas del sistema
se situan a 90◦ entre sı, comenzando en 45◦ como se puede ver en la figura 4.10.
Figura 4.10: Lugar de las raices incluyendo los polos del actuador y de
la planta.
Al estar las asıntotas pertenecientes a la dinamica de la esfera en direccion al
semiplano positivo y los polos en cadena abierta de dicha dinamica muy cercanos
al eje de Real, el sistema realimentado tenıa una Kp crıtica de 0,088.
48
4.2 Angulo de inclinacion de la esfera.
Ya que el regulador PID real anade parejas de polos-ceros al lugar de las
raıces, las asıntotas de este nunca iba ha cambiar, por lo que finalmente se decidio
descartar el PID y probar otro tipo de reguladores.
Tras un estudio y evaluacion de diferentes reguladores, se opto por la reali-
mentacion taquimetrica.
Dicha realimentacion se utiliza para sistemas muy oscilantes en los que se
quiere hacer un control en posicion. Para realizar dicho control, no se realimenta
unicamente la posicion si no tambien la velocidad esta. Esto provoca que el siste-
ma sea consciente de la rapidez con la que varıa la posicion, y por lo tanto puede
prever cuando va a alcanzar su setpoint e ir frenando para evitar que el sistema
sobreoscile.
Figura 4.11: Esquema basico de realimentacion taquimetrica.
Evaluando su efecto en un marco mas teorico, al anadir una realimentacion
en velocidad, se esta anadiendo un cero a la cadena abierta, lo que va a atraer
ramas del lugar de las raıces a su posicion. Aplicandolo al sistema de la Rosphere,
si se consigue atraer a las dos ramas pertenecientes a la dinamica de la esfera, se
podra aumentar la ganancia, no solo sin miedo a que el sistema se haga inestable,
si no que ademas se acercaran los polos al eje real, haciendo que el sistema oscile
menos.
Como se puede ver en la figura 4.11, se disponen de 3 parametros que ajustar.
El termino a es el que va a determinar la posicion del cero en el eje real, y mediante
49
4. MODELADO Y CONTROL.
la modificacion de Ke y Kfb se consigue la situacion de los polos deseada en el
lugar de las raices y que la ganancia estatica sea la deseada.
Se plantea por lo tanto una realimentacion taquimetrica del angulo del eje
principal de la esfera sin conseguir ningun resultado satisfactorio, puesto que
para cualquier valor de a el cero atre a las ramas pertenecientes a la dinamica del
actuador, y no a las de la esfera, tal y como muestra la figura 4.12.
Figura 4.12: Lugar de las raices al anadir una realimentacion taquimetri-
ca.
4.2.4.4. Control en cascada con realimentacion taquimetrica.
Para que el cero que aporta la realimentacion taquimetrica atraiga a las ramas
pertenecientes a la dinamica de la planta al eje real, se han de alejar del cero las
del motor mediante la modificacion de su dinamica, y para ello se cierra otro lazo
de control para la posicion del motor.
Se tiene por lo tanto un control en cascada cuyo bucle mas externo posee una
realimentacion taquimetrica. Al ser mas complejo que los anteriores sistemas,
Matlab no ofrece herramientas para ajustar dicho regulador por lo que se ha
50
4.2 Angulo de inclinacion de la esfera.
llevado a cabo el desarrollo matematico necesario para calcularlo.
En primer lugar, se comienza por ajustar el lazo interno, correspondiente al
motor, cuyo diagrama de bloques se puede ver en la figura 4.13. Pese a que ya
tiene un regulador propio implementado, nuestro interes es alejar los polos del eje
real pero mantener unitaria la ganancia en regimen permanente.
Los dos parametros a ajustar son Km y Kmh, necesarios para determinar por
un lado el lugar de los polos en cadena cerrada y la ganancia estatica del sistema.
Figura 4.13: Diagrama de bloques del lazo de realimentacion del motor.
La funcion de transferencia total del sistema del motor realimentado GM viene
definida por
GM =Km ·Gm
1 +Km ·Kmh·Gm
(4.22)
A partir de ella, debido a que la ganancia estatica de Gm es unitaria, se deduce
que la ganancia del lugar de las raices es
KLDR = Km ·Kmh(4.23)
Y la ganancia estatica, teniendo en cuenta que la de la funcion de transferencia
del motor ya era la unidad sera
KM =Km
1 +Km ·Kmh
(4.24)
Al no tener una cuantıa de como afecta la separacion de los polos del motor
del eje real al lugar de las raices del sistema total, incluyendo la realimentacion
51
4. MODELADO Y CONTROL.
taquimetrica, y al ser necesario un valor de KLDR para tener un sistema deter-
minado, se llega a un valor empırico razonable.
Para un valor de KLDR = 1 los polos de la realimentacion se situan a un valor
de −7,37±12,2i, un valor que casi duplica al valor en el eje imaginario del sistema
original del motor, −7,37 ± 6,83i. El valor buscado era en torno a ±10i por lo
tanto se tomara como valida una KLDR = 1 debido a la simplicidad de calculo
con un numero exacto.
Se tiene por lo tanto como restricciones KLDR = 1 y mantener la ganancia del
sistema unitaria por lo tanto KM = 1 dando como resultado:
Km = 2
Kmh= 0,5
Figura 4.14: Respuesta al escalon del actuador sin realimentar (Linea
continua) y una vez realimentado (Linea discontinua).
52
4.2 Angulo de inclinacion de la esfera.
Como se puede ver en la figura 4.14 el motor se ha vuelto mas rapido a la vez
que mas oscilante. De todas formas, esta mayor sobreoscilacion del motor es un
efecto de menor importancia, ya que el objetivo no era tener unas especificaciones
concretas de respuesta del motor, sino afectar al lugar de las raices total.
Una vez ajustado el lazo interno, se procede a ajustar los valores correspon-
dientes a la realimentacion taquimetrica. Para facilidad de calculo, se extrae la
ganancia de dicha realimentacion Kf como se indica en la figura 4.15, que sera
anadida y ajustada despues para hacer unitaria la ganancia del conjunto total.
Figura 4.15: Esquema de control total.
El valor de a es el que decide la situacion del cero a lo largo del eje real, por
lo tanto sera escogido lo mas alejado del origen posible, ya que esto atraera a los
polos lejos del semiplano real positivo, pero lo suficientemente cerca de los dos
polos pertenecientes a la dinamica de la esfera como para que atraiga a las ramas
de esta dinamica y no a las del motor.
Por otro lado, el valor de Ke sera el que ajuste la ganancia del lugar de las
raices del sistema por lo tanto sera dependiente de las condiciones de diseno.
Se ha establecido como criterios de diseno que el sistema ha de ser rapido,
aun que ello provoque una gran sobreoscilacion. Por ello, se han escogido como
parametros de diseno un tiempo de establecimiento ts = 1,2s, mas de 10 veces
menor que el del sistema original, y una sobreoscilacion Mp = 30% que pese a ser
menos de la mitad que la del sistema original, es un valor bastante mas permisivo
que el tiempo de establecimiento.
53
4. MODELADO Y CONTROL.
Figura 4.16: Lugar de las raices final con realimentacion taquimetrica y
control en cascada.
Teniendo esto en cuenta, se ha ajustado el regulador llegando a los siguientes
valores:
a = 1
Ke = 0,091
La figura 4.16 muestra que el valor de Ke ha tenido que ser ajustado con precision
ya que los polos del sistema se situaban muy cerca de la frontera de ambas
restricciones.
Una vez asegurada la respuesta dinamica, se procede al ajuste de Kf para que
la ganancia total sea unitaria siendo el resultado:
Kf = 10,23
Pese a que esta configuracion ha sido de ayuda a la hora de realizar los calculos
necesarios para ajustar el regulador, en la implementacion se ha reordenado el
diagrama de bloques como se puede ver en la figura 4.17 por simplicidad a la hora
de implementarlo. Se tiene por lo tanto los siguientes valores finales:
54
4.2 Angulo de inclinacion de la esfera.
Figura 4.17: Diagrama de bloques del sistema total listo para ser imple-
mentado.
Km = 2
Kmh= 0,5
Kf ·Ke = 0,93
a = 1
1Kf
= 0,098
4.2.5. Implementacion y pruebas.
Una vez disenado el regulador, se procedio a su implementacion. Ya que el
regulador ha sido disenado en el dominio de Laplace, se ha alicado el metodo
de Euler, tambien conocido como aproximacion derivada para poder aplicar el
control de forma discreta. Debido a inexactitudes del modelo y a la deformacion
que sufre la carcasa esferica en el perımetro de union de sus dos mitades, se
producian vibraciones de alta frecuencia debido a las acciones del regulador para
llegar al valor de consigna.
Para solucionar esto, en la implementacion se anadio una histeresis del error
para dejar de efectuar acciones de control cuando este hubiese alcanzado un mıni-
mo. Dicho mınimo se determino experimentalmente, dando lugar a un valor ab-
55
4. MODELADO Y CONTROL.
(a) Histeresis de 5◦ (b) Histeresis de 3◦
Figura 4.18: Respuesta al escalon del sistema con diferentes valores de
histeresis. Ante una entrada escalon de 20◦ de amplitud, se puede ver que en la
figura (a), pese a amortiguarse tras dos primeras oscilaciones amplias, el sistema
permanece oscilando a alta frecuencia, incluso una vez las oscilaciones de menor
frecuencia ya se han amortiguado. En la figura (b) se ve que el sistema respon-
de mucho mejor, no teniendo dichas oscilaciones de alta frecuencia y llegando al
regimen permanente aproximadamente 3 segundos antes que en el otro caso.
soluto de 1, 5◦, haciendo un total de 3◦. La figura 4.18 muestra la diferencia de
la respuesta al un escalon de una amplitud de 20◦ para diferentes valores de
histeresis.
Debido a esto, y a las imperfecciones ya comentadas de la carcasa esferica, la
respuesta real del sistema aplicando el regulador da un error considerable para
escalones de valores pequenos, pero resulta muy efectiva para cambios de la senal
de consigna de mayor valor.
56
4.2 Angulo de inclinacion de la esfera.
Figura 4.19: Respuesta a un escalon de valor pequeno. Como se puede ver,
el regimen transitorio posee unas buenas caracterısticas. Sin embargo, la senal de
consigna era de 4◦ y el valor en regimen permanente es de 2, 5◦, habiendo un error
correspondiente a la histeresis.
Figura 4.20: Respuesta a un escalon de gran valor. Para un escalon de −33◦
el sistema alcanza dicho valor tras un regimen transitorio de aproximadamente 1,5
segundos.
57
4. MODELADO Y CONTROL.
4.3. Modelo cinematico.
El modelado dinamico se ha realizado con el objetivo de tener control sobre
dos variables: la velocidad angular a la que gira el casquete esferico en torno al
eje fijo, llamada velocidad de rodadura, y el angulo de dicho eje principal con
respecto a la horizontal, llamado angulo de inclinacion. Ya que el objetivo final
es guiar al robot en el plano XY, hay que estabecer la relacion entre las variables
tratadas en la dinamica con las que afectan directamente al movimiento del robot,
ha sido necesario el establecimiento de un modelo cinematico de la Rosphere.
4.3.1. Cinematica directa.
Mediante la cinematica directa, se obtienen los valores de las variables que
determinan la posicion del robot en el plano de trabajo a partir de los valores de
las variables de salida de los actuadores.
Como se explico en ocasiones anteriores, la Rosphere es un robot movil terres-
tre no-holonomico. Los movimientos que realiza, pueden ser generalizados en uno
solo correspondiente a una trayectoria circular representada en la figura definida
por dos variables:
Velocidad lineal: Su direccion viene definida por la tangente de la trayec-
toria circular que este siguiendo en ese momento, y su modulo viene definido
por la siguiente ecuacion:
V = ω · 2π · (Re · sin(θe)) (4.25)
Siendo ω la velocidad de rodadura, Re el radio del casquete esferico, por lo
tanto constante y θe el angulo entre el eje fijo y la horizontal.
Radio de curvatura: Correspondiente al radio de la trayectoria circular
que realiza la esfera, viene definido por la ecuacion:
R =Re
tan(θe)(4.26)
58
4.3 Modelo cinematico.
Figura 4.21: Representacion del movimiento de la esfera con las variables
implicadas.
Como se puede ver, ambas variables pueden ser tanto positivas como negativas.
En el caso de la velocidad lineal, indica si la esfera se estara moviendo hacia
delante si su signo es positivo o hacia atras si este es negativo. En cuanto al
radio, indica si, segun el sistema de referencia de la esfera, esta va a realizar un
giro hacia su izquierda (signo positivo) o hacia su derecha (negativo).
Un caso concreto de este movimiento es cuando el angulo θe es 0. En tal caso,
su tangente sera tambien nula, por lo que el radio de curvatura sera infinito,
siendo la trayectoria una linea recta y, para una velocidad angular ω constante,
la velocidad lineal sera maxima puesto que el coseno del angulo valdra la unidad.
4.3.2. Cinematica Inversa.
Como en todo robot, la cinematica inversa es mas importante que la directa, ya
que con esta se puede obtener las variables de entrada de los actuadores necesarias
a partir de un movimiento deseado.
En la Rosphere, esta cinematica es sencilla de obtener despejando directa-
mente de las ecuaciones que definen la cinematica directa. Sin embargo, hay que
59
4. MODELADO Y CONTROL.
tener en cuenta que hay que calcular primero el angulo de inclinacion de la esfera
deseado para poder despues calcular la velocidad angular del casquete esferico.
Las ecuaciones que definen la cinematica inversa son las siguientes:
θe = atan
(Re
R
)(4.27)
ω =V
Re · cos(θe)(4.28)
En dichas ecuaciones, se han de introducir las variables deseadas de la esfera
(radio de curvatura de la trayectoria Re y velocidad lineal V ) segun el criterio de
signos explicado en el apartado anterior.
60
5
Arquitectura Hardware y
Software.
La Rosphere se plantea como un robot movil con capacidad de ser tanto
teleoperado como autonomo, puediendo llevar a cabo misiones de adquisiciones
de datos del medio en el que se desenvuelve y/o formar parte de Sistemas Multi-
Robot (MRS).
Al ser de diseno propio, todo el desarrollo necesario para hacer de la Rosphere
un prototipo funcional ha sido realizado en este trabajo. Este capıtulo recoge los
requisitos y las caracterısticas de las arquitecturas tanto hardware como software
de la version RosphereV0.3.
5.1. Seleccion de componentes Hardware.
La arquitectura hardware de este robot esta formada por aquellos elementos
fısicos encargados de la actuacion sobre los grados de libertad, el procesamiento
necesario para ejecutar los algoritmos de control y la recogida de datos de sensores,
principalmente propioceptivos pero tambien de carga de pago.
61
5. ARQUITECTURA HARDWARE Y SOFTWARE.
Es por esto que hay que tener en cuenta que para la seleccion de dichos ele-
mentos, estos han tenido que cumplir una serie de requisitos bastante definidos,
y altamente relacionados entre si. Por lo tanto, como requisitos iniciales, no se
establecieron caracterısticas muy concretas, si no un rango de valores que poste-
riormente se han ajustado teniendo en cuenta todos los factores.
5.1.1. Requisitos de los actuadores:
Par maximo: Se ha establecido un factor de seguridad Fseg tal que el
maximo par necesario en cualquiera de los dos grados de libertad sea un
90 % del par maximo capaz de realizar su correspondiente actuador. Para el
actuador encargado de originar la velocidad de rodadura, se ha supuesto una
relacion de transmision de 1:1, por lo que el par del motor maximo dentro del
rango de seguridad efectuara como maximo el par correspondiente a levantar
la masa de todo el mecanismo interno hasta que la fuerza de gravedad sea
perpendicular al brazo maximo, siendo este la distancia ente el eje principal
y el centro de masas de todo el mecanismo interno cuando el pendulo se
encuentra en estado neutro.
En el prototipo RosphereV0.2, la distancia del centro de masas al eje prin-
cipal esta en torno a un 60 % del radio del casquete esferico y un peso de
1400 gramos. Como uno de los alicientes para hacer un tercer prototipo
era mejorar estos aspectos, se ha supuesto un aumento de la relacion KCM
entre el brazo y el radio exteno Resf de hasta un 70 %, y un aumento de
la masa de 100 gramos por lo que la masa del mecanismo interno Mtotal
valdra 1500 gramos. En el ultimo apartado del capıtulo 3.Diseno Mecanico
se puede ver que estos requisitos se han cumplido. Se tienen por lo tanto la
siguiente relacion:
TM ≥g ·Mtotal ·Resf ·KCM
Fseg
· (5.1)
Viniendo Resf impuesto por las caracterısticas de la carcasa esferica dispo-
nible, y de valor 16cm, se tiene que el par maximo del motor debe de ser
mayor o igual a 1, 83Nm.
62
5.1 Seleccion de componentes Hardware.
Para el actuador del segundo grado de libertad correspondiente a la incli-
nacion de la efera no se han tenido unas especificaciones concretas de par
ya que en el diseno mecanico se ha previsto una reduccion de transmision
de aproximadamente 1:3 y a la carga hay que descontarle el peso de la IDU,
ya que dicho actuador solo mueve al pendulo. Estos factores hacen que el
par necesario sea asequible por la mayorıa de las posibilidades barajadas,
haciendolo despreciable con respecto a otras caracterısticas.
Velocidad: Dicho factor tambien es por un lado crıtico en el actuador
correspondiente al movimiento de rodadura y por el otro, irrelevante para
el actuador encargado de la inclinacion.
La velocidad alcanzable por el motor se va a ver afectada por la carga.
Sin embargo, en regimen permanente, el angulo de inclinacion frontal del
pendulo necesario para mantener el movimiento es casi nulo, ya que la esfera
ya ha obtenido una inercia. Por ello, se tomara como referencia la velocidad
en vacıo de los actuadores.
Se ha establecido una velocidad lineal maxima Vmax de 1,5m/s, por lo que
teniendo en cuenta el radio de la esfera se tiene que:
ωvacio ≥ Vmax ·1rev
2π ·Resf
· 60s
1min(5.2)
Por lo que se necesita una velocidad angular del actuador ωvacio mayor o
igual que 90rpm.
Consumo: El voltaje ha de poder ser suministrado por una baterıa de
Polımero-Litio de un valor razonable que no supere los 15 voltios, y un
consumo maximo ocasional de 5 amperios.
Caracterısticas adicionales: El motor del primer grado de libertad ha de
ser de giro continuo, mientras que el de inclinacion de la esfera ha de tener un
recorrido mayor o igual al maximo recorrido previsto del pendulo contando
con la relacion de transmision aplicable. Como se supone un recorrido de
90◦ y una reduccion de 1:3, es necesario un recorrido del motor de 270◦.
63
5. ARQUITECTURA HARDWARE Y SOFTWARE.
5.1.2. Requisitos de elementos de potencia.
Voltaje: Se ha de poder alimentar por un lado a los motores, y por el otro
ofrecer voltaje estable de 5 voltios para la logica TTL.
Consumo: Han de soportarse picos de 6 amperios, que es el consumo de la
electronica mas el consumo maximo ocasional de los actuadores. Ademas,
en regimen nominal, del que se estima un consumo de 4 amperios, ha de
tener una autonomıa de 30 minutos o mas.
Tamano: Como las baterıas de Polımero-Litio son bastante densas, el ob-
jetivo, como en las anteriores versiones, es colocarlas en el pendulo de tal
manera que formen parte del contrapeso, por lo que tienen que poder ser
situadas en este sin problemas.
5.1.3. Requisitos de sistemas de instrumentacion y con-
trol.
Sensores: Son necesarias las medidas de posicion y de velocidad de los
motores, ası como una IMU de 9 grados de libertad que se pueda situar en
la IDU y GPS con tal de poder hacer la integracion de dichos sensores para
la propiocepcion de la esfera robotica. Ademas, para la carga de pago es
necesario disponer de entradas y salidas tanto analogicas como digitales y
de entrada de video.
Procesamiento: Con tal de integrarse en un MRS (Sistema Multi-Robot)
y de ser compatible con las interfaces de control que se han desarrollado pa-
ralelamente a este proyecto, es necesario poder tener corriendo ROS (Robot
Operating System), un framework de desarrollo para robots, y para esto es
necesario tener un sistema operativo LINUX. Tambien se ha de disponer de
capacidad de procesamiento de video para las camaras que se situaran en
los modulos externos sin que ello afecte al normal funcionamiento del resto
de procesos.
64
5.1 Seleccion de componentes Hardware.
Como caracterıstica mas importante, es necesario que la informacion se pro-
cese lo suficientemente rapido como para que el control de actitud funcione
correctamente. Sin embargo, al ser un sistema con una alta inercia, y por
lo tanto lento, y disponiendo de un sistema que es capaz de correr una
distribucion de LINUX, este requisito queda mas que cubierto.
Comunicaciones: Para el control de los actuadores sera necesaria la co-
municacion que requieran estos, ya sea PWM, I2C o serie. Por otro lado
para llevar a cabo la teleoperacion o tareas colaborativas con otros robots,
sera necesaria algun tipo de conexion inalambrica del tipo Bluetooth, WiFi
o similares.
En la tabla 5.1 se recogen los requisitos previamente comentados.
Actuadores Potencia Electronica
• 1, 83 Nm • Vmotor, 5V • IMU, GPS, GPIO, video
• 90 rpm • 2000mah, 3c • LINUX
• 5A • Tamano reducido • Comunicaciones alambricas
• 270◦ ∼ continuo e inalambricas
Cuadro 5.1: Requisitos Hardware.
5.1.4. Componentes seleccionados.
Teniendo todos estos requisitos en cuenta, se llevo a cabo una busqueda y
seleccion de cada componente, dando como resultado el siguiente:
•Actuadores Dynamixel AX-12A y AX-18F.
Pensados especialmente para la robotica, disponen de cualidades tales como
bucles de control ya ajustados, capacidad de consulta de variables internas a
saber la posicion, la temperatura, el voltaje aplicado, etc. Ademas de comuni-
cacion en serie asıncrona half duplex y la capacidad de conectarlos en cadena.
65
5. ARQUITECTURA HARDWARE Y SOFTWARE.
Figura 5.1: Actuador Dynamxel
AX-12A.
Cinendose mas a los requisitos que lleva-
ron a escoger estos actuadores, disponen de
las siguientes caracterısticas:
Alimentacion entre 9∼12 Voltios
Capacidad tanto de giro controlado en-
tre 0 y 300o como de giro continuo.
55 gramos
Dimensiones 32mm× 50mm× 40mm
En el caso del motor que actua sobre la velo-
cidad de rodadura , modelo AX-18F, su ve-
locidad al vacio es de 94 rpm y tiene un par maximo de 1,83Nm, con un consumo
en dicha situacion de 2,2A.
En el encargado de controlar la inclinacion de la esfera, tiene una capacidad
de par de 1,52Nm consumiendo 1,5A.
•Baterıas LiPo 3S 1300mah 25 50c Turnigy.
Figura 5.2: Bateria LiPo 3S-1.3 Turnigy.
Debido a los requisitos de los ac-
tuadores, era necesario una alimen-
tacion de 3 celdas LiPo en serie, para
suministrar 11,1 V. Sin embargo, pa-
ra cubrir los requisitos de consumo,
las baterıas disponibles eran dema-
siado grandes, por lo que se ha op-
tado por utilizar dos conectadas en
paralelo, de menor tamano y capa-
cidad, por comodidad a la hora de
situarlas en el pendulo.
66
5.1 Seleccion de componentes Hardware.
•Regulador de voltaje tipo Step-Down D15V35F5S3.
Figura 5.3: Regulador Stepdown
D15V35F5S3.
Para adaptar la tension de las baterıas a
la alimentacion de los circuitos TTL se ha
optado por este regulador debido a su rango
de entrada, comprendido entre los 4,5 y 24
V, la salida de 5V estables.
Su corriente de salida alcanza los 3,5A,
mas que suficiente para su finalidad y pro-
teccion a cortocircuitos en la salida, carac-
terıstica muy importante ya que la capaci-
dad de descarga de las baterıas selecciona-
das es tal, que en caso de cortocircuito estas
podrıan entrar en combustion.
•Raspberry Pi Model B + Modulo WiFi.
Figura 5.4: Raspberry Pi B.
Es un ordenador de placa redu-
cida (SBC) con un procesador de
700MHz, 512 Mb de RAM, un proce-
sador grafico (GPU) y un adaptador
de tarjetas SD.
Se ha escogido este modelo debi-
do a que tiene una propia distribu-
cion tanto del sistema operativo LI-
NUX (Distribucion Raspbian) como
del framework ROS, a parte de su
procesador de video (GPU), que ali-
gera la carga del procesador princi-
pal.
67
5. ARQUITECTURA HARDWARE Y SOFTWARE.
•ArduPilot Mega 2,5 + GPS EM406A.
Figura 5.5: ArduPilot Mega 2.5.
Dicha controladora es una placa
de piloto automatico pensada prin-
cipalmente para el control de UAVs
basada en la plataforma de la Ar-
duino Mega, por lo que su programa-
cion guarda grandes similitudes con
C++.
Tiene integrada una IMU de 9
GdL, con el firmware y las bibliote-
cas necesarias para su uso, ası como
para el GPS seleccionado. Ademas,
dispone de puertos serie suficientes
como para comunicarse con el resto
de controladoras.
•Controladora ROBOTIS OpenCM 9.04.
Figura 5.6: OpenCM 9.04.
De los mismos fabricantes que
los actuadores seleccionados, esta
controladora esta especialmente di-
senada para la interaccion con los
Dynamixel AX, proporcionandoles la
alimentacion a traves de sus conec-
tores compatibles y disponiendo de
librerıas para el control de dichos ac-
tuadores en un entorno tambien ba-
sado en la programacion de Arduino.
68
5.2 Arquitectura Hardware.
5.2. Arquitectura Hardware.
Como se ha visto en el apartado anterior, para los componentes electronicos
encargados de ejecutar los algoritmos, se han escogido un total de tres controla-
doras, cada una con una funcionalidad, debido a la imposibilidad de encontrar
una sola que unificase todos los requisitos. Es por esto que la arquitectura hard-
ware ha sido mas complicada de la idea principal que se tenia, pero a su vez, mas
distribuida en cuanto a tareas.
Al trabajar las tres con un fin comun ha sido necesario que estas estuviesen
comunicadas bidireccionalmente de forma efectiva. Para ello, se ha utilizado co-
municacion serie en cadena ordenadas en cuanto a nivel de control que manejaba
cada una. Ası pues, la Raspberry Pi se conecta a la ArduPilot Mega, y esta a su
vez a la controladora OpenCM 9.04.
La ArduPilot, puesto que posee las conexiones fısicas necesarias ası como
las bibliotecas, es a la que se ha conectado el GPS. Puesto que esta pensada
para ser una microcontroladora autopiloto completamente independiente, dispone
de numerables salidas para motores de corriente continua ası como servos. La
utilizacion de estos habrıa ahorrado la necesidad de una tercera controladora pero
ningun servo ofrece las funcionalidades que ofrecen los motores seleccionados.
Pese a que la idea de la distribucion de tareas, ya que se dispone de tres placas
diferentes, era la de mantener todos los sensores en los niveles bajo e intermedio,
al ser la Raspberry Pi la unica con capacidades de procesado de video, la camara
ha sido conectada a esta controladora.
Una caracterıstica importante de la arquitectura hardware ha sido la inclusion
de un tirador externo que corta la alimentacion de todo el sistema. Esto se ha
hecho debido a que en las anteriores versiones se quemaron varios componentes
ya que para la desconexion era necesario el abrir la esfera.
La distribucion del hardware se puede ver mas detalladamente en la figura
5.7.
69
5. ARQUITECTURA HARDWARE Y SOFTWARE.
Figura 5.7: Esquema de arquitectura HW.Todas las conexiones rojas y negras
se corresponen a la alimentacion y la tension de referencia 0V respectivamente. La
Raspberry Pi (1) recibe la informacion de la camara (10) y se comunica via WiFi
(9) por el puerto USB con la estacion en tierra. Tanto para recibir como para enviar
informacion al control de bajo nivel de la esfera, se comunica via serie tambien con
el puerto USB con la ArduPilot (2). Esta tiene integrada la IMU de 9 GdL y recibe
los datos del GPS (8). Para comandar los movimientos de la esfera, se comunica via
serie con la controladora OpenCM (3), y es esta la que envia las ordenes directas a
los motores (4), que estan conectados en cadena. En cuanto para la alimentacion,
se conectan las dos baterıas LiPo (5) en paralelo, que alimentan directamente a la
OpenCM, y alimentan tanto a la Raspberry Pi como a la ArduPilot a traves del
Regulador de voltaje (6). Por cuestiones de seguridad, se dispone de un tirador de
emergencia (7) situado en el exterior de la esfera, que abre el circuito.
70
5.3 Arquitectura Software.
5.3. Arquitectura Software.
En este trabajo ha tenido lugar el diseno y la implementacion del software de
control de la Rosphere hasta su control de actitud, por lo tanto, se ha progra-
mado por completo el software implementado en la controladora OpenCM 9.04
y la ArduPilot Mega. La implementacion de los algoritmos en la Raspberry Pi,
destinados al guiado y la navegacion de la Rosphere, esta enmarcada en otro
proyecto.
5.3.1. Distribucion de tareas.
Al tener tres microcontroladoras diferentes, cada una con sus caracterısticas
especıficas, se ha asignado a cada una los procesos adecuados para sus capacida-
des.
5.3.1.1. Controladora OpenCM9.04.
Encargada del control directo de los motores, maneja todas las operaciones
relacionadas con estos de tal manera que ofrezca una capa de abstraccion para el
control de un nivel superior. Entre sus tareas se encuentran:
Adaptar las senales de control recibidas desde la ArduPilot Mega a su rango
de entradas, ya que el motor de giro continuo recibe una senal de mando de
porcentaje del par maximo distribuido entre los valores 0 y 2047 (211)siendo
1024 la aplicacion de un par nulo, 1023 el maximo par en sentido levogiro
y 2047 el maximo en sentido destrogiro (El ultimo bit es el que indica el
sentido) y el motor de inclinacion maneja un rango de entradas entre 0 y
1023, correspondientes a los 300o de recorrido que tiene.
Cerrar el lazo de realimentacion de bajo nivel del esquema de control del
angulo de la inclinacion de la esfera, correspondiente al control en posicion
del actuador que se explico mas detalladamente en el capıtulo de control.
71
5. ARQUITECTURA HARDWARE Y SOFTWARE.
Toma de datos de temperatura y voltaje aplicado sobre los motores, ası
como cambiar su modo de funcionamiento segun el valor de estas variables.
Esto es necesario por cuestiones de seguridad, ya que el voltaje aplicado a los
motores es directamente el de las baterıas, por lo tanto, sirve para calcular el
nivel de carga de estas, siendo bastante importante ya que a partir de cierto
voltaje mınimo, las baterıas pueden quedar inutilizadas de forma definitiva
y en algunos casos inflamarse. Mantener un control de la temperatura de
los motores tambien es de gran importancia debido a cuestiones obvias.
Calcular la velocidad del motor de giro continuo. Las prestaciones de los
actuadores escogidos se ven disminuidas cuando estos son configurados en
modo de giro continuo. El sensor que utilizan internamente para realimentar
su posicion, es un potenciometro que pese a poder girar libremente una
vuelta completa, solo da una salida valida en un rango de 300o, lo que lo
hace inservible en un rango de 60o. Es por ello que en las funciones incluidas
en la biblioteca dedicada al control de los motores, no se ofrece un control
ni una lectura de velocidad cuando el motor es configurado para girar de
modo continuo.
Esto ha afectado al control ya que la variable de entrada disponible es un
porcentaje del par maximo de salida, y la salida necesaria es la velocidad
angular del motor, por lo que se ha tenido que hacer el calculo evaluando
el incremento de la posicion en un tiempo determinado cuando el eje del
motor se encontrase dentro de los 300o de zona visible y una estimacion de
la velocidad en la zona ciega, teniendo en cuenta la ultima velocidad y la
ultima aceleracion tomadas en el rango visible, y modificando la aceleracion
en el caso en que el motor no hubiese salido de la zona ciega en el tiempo
estimado con la velocidad y la aceleracion con la que entro.
Pese a que esta aproximacion se basa en suposiciones, resulto dar resultados
bastante aceptables.
Enviar datos de velocidad y posicion de los motores, ası como la temperatura
y el nivel de las baterıas con una menor frecuencia, a la ArduPilot.
72
5.3 Arquitectura Software.
5.3.1.2. ArduPilot Mega 2.6.
Pese a que su programacion ha precisado de gran parte del tiempo de este
proyecto debido a la necesidad de integrar todos los sensores que incluye, la
cantidad de tareas que ha de realizar esta muy por debajo de sus capacidades.
Sus tareas principales son:
Obtener las senales de control que hay que enviar a los actuadores, mi-
diendo las inclinaciones reales de la esfera y realizando la realimentacion
taquimetrica.
Distribuir la informacion entre las capas inferiores y superiores de hardware.
esto implica enviar las senales de control de los motores a la OpenCM,
ası como senales de apagado, recibir la informacion proveniente de esta,
y comunicarse con la Raspberry Pi, recibiendo ordenes del control de alto
nivel y enviando la informacion necesaria para su correcto funcionamiento.
5.3.2. Algoritmia.
Debido a las caracterısticas y a los requisitos de este sistema, se ha tenido
que prestar especial atencion a la forma de programar los algoritmos necesario
para el funcionamiento de la Rosphere. El principale requisito es el poder ejecutar
procesos en paralelo. Esto no es realizable de forma directa, ya que no se dispone
de un sistema operativo que reparta el uso del procesador cuando un proceso se
bloquea, y que el lenguaje de programacion de ambos se basa en C++, por lo
tanto son estructurados y secuenciales.
Es por ello que no se ha utilizado ninguna operacion bloqueante tal como
bucles dependientes de condiciones externas o el bloqueo del programa durante
un tiempo (delay()), ambas practicas muy habituales en estas plataformas.
Ademas ha sido necesario el reparto de tareas del procesador, emulando me-
diante polling los diferentes tipos de interrupciones:
73
5. ARQUITECTURA HARDWARE Y SOFTWARE.
Interrupciones por tiempo: Para tareas tales como el calculo de las va-
riables de control, el envıo de datos no crıticos y la consulta de variables, se
ha definido una frecuencia de consulta concreta para cada caso, y en cada
ejecucion del bucle principal, se ha consultado el reloj de la microcontrola-
dora y comparado con la ultima vez que se realizo la tarea en cuestion. Si
la diferencia era igual o mayor al periodo establecido, se ejecutaba. A este
tipo de interrupciones pertenecen concretamente:
Por parte de la Controladora OpenCM:
• Consultar la posicion de ambos motores, calcular la velocidad del mo-
tor de giro continuo y enviar dichos datos a la Ardupilot (50 ms)
• Consultar y enviar la temperatura de los motores y la carga de las
baterıas.(60000 ms)
La ArduPilot tiene como tareas periodicas:
• Calculo de las variables de salida de control(50 ms)
• Envıo de datos de inclinacion de la esfera en el modo de identificacion,
en el que eran necesarios para determinar los parametros del mode-
lo.(50 ms)
• Envıo de velocidad lineal y heading.(200 ms)
• Envıo de los datos del GPS. (2000 ms)
Interrupciones asıncronas: Pese a que este termino no es correcto ya
que dichas interrupciones no se realizan de manera fısica directamente al
procesador, es utilizado haciendo referencia a eventos externos al procesador
y al reloj que necesitan ser manejados en cuanto se tenga consciencia de
ellos. Para su tratamiento, se ha hecho un polling incondicional en cada ciclo
del bucle principal, ejecutando las tareas de tratamiento de dichos eventos
siempre que hubiese uno.
Pertenecientes a la Controladora OpenCM:
74
5.3 Arquitectura Software.
• Calculo y envio de las variables de control directas de los motores. E
calculo se ejecuta cada ciclo, y la variacion de su resultado con respecto
al del ciclo anterior provoca el envıo de dicho resultado a los motores.
• Recibo de mensajes de la ArduPilot por el puerto serie. Provocado por
la presencia de datos en el buffer de entrada de dicho puerto.
Son competencia de la ArduPilot:
• Toma de datos de los sensores de inercia. Se hace una vez cada ciclo
y pese a que dichos datos solo se utilizan cada vez que se ejecuta el
calculo del regulador, es necesario ya que para realizar correctamente
el filtro disponible en las librerıas de dichos dispositivos, son necesarias
varias medidas.
• Envıo de nuevas senales de control para los motores a la controladora
OpenCM. Ejecutado cada vez que hay un cambio en dichas senales.
Sin embargo, en caso de no experimentar ningun cambio, esta tarea es
realizada por tiempo, con una frecuencia de 1Hz.
• Recepcion de datos, tanto de la controladora OpenCM como de la
Raspberry Pi. Se consulta cada buffer de entrada por separado y se
leen los datos en caso de haberlos.
5.3.3. Comunicaciones.
Puesto que se han tenido que utilizar tres microcontroladoras diferentes, te-
niendo que interactuar entre si de manera rapida y eficaz, la mayor parte de la fase
de programacion se ha empleado en establecer un protocolo de comunicaciones.
Las tres placas se comunican entre si por puerto serie Full Duplex (Un canal
de recepcion y otro de emision por cada microcontroladora) y disponen de buffers
del tamano suficiente como para que no se produzca desbordamiento de datos.
Sin embargo carecen de ningun procedimiento de sincronizacion, por lo que ha
sido necesario establecer de un protocolo para asegurarse de la correcta recepcion
de los mensajes.
75
5. ARQUITECTURA HARDWARE Y SOFTWARE.
5.3.3.1. Protocolo.
Debido a la posibilidad de perder datos y de falta de sincronismo se establecio
un protocolo de comunicaciones formado por los siguientes elementos:
Cabecera: Consta de un byte de inicio de valor constante255 y de otro
byte indicando el tipo de mensaje. El tipo de mensaje ha sido predefinido
y los valores de los diferentes tipos han sido escogidos de tal manera que
se diferencien por al menos 3 bits, para evitar en lo posible la erronea
interpretacion en caso de que se haya corrompido la informacion.
Contenido: La longitud de este viene definida por el tipo de mensaje al
que pertenece, por lo tanto no es necesario incluir un byte de longitud en
la cabecera.
Checksum: El ultimo byte del mensaje se destina a la comprobacion de
la recepcion correcta de la informacion. Para ello, se realiza la suma de
todos los bytes del contenido, volviendo a contar desde cero si se produce
desbordamiento.
5.3.3.2. Implementacion.
Para disponer de dicho protocolo en ambas plataformas, la controladora OpenCM
y la Ardupilot, se ha realizado una biblioteca compuesta por dos clases de C++
y 7 tipos de datos especıficos para el tratamiento y envio de la informacion.
Esta biblioteca se ha implementado de tal manera que sea valida para ambas
plataformas, incluyendo instrucciones para el compilador cuando fuese necesario
ya que, pese a tener un lenguaje de programacion comun, las bibliotecas y el
manejo de los perifericos de cada controladora funcionan de manera diferente.
Los tipos de datos recogen los diferentes tipos de mensaje mediante enum y
se realizan las conversiones de un tipo de dato cualquiera a cadenas de bytes
76
5.3 Arquitectura Software.
y viceversa mediante union, ya que las funciones de lectura y escritura de los
puertos serie de ambas microcontroladoras manejan este tipo de dato.
Ambas clases heredan de una clase virtual Serial_Rosphere que dispone de
tres metodos publicos:
void send message(enum message type,*char) Este metodo se encarga
de recopilar el contenido y preparar el mensaje, calculando el checksum,
para despues enviarlo por el puerto serie correspondiente. Como parame-
tros tiene una variable del tipo message type, enumeracion que recoje los
diferentes tipos de mensaje que se pueden enviar, y un vector *char co-
rrespondiente a la cadena de datos que se desea enviar, ya transformados a
bytes (byte y char son equivalentes, ambos ocupan 8 bits).
Es necesario por lo tanto adaptar los datos que se quieran enviar a un vector
de bytes mediante los tipos especıficos de conversion disponibles en esta
biblioteca para poder utilizar dicho metodo. Aun que esto hace que el codigo
pierda encapsulamiento, se ha hecho ası ya que introducirlo dentro de las
clase la habrıa hecho altamente acoplada y por lo tanto, poco independiente.
void receive message(void) Dicho metodo se encarga de comprobar si
hay mensajes disponibles en el buffer de entrada y extraer los datos del
mensaje, comprobando su validez con el checksum. Ademas, se encarga de
sincronizar los mensajes, desechando los bytes si no forman parte de un
mensaje completo (cabecera, contenido y checksum).
Como los procesos han de ser no-bloqueantes, ya que se deben de ejecutar
tareas tan importantes como el control de actitud, se ha programado este
metodo de tal manera que no quede a la espera de la llegada del mensaje.
Para ello dispone de dos modos, el de escucha y el de lectura. En el modo
de escucha, consulta si el buffer ha recibido dos o mas bytes. En tal caso,
lee los dos primeros y comprueba que se correspondan con el byte de start
y con un tipo de mensaje valido. En tal caso, guarda el tipo, pasa a modo
de lectura y le devuelve el control al programa principal. En caso negativo,
descarta los bytes leidos y retorna al programa principal.
77
5. ARQUITECTURA HARDWARE Y SOFTWARE.
Cuando se vuelve a llamar al metodo y se esta en modo de lectura, se com-
prueba si el buffer tiene una cantidad de bytes mayor o igual a la corres-
pondiente al tipo de mensaje que se habia almazenado. En caso negativo,
devuelve el control al programa principal, y en caso afirmativo, lee tantos
bytes como longitud tenga el mensaje, hace la suma del contenido y los
comprueba con el ultimo (correspondiente al checksum). En caso de coin-
cidir, almacena los datos recibidos, y en caso de ser diferentes, los desecha.
En ambos casos, pasa a modo de escucha, para volver a realizar todo el
proceso con futuros mensajes.
byte ack checker(void) Este metodo se ha realizado con objetivo de tra-
tar los mensajes de tipo ACK. En comunicaciones, un mensaje ACK, del
ingles acknowledgement, traducido como .acuse de recibo”, son aquellos que
indican al receptor que el emisor de dicho mensaje recibio correctamente el
un mensaje determinado que fue enviado anteriormente en sentido contra-
rio.
Ası pues, este metodo almacena en un pequeno buffer los mensajes enviados
mas recientemente y el momento en el que se enviaron.En la revision que
realiza cada ciclo, comprueba si ha llegado algun mensaje de tipo ACK al
sistema, y en tal caso, elimina del buffer el mensaje a espera de acuse de
recibo correspondiente. En caso de que haya pasado un tiempo, definido
para cada tipo de mensje, y no haya llegado su correspondiente mensaje de
acknouledgement, se activa un flag en un bit del byte de retorno, para que
el sistema trate esta situacion.
En un principio, todos los mensajes poseian de un aknowledge que el re-
ceptor debia de enviar cuando hubiese recivido el mensaje. Sin embargo,
una vez comprobado que la perdida de mensajes era mınima, se suprimio
este procedimiento para los mensajes mas habituales y para los que son
enviados periodicamente. Con esto se consiguie ademas liberar la linea de
transmision, que antes estaba ocupada continuamente con dicho mensaje.
Se mantuvo sin embargo este procedimiento para los mensajes ocasionales
y de mayor importancia, tales como alarmas por temperatura o nivel de las
baterıas y senales de apagado del sistema.
78
6
Conclusiones y trabajos futuros.
Este trabajo ha supuesto la creacion de un robot esferico funcional, recorrien-
do desde la concepcion de su diseno hasta su desarrollo mecatronico completo,
entendiendo mecatronica como integracion de la mecanica, el hardware, el soft-
ware y el control de un sistema. En el desarrollo de este trabajo se ha adquirido
destreza en el diseno de este tipo de robots, ası como nociones de su funciona-
miento y sus capacidades y limitaciones.
Asimismo se han adquirido y mejorado competencias en duseno mecanico y la
utilizacion del software pertinente (Inventor, Autocad y Catia), simulacion y di-
seno de control (Matlab, Simulink), desarrollo de codigo en tiempo real (LINUX,
IDE Arduino), cubriendo las fases de diseno, desarrollo, prueba y depuracion co-
rrespondientes al ciclo de vida del Software. Tambien se ha tenido la oportunidad
de trabajar un cierto numero de competencias transversales, como el trabajo en
equipo, la creatividad, la comunicacion en particular en ingles, la planificacion
del trabajo y el autoaprendizaje.
Este capıtulo recoge una sıntesis de lo aprendido sobre este tipo de robots,
destacando sus caracterısticas mas llamativas. Ası mismo, se proponen futuros
desarollos sobre el prototipo descrito en este proyecto, que haran de el un robot
aun mas funcional.
79
6. CONCLUSIONES Y TRABAJOS FUTUROS.
6.1. Conclusiones.
Este trabajo ha validado a las esferas roboticas como un tipo de robot movil
viable, siendo especialmente util en terrenos no compactos tales como arena de
playa o campos de cultivo, a diferencia de otros tipos de robots moviles. A su vez,
ha demostrado tener una gran capacidad de recuperacion, siendo casi imposible
colocar al robot en una posicion tal que este necesite de la ayuda de un agente
externo para volver a su funcionamiento normal, siendo esta aquella en la que el
eje fijo se situa perpendicularmente al suelo.
El aspecto mecanico ha demostrado ser un factor crıtico para este tipo de
robots debido a su principio de locomocion basado en la inestabilidad, y descri-
to mediante un modelo ideal que hay que esforzarse por emular al maximo. El
medio de locomocion escogido ha demostrado ser muy efectivo, aunque su diseno
presenta complejidad, pero esta es debida en parte al poco desarrollo que existe
en este tipo de robots, por lo que este proyecto aporta ciertos avances al respecto.
En cuanto a las estrategias de control utilizadas, hasta el punto en el que
se han desarrollado, han demostrado ser utiles, mejorando el comportamiento
dinamico enormemente.
Pese a que se pueda plantear que invierte demasiada energia en controlar su
inclinacion, tal como deberıa de hacer un robot caminante, hay que recordar que
el control de actitud es unicamente necesario de aplicar cuando el robot este
en movimiento para que mantenga su orientacion. Por lo tanto, este control de
actitud se puede desactivar cuando se pretenda que el robot este en reposo, ya
que, sea cual sea la posicion que alcance para llegar al un estado de equilibrio,
como ya se ha exlicado, podra recuperarse, siempre y cuando no este atrapado el
robot.
80
6.2 Lıneas futuras.
6.2. Lıneas futuras.
Pese a que este trabajo ha concluido con un robot funcional, las limitaciones de
tiempo han provocado que siga habiendo campos que no se han tratado, y aspectos
de este que se pueden mejorar o continuar con su desarrollo. Los principales son
los siguientes:
Carga de pago: Pese a que en anteriores trabajos con la Rosphere (Her-
nandez et al((15),(16)), Hernandez (3)) una de las lineas principales de
desarrollo fue la implementacion de sensores tales como humedad y tem-
peratura, este trabajo no ha incluido la instrumentacion del robot, es por
ello que una de las lineas de desarrollo de la Rosphere mas importante es
el dotar esta de sensores que le den un valor anadido. Ademas, el diseno
actual ha tenido esto en cuenta, siendo facilmente implementables modulos
externos que incluyan dichos sensores.
Una de las posibilidades de modulos externos es el de una camara, una de las
razones por las que se escogio la Raspberry Pi debido a sus capacidades de
procesamiento de video. Actualmente se esta trabajando en dicho modulo,
disponiendo de la camara y disenandose una estructura que permita su
acoplamiento a los brazos externos y la disposicion de dos grados de libertad
para cambiar su orientacion.
Hardware: Pese a que la eleccion de los actuadores y las controladoras
ha sido acertada, esta se podrıa mejorar. Por un lado, un actuador que
disponga de modo de giro continuo y un control de velocidad facilitarıa
considerablemente el control de la velocidad de rodadura
Por otro lado, seria pertinente el buscar una microcontroladora destinada
a la robotica que disponga de sensores tales como una IMU ya integrados.
Sin embargo, este es el caso de las dos primeras versiones de la Rosphere,
que utilizaban una Gumstix + RoboVero, y esta se descarto debido a la
complejidad de su programacion.
81
6. CONCLUSIONES Y TRABAJOS FUTUROS.
Otra solucion a este problema serıa la integracion directa de sensores exter-
nos con la Raspberry Pi o el uso de shields de navegacion disenadas para
esta controladora tales como NAVIO que incluyen ya estas funcionalidades.
Guiado, navegacion y control: Pese a que ya existen tecnicas del control
de actitud propuestas y corroboradas por diferentes autores, y que este
trabajo aporta desarrollos en este aspecto, un estudio mas de otras tecnicas
de control podrian llevar a la mejora de la respuesta dinamica del robot.
En cuanto a el guiado y navegacion, existen artıculos (Quiang et al(17),
Bhattacharya et al(18)) que tratan la planificacion de trayectorias de este
tipo de robots, por lo que solo serıa necesario implementarlos en la Rosp-
here. Esta es facil de implementar, ya que como uno de los requisitos de
diseno fue que se disponiese de ROS en el robot, framework que dispone de
herramientas disenadas para tales fines.
Mecanica: Si bien el diseno mecanico de la Rosphere V0.3 es altamente
eficiente, existen factores que pueden ser mejorados. El principal es la uti-
lizacion de otra carcasa esferica. La utilizada en la Rosphere es una esfera
de ejercicio para mascotas. Un cambio de dicha esfera por una disenada
especıficamente para los requisitos de la Rosphere mejorarıa sus capacida-
des. Entre estas se encuentra el montaje y desmontaje, la esfericidad y la
traccion, que se podrian solucionar con pequenas inversiones en diseno y el
uso de un material adecuado para la aplicacion.
82
Bibliografıa
[1] Shengju Sang, Zhao Jichao, Hao Wu, Shoujun Chen, and
Qi An. Modeling and simulation of a spherical mo-
bile robot. Computer Science and Information Systems,
7(1):51–62, 2010. 3
[2] Jean-Francois Laplante, Patrice Masson, and Francois
Michaud. Analytical Longitudinal and Lateral Mo-
dels of a Spherical Rolling Robot. Technical report,
Ca- nada, 21(5):15 – 22, 2007. 3
[3] Juan David Hernandez Vega. ROSPHERE: Diseno, Cons-
truccion y Aplicacion de una Esfera Robotica. Master’s
thesis, Escuela Tecnica Superior de Ingenierıa Industrial
- Universidad Politecnica de Madrid. 3, 81
[4] Aarne Halme, Torsten Schonberg, and Yan Wang. Mo-
tion control of a spherical mobile robot. In Ad-
vanced Motion Control, 1996. AMC’96-MIE. Proceedings.,
1996 4th International Workshop on, 1, pages 259–264.
IEEE, 1996. 7, 8, 12
[5] A Bicchi, A Balluchi, D. Prattichizzo, and A Gorelli. In-
troducing the ldquo;SPHERICLE rdquo;: an ex-
perimental testbed for research and teaching in
nonholonomy. In Robotics and Automation, 1997. Pro-
ceedings., 1997 IEEE International Conference on, 3, pa-
ges 2620–2625 vol.3, Apr 1997. 9
[6] J Alves and J Dias. Design and control of a spherical
mobile robot. Proceedings of the Institution of Mecha-
nical Engineers, Part I: Journal of Systems and Control
Engineering, 217(6):457–467, 2003. 10
[7] Fran cois Michaud, Jean de Lafontaine, and Serge Caron.
A Spherical Robot for Planetary Surface Explo-
ration. 10
[8] M. Seeman, M. Broxvall, A Saffiotti, and P. Wide. An
Autonomous Spherical Robot for Security Tasks.
In Computational Intelligence for Homeland Security and
Personal Safety, Proceedings of the 2006 IEEE Internatio-
nal Conference on, pages 51–55, Oct 2006. 10
[9] Puyan Mojabi et al. Introducing August: a novel
strategy for an omnidirectional spherical rolling
robot. In Robotics and Automation, 2002. Proceedings.
ICRA’02. IEEE International Conference on, 4, pages
3527–3533. IEEE, 2002. 11
[10] Masaki Nagai. Control system for a spherical robot. Mas-
ter’s thesis, Lulea tekniska universitet, 2008. 12
[11] Erkan Kayacan, Zeki Y. Bayraktaroglu, and Wouter
Saeys. Modeling and control of a spherical rolling
robot: a decoupled dynamics approach. Robotica,
30:671–680, 7 2012. 12, 29
[12] Qiang Zhan, Yao Cai, and Zengbo Liu. Near-optimal
trajectory planning of a spherical mobile robot
for environment exploration. In Robotics, Automa-
tion and Mechatronics, 2008 IEEE Conference on, pages
84–89. IEEE, 2008. 12
[13] C. Camicia, F. Conticelli, and A Bicchi. Nonholonomic
kinematics and dynamics of the Sphericle. 1:805–
810 vol.1, 2000. 29
[14] Jonathan M. Cameron and Wayne J. Book. Mode-
ling Mechanisms with Nonholonomic Joints Using
the Boltzmann-Hamel Equations. The International
Journal of Robotics Research, 16(1):47–59, 1997. 30
[15] Juan D. Hernandez, Jorge Barrientos, Jaime del Cerro,
Antonio Barrientos, and David Sanz. Moisture measu-
rement in crops using spherical robots. Industrial
Robot: An International Journal, 40(1):59–66, 2013. 81
[16] Juan David Hernandez, David Sanz, Gonzalo R. Rodrıguez-
Canosa, Jorge Barrientos, Jaime del Cerro, and Antonio
Barrientos. Sensorized robotic sphere for large ex-
terior critical infrastructures supervision. Journal
of Applied Remote Sensing, 7(1):073522–073522, 2013.
81
[17] Zhan Qiang, Liu Zengbo, and Cai Yao. A Back-stepping
Based Trajectory Tracking Controller for a Non-
chained Nonholonomic Spherical Robot. Chinese
Journal of Aeronautics, 21(5):472 – 480, 2008. 82
[18] S. Bhattacharya and S.K. Agrawal. Spherical rolling
robot: a design and motion planning studies. Robo-
tics and Automation, IEEE Transactions on, 16(6):835–
839, Dec 2000. 82
83
Top Related