Tesis Edgar Daniel Martinez Rodiguez

UNIVERSIDAD DE GUANAJUATO
DIVISIÓN DE INGENIERÍAS
CAMPUS IRAPUATO - SALAMANCA
“ Instrumentación de un Robot
Móvil de Exterior”
TESIS PROFESIONAL
QUE PARA OBTENER EL TÍTULO DE:
INGENIERO EN MECATRÓNICA
PRESENTA:
Edgar Daniel Martı́nez Rodrı́guez
CO-ASESORES:
Dr. Juan Gabriel Aviña Cervantes
Dr. Maximino Antonio González Palacios
SALAMANCA, GTO. Abril, 2010

Dedicatoria
A Dios: Por acompañarme cada instante de mi vida, por que nunca me

faltó nada y siempre estuvo cuidándome para seguir el camino más seguro
para alcanzar esta meta.
A mis padres: Ramiro Esaul Martı́nez González y Ma. Dolores Rodrı́guez

Rodrı́guez, por brindarme su apoyo incondicional, por que sus consejos y en-
señanzas hoy son parte importante en la formación de mi vida personal y
profesional llevadome a dar un paso más por alcanzar esta meta.
A mis hermanos: Oscar Ramiro Martı́nez Rodrı́guez y Diana Esme-

ralda Martı́nez Rodrı́guez por darme su apoyo, su confianza y por ser mis
amigos de toda la vida.
i
Agradecimientos
A mis asesores: Dr. Juan Gabriel Aviña Cervantes y Dr. Maximino

Antonio González Palacios, por su ayuda, guı́a y enseñanza durante el trans-
curso de mi carrera y el desarrollo de este trabajo de tesis.
A mis tı́os: Jesús Martı́nez, Carlos Martı́nez, Emma Martı́nez, Sil-

via Martı́nez, Rosalva Martı́nez, Miguel Martı́nez y Verónica Martı́nez que
siempre me apoyaron incondicionalmente y me acompañaron incluso en los
momentos más difı́ciles de la vida.
A mis abuelos: Esperanza González, Pascual Martı́nez q.e.d., Belén

Rodrı́guez q.e.d., que con su experiencia en la vida me guiaron enseñandome
a no rendirme y que pese a los malos momentos nunca se debe perder la
esperanza.
A mis profesores: Por que contribuyeron enormemente en mi forma-

ción académica e inspiración para seguir estudiando.
A mis compañeros y amigos: Pedro Patlán, Ángel Maldonado, Paola

Alvarado, Irma Estrada, Christian Luna, Daniel Razo, Natzielly Anzaldo,
Evelia López, Diana Quintero, Luis Negrete y Elena Dávila que me brin-
daron su ayuda y compañı́a en todos los momentos de mi vida y durante
mi carrera ya que hoy en dı́a los sigo conservando como mis fieles amigos,
gracias.
ii
Agradecimientos
Institucionales
Agradecemos a la Dirección de Apoyo a la Investigación y Posgrado

(DAIP) de la Universidad de Guanajuato que por medio de la convocatoria
Institucional 2009 apoyó el proyecto 0082/09 “CONTROL DE UN MANI-
PULADOR INDUSTRIAL POR MEDIO DE VISIÓN ARTIFICIAL” que
nos permitió sostener parte de nuestro trabajo e investigaciones.
iii
Prólogo
Por siglos la naturaleza ha sido la inspiración para el desarrollo tecnológi-

co, y el campo de la robótica no es la excepción. Por años los investigadores
se han enfrentado a la tarea de desarrollar sistemas robóticos capaces de
interactuar con el entorno que los rodea. Esta disciplica es conocida como
robótica autónoma móvil.
Uno de los campos más importantes que abarca la robótica autónoma

móvil ha sido dirigida hacia la exploración. El ser humano siempre ha si-
do curioso por naturaleza y en su búsqueda por más conocimiento se ha
lanzado a explorar entornos con los que no se encuentra familiarizado. Sin
embargo, existen condiciónes fı́sicas ambientales que pueden llegar a limitar
el acceso humano en estos nuevos entornos. Es por ello que se han desarro-
llado vehı́culos con una amplia veriedad de sensores que le permitan obtener
datos del medio, los cuales son procesados en sistemas de gran potencia
computacional registrando sus caracterı́sticas.
La presente tesis tiene por objetivo la instrumentación de un robot móvil

de exterior tipo oruga que puede ser utilizado para la exploración de entornos
hostiles o de difı́cil acceso para el ser humano.
iv
Índice general
1. Generalidades 1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1. El robot Shakey . . . . . . . . . . . . . . . . . . . . . 2
1.2.2. Mars Pathfinder . . . . . . . . . . . . . . . . . . . . . 2
1.2.3. Proyecto Vida en Atacama . . . . . . . . . . . . . . . 5
1.2.4. Spirit y Opportunity . . . . . . . . . . . . . . . . . . . 7
1.3. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Plan de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Robot móvil de exterior tipo oruga 10
2.1. Robots de ruedas . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Robots tipo oruga . . . . . . . . . . . . . . . . . . . . . . . . 11
v
ÍNDICE GENERAL
2.3. HD2 Treaded ATR Tank Robot . . . . . . . . . . . . . . . . . 12
2.3.1. Módulo de control de motores . . . . . . . . . . . . . . 12
2.3.2. Diseño de una PC de alto rendimiento . . . . . . . . . 17
2.4. Diseño de un gabinete para un CPU . . . . . . . . . . . . . . 19
2.4.1. Diseño en Autodesk Inventor . . . . . . . . . . . . . . 19
2.5. Diseño de la unidad de potencia . . . . . . . . . . . . . . . . . 21
3. Instrumentación del sistema 23
3.1. Instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Sistema operativo GNU/Linux: OpenSUSE . . . . . . . . . . 26
3.2.1. Concepto GNU/GPL . . . . . . . . . . . . . . . . . . . 26
3.2.2. Distribuciones de Linux . . . . . . . . . . . . . . . . . 27
3.3. Instrumentación virtual: LabVIEW . . . . . . . . . . . . . . . 28
3.3.1. Adquisición de Datos (DAQ):USB-6009 NI . . . . . . 30
3.4. Instalación de cámaras de alta resolución

IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5. Integración de sensores ultrasónicos . . . . . . . . . . . . . . . 37
3.5.1. Sensor ultrasónico de distancia SRF02 . . . . . . . . . 37
3.6. Instalación del sensor Laser Range Finder 2D . . . . . . . . . 42
3.6.1. Hokuyo UBG-04LX-F01 . . . . . . . . . . . . . . . . . 42
vi
ÍNDICE GENERAL
3.6.2. Protocolo SCIP2.0 para sensores Láser . . . . . . . . . 42
3.6.3. Programación en C/C++ para la comunicación con el

Láser Range Finder . . . . . . . . . . . . . . . . . . . 50
3.6.4. Graficado con OpenGL . . . . . . . . . . . . . . . . . 54
4. Resultados Experimentales 58
4.1. Una CPU de alto rendimiento con el S.O. Linux OpenSUSE

11.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2. Cámaras de video de alta resolucion IEEE 1394 . . . . . . . . 60
4.3. Instalación de un anillo de 10 sensores para detección de

obstáculos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4. Un sistema Laser Range Finder funcional para detección de

obstáculos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5. Un robot capaz de operar implementando algoritmos en Lab-

VIEW y C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6. Un robot tipo oruga con una amplia variedad de sensores . . 73
5. Conclusiones Generales 75
5.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A. Instalación de Linux: OpenSUSE 78
A.1. Paso 1: Respaldo y Desfragmentación del Disco Duro . . . . . 78
A.2. Paso 2: Partición del disco duro . . . . . . . . . . . . . . . . . 78
vii
ÍNDICE GENERAL
A.3. Instalación de OpenSUSE . . . . . . . . . . . . . . . . . . . . 80
Bibliografı́a. 82
viii
Índice de figuras
1.1. Robot Shakey. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Mars Pathfinder. . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Explorador Sojourner. . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Robot Hyperion. . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Robot Zoe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6. Robot Spirit. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. HD2 Treaded ATR Tank Robot. . . . . . . . . . . . . . . . . 12
2.2. Controlador MD03. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Entradas MD03. . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Lectura de Registros en Protocolo I 2 C. . . . . . . . . . . . . 15
2.5. Tarjeta madre GIGABYTE GA-P43-ES3G. . . . . . . . . . . 18
2.6. Diseño del gabinete en 3D. . . . . . . . . . . . . . . . . . . . 20
2.7. Diferentes vistas del gabinete en 3D. . . . . . . . . . . . . . . 21
ix
ÍNDICE DE FIGURAS
2.8. Gabinete ensamblado. . . . . . . . . . . . . . . . . . . . . . . 22
3.1. Sistema de Adquisición de Datos. . . . . . . . . . . . . . . . . 24
3.2. Estimación del uso de Sistemas Operativos. . . . . . . . . . . 26
3.3. Panel Frontal de un VI. . . . . . . . . . . . . . . . . . . . . . 29
3.4. Diagrama de Bloques de un VI. . . . . . . . . . . . . . . . . . 30
3.5. Diagrama de instrumentación utilizando una DAQ. . . . . . . 31
3.6. Ventana de configuración DAQ Assistant. . . . . . . . . . . . 32
3.7. Ejemplo de instrumentación de un sensor de temperatura con

DAQ Assistant. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8. Lectura de un dato utilizando NI-DAQ base. . . . . . . . . . 34
3.9. Factores que afectan la medición de un sensor ultrasónico. . . 38
3.10. Área de sensado ultrasónico. . . . . . . . . . . . . . . . . . . . 39
3.11. Sensor ultrasónico SRF02. . . . . . . . . . . . . . . . . . . . . 39
3.12. Pines de control del SRF02. . . . . . . . . . . . . . . . . . . . 40
3.13. Sensor Hokuyo UBG-04LX-F01. . . . . . . . . . . . . . . . . . 43
3.14. Rango de detección Hokuyo UBG-04LX-F01. . . . . . . . . . 43
3.15. Parametros de medición del Laser UBG-04LX-F01. . . . . . . 45
3.16. Codificación de 4 caracteres. . . . . . . . . . . . . . . . . . . . 46
3.17. Decodificación de 4 caracteres. . . . . . . . . . . . . . . . . . 47
x
ÍNDICE DE FIGURAS
3.18. Protocolo de comunicación en SCIP2.0. . . . . . . . . . . . . 47
3.19. Software Vmon.exe en Windows. . . . . . . . . . . . . . . . . 50
3.20. Diagrama de flujo del programa para el sensor. . . . . . . . . 53
3.21. Bloque de la interfaz y ajuste de datos en OpenGL para el

desplegado de los datos en una gráfica. . . . . . . . . . . . . . 54
3.22. Interfaz OpenGL desglosado en bloques de ejecución. . . . . . 55
4.1. Entorno Linux OpenSUSE 11.0. . . . . . . . . . . . . . . . . . 59
4.2. Unidad Central de Procesamiento de alto rendimiento. . . . . 61
4.3. Resultados de la función bench de MATLAB

R para esta PC. 62
4.4. Imagen capturada por la cámara XCD-X710CR. . . . . . . . 63
4.5. Cámara XCD-X710CR de SONY

R FireWire IEEE 1394. . . 64
4.6. Resultados de la tesis de licenciatura “Navegación Reactiva

con Sensores Ultrasónicos”˜[18]. . . . . . . . . . . . . . . . . . 65
4.7. Sala de electrónica sin personas medida con el Laser Hokuyo. 67
4.8. Laboratorio de Electrónica con personas medido con el Laser

Hokuyo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.9. Laboratorio de Electrónica con personas medido con el Laser

Hokuyo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.10. Programa Server de comunicaciones y control de motores. . . 71
4.11. Programa Cliente de comunicaciones y control de motores. . . 72
xi
ÍNDICE DE FIGURAS
4.12. Robot HD2 Treaded ATR Tank con CPU y sensores integrados. 74
xii
Índice de Tablas
3.1. Registros del SRF02. . . . . . . . . . . . . . . . . . . . . . . . 40
3.2. Comandos del SRF02. . . . . . . . . . . . . . . . . . . . . . . 41
3.3. Parametros de medición del Laser UBG-04LX-F01. . . . . . . 45
xiii
Capı́tulo 1
Generalidades
1.1. Introducción
Durante siglos, el ser humano ha construido máquinas capaces de realizar

tareas imitando funciones de partes humanas como son los sentidos que nos
permiten obtener información del entorno y las extremidades que nos ayudan
a manipular objetos. La mayorı́a de los robots usan ruedas o extremidades
para moverse. Estas son usualmente montadas sobre una base para formar un
vehı́culo, también se montan sobre esta base equipo y accesorios que realizan
otras funciones. Es importante mencionar que los robots con extremidades
pueden desplazarse en terrenos complejos o irregulares que los robot con
ruedas, pero el problema de control se vuelve más complejo.
Mientras las personas y la mayorı́a de los animales se desplaza sobre ex-

tremidades, la mayorı́a de las máquinas móviles utilizan ruedas ya que éstas
son más simples de controlar, tienen pocos problemas de estabilidad, usan
menos energı́a por unidad de distancia de movimiento y son más veloces que
las extremidades. La estabilidad se mantiene al fijar el centro de gravedad
del vehı́culo en triangulación de los puntos que tocan tierra. Sin embargo,
las ruedas solamente pueden utilizarse sobre terrenos relativamente lisos y
sólidos. Si se quiere utilizar el robot en terrenos rugosos las ruedas tienen
que tener un tamaño mayor que los obstáculos encontrados o utilizar un tipo
1
1.2 Antecedentes
diferente de rodamiento como el tipo oruga cuyo diseño es tratado en esta

tesis ya que permite trasladarse en terrenos rugosos e inclinados ası́ como
subir escaleras.
1.2. Antecedentes
Actualmente, el concepto de robótica ha evolucionado hacia los sistemas

móviles autónomos, ya que éstos son capaces de desenvolverse por sı́ mis-
mos en entornos desconocidos y parcialmente cambiantes sin necesidad de
supervisión, es por esta razón que se debe proveer de una amplia variedad
de sensores capaces adquirir información necesaria respecto al entorno pa-
ra lograr la autonomı́a de estos sistemas móviles [14]. Por más de 40 años
se ha trabajado en el desarrollo estos sistemas para fines de transporte de
materiales y exploración de terrenos hostiles, algunos de los trabajos más
representativos de este tipo de robots han sido desarrollados por la NASA
para la exploración espacial [4] [5].
1.2.1. El robot Shakey
El robot Shakey [8], desarrollado en los laboratorios de Inteligencia arti-

ficial del SRI (Standford Research Institute) desde 1966 hasta 1972, provisto
de una gran variedad de sensores, cámara de televisión, sensores táctiles y
un microprocesador, fue el primer robot móvil capaz de razonar sus propias
acciones. Shakey estaba dotado de la capacidad de trasladar objetos pesados
de un lugar a otro, ver Figura 1.1.
1.2.2. Mars Pathfinder
El 4 de julio de 1997 Estados Unidos celebra su independencia con el

aterrizaje en Marte del Mars Pathfinder [5], ver Figura 1.2, la primera de una
serie de misiones de la NASA que incluye vehı́culos de exploración (rovers).
2
1.2 Antecedentes
Figura 1.1: Robot Shakey.
3
1.2 Antecedentes
Figura 1.2: Mars Pathfinder.
El Mars Pathfinder realizó diferentes investigaciones sobre el suelo mar-

ciano a través de tres instrumentos cientı́ficos. En el lander (la plataforma de
aterrizaje) contenı́a una cámara estereoscópica con filtros especiales en un
mástil extensible llamado Imágenes para Mars Pathfinder (IMP) y el Instru-
mento de Estructura Atmosférica / Paquete de Metrologı́a (ASI /MET) que
actúa como una estación meteorológica de Marte, recogiendo datos sobre la
presión, temperatura y vientos.
El explorador Sojourner disponı́a de un Espectrómetro de rayos X Alfa

Protón (APXS), utilizado para el análisis de la composición de las rocas y
el suelo. El rover también tenı́a dos cámaras blanco y negro y una cáma-
ra en color, rastreadores láser, acelerómetros y potenciómetros, ver Figura
1.3. Estos instrumentos permitı́an realizar investigaciones geológicas de la
superficie desde sólo unos milı́metros hasta cientos de metros, la geoquı́mica
e historia evolutiva de la superficie y las rocas, las propiedades magnéticas
y mecánicas del terreno además de las propiedades magnéticas del polvo, la
atmósfera y la dinámica rotacional y orbital marcianas.
4
1.2 Antecedentes
Figura 1.3: Explorador Sojourner.
1.2.3. Proyecto Vida en Atacama
En el 2004 el proyecto Vida en Atacama [2] fue la segunda fase de un

proyecto de 3 años cuyo objetivo es encontrar la manera de detectar vida
mediante un robot explorador a control remoto. El proyecto es parte del
programa de tecnologı́a y astrobiologı́a de la NASA para la exploración de
planetas (ASTEP), el cual se concentra en forzar la tecnologı́a al lı́mite
en ambientes hostiles. David Wettergreen, profesor adjunto del Instituto de
Robótica de Carnegie Mellon, dirige el desarrollo de los robots exploradores
e investigación de campo del proyecto. Natalie Carbol, del Ames Research
Center de la NASA y el Instituto SETI, dirige la investigación cientı́fica.
La primera fase del proyecto comenzó en el 2003 cuando un robot pro-

pulsado con energı́a solar llamado Hyperion, mostrado en la Figura 1.4,
desarrollado en Carnegie Mellon, fue probado en el desierto de Atacama.
Se realizaron experimentos para determinar el diseño óptimo, software e
instrumentación de un robot para experimentos de mayor alcance [3].
5
1.2 Antecedentes
Figura 1.4: Robot Hyperion.
Zoe, es un robot que fue desarrollado en respuesta a los experimentos

del 2003 con el fin de operar de forma autónoma en un recorrido de 50 km
durante dos meses [3], ver Figura 1.5.
Figura 1.5: Robot Zoe.
6
1.2 Antecedentes
1.2.4. Spirit y Opportunity
El 3 de enero del 2004 el robot explorador Spirit descendió sobre el

cráter Gusev en Marte tres semanas después, el 24 de enero, su gemelo el
Opportunity se posó en el extremo opuesto del planeta rojo [4] , ver Figura
1.6.
Figura 1.6: Robot Spirit.
Estos robots son equipados con una cámara estéreo que reproduce con
alta fidelidad la visión humana y con un avanzado panel de instrumentos
con los que se quiere averiguar la existencia de agua en Marte; tiene seis
ruedas y es mucho más grande y sofisticado que el Sojourner y al igual que
éste cuentan con paneles solares que los proveen de energı́a.
Estos vehı́culos han sido aprovechados por la sonda espacial “Mars Ex-
press”, de la Agencia Espacial Europea (ESA), para realizar observaciones
atmosféricas coordinadas con su espectrómetro de emisiones termales y su
cámara panorámica.
7
1.3 Objetivo
Como se ha mencionado anteriormente se ha concentrado el desarrollo de

este tipo de robots para fines de exploración y éstos pueden ser equipados con
sensores e instrumentos que permitan recolectar de manera más detallada
datos sobre las condiciones del terreno a explorar.
1.3. Objetivo
La presente tesis tiene por objetivo la instrumentación de un robot móvil

de exterior tipo oruga que puede ser utilizado para la exploración de terre-
nos irregulares o de difı́cil acceso para el ser humano. El diseño comprende
la adecuación e instalación de una PC de alto rendimiento la cual sera ali-
mentada por un inversor de voltaje y un par de baterı́as de ácido de 12A/h.
Al sistema se integra una red de sensores ultrasónicos, cámaras de video de
alta resolución IEEE1394, un sistema de escaneo láser de entorno Hokuyo
para la adquisición de datos y control de navegación.
1.4. Justificación
El desarrollo de la instrumentación y control de un robot móvil de exte-

rior tipo oruga que sea capaz de detectar y esquivar obstáculos por medio
de sensores de rango (láser y ultrasónicos) y obtener imágenes del entorno
con cámaras de alta resolución permitirá al usuario tener las herramientas
suficientes para implementar algoritmos de navegación obteniendo de este
trabajo útiles aplicaciones como es el transporte y localización de objetos,
ası́ como mapeo y exploración de terrenos de difı́cil acceso.
1.5. Plan de Trabajo
El presente manuscrito se divide en 5 capı́tulos y sus referencias bi-

bliográficas como se describe a continuación:
8
1.5 Plan de Trabajo
Capitulo 2: Robot Móvil de Exterior Tipo Oruga. Se presen-

tan las caracterı́sticas fı́sicas y de control del robot tipo oruga HD2
Treaded ATR Tank.
Capitulo 3: Instrumentación del Sistema. Se presenta el desa-
rrollo de la instrumentación e instalación de sensores y tarjetas de
adquisición de datos.
Capitulo 4: Resultados Experimentales. Se muestran los resulta-
dos obtenidos de las mediciones efectuadas por los sensores y tarjetas
de adquisición de datos ası́ como del funcionamiento de la unidad de
control del sistema.
Capitulo 5: Conclusiones Generales. Se presentan las conclusio-
nes obtenidas al término del proyecto ası́ como trabajos futuros a
realizar sobre el sistema robótico.
Apéndice A: Instalación de Linux: OpenSUSE. Se presentan
los pasos necesarios para la instalación del sistema operativo Linux
OpenSUSE.
9
Capı́tulo 2
Robot móvil de exterior tipo

oruga
En este Capı́tulo se muestran las diferencias de las rodaduras utilizadas

en los robots móviles de ruedas y el de tipo oruga. También se trata las
caracterı́sticas principales del robot “HD2 Treaded ATR Tank Robot”, sus
componentes y el diseño de la Unidad Central de Procesamiento que controla
al robot, ası́ como el diseño de la unidad de potencia que alimenta a todo el
sistema.
2.1. Robots de ruedas
Los robots de ruedas son los más utilizados por diversas razones [14],
entra las principales se encuentra que:
Son estructuras más simples de construir.

Tienen una alta eficiencia en terrenos planos y sólidos.
Por su estabilidad son más fáciles de controlar.
Tienen gran capacidad de carga.
Son más robustos y por lo tanto tienen menos partes móviles.
Tienen mayor eficiencia energética.
10
2.2 Robots tipo oruga
Pueden alcanzar altas velocidades.
Al mismo tiempo, esto genera desventajas ya que este tipo de robots

están limitados a moverse sólo en terrenos relativamente planos y son afec-
tados por las diferencias del terreno u obstáculos de radio mayor al de sus
ruedas, por lo cual es recomendable diseños con ruedas grandes.
2.2. Robots tipo oruga
Los robots tipo oruga son utilizados para aplicaciones sobre entornos hos-
tiles y entre las principales ventajas que superan a los robots de ruedas [22]
se encuentra que:
Debido al diseño de sus rodaduras son robustos ante las variaciones

del terreno.
Movimiento rectilı́neo con alto grado de exactitud.
Alta fricción al girar por sus múltiples puntos de contacto con la su-
perficie.
Algunos tienen la capacidad de subir escaleras.
Tiene gran capacidad de carga.
Sus principales desventajas son:
Requieren de alto torque y de mucha energı́a para el cambio de direc-

ción.
Sus rodaduras generan resbalamientos.
Es difı́cil determinar la pose del robot a partir de modelos cinemáticos.
Sin embargo, los problemas de posición debida a los resbalamientos ge-

nerados por sus rodaduras pueden ser corregidos mediante el estudio de su
odometrı́a [22].
11
2.3 HD2 Treaded ATR Tank Robot
2.3. HD2 Treaded ATR Tank Robot
En la presente tesis se trabajó con el HD2 Treaded ATR Tank Robot [21]
que es un vehı́culo explorador diseñado para trasladarse en terrenos irregu-
lares y obstaculizados, ver Figura 2.1. Debido a la potencia de sus 4 motores
IG52-02, 24VDC, 290 RPM y el diseño de sus rodaduras tipo oruga
tiene la capacidad de subir escaleras y trasladarse en velocidades que lle-
gan alrededor de los 4ft/s (1.22m/s). El chasis de este robot esta hecho de
aluminio del mismo grado que usan algunas aeronaves, lo que lo hace muy
resistente.
Figura 2.1: HD2 Treaded ATR Tank Robot.
2.3.1. Módulo de control de motores
Una caracterı́stica importante del robot HD2 Treaded ATR Tank Robot
son los módulos de potencia integrados MD03 [20], que es un controlador
de motor de corriente continua de mediana potencia, ver Figura 2.2. La
potencia del motor es controlada mediante Modulación de Ancho de Pulso
12
(PWM) del puente H a una frecuencia de 7.8KHz. Los 15V de la tensión de

control del MOSFET se genera en el mismo circuito mediante una bomba
de carga, por lo que sólo se requieren 5V a 50 mA para la alimentación del
circuito, además de la alimentación del motor que está comprendida entre
los 5 y los 24V dependiendo de los requerimientos del motor.
Figura 2.2: Controlador MD03.
El módulo MD03 puede ser controlado de 5 maneras diferentes:
Modo bus I 2 C.
Entrada analógica 0V - 2.5V - 5V.
Entrada analógica 0V - 5V.
Modo PWM.
Modo RC.
Las señales a utilizar para cada uno de los modos de control del MD03
son recibidas por las entradas SDA, SCL de este módulo, ver Figura 2.3.
13
Figura 2.3: Entradas MD03.
Modo I 2 C
I 2 C es un bus de comunicaciones en serie, su principal caracterı́stica

es que utiliza dos lı́neas para transmitir la información: una para los datos
(SDA) y por otra la señal de reloj (SCL). También es necesaria una tercera
lı́nea para la referencia (GND).
El modo I 2 C permite conectar el MD03 a un circuito controlador como

Basicx24, OOPic, Basic Stamp, por citar algunos, o bien a algunos micro-
controladores como PIC, 8051, H8, entre otros. El Bus I 2 C puede manejar
hasta 8 módulos MD03 con direcciones seleccionables.
Para leer uno o más registros del MD03, primero se envı́a un bit de
comienzo seguido de la dirección del modulo (0XB0, dirección base) con
el bit de lectura/escritura puesto a cero. Después se manda el número del
registro que desea leer seguido de nuevo de un bit de comienzo y otra vez
14
la dirección del módulo con el bit lectura/escritura puesto a 1(0XB1), véase

Figura 2.4.
Figura 2.4: Lectura de Registros en Protocolo I 2 C.
Modo entrada analógica 0V - 2.5V - 5V
En esta modalidad, el motor es controlado por una señal analógica de

0 a 5 voltios en la entrada SDA. La entrada SCL no se utiliza y debe ser
conectada a 0v o a +5V.
En este modo 0V es la máxima velocidad en un sentido, 2.5V es la

posición de reposo y 5V corresponde la máxima velocidad en el otro sentido.
Hay una pequeña zona muerta de un 2.7 % de ancho en la zona central,

para proporcionar una zona de apagado estable. La impedancia de entrada
es de 47 KΩ.
Modo entrada analógica 0V - 5V
En este modo, el motor es controlado por una señal analógica entre 0V y

5V conectada a la entrada SDA, donde 0 corresponde a la posición de reposo
y 5V la máxima potencia. La dirección se controla mediante el nivel lógico
de la entrada SCL, cuando está a 0 gira en un sentido y cuando está a 1 en
el otro.
15
Modo PWM
Se puede emplear una señal de modulación de ancho de pulso (PWM) en

lugar de la señal analógica en la lı́nea SDA. Hay un sencillo filtro formado por
condensador y una resistencia capaz de generar la tensión analógica desde
la señal PWM. La señal PWM debe ser de 20Khz o superior e idealmente
procedente de una puerta CMOS (0, 5V) mejor que de una TTL (0-3, 5V).
Un ciclo de trabajo de 0 % representa 0V y un ciclo de 100 % representan
5V. Esto es válido para los dos modos analógicos anteriores.
Modo RC
Este modo permite la conexión directa a un receptor de radio control

estándar. La mayorı́a de los receptores comerciales trabajan con un paquete
de baterı́as de 4.8 a 6V y pueden ser proporcionados por los mismos 5V de
la alimentación del MD03. El pulso de control del receptor debe conectarse
al terminal SDA. El terminal SCL no se utiliza, debe conectarse a 0V o a
5V. El cable de alimentación del receptor debe ser conectado a la terminal
de +5V y el cable de tierra a la terminal de tierra del módulo controlador.
La salida del receptor es un pulso alto de 1.5ms de ancho cuando el

joystick está en el centro. El rango varı́a desde 1.1ms hasta los 1.9ms cuando
se mueve la palanca de control. EL rango puede ser desplazado desde su
centro en +-100µs desde 1ms - 1.8ms a 1.2ms - 2ms. El circuito MD03
proporciona un control total en el rango desde 1.1ms hasta los 1.9ms siendo
1.5ms la zona central correspondiente a la parada. Hay una zona muerta de
7µs entorno a la zona central para facilitar la posición de parada. El control
de centrado del radio transmisor deberá ajustarse de forma que el motor
esté parado cuando la palanca de control esté en posición de reposo.
De los 5 modos de operación del MD03, se eligió trabajar con el modo

entrada analógica 0V - 5V, esto debido a que las señales para este contro-
lador serán enviadas por medio de la plataforma de instrumentación virtual
LabVIEW en conjunto con la tarjeta de adquisición de datos USB-6009 de
16
National Instruments, capaces de manejar señales analógicas y digitales re-

queridas en desarrollo de este proyecto, pero esto será tratado con mayor
profundidad en el Capı́tulo 3.
2.3.2. Diseño de una PC de alto rendimiento
Para lograr la autonomı́a de un robot, es necesario integrar una Uni-

dad Central de Procesamiento (CPU) que cuente con las caracterı́sticas es-
pecı́ficas como son: potencia de cómputo, suficiente cantidad de puertos de
expansión y tamaño reducido, permitiendo la instalación de tarjetas de ad-
quisición de datos y sensores necesarios para obtener y procesar datos del
entorno a explorar para programar rutas de movimiento.
En el diseño de la Unidad Central de Procesamiento que controla al HD2

Treaded ATR Tank Robot se deben tener como requerimientos mı́nimos 3
puertos PCI (Expansión FireWire IEEE, adquisición de video, tarjeta de red
inalámbrica), 1 puerto PCI EXPRESS (Tarjeta de video), 4 puertos USB
(Sensores Ultrasónicos, sensor láser, Tarjeta USB-6009 NI) por ello que se
hizo la elección de los siguientes componentes:
Tarjeta madre: GIGABYTE GA-P43-ES3G DDR2 1600FSB

Dual Bios.
Procesador: INTEL CORE 2 DUO E7400 2.8Ghz 1066Mhz 3MB.
Disco Duro: WD 160 GB 7200 RPM SATA II.
Memoria RAM: DDR II KINGSTON HYPERX 2 GB 1066Mhz.
Tarjeta de video: GIGABYTE 8400GS 512 MB PCI-E.
Ventilador de 120 mm.
Unidad lectora/grabadora de DVD.
Fuente de poder: Acteck AF-B500E de 500W
Tarjeta de expansión de puertos FireWire IEEE1394.
Tarjeta de red Wi-FI.
La tarjeta madre [10] es de alto rendimiento y es la que define princi-

palmente los componentes que se le pueden instalar siendo entre los más
17
importantes: el procesador, la memoria RAM y la tarjeta de video ya que

éstos son los componentes clave para tener una buena potencia de cómputo.
Cuenta con suficientes puertos de expansión de memoria (Hasta 16 GB en
RAM DDR2 en 4 módulos), Ranuras de Expansión (1 ranura PCI-E x16,1
ranura PCI-E x1, 5 ranuras PCI), Interfaz de almacenamiento (6 x SATA
3Gb/s), 1 Conector IDE ATA-133/100/66/33 (hasta 2 dispositivos IDE), 1
conector de disquetera y hasta 12 puertos USB 2.0/1.1, vease Figura 2.5.
Figura 2.5: Tarjeta madre GIGABYTE GA-P43-ES3G.
Es importante resaltar que la tarjeta madre, el procesador, la memoria

RAM y la tarjeta de video son compatibles en cuanto a transferencia de datos
ya que todos trabajan a 1066MHz, lo cual permite tener alta velocidad al
cargar datos, programas y procesos en el sistema operativo.
Adicionalmente se integró al sistema una tarjeta de expansión de puertos

FireWire IEEE 1394 para la adquisición de video desde cámaras de alta
resolución y una tarjeta de red Wi-FI como una opción de comunicación
inalámbrica desde otra PC u otro dispositivo con esta tecnologı́a.
18
2.4 Diseño de un gabinete para un CPU
2.4. Diseño de un gabinete para un CPU
Con el fin de proteger el CPU contra factores como la presencia de hu-

medad y polvo, el movimiento o conexión y desconexión de los componentes
durante el funcionamiento, la presencia de señales de voltaje ajenas a la
unidad, etc., se debe contar con un gabinete lo suficientemente resistente a
estos factores.
Una de las caracterı́sticas importantes a tomar en cuenta para el diseño

del gabinete de un CPU para un robot es que este debe ser acoplado a las
dimensiones del robot de modo que no muestre ser un inconveniente para
la operación de movimiento y que permita contener todos los componentes
seleccionados para conformar esta PC.
2.4.1. Diseño en Autodesk Inventor
Para tener una idea clara del diseño e instalación del gabinete de la PC
en el robot, se utilizó el programa Autodesk Inventor que es un sistema
de diseño mecánico en 3D para el modelado de piezas sólidas, las cuales
están basadas por lo general en bocetos (Sketch), a los que se le aplica una
operación para la generación del sólido.
Después de haber determinado la posición que tendrá cada uno de los

componentes y obtener las dimensiones de la PC con estos componentes ya
en conjunto, se procedió a realizar un diseño en 3D para visualizar fácilmente
la instalación de éste en el robot, ver Figura 2.6.
En la siguiente imagen, Figura 2.7, donde se muestran las diferentes

vistas que tiene nuestro diseño, podemos apreciar que en la parte superior
del gabinete tiene un par de puertas que nos permiten el acceso al interior
de éste para instalar o desinstalar componentes.
Una vez obtenido el modelado 3D en Autodesk Inventor, las medidas de

las vistas a frontal, trasera, laterales y superior (puertas) se pasaron al for-
19
2.4 Diseño de un gabinete para un CPU
Figura 2.6: Diseño del gabinete en 3D.
mato del software de dibujo CorelDRAW para mandar cortar estas piezas
en material acrı́lico con láser a un taller de corte y grabado de acrilico ya
que su equipo maneja este formato de dibujo. Posteriormente se procedió a
armar y pegar todas las piezas. Cabe resaltar que se utilizó el material acrı́li-
co ya que por su transparencia y su estética permite visualizar el estado de
los componentes ası́ como errores de conexión en circuitos a simple vista,
ver Figura 2.8. A pesar de que el gabinete de acrı́lico es lo suficientemente
resistente y útil para aplicaciones en entornos interiores y exteriores relati-
vamente planos, una vez asegurado el correcto funcionamiento de la PC ante
las pruebas con los sensores, tarjetas y el movimiento del robot, es recomen-
dable construir un gabinete de aluminio del mismo tipo del robot ya que
ası́ se proporcionará una mayor protección en terrenos más hostiles, trabajo
20
2.5 Diseño de la unidad de potencia
Figura 2.7: Diferentes vistas del gabinete en 3D.
que se dejará a futuro debido al alto costo y al largo tiempo de manufactura

de este material.
2.5. Diseño de la unidad de potencia
Como todo sistema electrónico, el robot HD2 Treaded ATR Tank Ro-
bot requiere de una unidad de potencia que proporcione la alimentación al
sistema.
Originalmente el HD2 Treaded ATR Tank Robot cuenta con un banco

de baterı́as que es una red de baterı́as recargables de 24VCD 10000 mAhr
Ni-MH. Debido a la ausencia del módulo de recarga de este tipo de baterı́as,
estas fueron reemplazadas paulatinamente por un par de baterı́as de áci-
do (selladas) de 12VCD 12000 mAhr en serie, éstas son recargadas con un
módulo de carga automotriz (carga lenta). Se integró un inversor de volta-
21
2.5 Diseño de la unidad de potencia
Figura 2.8: Gabinete ensamblado.
je CD-CA obteniendo como salida 115 VCA necesarios para alimentar la

Unidad Central de Procesamiento.
En este Capı́tulo vimos las caracterı́sticas principales de los robots de

ruedas y los tipo oruga resaltando las ventajas y desventajas que diferencian
uno del otro. También se mencionaron las caracterı́sticas fı́sicas y de control
de motores del robot HD2 Treaded ATR Tank. En el Capı́tulo 3 veremos
el proceso de instalación e instrumentación de sensores y uso de tarjetas de
adquisición de datos con el objeto de tener una unidad con herramientas
suficientes para controlar el movimiento del robot ası́ como recolectar infor-
mación del entorno lo cual complementará sustancialmente este trabajo.
22
Capı́tulo 3
Instrumentación del sistema
En el Capı́tulo 2, se mencionaron las ventajas y desventajas de los robots

tipo oruga, también se abarcó el estudio de las caracterı́sticas fı́sicas y de
control del HD2 Treaded ATR Tank, además de contemplar el diseño de la
Unidad Central de Procesamiento y del sistema de potencia.
En este Capı́tulo se trata la instrumentación de sensores y cámaras bajo

el sistema operativo Linux instalado en la PC del robot en base a la compa-
tibilidad y estabilidad de éste para trabajar con los controladores de éstos,
se incluye el tema de instrumentación virtual bajo la plataforma LabVIEW
versión Linux ası́ como el trabajo con tarjetas de adquisición de datos de la
National Instruments.
3.1. Instrumentación
En términos generales cuando se habla de instrumentación, se refiere

al acondicionamiento y procesamiento de datos provenientes de variables
fı́sicas y quı́micas percibidas por uno o varios elementos sensores para el
control y monitoreo de procesos con la finalidad de optimizar recursos en
diversas aplicaciones. En la Figura 3.1 se observa cada una de las etapas de
la instrumentación de cualquier sensor.
23
3.1 Instrumentación
Figura 3.1: Sistema de Adquisición de Datos.
24
3.1 Instrumentación
Generalmente concluir cada una de las etapas mostradas en la Figura

3.1, implica el diseño y armado de circuitos ası́ como crear una interfaz para
visualizar los datos fı́sicos ya sea desde una PC, un DSP o un FPGA.
Existe una opción muy sofisticada que permite realizar la instrumenta-

ción de sensores sin tener que darse a la tarea de diseñar circuitos fı́sicos
complejos para obtener el acondicionamiento de la señal, esto se hace uti-
lizando algún software que hoy conocemos como plataforma de Instrumen-
tación Virtual, siendo una de las más importantes aquella que desarrollo
la firma National Instruments, esta plataforma tiene por nombre LabVIEW
cuyo uso forma parte de este proyecto de tesis.
Hoy en dı́a la mayorı́a de sensores industriales de alta calidad y precisión

ya cuentan con un circuito interno que realiza cada una de las etapas de ins-
trumentación restando al usuario conectar el sensor a la PC para establecer
la comunicación y realizar programas en base a la codificación de los datos
recibidos por el sensor.
Debe resaltarse que la calidad de procesamiento de datos en la PC no

sólo está dada por su hardware, sino también depende del sistema operativo
en el que se trabaja. Los sistemas operativos más conocidos son:
Windows, un S.O. comercial que destaca por dominar el mercado de

las PC’s y ser muy amigable con el usuario
Mac OS, un S.O. flexible con una interfaz gráfica muy agradable, tiene
la ventaja de que existen pocos virus para atacar este sistema.
GNU/Linux, un S.O que muestra ser uno de los ejemplos mas promi-
nentes de software libre.
En la Figura 3.2 observamos la gráfica de la estimación del uso de siste-

mas operativos en computadoras con acceso a Internet [6].
En el presente proyecto es trabajado bajo el S.O. GNU/Linux para apro-

vechar las ventajas de tener un software libre, estable y eficiente.
25
3.2 Sistema operativo GNU/Linux: OpenSUSE
Figura 3.2: Estimación del uso de Sistemas Operativos.
3.2. Sistema operativo GNU/Linux: OpenSUSE
Linux [13] es un sistema operativo en versiones de 32 y 64 bits que puede

ser usado sobre cualquier plataforma de hardware de cómputo. Se caracte-
riza por ser muy estable, seguro y flexible. Es utilizado en PC’s, Estaciones
de Trabajo, servidores, direccionadores, y prácticamente en cualquier pla-
taforma de cómputo. Trabaja bien sobre todos estos entornos ya que es
multiusuario y puede realizar cualquier grupo de tareas de manera rápida y
eficiente. Linux es tan poderoso como cualquier otro sistema operativo pero
a comparación de otros éste es gratuito.
3.2.1. Concepto GNU/GPL
La disponibilidad del kernel de Linux es diferente a la del kernel de

Unix y del kernel de Windows por que es distribuido bajo GNU General
Public License (GPL). Esta licencia permite que el código fuente sea libre-
mente distribuido y disponible para el público en general, usualmente por
26
3.2 Sistema operativo GNU/Linux: OpenSUSE
vı́a internet. GNU GPL también significa que cualquier persona que reciba
el software, incluso si se cobra por ello, está protegido por la Licencia Públi-
ca General GNU para tener las mismas capacidades para hacer cambios y
distribuir el software. La GPL de GNU garantiza que ninguna persona u
organización puede realizar un cambio en el kernel sin hacer estos cambios
a disposición del público.
3.2.2. Distribuciones de Linux
Cuando se habla de kernel, se refiere al núcleo del sistema operativo,

el cual proporciona al software acceso al hardware. Dado que el kernel se
utiliza para acceder al hardware es actualizado a menudo para proporcionar
o mejorar la compatibilidad con las nuevas tecnologı́as.
Debido a la naturaleza de Open Source (código abierto) del kernel de

Linux, que permite a cualquiera modificar o mejorar el núcleo de base con
otro software, Linux está disponible en una amplia variedad de distribucio-
nes: BlueCat, Caldera OpenLinux, Debian, Corel, DragonLinux, Elfstone,
Gentoo, Hard Hat Linux, KRUD, LinuxPPC, Mandrake/Mandriva, Phat
Linux, Red Hat, Slackware, StormLinux, SuSE, TurboLinux, Yellow Dog
Linux, Ubuntu, Fedora, OpenSUSE, Scientific Linux.
Para introducirse al entorno Linux, en este proyecto se probaron varias

versiones: Ubuntu, Scientific Linux, Fedora y OpenSUSE.
Para elegir una distribución adecuada para el sistema del robot, se tomó en
consideración los requisitos del hardware y software, ası́ como la estabilidad
del kernel para la integración de sensores. Bajo estos requisitos se optó por
la instalación de OpenSUSE 11.0 que opera bajo el kernel 2.6.25.5, uno
de los más estables de Linux, caracterizado por tener compatibilidad con
tecnologı́as de hardware y software actuales.
En este proyecto la instalación de software adicional es dependiente de

los requisitos de cada herramienta necesaria para la instrumentación del
27
3.3 Instrumentación virtual: LabVIEW
robot.
3.3. Instrumentación virtual: LabVIEW
LabVIEW [15] es una plataforma de programación gráfica orientada a

la instrumentación desarrollada por National Instruments (NI) que trabaja
con la conexión y desconexión de bloques que contienen funciones para pro-
cesar datos obtenidos de la comunicación de sensores o sistemas externos a
través de los puertos de la PC o por medio de Tarjetas de Adquisición de
Datos (DAQ). Una de las caracterı́sticas principales de LabVIEW es que
su velocidad de trabajo es comparable con la del lenguaje de programación
C/C++.
Los programas generados en LabVIEW son llamados Instrumentos Vir-

tuales (VIs). Cada VI tiene 3 partes principales:
Panel frontal, visualiza como el usuario interacciona con el VI.

Diagrama de bloque, trabaja el código de control del programa.
Icono/Conector, medio de conexión un VI con otros VIs.
El panel frontal es utilizado para interaccionar con el usuario cuando el

programa esta corriendo. Usuarios pueden controlar el programa, cambiar
entradas, y ver datos actualizados en tiempo real, ver Figura 3.3. Haga
énfasis en que los controles son usados como entradas, ajustando controles
de deslizamiento para colocar un valor de alarma, encendiendo o apagando
un switch, o parando un programa. Los indicadores son usados como salidas.
Termómetros, luces, y otros indicadores muestran los valores del programa.
Esto puede incluir datos, estados de programa u otra información.
Cada control o indicador del panel frontal tiene una terminal correspon-
diente en el diagrama de bloques. Cuando un VI se ejecuta, los valores de
los controles fluyen a través del diagrama de bloques, en donde éstos son
usados en las funciones del diagrama, y los resultados son pasados a otras
funciones o indicadores.
28
Figura 3.3: Panel Frontal de un VI.
El diagrama de bloque contiene el código fuente gráfico. Los objetos del

panel frontal aparecen como terminales en el diagrama de bloque, ver Figura
3.4. Adicionalmente, el diagrama de bloque contiene funciones y estructu-
ras incorporadas en las bibliotecas de LabVIEW VI. Los cables conectan
cada uno de los nodos en el diagrama de bloques, incluyendo controles e
indicadores de terminal, funciones y estructuras.
A partir de LabVIEW 7.0 se introduce un nuevo tipo de subVI llama-

do VIs Expreso (Express VIS). Estos son VIs interactivos que tienen una
configuración de caja de dialogo que permite al usuario personalizar la fun-
cionalidad del VI Expreso. LabVIEW entonces genera una subVI basado en
estos argumentos.
Los VIs estándar son aquellos VIs (que consisten de un panel frontal y
un diagrama de bloque) que son usados adentro de otro VI.
Las funciones son los bloques de construcción de todos los VIs. Las fun-
ciones no tienen un panel frontal o un diagrama de bloque.
29
Figura 3.4: Diagrama de Bloques de un VI.
3.3.1. Adquisición de Datos (DAQ):USB-6009 NI
Para la adquisición de datos en LabVIEW, ver Figura 3.5, se trabaja con

dos plataformas:
NI-DAQ Tradicional, VI’s especı́ficos para realizar:

• Entrada Análoga.
• Salida Análoga.
• I/O (entrada/salida) Digital.
• Operaciones de Conteo.
NI-DAQmx, el driver de la nueva generación:
• VI’s para ejecutar una tarea.
• Una serie de VI’s para todo tipo de mediciones.
Para trabajar con la adquisición de datos en LabVIEW debe seguirse

algunos pasos para configurar la PC:
1. El software NI-DAQ debe estar instalado en la PC (Puede descargarse

de la Página Web de National Instruments [17]).
30
Figura 3.5: Diagrama de instrumentación utilizando una DAQ.
2. Se debe tener instalado el software Measurement & Automation Ex-

plorer (MAX) de NI, éste permite configurar las tarjetas de adqui-
sición de datos de NI y en caso de no contar con alguna de ellas,
permite simular las tarjetas para realizar la configuración antes de
trabajar con ellas.
La plataforma de NI-DAQ cuenta con una herramienta para la confi-

guración rápida de las tarjeta de adquisición de datos, esta herramienta es
conocida como DAQ Assistant, ver Figura 3.6.
La terminologı́a de adquisición de datos implica el control sobre:
Resolución: Determina cuantos cambios de voltajes pueden ser medi-

dos. Una resolución más grande representa una señal más exacta.
Rango: Voltajes mı́nimos y máximos. Un rango mas pequeño deter-
mina una representación más precisa de la señal.
Gain (Ganancia): Amplifica o atenúa la señal para un mejor ajuste de
rango.
31
Figura 3.6: Ventana de configuración DAQ Assistant.
Como se puede observar LabVIEW otorga muchas facilidades para rea-

lizar un trabajo de instrumentación, con estas herramientas puede instru-
mentarse un sensor con un par de click’s para arrastrar y configurar el DAQ
Assistant y realizar las interconexiones necesarias para graficar o mostrar
numéricamente los resultados, ver simple ejemplo en la Figura 3.7. Sin em-
bargo, estas son las caracterı́sticas que tiene la versión para Windows de
LabVIEW.
Existe la versión para Linux de LabVIEW, pero para usarla tenemos

que olvidarnos de la existencia del DAQ Assistant y del Measurement &
Automation Explorer (MAX), pues no están disponibles para este sistema
operativo. Aun ası́ esto no implica que no se puede usar una tarjeta de
adquisición de datos en Linux, simplemente quiere decir que será un poco
más complicado.
32
Figura 3.7: Ejemplo de instrumentación de un sensor de temperatura con

DAQ Assistant.
Después de una búsqueda exhaustiva se confirmó la existencia de los

controladores de adquisición de datos: NI-DAQ base y NI-DAQmx (también
disponibles para Windows), pero éstos no son aún compatibles con todos
los modelos de tarjetas DAQ, por suerte, el controlador NI-DAQ base es
compatible con la tarjeta DAQ USB-6009 NI, siendo ésta la que se trabaja
en el desarrollo de este proyecto.
Las caracterı́sticas principales de la DAQ USB-6009 [16] NI son:
8 entradas analógicas (14 bits, 48 KS/s), ±20 V modo diferencial.

2 salidas analógicas (12 bits, 150 S/s), de 0 a 5 Volts de salida.
12 I/O digitales
Contador de 32 bits
Tiene protección contra sobrevoltaje hasta los ±35 V.
Para instalar LabVIEW ası́ como los controladores NI-DAQ base en Li-
nux es requerido el kernel 2.6.2 por ser uno de los más estables, ya que otros
kernel demostraron incompatibilidad con el mal funcionamiento del progra-
33
ma, en algunos ni siquiera permitı́a la instalación. La razón de estas incom-

patibilidades es por que este software fue desarrollado bajo el kernel 2.6.2
por lo que otra versión de kernel requerirı́a un recompilación del programa
o hacer modificaciones en el kernel para lo cual es requerido conocimientos
avanzados en Linux.
La manera de sustituir el DAQ Assistant en Linux es mediante la progra-

mación manual de adquisición de datos utilizando los controladores NI-DAQ
base, esto es que en vez de usar un solo bloque para leer un dato de la tarjeta
DAQ, se usará un mı́nimo de 8 bloques para realizar esa misma lectura, ver
Figura 3.8.
Figura 3.8: Lectura de un dato utilizando NI-DAQ base.
Aparentemente se puede pensar que por ser un mayor número de bloques

sera más tardado el proceso de lectura/envı́o de datos por la tarjeta DAQ
pero resulta ser lo contrario. Para hacer la lectura de un dato, DAQ Assistant
inicia la comunicación con la tarjeta y la termina por cada dato leı́do, y hace
este proceso hasta que el usuario indica que se detenga. La programación con
el NI-DAQ base como se muestra en la Figura 3.8 inicia con la comunicación,
luego se mantiene leyendo datos hasta que el usuario indica que se detenga,
34
3.4 Instalación de cámaras de alta resolución
IEEE 1394
es entonces que termina la comunicación con la tarjeta DAQ. Esto permite

ahorrar el tiempo de inicio y término de comunicación por cada dato.
Como se menciona en el Capı́tulo 2, el control de motores del robot

HD2 Treaded ATR Tank Robot estará determinado por el modo de entrada
analógica 0V -5V en la entrada SDA y enviando una señal digital para el
cambio de dirección en la entrada SCL del módulo MD03. Es fácil darse
cuenta que estas señales pueden ser proporcionadas por la tarjeta USB-
6009 NI mediante la programación de algún algoritmo en LabVIEW de
variación de voltaje de 0V a 5V por las salidas analógicas para incremento
o decremento de velocidad y enviando una señal digital por el puerto I/O
para cambio de dirección.
3.4. Instalación de cámaras de alta resolución

IEEE 1394
El Firewire fue desarrollado por Apple Computer a mediados de los 90,

para luego convertirse en el estándar multiplataforma IEEE 1394.
FireWire 400 (1995), tiene un ancho de banda de 400 Mbit/s, 30 veces

mayor a USB 1.1 (12 Mbps) y similar a USB 2.0 (480 Mbps), en
pruebas realizadas FireWire completó el proceso con un 33 % más de
velocidad que USB 2.0, debido a su arquitectura peer-to-peer mientras
USB utiliza slave-master.
En 2000 se implementó una revisión de IEEE 1394, añadiéndole ca-
racterı́sticas como difusión ası́ncrona, una reconfiguración de bus más
rápida, concatenación de paquetes, y ahorro de energı́a en modo sus-
pensión.
FireWire 800 (2000), Duplica aproximadamente la velocidad del Fire-
Wire 400, hasta 786.5 Mbps con tecnologı́a full-duplex.
FireWire s800T (2007), aporta mejoras técnicas que permite el uso
de FireWire con puertos RJ45 sobre cable CAT 5, combinando ası́ las
ventajas de Ethernet con Firewire800
35
3.4 Instalación de cámaras de alta resolución
IEEE 1394
FireWire s1600 y s3200 (2008), permiten un ancho de banda de 1’6 y

3’2 Gbit/s, cuadruplicando la velocidad del Firewire 800.
Instalar una tarjeta de expansión de puertos FireWire IEEE 1394 en un

slot PCI es tarea fácil ya que Linux ha demostrado una completa compatibi-
lidad con los puertos de expansión PCI. La tarjeta de expansión de puertos
FireWire instalada en la PC del robot cumple con el estándar IEEE 1394-
1995 revisión 1.1 (en el año 2000) proporcionandonos una transferencia de
datos ası́ncronos e isócronos a 100/200/400Mbit/s.
Debido a la alta velocidad del puerto FireWire, hace que sea la inter-
faz más utilizada para audio y vı́deo digital. Instalar una cámara de alta
definición en este puerto en el sistema del robot no es ningún problema ya
que el kernel 2.6.2 de Linux es muy estable y basta con conectar los cables
de la cámara al puerto y usar algún programa de video para IEEE 1394,
siendo los más comunes el coriander, o el dvgrab por mencionar algunos.
Otra opción para permitir un buen funcionamiento de camaras es instalar
las librerı́as de la interfaz 1394 y programar a gusto propio un algoritmo
para la adquisición de video.
La integración de video de alta definición al sistema del robot proporcio-

na una gran herramienta para fines de exploración brindando la capacidad
de trabajar con algoritmos de visión por computadora y trabajar en las
siguientes áreas:
Sensado: Es el proceso que lleva a la obtención de una imagen visual.

Preprocesamiento: Trata de técnicas de reducción de ruido y enrique-
cimiento de detalles en la imagen.
Segmentación: Es el proceso que particiona una imagen en objetos de
interés.
Descripción: Trata con el cómputo de caracterı́sticas útiles para dife-
renciar un tipo de objeto de otro.
Reconocimiento: Es el proceso de identificación de objetos.
Interpretación: Asigna un significado a un conjunto de objetos reco-
nocidos.
36
3.5 Integración de sensores ultrasónicos
3.5. Integración de sensores ultrasónicos
Un sensor ultrasónico mide la distancia empleando un transductor que

emite paquetes de ultrasonido que contienen una serie de ondas sonoras
intermitentes. El paquete se emite en forma cónica, se rebota o refleja en la
superficie objetivo siendo recibida al regreso en un transductor. El tiempo
requerido por el sonido para ir y volver se mide y se convierte a unidades de
distancia. Existen varios factores que afectan la medición (Ver Figura 3.9),
a saber:
El tipo de superficie.
Tamaño del objetivo.
Distancia del objetivo.
Ángulo del cono sobre la superficie.
También afectan las condiciones ambientales: Temperatura, gases, va-
pores, presión, etc.
El patrón del haz producido por el sensor se expresa en número de gra-

dos que el haz se separa de la lı́nea central del sensor. El haz se desparrama
con un patrón cónico a partir del transductor y aunque continúa despa-
rramándose, el área de detección empieza a acortarse respecto al rango de
operación publicado.
El área de sensado se ve afectada por el número de pulsos enviados por el

sensor y por el nivel de sensibilidad. A un nivel alto de pulsos y sensibilidad
hay mayor superficie que a niveles bajos, ver Figura 3.10.
3.5.1. Sensor ultrasónico de distancia SRF02
El SRF02 [7] es un medidor ultrasónico de distancia, ver Figura 3.11, fun-

ciona mediante un solo transductor. Entre las caracterı́sticas más destacadas
se encuentra el hecho de utilizar un único transductor tanto para transmitir
la ráfaga ultrasónica como para recibir el eco de la misma para poder medir
37
Figura 3.9: Factores que afectan la medición de un sensor ultrasónico.
la distancia. Esta caracterı́stica hace que la distancia mı́nima medida sea

mayor que la de otros medidores que utilizan dos transductores diferentes.
La distancia mı́nima que es capaz de medir es alrededor de 15cm (6”). El
SRF02 puede medirse en unidades de µs, cm o pulgadas. Este medidor per-
mite comunicaciones serie e I2C, con un total de 16 dispositivos diferentes
en ambos modos. Ya que los niveles de tensión son TTL se pueden conectar
directamente con la UART de cualquier microcontrolador. El SRF02 tiene
nuevos comandos que permiten enviar ráfagas ultrasónicas sin medir el eco
recibido y medir el eco sin haber enviado los impulsos previamente.
Para seleccionar el modo I2C deberá dejar sin conectar el Pin Modo
38
Figura 3.10: Área de sensado ultrasónico.
Figura 3.11: Sensor ultrasónico SRF02.
39
del SRF02. El Pin SDA corresponde a la señal de datos y el Pin SCL a la

señal de reloj. Ambas señales se deben polarizar a +5Vcc a través de dos
resistencias de polarización positiva que normalmente se encuentran en el
circuito maestro del bus I2C que controla los dispositivos I2C esclavos, ver
Figura 3.12. Esto quiere decir que sólo son necesarias dos resistencias en
todo el bus.
Figura 3.12: Pines de control del SRF02.
La dirección I2C del medidor SRF02 por defecto es 0xE0 pero puede
elegir cualquiera de las otras 16 siguientes para conectar otros sensores:
0xE0, 0xE2, 0xE4, 0xE6, 0xE8, 0xEA, 0xECC, 0xEE, 0xF0, 0xF4, 0xF6,
0xF8, 0xFA, 0xFC, 0xFE.
RF02 está compuesto por un juego de 6 registros, véase Tabla 3.1.
Registros Modo de lectura Modo de Escritura

0 Revisión de software interno Registros de comandos
1 No usado (se lee 0x80) No disponible
2 Byte alto de medida realizada No disponible
3 Byte bajo de medida realizada No disponible
4 Byte alto de valor mı́nimo de distancia No disponible
5 Byte bajo de valor mı́nimo de distancia No disponible
Tabla 3.1: Registros del SRF02.
En la Tabla 3.2 se describe los comandos necesarios para trabajar con el

SRF02.
40
Comandos Descripción
0x50 Iniciar nueva medición real (pulgadas)
0x51 Iniciar nueva medición real (centı́metros)
0x52 Iniciar nueva medición real (microsegundos)
0x56 Iniciar nueva medida falsa (pulgadas)
0x57 Iniciar nueva medida falsa (centı́metros)
0x58 Iniciar nueva medida falsa (microsegundos)
0x5C Transmite una ráfaga de 8 ciclos de 40khz
(no hace cálculos de medición)
0x60 Fuerza un reinicio del sonar SRF02
realizando un ciclo de autoajuste.
0xA0 1o comando de secuencia para cambio de dirección I2C
0xA5 3o comando de secuencia para cambio de dirección I2C
0xAA 2o comando de secuencia para cambio de dirección I2C
Tabla 3.2: Comandos del SRF02.
Para realizar un cálculo de medición se debe escribir un comando de los

de arriba sobre el registro de comandos y esperar un tiempo (aprox. 66 ms)
para poder leer los registros 2 y 3 y obtener el cálculo completo.
Para cambiar la dirección I2C del SRF02 es necesario tener conectado

sólo un circuito en el bus. Debe escribirse la secuencia de los 3 comandos en
el orden correcto seguido de la nueva dirección que se le quiere poner. Por
ejemplo, para cambiar la dirección por defecto de (0xE0) a la (0xF2) debe
escribir la siguiente secuencia: 0xA0, 0xAA, 0xA5, 0xF2.
En este proyecto se hizo la instalación de un sistema de sensores ul-

trasónicos SRF02 controlados con el protocolo I2C cuyo esquema de funcio-
namiento fue desarrollado por Carlos Ortiz López [18] en su tesis de licen-
ciatura. La conexión del sensor SRF02 a un PC se realiza con la ayuda del
circuito USBI2C S310425, que es un circuito interfaz que convierte señales
USB en señales de bus I2C.
41
3.6 Instalación del sensor Laser Range Finder 2D
3.6. Instalación del sensor Laser Range Finder 2D
Un Laser Range Finder 2D proporciona un haz que es proyectado en un

plano, estos sensores son cada vez más comunes en aplicaciones de robótica
debido a su gran resolución y a los datos generados a alta frecuencia.
El principio de medición de distancia del range finder se basa en el cálculo

de la diferencia de fase, debido a que es posible obtener medidas estables
con mı́nima influencia del color del objeto y de la reflexión.
3.6.1. Hokuyo UBG-04LX-F01
En la presente tesis se trabaja con el sensor Range Finder 2D Hokuyo

UBG-04LX-F01 [11], ver Figura 3.13, que es un sensor láser para explora-
ción de áreas. La fuente de luz del sensor es de láser infrarrojo de 785 nm
de longitud de onda de clase 1 de seguridad. Clase 1 se refiere a sistemas
de láseres que bajo condiciones normales de operación no producen riesgo
(Potencia de salida menor a 1µW).
El UBG-04LX-F01 tiene un área de exploración que va desde los 20 mm

hasta 5600 mm en un rango de 240◦ . Su resolución angular es de 0.36◦ obtiene
una medición de distancia por paso (682 pasos), ver Figura 3.14.
3.6.2. Protocolo SCIP2.0 para sensores Láser
La comunicación con el sensor UBG-04LX-F01 es establecida por medio

del protocolo SCIP2.0 [12] desarrollado por el grupo de investigación de in-
terfaz de sensores (Intelligent Robot Laboratory, University of Tsukuba) con
el fin de proporcionar flexibilidad y eficacia de la interconexión de sensores
para aplicaciones de robótica.
El sensor está equipado con RS232C y USB para la interfaz con un dispo-
sitivo externo (PC). La comunicación puede hacerse a través de cualquiera
42
Figura 3.13: Sensor Hokuyo UBG-04LX-F01.
Figura 3.14: Rango de detección Hokuyo UBG-04LX-F01.
43
de estos canales. Si se conectan las dos interfaces del sensor con la PC la co-
nexión USB tendrá prioridad. También es posible pasar de la conexión USB
y RS232C conectado y desconectando el cable USB en el lado del sensor,
incluso cuando el sensor está funcionando.
USB tiene la clase de comunicación de dispositivos (CDC) estándar

con su configuración similar a la RS232. Los programas desarrollados pa-
ra RS232C también puede ser utilizados para USB.
Cuando se utiliza la conexión USB, el puerto sólo se abrirá después

de que el sistema operativo asigna el número del dispositivo. El acceso al
dispositivo de la aplicación debe realizarse sólo cuando la configuración de
la PC se completa y reconoce el dispositivo. En Linux este proceso dura de
8 a 10 segundos.
Dirección de medición y puntos de datos
La Figura 3.15 muestra detalles de medición del sensor. El escaner se

gira en sentido contrario a las manecillas del reloj. Rango de detección (E)
es el ángulo máximo de medición del sensor (240◦ ). Resolución angular se
define como 360 grados dividido entre la División de hendidura (F).
Los puntos de medición son llamados Pasos. Paso 0 es el primer punto

de medición. Paso A es el punto de medición inicial en el rango de detección.
Paso B es el escalón de entrada del sensor. Paso C es el punto final del rango
de detección. Paso D es el último punto de medición. La Tabla 3.3 muestra
los parámetros de medición del UBG-04LX-F01.
Codificación de datos
Los datos del sensor son codificados para reducir el tiempo de transmisión
entre la PC y el sensor. Estos datos deben ser decodificados en la PC antes
de ser procesados. Hay tres tipos de técnicas de codificación aplicadas en el
44
Figura 3.15: Parametros de medición del Laser UBG-04LX-F01.
UBG-04LX-F01
Paso 0 Primer punto de medición 0
Paso A Paso inicial de medición en el rango de detección 44
Paso B Paso frontal del sensor 384
Paso C Punto final en el rango de detección 725
Paso D Último punto de medición 768
E Rango de detección 239.77
F División de hendidura 1024
Tabla 3.3: Parametros de medición del Laser UBG-04LX-F01.
45
sensor en función del tamaño de los datos:
1. Codificación de dos caracteres. Esta técnica de codificación se aplica

para expresar los datos que tengan una longitud máxima de 12 bits.
La codificación es realizada por la separación de datos en la parte su-
perior e inferior de 6 bits y, a continuación se suma 30h para convertir
en caracteres ASCII.
2. Codificación de tres caracteres. Esta técnica de codificación se aplica
para expresar los datos que tengan una longitud máxima de 18 bits.
La codificación es realizada por la separación de datos en la parte
superior, media e inferior en 6 bits y, a continuación se suma 30h
para convertir en caracteres ASCII.
3. Codificación de cuatro caracteres. Se aplica para expresar los datos
que tengan una longitud máxima de 24 bits. La codificación es reali-
zada por la separación de datos en cuatro partes, cada una de 6 bits,
y luego se suma 30h para convertir en caracteres ASCII.
En la Figura 3.16 y la Figura 3.17 se muestra un ejemplo de codificación

y decodificación de 4 caracteres. El sensor y la PC intercambian datos
Figura 3.16: Codificación de 4 caracteres.
usando comandos predefinidos. Estos comandos tienen un formato especı́fico

conocido como protocolo de comunicación, ver Figura 3.18.
Command Symbol, es código de 2 bytes en el inicio de cada comando.

Cada comando tiene sı́mbolos especı́ficos.
String Characters, es información opcional en el comando. Son usados
46
Figura 3.17: Decodificación de 4 caracteres.
Figura 3.18: Protocolo de comunicación en SCIP2.0.
47
para verificar la respuesta cuando usamos el mismo comando repetido

más de una vez, permitiendo checar por cada comando enviado un
comando de respuesta.
Avance de linea (LF) y Retorno de carro (CR), indican el termino del
código.
Status, es un dato de 2 bytes en la respuesta que indica procesamiento
normal si el comando es autentificado y errores si esta indefinido,
comando inválido o recibido por el sensor. Estados del 00 al 99 son
errores de código.
SUM, es un dato de un byte usado para la autentificación. Es calculado
por suma de datos entre 2 LF, tomando los 6 bytes más bajos de la
suma y agregando 30H.
DATA, es la información principal relacionada con el comando. Es
separada por LF y suma después de cada 64 bytes si excede 64 bytes.
Comandos del Sensor
Comando MD-MS. Este es un comando para adquisición de datos del

sensor. Siempre que el sensor recibe este comando este transmite el eco
con el estado 00 seguido por la respuesta teniendo los datos medidos
que tomara después de que el comando sea recibido. El láser conmuta a
ON automáticamente antes de la medición y conmuta a OFF después
completar el número de escaneos definidos en el comando.
Comando GD-GS. Siempre que el sensor recibe este comando está su-
ministrando los últimos datos medidos a la PC. Si el láser es conmuta-
do a OFF, éste será conmutado a ON mediante el envı́o del comando
BM antes de la medición. El láser debe conmutar a OFF por medio
del comando QT despues de haber sido completada la medición.
Comando BM. Este comando iluminara el sensor láser habilitando la
medición. El estado del láser puede ser verificado por el LED verde en
el sensor. El láser no esta en uso si el LED parpadea rápidamente y
éste se encuentra en encendido cuando el LED brilla continuamente.
Comando QT. Este comando conmutara a OFF el láser deshabilitando
el estado de medición del sensor.
48
Comando RS. Este comando reiniciara toda configuración que se haya

cambiado después de que el sensor fue conmutado a ON.
Comando TM. Este comando es usado para sincronizar los tiempos
de la PC y el sensor.
Comando SS. Este comando cambiará la velocidad de bits de comu-
nicación del sensor cuando esté conectado por RS232.
Comando CR. Este comando es usado para ajustar la velocidad del
motor del sensor. Cuando se usan múltiples sensores en el mismo en-
torno, sus motores pueden ser obligados a correr a diferentes veloci-
dades para evitar interferencia con la luz utilizando este comando.
Comando HS. Este comando conmutará entre los modos de sensibili-
dad alta y sensibilidad normal. La capacidad de detección del sensor
incrementara sobre un 20 % en el modo de alta sensibilidad. Sin em-
bargo, puede tener error de medición debido a la fuerte reflexión de
objetos cercanos.
Comando DB. Este comando simulará el mal funcionamiento del sen-
sor.
Comando VV. El sensor transmite detalles de versión como, número
de serie, versión firmware etc.
Comando PP. El sensor transmite sus especificaciones al recibir este
comando.
Comando II. El sensor transmite su estado de ejecución al recibir este
comando.
Todos los comandos mencionados anteriormente tienen una gran impor-

tancia, pero es claro que los comandos que nos van a proporcionar los datos
de medición del láser son los comandos MD-MS y GD-GS.
El fabricante ya proporciona un software llamado “Vmon.exe” donde

muestra mediante una gráfica de coordenadas polares los ángulos y distan-
cias a las que se encuentran los objetos dentro del rango de detección del
láser, ver Figura 3.19, pero este software es sólo para el S.O. Windows.
49
Figura 3.19: Software Vmon.exe en Windows.
3.6.3. Programación en C/C++ para la comunicación con el

Láser Range Finder
Para leer datos del láser en Linux hay que descargar las librerı́as de
código C o C++ que proporciona el fabricante en su página WEB [1], estas
librerı́as proporcionan funciones para comunicación y adquisición de datos
del láser basándose en los comandos del protocolo SCIP2.0. Una vez obte-
nidas estas librerı́as se puede generar código en C/C++ para obtener los
datos del láser y detectar obstáculos.
Los datos medidos pueden ser visualizados en la terminal de Linux ejecu-

tando la aplicación generada por el código C mediante la instrucción ./Nom-
breDeLaAplicación. Sin embargo, para tener una visión más clara de lo que
se está midiendo los datos son graficados en coordenadas polares mediante
el uso de las librerı́as de OpenGL.
50
A continuación se muestra el código utilizado para la lectura de datos

medidos por el láser UBG-04LX-F01:
#include ” u r g c t r l . h”
#include <s t d i o . h>
#include <s t d l i b . h>
#include<math . h>
#include<GL/ g l u t . h>
#include ” G r a f i c a D a t . h”
#define DEG2RAD M PI / 1 8 0 . 0
#define rad 6 0 0 0 . 0
i n t xx , yy ;
float esc =1.5;
long ∗ data ; // E s t e a r r e g l o almacena l o s d a t o s de medi ci on o b t e n i d o s

int i ;
i n t n ; //Numero maximo de p a s o s
s t a t i c void u r g e x i t ( u r g t ∗ urg , const char ∗ message )

{
p r i n t f ( ” %s : %s \n” , message , u r g e r r o r ( urg ) ) ;
u r g d i s c o n n e c t ( urg ) ;
#i f d e f MSC
getchar ( ) ;
#endif
exit (1);
}
i n t main ( i n t argc , char ∗ argv [ ] )

{
i n t data max ;
i n t timestamp ;
int r e t ;
#i f d e f WINDOWS OS
const char d e v i c e [ ] = ”COM3” ; // En Windows
#e l s e
const char d e v i c e [ ] = ” / dev /ttyACM0” ; // En Li nux
#endif
// Conexion d e l l a s e r
u r g t urg ;
r e t = u r g c o n n e c t (&urg , d e v i c e , 1 1 5 2 0 0 ) ;
i f ( r e t < 0) {
u r g e x i t (&urg , ” u r g c o n n e c t ( ) ” ) ;
}
// R e s e r v a r e s p a c i o para d a t o s
data max = urg dataMax(&urg ) ;
data = ( long ∗ ) m a l l o c ( s i z e o f ( long ) ∗ data max ) ;
51
i f ( data == NULL) {
p er r or ( ” malloc ” ) ;
exit (1);
}
// S o l i c i t a r d a t o s medi ante l a i n s t r u c c i o n GD
r e t = u r g r e q u e s t D a t a (&urg , URG GD, URG FIRST , URG LAST ) ;
i f ( r e t < 0) {
u r g e x i t (&urg , ” u r g r e q u e s t D a t a ( ) ” ) ;
}
// Recepci on de d a t o s
n = u r g r e c e i v e D a t a (&urg , data , data max ) ;
p r i n t f ( ”# n = %d\n” , n ) ;
i f ( n < 0) {
u r g e x i t (&urg , ” u r g r e c e i v e D a t a ( ) ” ) ;
}
// Mostrar d a t o s en c o n s o l a y en OpenGL
timestamp = u r g r e c e n t T i m e s t a m p(&urg ) ;
p r i n t f ( ”# timestamp : %d\n” , timestamp ) ;
f o r ( i = 4 4 ; i < n ; ++i ) {
p r i n t f ( ” %d %ld , ” , i , data [ i ] ) ;
}
p r i n t f ( ” \n” ) ;
// i n i c i a l i z a r G r a f i c a n d o
g l u t I n i t (& argc , argv ) ;
g l u t I n i t D i s p l a y M o d e (GLUT DOUBLE | GLUT RGB ) ;
glutInitWindowSize ( 700 ,700) ;
glutInitWindowPosition ( 100 ,100) ;
glutCreateWindow ( ” L a s e r Hokuyo−LABICE” ) ;
init ();
glutDisplayFunc ( d isp lay ) ;
glutCreateMenu ( MenuOpciones ) ;
glutAddMenuEntry( ”Zoom In ” , 1 ) ;
glutAddMenuEntry( ”Zoom Out” , 2 ) ;
glutAttachMenu (GLUT RIGHT BUTTON ) ;
u r g d i s c o n n e c t (&urg ) ;
#i f d e f MSC
getchar ( ) ;
#endif
glutMainLoop ( ) ;
f r e e ( data ) ;
return 0 ;
}
En la Figura 3.20, se muestra el diagrama de flujo del programa de

operación para la comunicación entre el sensor y la PC.
52
Figura 3.20: Diagrama de flujo del programa para el sensor.
53
3.6.4. Graficado con OpenGL
El objetivo de realizar una gráfica es poder visualizar los datos extraı́dos

por el sensor laser Hokuyo UBG-04LX-F01. Las herramientas que se usaron
fueron las biblotecas de OpenGL desarrolladas por Sillicon Graphics Inc.
(SGI). OpenGL es una interfaz de software de hardware gráfico. Es un motor
3D cuyas rutinas están integradas en tarjetas gráficas. OpenGL posee todas
las caracterı́sticas necesarias para la representación mediante computadoras
de escenas 3D modeladas con polı́gonos, desde el pintado más básico de
triángulos, hasta el mapeado de texturas.
OpenGL trabaja como una máquina de estados, esto quiere decir que
consiste en activar y desactivar opciones. Estas opciones pueden representar
en pantalla una serie de datos, dependiendo del estado en el que se encuen-
tran.
El graficado depende de los datos que envı́a el sensor laser a la compu-

tadora. Una vez adquiridos los datos como se muestra en la Figura 3.20,
deben ser ajustados para poder graficarlos. En las Figuras 3.21 y Figura
3.22 se representa por medio de bloques el sistema que realiza el graficado
de los datos en pantalla.
Figura 3.21: Bloque de la interfaz y ajuste de datos en OpenGL para el

desplegado de los datos en una gráfica.
El área de sensado tiene un rango de 330◦ a 210◦ , debido a esto los

valores se grafican en forma polar para poder visualizar todo el rango de
sensado. Los datos adquiridos por el sensor proporcionan la información del
paso (los pasos para este sensor van de 44 hasta 725), el cual cambia cada
0.36◦ y la distancia en milı́metros a la cual detecta un obstaculo dentro de un
54
Figura 3.22: Interfaz OpenGL desglosado en bloques de ejecución.
rango menor a 5600 mm. Para poder graficar con las funciones de OpenGL
es necesario transformar las coordenadas a coordenadas rectangurales (ver
Ecuaciones 3.1 y 3.2).
x = rcosθ (3.1)
y = rsenθ (3.2)
Creación del Espacio de Trabajo con OpenGL
La creación del espacio de trabajo se programa en lenguaje C. En la

función principal main() se deben incluir las siguientes funciones propias de
OpenGL, las cuales son las siguientes:
55
int main ( i n t argc , char ∗∗ argv )

{
...
/∗ I n i c i o de b i b l i o t e c a s OpenGL−G l u t ∗/
g l u t I n i t (& argc , argv ) ;
/∗ Modo de d e s p l e g a d o ∗/
g l u t I n i t D i s p l a y M o d e (GLUT DOUBLE | GLUT RGB ) ;
/∗ Tamanio de l a v e n t a n a ∗/
glutInitWindowSize ( 700 ,700) ;
/∗ P o s i c i o n de l a v e n t a n a ∗/
glutInitWindowPosition ( 100 ,100) ;
/∗ Nombre de l a v e n t a n a ∗/
glutCreateWindow ( ” L a s e r Hokuyo−LABICE” ) ;
/∗ Parametros de i n i c i o de l a v e n t a n a ∗/
init ();
/∗ Funcion de d e s p l e g a d o ∗/
glutDisplayFunc ( d isp lay ) ;
glutMainLoop ( ) ;
return 0 ;
}
La función para graficar los datos es de acuerdo a la adquisición de los

datos del sensor es la siguiente:
void R ageFinder ( f l o a t r , f l o a t paso )
{
f l o a t npaso , x , y , t h e t a ;
npaso=paso − 4 4 . 0 ;
t h e t a =11.0∗ M PI /6.0+( npaso ∗ ( 0 . 3 5 2 4 2 2 9 0 7 ∗DEG2RAD) ) ;
x=r ∗ c o s ( t h e t a ) ;
y=r ∗ s i n ( t h e t a ) ;
glColor3f (1.0 , 0.0 ,0.0);
g l B e g i n (GL POINTS ) ;
glVertex2f (x , y ) ;
glEnd ( ) ;
}
La función RageFinder recibe el número de paso y la distancia que se

mide en ese paso. Esta función tranforma el número de paso (ángulo) y
distancia en coordenadas cartesianas que se dibujan en la ventana de salida.
La función display contiene el algoritmo para hacer el dibujado de la in-

terfaz y gráfica de los datos enfocado al usuario, en ella se realiza el dibujado
de las lı́neas que ayudan en la visualización de los datos.
En este Capı́tulo se mencionaron las caracterı́sticas principales que de-

terminan el funcionamiento de cada uno de los sensores y tarjetas de adqui-
sición de datos. El estudio de estas caracterı́sticas fue el punto clave para
56
void d i s p l a y ( void )
{
int i ;
g l C l e a r (GL COLOR BUFFER BIT ) ;
g l S c a l e f ( esc , esc , esc ) ;
D r a w c i r c l e ( 0 . 0 , 0 . 0 , rad ) ;
Dibuja circulos ();
ParamCircle ( rad ) ;
f o r ( i =44; i <=725; i ++)
{
i f ( i >100&& i <400){
R ageFinder ( 5 0 0 0 . 0 , i ) ; r e l l e n o o b j ( 5 0 0 0 . 0 , i ) ; }
e l s e i f ( i >=400&&i <=725){
else{
}
centro ( ) ;
comentarios ( ) ;
glutSwapBuffers ( ) ; glFlush ( ) ;
}
el desarrollo de cada una de las etapas de instrumentación de los sensores

ası́ como la instalación de tarjetas de adquisición de datos bajo el S.O. Linux
OpenSUSE mediante la plataforma de LabVIEW y lenguaje de programa-
ción en C/C++. En el Capı́tulo 4 se muestran los resultados experimentales
obtenidos en base al desarrollo de la instrumentación del sistema robótico.
57
Capı́tulo 4
Resultados Experimentales
En el Capı́tulo 3 se menciona a detalle cada una de las etapas de instru-

mentación de sensores para un robot móvil de exterior tipo oruga, ası́ como
la información fundamental para lograr la integración y el buen funciona-
miento de los sensores y tarjetas de adquisición de datos con la Unidad
Central de Procesamiento que opera bajo el S.O Linux OpenSUSE 11.0.
En el presente Capı́tulo se muestran los resultados obtenidos con la ins-

talación de una PC de alto rendimiento, la instalación de una plataforma de
instrumentación virtual, tarjetas de adquisición de datos y la instrumenta-
ción completa de sensores para el robot móvil de exterior tipo oruga HD2
Treaded ATR Tank Robot.
4.1. Una CPU de alto rendimiento con el S.O. Li-

nux OpenSUSE 11.0
Uno de los objetivos en el desarrollo de esta tesis es la elaboración de

una PC de alto rendimiento diseñada para ejecutar varios procesos sin que
esto afecte la velocidad de respuesta ante la ejecución de tareas externas so-
licitadas por el usuario o internas generadas por el sistema operativo Linux
OpenSUSE 11.0, en la Figura 4.1 se muestra el entorno de Linux ejecutan-
do varias tareas. Esto es con la finalidad de tener una Unidad Central de
Procesamiento de gran potencia computacional para el control del robot.
58
4.1 Una CPU de alto rendimiento con el S.O. Linux OpenSUSE 11.0
Figura 4.1: Entorno Linux OpenSUSE 11.0.
59
4.2 Cámaras de video de alta resolucion IEEE 1394
Las especificaciones técnicas de la PC son:
Procesador Intel Core 2 Duo 2.8 Ghz y bus de datos a 1066 Mhz.
Memoria RAM 2 GB a 1066 Mhz con posibilidad de expandirse a 16
GB.
Tarjeta de video dedicada 512 MB PCI-Express
Disco duro de 160GB SATA II
Fuente de poder de 500 W
Tarjeta de expansión de puertos FireWire IEEE 1394
Tarjeta de red Inalámbrica Wi-FI
Hasta 12 puertos USB
Un puerto serial RS232
Un puerto paralelo
3 puertos PCI y un puerto PCI-E de 1 slot disponibles para la inte-
gración de tarjetas.
Estas caracterı́sticas nos ofrecen la opción de actualizar la PC con mejores

componentes e integrar más tarjetas, sensores u otros dispositivos útiles pa-
ra el control del robot, ver Figura 4.2. Para probar el rendimiento de esta
PC se utilizo la función bench de MATLAB R la cual ejecuta seis diferen-
tes tareas (LU, FFT, ODE, Sparse, 2-D, 3-D) y compara la velocidad de
ejecución con la de diversas computadoras. En los resultados obtenidos, ver
Figura 4.3, se observa que la PC del robot queda en 2do lugar, debajo de
una computadora Linux (64-bit) 2.5 GHz Intel Core 2 Quad Q9300 y arriba
de una computadora Windows Server 2008 (64-bit) 2.5 GHz Intel Core 2
Quad Q9300
4.2. Cámaras de video de alta resolucion IEEE

1394
Instalar una tarjeta de expansión de puertos FireWire IEEE 1394-1995

y controladores de ésta permite al robot agregar cámaras de alta resolución
para obtener imágenes claras del entorno a explorar y aplicar algoritmos de
visión para reconocimiento de objetos y texturas.
En la Figura 4.4, se observa una imagen obtenida por la cámara XCD-

X710CR con puerto IEEE 1394 de SONY R comprobando el funcionamiento
del puerto FireWire, ver Figura 4.5.
60
Figura 4.2: Unidad Central de Procesamiento de alto rendimiento.
61
Figura 4.3: Resultados de la función bench de MATLAB

R para esta PC.
62
4.3 Instalación de un anillo de 10 sensores para detección de obstáculos
Figura 4.4: Imagen capturada por la cámara XCD-X710CR.
4.3. Instalación de un anillo de 10 sensores para

detección de obstáculos
Se instaló a la PC el anillo de sensores ultrasónicos cuyo funcionamiento

fue desarrollado por Carlos Ortiz Lopez [18] en su tesis de licenciatura, en
la Figura 4.6 se muestran los resultados que obtuvo.
En la parte derecha de la Figura 4.6, se muestra en color rojo la zona de

peligro para el robot, en amarillo la zona de precaución, y en verde la zona
libre de obstáculos.
63
4.3 Instalación de un anillo de 10 sensores para detección de obstáculos
Figura 4.5: Cámara XCD-X710CR de SONY

R FireWire IEEE 1394.
64
4.4 Un sistema Laser Range Finder funcional para detección de
obstáculos
Figura 4.6: Resultados de la tesis de licenciatura “Navegación Reactiva con

Sensores Ultrasónicos” [18].
4.4. Un sistema Laser Range Finder funcional pa-

ra detección de obstáculos
El sensor de mayor precisión integrado a este sistema robótico es el sensor

Laser Range Finder Hokuyo UBG-04LX-F01. Para establecer la comunica-
ción de la PC con este sensor en el entorno de Linux OpenSUSE 11.0 es
necesario trabajar con las librerı́as C o C++ que proporciona el fabricante
Hokuyo en su pagina Web [1] ya que estas contienen las funciones de comu-
nicación con los puertos serial y USB, ası́ como los comandos del protocolo
SCIP2.0 a los que responde el láser.
Del análisis de las librerı́as se sabe que los datos de distancia proporcio-
nados por el láser son guardados en un arreglo que contiene 725 datos para
el sensor UBG-04LX-F01 ya que el número de datos depende del máximo
de pasos de medición del sensor. De este arreglo podemos descartar los pri-
meros 43 datos ya que en el UBG-04LX-F01 el paso inicial en el rango de
detección se encuentra en el paso 44. Una vez claro el uso de las librerı́as es
necesario compilar un programa en C o C++ (Dependiendo de las librerı́as
descargadas) seleccionando los pasos de lectura relevantes que abarcan los
240◦ de rango (del paso 44 al 725).
65
obstáculos
El código desarrollado en el Capı́tulo 3 en la Secciones 3.6.3 y 3.6.4

permite la adquisición de datos medidos por el Laser mostrando estos en
una gráfica hecha en OpenGL.
Se hizo varias pruebas para comprobar el funciónamiento del laser y del

programa desarrollado en C. Estas pruebas fueron realizadas en el Labo-
ratorio de Electrónica de la División de Ingenierı́as del Campus Irapuato-
Salamanca. Se posicionó el sensor en una zona de mesas de trabajo donde
transitan personas. Los resultados de medición obtenidos por el laser fueron
muy precisos y no hubo ninguna incidencia mediante el desarrollo de las
pruebas.
Cada uno de los obstáculos presentes fueron detectados con gran exacti-
tud. La interfaz gráfica de OpenGL muestra con mayor claridad la precisión
de estos resultados.
En la Figura 4.7 , la Figura 4.8 y la Figura 4.9, se muestran los resultados

obtenidos de algunas mediciones efectuadas por el láser.
El área gris en las gráficas de OpenGL indica la distancia desde el sensor

hasta el obstáculo en el ángulo que fue detectado. El área de color blanco
dentro del rango de detección del láser indica que no se encuentra ningún
obstáculo en una distancia menor a los 5600 mm.
Hokuyo garantiza una precisión de ±10 mm en las mediciones y un mar-

gen de error del 1 % para distancias mayores de 1 m con el modelo UBG-
04LX-F01.
66
obstáculos
Figura 4.7: Sala de electrónica sin personas medida con el Laser Hokuyo.
67
obstáculos
Figura 4.8: Laboratorio de Electrónica con personas medido con el Laser

Hokuyo.
68
obstáculos
Figura 4.9: Laboratorio de Electrónica con personas medido con el Laser

Hokuyo.
69
4.5 Un robot capaz de operar implementando algoritmos en LabVIEW
y C/C++
4.5. Un robot capaz de operar implementando al-

goritmos en LabVIEW y C/C++
Debido al diseño de la Unidad Central de Procesamiento, la estabilidad

del S.O. Linux OpenSUSE 11.0, la instalación de la plataforma de instru-
mentación virtual LabVIEW y el desarrollo de obtención de datos de los
sensores por medio de código en C/C++, es posible operar la locomoción y
aplicar algoritmos de navegación en el robot.
Un algoritmo de locomoción para el robot HD2 Treaded ATR Tank fue

desarrollado en LabVIEW por los trabajos de Lisseth Celeste Razo Var-
gas [19] durante sus estudios de Posgrado, en su proyecto utiliza la tarjeta
de adquisición de datos USB-6009 NI para operar los módulos de potencia
del robot. La programación en LabVIEW la dividió en 2 partes:
Server. Manda las instrucciones de movimiento, cuenta con dos con-

troles de variación de voltaje que permiten cambiar la velocidad de los
motores (uno para los motores de la derecha y otro para los de la iz-
quierda), dos controles de giro para la izquierda o derecha, un selector
de funciones que maneja las opciones para el movimiento hacia ade-
lante o hacia atrás, para giros, control independiente de los motores
y pausa. Finalmente tiene una etapa de emisión/transmisión de datos
por Wi-Fi al programa Cliente. En el Panel frontal incluye la exhibi-
ción de distancia recorrida por el robot, este dato es proporcionado
por el programa Cliente.
Cliente. Recibe las instrucciones de movimiento del programa Server,
cuenta con la etapa de emisión/transmisión de datos por Wi-Fi, una
etapa de comunicación con la tarjeta de adquisición de datos para la
salida de voltaje que permite el control y variación de velocidad de
motores ası́ como adquisición de datos proporcionados por los sensores
encoder para cálculo de odometrı́a del robot, siendo este dato emitido
al programa Server.
En la Figura 4.10 y la Figura 4.11, se muestran el panel de control y el

diagrama de los programas Cliente y Server desarrollados en LabVIEW.
Por tanto, este algoritmo en LabVIEW es muy útil ya que puede ser la
primer etapa para el desarrollo de un robot autónomo, pero queda la cuestión
de como acoplar los algoritmos generados para el funcionamiento de los
sensores láser y ultrasónicos si fueron desarrollados en C/C++. La respuesta
se encuentra en un bloque de función de LabVIEW llamado Call Library
70
y C/C++
Figura 4.10: Programa Server de comunicaciones y control de motores.
71
y C/C++
Figura 4.11: Programa Cliente de comunicaciones y control de motores.
72
4.6 Un robot tipo oruga con una amplia variedad de sensores
Function Node, el cual permite llamar a funciones de librerı́as dinámicas las

cuales pueden generarse en C/C++. Basta con compilar el código para el
láser y sensores ultrasónicos para generar una librerı́a dinámica conocidos
como archivos *.dll en Windows y *.so en Linux. Una vez que la librerı́a
dinámica es llamada en LabVIEW, se puede leer cada función en el código
C/C++ asignando en el bloque Call Library Function Node conectores de
entrada por cada parámetro de entrada de una función en C/C++ y un
conector de salida por cada parámetro que regresa esa función en C/C++.
Debido a que una función en C/C++ sólo puede tener un parámetro de
salida, es posible utilizar punteros para poder asignar más de un conector
de salida en el bloque Call Library Function Node. De esta manera se puede
leer los datos adquiridos por C/C++ de los sensores sin necesidad de diseñar
códigos completamente basados en LabVIEW.
4.6. Un robot tipo oruga con una amplia variedad

de sensores
El objetivo principal de este proyecto de tesis es instrumentar un robot

móvil tipo oruga para fines de exploración obteniendo datos del entorno a
través de la integración de sensores de alta precisión como el sensor láser
Hokuyo UBG-04LX-F01, un grupo de sensores ultrasónicos, cámaras de alta
resolución FireWire IEEE 1394, tarjetas de adquisición de datos y una Uni-
dad Central de Procesamiento capaz de operar todos estos componentes de
manera rápida y eficaz utilizando la plataforma de instrumentación virtual
LabVIEW bajo un sistema operativo poderoso y estable como lo es Linux.
El resultado final de esta tesis es la integración de todos estos compo-

nentes para formar una unidad capaz de recibir algoritmos de programación
LabVIEW y C/C++, ver Figura 4.12.
En este Capı́tulo vimos los resultados obtenidos con el funcionamiento

de la Unidad Central de Procesamiento, sensores y terjetas de adquisición de
datos en el sistema róbotico. En el Capı́tulo 5 se mencionan las conclusiones
en base al desarrollo del proyecto.
73
4.6 Un robot tipo oruga con una amplia variedad de sensores
Figura 4.12: Robot HD2 Treaded ATR Tank con CPU y sensores integrados.
74
Capı́tulo 5
Conclusiones Generales
En este Capı́tulo se presentan las conclusiones del actual proyecto de

tesis, ası́ como la mención de trabajos futuros.
El objetivo principal de la tesis se cumplió, se logró diseñar y construı́r

una Unidad Central de Procesamiento de alto rendimiento que opere con la
plataforma de instrumentación virtual LabVIEW bajo el sistema operativo
Linux OpenSUSE 11.0, la instrumentación del sensor Láser Hokuyo UBG-
04LX-F01, la instalación de un grupo de sensores ultrasónicos, instalación
de camaras de alta definición FireWire IEEE 1394 y la integración de la
tarjeta de adquisición de datos USB-6009 NI.
Cada uno de estos componentes forman parte de un un robot móvil

exterior tipo oruga, proporcionando herramientas para la adquisición de
datos del entorno y control de motores del robot, restando al usuario el
desarrollo de algoritmos en LabVIEW o C/C++ para control, navegación y
exploración autónoma en diversos ambientes.
La Unidad Central de Procesamiento tiene la capacidad de ser actuali-

zada con la integración de nuevos componentes y cuenta suficientes puertos
de expansión para integrar más sensores y tarjetas de adquisición de datos.
Se desarrolló un programa en Linux mediante el lenguaje de progra-

mación en C para el sensor láser Hokuyo UBG-04LX-F01 que nos permite
obtener y graficar datos de distancia desde el sensor a cualquier obstáculo
dentro de un radio menor a 5600 mm en 240◦ . La alta precisión que propor-
ciona el sensor láser permite detectar obstáculos y la arquitectura de zonas
75
5.1 Trabajo futuro
con una gran velocidad de muestreo, ésto puede ser una herramienta clave
para el desarrollo de algoritmos de navegación.
Una de las herramientas más importantes que serán clave para el desarro-
llo de algoritmos para el robot es la opción de combinar el lenguaje de pro-
gramación C/C++ con la plataforma de instrumentación virtual LabVIEW,
de tal manera que se puede trabajar algoritmos para toma de decisiones del
robot en C/C++ y dejando a LabVIEW la parte de la instrumentación y
adquisición de datos a través de la tarjeta USB-6009 NI.
Durante la conformación de esta tesis se logró el desarrollo de habilidades

como, aprender a seleccionar componentes para integrar un sistema, traba-
jar en diferentes sistemas operativos, programar con librerı́as de protocolo
SCIP2.0 y OpenGL, instrumentación virtual en LabVIEW y sus tarjetas de
adquisición de datos, diseño y modelado 3D en Autodesk Inventor, instru-
mentación de sensores bajo protocolos de comunicación I2C y SCIP2.0.
5.1. Trabajo futuro
Queda la tarea de aprovechar los datos obtenidos por los sensores y

tarjetas de adquisición de datos para el desarrollo de algoritmos de control
y navegación del robot móvil exterior tipo oruga que le permitan operar de
manera autónoma.
Para fines de identificación del ambiente y objetos deben desarrollarse

algoritmos de visión por computadora trabajando con las cámaras de alta
definición FireWire IEEE 1394.
Es recomendable instalar un receptor GPS para poder obtener los datos

de ubicación del robot y poder mandarle instrucciones para desplazarse de
un punto a otro con mayor exactitud.
Para fines de exploración en terrenos hostiles es recomendable diseñar

un nuevo gabinete del mismo material del robot HD2 Treaded ATR Tank
para poder proveer de mayor protección a los componentes de la Unidad
Central de procesamiento y sensores.
Es ideal instalar un sistema de carga de baterı́as aprovechando recursos

naturales como la energı́a del sol mediante el uso de celdas solares.
76
5.1 Trabajo futuro
La contribución de este trabajo deja la puerta abierta para futuros tra-

bajos, como la integración de sensores que nos permitan saber un poco más
de las caracterı́sticas fı́sicas del entorno como puede ser, temperatura, hu-
medad, presión, entre otros. Además, deja al usuario la tarea de dedicarse a
la programación de algoritmos que permitan la autonomı́a del robot.
77
Apéndice A
Instalación de Linux:
OpenSUSE
Para realizar la instalación de cualquier distribución de Linux [9], debe

tenerse en cuenta si va a ser el único sistema operativo funcionando en la
PC, o ésta contendrá un segundo sistema operativo, Windows por ejemplo.
Los pasos necesarios para realizar la instalación de un S.O. de Linux se
muestran a continuación:
A.1. Paso 1: Respaldo y Desfragmentación del Dis-

co Duro
Es recomendable hacer un respaldo de datos de este, librar espacio y

hacer la desfragmentación del disco duro utilizando las herramientas del
sistema operativo instalado o usar algún software alterno que tenga esta
función. En Windows las herramientas necesarias para realizar estas tareas
están en: Inicio ⇒ Todos los programas ⇒ Accesorios ⇒ Herramientas del
sistema.
A.2. Paso 2: Partición del disco duro
Se puede optar por dos opciones:
78
A.2 Paso 2: Partición del disco duro
Dejar el espacio libre en que se instalara el S.O. de Linux sin parti-

cionar. Por ejemplo si se dejan los últimos 10 GB del disco duro sin
particionar, y una vez en el instalador de Linux elegir la opción “Usar
espacio libre a continuación”, ası́ Linux automáticamente creará el es-
quema por omisión del espacio reservado. Esta opción es útil cuando
se es muy ordenado con los datos en el disco duro, evitando compli-
caciones al crear particiones.
Partición manual: Esta opción es para quien gusta de tener control
sobre todo.
Los S.O. de Linux cuentan con al menos dos particiones, la partición

principal o raı́z que es donde se instala el sistema operativo como tal (equi-
valente digamos a C:/), y la partición SWAP que es un espacio que actúa
como memoria de intercambio.
El archivo de intercambio es un espacio en el disco duro que se crea para

compensar la falta de memoria RAM. En Windows el archivo se denomina
pagefile.sys y está ubicado en el disco duro local, en tanto que en los siste-
mas operativos Linux se ubica en una partición diferente denominada SWAP
aumentando el desempeño al estar lógicamente separada del sistema opera-
cional y con un sistema de archivos especial para tareas de lectura/escritura
intensivas.
Cabe mencionar que en algunas distribuciones de Linux es posible usar

el sistema de archivos ext4. Sin embargo, el cargador de arranque GRUB
(Programa que permite elegir el S.O. con el que se trabajara al iniciar la
PC) no soporta particiones en formato ext4 por lo que se debe crear una
partición aparte con punto de montaje /boot (para el arranque) y formato
ext3. Al tener la partición /boot aparte, es recomendable para separarla (al
igual que /home) para permitir una fácil recuperación del sistema en caso
de daños al sistema.
Para crear las particiones del disco duro, se recomienda una utilidad
llamada PartitionMagic, lo cuál hará fácil y seguro el trabajo de particionar
la unidad desde el entorno de Windows. En caso de no contar con Windows
se recomienda usar el LiveCD GParted cargandolo desde el boot, ésta es una
herramienta muy útil para realizar particiones y formateo de éstas ya que
cuenta con una gran diversidad de formatos (.ext3, .ext4, Fat32, NTFS, etc.)
Una vez que se entienden las particiones que debe tener Linux nos queda
la duda de cuánta memoria debe ser asignada a éstas. Las recomendaciones
para ello son las siguientes:
79
A.3 Instalación de OpenSUSE
La partición de arranque /boot sólo contendrá los archivos necesarios

para levantar el kernel y pasarle el control al S.O., por lo tanto es sufi-
ciente asignar un aproximado de 200MB para este propósito teniendo
en cuenta las futuras actualizaciones.
La partición que contendrá el S.O. es dependiente de la memoria libre,
pues los S.O. de Linux abarcan aproximadamente entre 7 y 10 GB.
El usuario es quien decide que tanto espacio quiere usar para trabajar
con Linux en base al uso que se le dará.
En cuanto a la partición de intercambio de memoria SWAP, se reco-
mienda asignar el doble de la cantidad de memoria RAM instalada,
sin embargo, esto sólo aplica para sistemas que tienen memoria RAM
menor a 1GB, ya que para Linux será memoria de sobra por lo cual
sólo se recomienda un máximo de 2 GB.
A.3. Instalación de OpenSUSE
Una vez concluidos estos pasos el sistema está listo para la instalación
del S.O. Linux, en este caso la distribución de OpenSUSE 11.0. Para la
instalación de éste, sólo debe cargarse el DVD y seguir las instrucciones
indicadas por el asistente, tal como se harı́a con Windows.
La instalación de software y controladores adicionales dependerá del

hardware a instalar, ası́ como de los requerimientos de programas a utili-
zar, normalmente el fabricante de éstos proporciona un archivo README
donde indica los pasos a seguir para la instalación.
No es tan sencillo instalar software y controladores en Linux como Win-

dows. Linux maneja varios modos de instalación dependiendo del tipo de
archivo que sea proporcionado para realizar la instalación de un progra-
ma o controlador. Algunos se instalan solo haciendo doble click al archivo,
la mayorı́a deben instalarse desde la “terminal” (Una consola parecida a
la de MS-DOS) usando instrucciones como ./Archivo Instalador, sh Archi-
vo instalador, config && make para generar el archivo instalador. En otros
casos se proporciona el código fuente de la aplicación y uno debe darse a la
tarea de compilarlo.
80
Bibliografı́a
[1] Librerias C/C++ SCIP2.0, (Mayo 2010). [En lı́nea]. Hoku-

yo Automatic CO., LTD. Disponible en: http://www.hokuyo-
aut.jp/02sensor/07scanner/download/urg programs en.
[2] Life in the Atacama (Diciembre 2009) [En lı́nea]. Disponible en:
http://www.frc.ri.cmu.edu/atacama.
[3] NASA Atacama Rovers (Diciembre 2009) [En lı́nea]. Disponible en:
http://www.nasa.gov/home/hqnews/2004/sep/HQ 04311 atacama rover.html.
[4] NASA Mars Exploration Rovers (Diciembre 2009) [En lı́nea]. Disponi-
ble en: http://www.nasa.gov/mission pages/mer/index.html.
[5] NASA Mars Pathfinder (Diciembre 2009) [En lı́nea]. Disponible en:
http://marsprogram.jpl.nasa.gov/MPF.
[6] W3Counter: Global Web Stats (Noviembre 2009) [En lı́nea]. Disponible
en: http://www.w3counter.com/.
[7] SRF02 Ultrasonic range finder Technical Specification, Octubre 2009.
[8] Bertram Raphael. The Thinking Computer: Mind Inside Matter. W H

Freeman & Co, 1976.
[9] D. Escobar. Manual Aprende Fedora 11. Comunidad Proyecto Fedora,

Marzo 2009.
[10] GIGABYTE. Manual de usuario GA-P43-ES3G, Junio 2009.
[11] Hokuyo Automatic CO., LTD. Specifications Scanning Laser Range

Finder UBG-04LX-F01, Rapid URG, 2007.
[12] Hokuyo Automatic CO., LTD. Communication Protocol Specification

For SCIP2.0 Standard, 2008.
81
BIBLIOGRAFÍA
[13] T. Kay. Linux+ Certification Bible. Hungry Minds, 2002.
[14] L. Enrique Sucar. Introducción a la Robótica. Conferencia. Puebla,

México INAOE, Diciembre 2009.
[15] National Instruments. Introducción a LabVIEW:

Curso de seis horas, 2003.
[16] National Instruments. User Guide and Specifications: USB-6008/6009,

2005.
[17] National Instruments. www.ni.com, 2009.
[18] C. A. Ortiz-López. Navegación Reactiva con Sensores Ultrasónicos.

(Tesis de Licenciatura). México. Universidad de Guanajuato, División
Ingenierı́as Campus Irapuato-Salamanca, Salamanca, Gto. Abril 2010.
[19] L. C. Razo-Vargas. Control de Locomoción de un Robot Móvil Exte-

rior. (Tesis de Posgrado). México. Universidad de Guanajuato, División
Ingenierı́as Campus Irapuato-Salamanca, Salamanca, Gto. Abril 2010.
[20] Super Droid Robots. Data Sheet MD03 Motor Controller Support, Abril
2009.
[21] Super Droid Robots. Data Sheet SDR H2, Abril 2009.
[22] J. C. Zagal. Robótica Móvil: Robots con Orugas, Articulados, Cinemáti-

ca. Conferencia. Chile. Universidad de Chile, Diciembre 2009.
82

Tesis Edgar Daniel Martinez Rodiguez

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesis Edgar Daniel Martinez Rodiguez

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE GUANAJUATO

QUE PARA OBTENER EL TÍTULO DE:

Edgar Daniel Martı́nez Rodrı́guez

SALAMANCA, GTO. Abril, 2010

A Dios: Por acompañarme cada instante de mi vida, por que nunca me

A mis padres: Ramiro Esaul Martı́nez González y Ma. Dolores Rodrı́guez

A mis hermanos: Oscar Ramiro Martı́nez Rodrı́guez y Diana Esme-

A mis asesores: Dr. Juan Gabriel Aviña Cervantes y Dr. Maximino

A mis tı́os: Jesús Martı́nez, Carlos Martı́nez, Emma Martı́nez, Sil-

A mis abuelos: Esperanza González, Pascual Martı́nez q.e.d., Belén

A mis profesores: Por que contribuyeron enormemente en mi forma-

A mis compañeros y amigos: Pedro Patlán, Ángel Maldonado, Paola

Agradecemos a la Dirección de Apoyo a la Investigación y Posgrado

Por siglos la naturaleza ha sido la inspiración para el desarrollo tecnológi-

Uno de los campos más importantes que abarca la robótica autónoma

La presente tesis tiene por objetivo la instrumentación de un robot móvil

1.2.1. El robot Shakey . . . . . . . . . . . . . . . . . . . . . 2

1.2.2. Mars Pathfinder . . . . . . . . . . . . . . . . . . . . . 2

1.2.3. Proyecto Vida en Atacama . . . . . . . . . . . . . . . 5

1.2.4. Spirit y Opportunity . . . . . . . . . . . . . . . . . . . 7

1.5. Plan de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Robot móvil de exterior tipo oruga 10

2.1. Robots de ruedas . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Robots tipo oruga . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3. HD2 Treaded ATR Tank Robot . . . . . . . . . . . . . . . . . 12

2.3.1. Módulo de control de motores . . . . . . . . . . . . . . 12

2.3.2. Diseño de una PC de alto rendimiento . . . . . . . . . 17

2.4. Diseño de un gabinete para un CPU . . . . . . . . . . . . . . 19

2.4.1. Diseño en Autodesk Inventor . . . . . . . . . . . . . . 19

2.5. Diseño de la unidad de potencia . . . . . . . . . . . . . . . . . 21

3. Instrumentación del sistema 23

3.2. Sistema operativo GNU/Linux: OpenSUSE . . . . . . . . . . 26

3.2.1. Concepto GNU/GPL . . . . . . . . . . . . . . . . . . . 26

3.2.2. Distribuciones de Linux . . . . . . . . . . . . . . . . . 27

3.3. Instrumentación virtual: LabVIEW . . . . . . . . . . . . . . . 28

3.3.1. Adquisición de Datos (DAQ):USB-6009 NI . . . . . . 30

3.4. Instalación de cámaras de alta resolución

3.5. Integración de sensores ultrasónicos . . . . . . . . . . . . . . . 37

3.5.1. Sensor ultrasónico de distancia SRF02 . . . . . . . . . 37

3.6. Instalación del sensor Laser Range Finder 2D . . . . . . . . . 42

3.6.1. Hokuyo UBG-04LX-F01 . . . . . . . . . . . . . . . . . 42

3.6.2. Protocolo SCIP2.0 para sensores Láser . . . . . . . . . 42

3.6.3. Programación en C/C++ para la comunicación con el

3.6.4. Graficado con OpenGL . . . . . . . . . . . . . . . . . 54

4.1. Una CPU de alto rendimiento con el S.O. Linux OpenSUSE

4.2. Cámaras de video de alta resolucion IEEE 1394 . . . . . . . . 60

4.3. Instalación de un anillo de 10 sensores para detección de

4.4. Un sistema Laser Range Finder funcional para detección de

4.5. Un robot capaz de operar implementando algoritmos en Lab-

4.6. Un robot tipo oruga con una amplia variedad de sensores . . 73

5.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A. Instalación de Linux: OpenSUSE 78

A.1. Paso 1: Respaldo y Desfragmentación del Disco Duro . . . . . 78

A.2. Paso 2: Partición del disco duro . . . . . . . . . . . . . . . . . 78

A.3. Instalación de OpenSUSE . . . . . . . . . . . . . . . . . . . . 80

1.1. Robot Shakey. . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Mars Pathfinder. . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Explorador Sojourner. . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Robot Hyperion. . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5. Robot Zoe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6. Robot Spirit. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. HD2 Treaded ATR Tank Robot. . . . . . . . . . . . . . . . . 12

2.2. Controlador MD03. . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Entradas MD03. . . . . . . . . . . . . . . . . . . . . . . . . . 14