77
Universidad Central “Marta Abreu” de las Villas Facultad de Ingeniería Eléctrica Departamento de Automática y Sistemas Computacionales TRABAJO DE DIPLOMA Actualización de la arquitectura de hardware del CIDNAV-AUV Autor: Jesús Javier Díaz Morey. Tutores: Msc. Alain Sebastián Martínez Laguardia. Ing. Carlos Enrique Guerra Morales. Santa Clara 2012 “Año 54 de la Revolución”

Actualización de la arquitectura de hardware del CIDNAV-AUV

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Actualización de la arquitectura de hardware del CIDNAV-AUV

Universidad Central “Marta Abreu” de las Villas

Facultad de Ingeniería Eléctrica

Departamento de Automática y Sistemas Computacionales

TRABAJO DE DIPLOMA

Actualización de la arquitectura de hardware del

CIDNAV-AUV

Autor: Jesús Javier Díaz Morey.

Tutores: Msc. Alain Sebastián Martínez Laguardia.

Ing. Carlos Enrique Guerra Morales.

Santa Clara

2012

“Año 54 de la Revolución”

Page 2: Actualización de la arquitectura de hardware del CIDNAV-AUV

Universidad Central “Marta Abreu” de las Villas

Facultad de Ingeniería Eléctrica

Departamento de Automática y Sistemas Computacionales

TRABAJO DE DIPLOMA

Actualización de la arquitectura de hardware del

CIDNAV-AUV

Autor: Jesús Javier Díaz Morey. E-mail: [email protected]

Tutores: Msc. Alain Sebastián Martínez Laguardia. Dpto. de Automática, Facultad de Ing. Eléctrica, UCLV E-mail: [email protected]

Ing. Carlos Enrique Guerra Morales. Dpto. de Automática, Facultad de Ing. Eléctrica, UCLV

E-mail: [email protected]

Santa Clara

2012

“Año 54 de la Revolución”

Page 3: Actualización de la arquitectura de hardware del CIDNAV-AUV

Hago constar que el presente TRABAJO DE DIPLOMA fue realizado en la

Universidad Central “Marta Abreu” de Las Villas como parte de la culminación

de estudios de la especialidad de Ingeniería en Automática, autorizando a que

el mismo sea utilizado por la Institución, para los fines que estime conveniente,

tanto de forma parcial como total y que además no podrá ser presentado en

eventos, ni publicados sin autorización de la Universidad.

__________________________________ ___________

Jesús Javier Díaz Morey Fecha

Los abajo firmantes certificamos que el presente trabajo ha sido realizado

según acuerdo de la dirección de nuestro centro y el mismo cumple con los

requisitos que debe tener un trabajo de esta envergadura referido a la temática

señalada.

__________________________________ ___________ Jesús Javier Díaz Morey Fecha Autor

__________________________________ ___________ Boris Luis Martínez Jiménez, Dr.C Fecha Jefe de Departamento

__________________________________ ___________ Responsable ICT o J’ de Carrera, (Dr.C, M.Sc. o Ing.) Fecha Responsable de Información Científico-Técnica

Page 4: Actualización de la arquitectura de hardware del CIDNAV-AUV

i

PENSAMIENTO

La ciencia se compone de errores, que a su vez,

son los pasos hacia la verdad.

Julio Verne.

Page 5: Actualización de la arquitectura de hardware del CIDNAV-AUV

ii

DEDICATORIA

A mis padres por el apoyo y la formación que me han dado

para alcanzar todas mis metas.

A mi hermana que espero ser su guía siempre.

A todos mis familiares y amistades que se mantuvieron

apoyándome incondicionalmente.

A todos los profesores que han sabido guiarme durante

toda mi vida estudiantil.

Page 6: Actualización de la arquitectura de hardware del CIDNAV-AUV

iii

AGRADECIMIENTOS

A mis padres por el apoyo brindado antes y durante este trabajo.

A mi abuelo por su ayuda.

A toda mi familia por la confianza que siempre han tenido en mí.

A Yasiel Morera por su ayuda indispensable

en la implementación electrónica

y en todo momento.

A mis tutores Alain y Carlos, por todo el tiempo y conocimientos brindados.

A Daliana Ramos por todo el tiempo dedicado

y consejos brindados en la redacción.

A mis amigos del aula que siempre me han apoyado.

Page 7: Actualización de la arquitectura de hardware del CIDNAV-AUV

iv

RESUMEN

Los vehículos sumergibles autónomos (AUV, Autonomous Underwater

Vehicles) son objeto de disimiles investigaciones a nivel mundial debido a su

utilidad y campos de aplicación. En nuestro país varias empresas han mostrado

interés en el tema, guiando su trabajo hacia el desarrollo de un autopiloto que

permita al AUV cumplir las misiones encomendadas de forma autónoma. Esta

investigación tiene como objetivo fundamental la inclusión en la arquitectura

de hardware del CIDNAV – AUV, sensores complementarios que asistan la

medición de rumbo y revoluciones del motor principal. Para su cumplimiento se

realizó la ingeniería inversa del compás magnético a incluir, quedando definido

el comportamiento de sus salidas. Para lograr la comunicación con el resto del

sistema se diseñó una arquitectura basada en DsPIC, la que procesa la

información brindada por el sensor y la envía a la PC por el protocolo RS-232.

Para la medición de las rpm se implementó un sensor óptico que genera un

tren de pulso en correspondencia con la velocidad de rotación del motor. Lo

anteriormente expuesto se validó mediante pruebas experimentales.

Page 8: Actualización de la arquitectura de hardware del CIDNAV-AUV

TABLA DE CONTENIDOS

v

TABLA DE CONTENIDOS

PENSAMIENTO...................................................................................................i

DEDICATORIA....................................................................................................ii

AGRADECIMIENTOS.........................................................................................iii

RESUMEN..........................................................................................................iv

INTRODUCCIÓN................................................................................................1

1. MARCO TEÓRICO REFERENCIAL…………………………………………....5

1.1. Desarrollo de los AUV a nivel internacional………………………………5

1.1.1. Definición……………………………………………………………....6

1.1.2. AUVs en desarrollo o explotación en la actualidad………………..6

1.1.3. Aplicaciones………………………………………………...………....7

1.2. Métodos de navegación autocontenidos de los AUV…..……………......8

1.2.1. Dead reconning………………………………………………………..8

1.2.2. Modelo básico………………………………………………………..10

1.2.3. Sistema de navegación inercial……………………………...….....12

1.3. Variables necesarias básicas………………………………...…….…..…13

1.3.1. Compás magnético……………………………………...…………..14

1.3.2. Codificadores ópticos……………………………………..……..….14

1.3.2.1. Modos de detección…………………………….……..…....16

1.3.3. Fuentes de error………………………………………….………....17

1.4. Arquitectura del hardware para lograr la navegación……………...…..17

1.5. Consideraciones finales…………………………………………......……19

2. SENSORES A TRABAJAR………………………………………………...….21

Page 9: Actualización de la arquitectura de hardware del CIDNAV-AUV

TABLA DE CONTENIDOS

vi

2.1. Principio de funcionamiento……………………………….……………...21

2.2. Implementación del sensor de rpm………………………………….…...21

2.2.1. Modo de conteo por detección de reflejo………………………...22

2.2.2. Modo de conteo por detección directa…………………….…......23

2.2.3. Circuito de salida…………………………………………….……...23

2.2.4. Errores…………………………………………………………....….26

2.3. Ingeniería inversa del Vetus Fluxgate Compass………………….……27

2.3.1. Obtención de los ángulos de rumbo………………………….......28

2.3.2. Corrección de errores………………………………………….......28

2.4. Hardware de adquisición……………………………………………….…29

2.4.1. Filtrado de las señales analógicas…………………….…….…....32

2.5. Consideraciones finales……………………………………….…...…......33

3. IMPLEMENTACIÓN Y RESULTADOS…………………………………..…..34

3.1. Adquisición de la información del sensor de rpm……………….…..….34

3.2. Adquisición de la información del Vetus fluxgate compass…….…......35

3.2.1. Implementación del software…………………….…………….…..35

3.2.2. Comunicación RS-232………………………………….……..…....37

3.3. Validación de las mediciones…………………………………….........…38

3.3.1. Sensor de rpm………………………………………………......…..38

3.3.2. Sensor Vetus Fluxgate Compass…………………………..……..41

3.4. Análisis económico…………………………………………………..........44

3.5. Consideraciones finales…………………………………………......……44

CONCLUSIONES………………………………………………………….............46

Page 10: Actualización de la arquitectura de hardware del CIDNAV-AUV

TABLA DE CONTENIDOS

vii

RECOMENDACIONES……………………………………………….……………..47

REFERENCIAS BIBLIOGRÁFICAS………………………………………………..48

ANEXOS………………………………………………………………….…………...51

Anexo I: Diseño del hardware del sensor de rpm.……………………….............51

Anexo II: Diseño del hardware de la unidad DsPIC para el Vetus Fluxgate......53

Anexo III: Código fuente de la programación del Vetus fluxgate……………….55

Anexo IV: Partes del código fuente de la programación del sensor de rpm…..64

Page 11: Actualización de la arquitectura de hardware del CIDNAV-AUV

INTRODUCCIÓN

1

Hoy en día el empleo de sistemas autónomos en la ejecución de tareas

submarinas se ha hecho algo común y hasta imprescindible en ciertos casos,

llevando a un rápido desarrollo de estas tecnologías y permitiendo la

ampliación de las fronteras que para el hombre presentaban las profundidades

de los océanos.

Las investigaciones iniciales en el campo de los AUVs (Autonomous

Underwater Vehicles) comenzaron en la década del 60, (Gorset, 2007). En

estos años solo unos pocos AUVs fueron construidos, la mayoría de ellos

fabricados para aplicaciones muy específicas. Poco después, en la década del

70, cuando los yacimientos petroleros de los mares del norte fueron

descubiertos, los vehículos operados de forma remota (ROV, Remotely

Operated Vehicles) fueron introducidos e inmediatamente su uso se extendió a

las tareas realizadas en las profundidades del océano que eran responsabilidad

de buzos hasta ese momento. Aun así, el uso de AUVs fue limitado, aunque se

reportan algunos desarrollos en los Estados Unidos cuyo objetivo era la

recolección de datos.

El progresivo desarrollo de los vehículos submarinos en los últimos años y la

incursión cada vez más frecuente de este medio en las investigaciones ha sido

crucial en el desarrollo de la industria de la oceanografía y de la industria

extractiva del petróleo. Este tipo de vehículos submarinos es objeto de varios

estudios a nivel mundial debido a su utilidad en un gran número de

aplicaciones, principalmente, en la sustitución del hombre en tareas de

inspección, exploración, búsqueda y recolección en ambientes peligrosos u

hostiles.

Numerosos centros de investigación cuentan hoy en día con vehículos

submarinos autónomos AUV y vehículos submarinos operados remotamente

para realizar experimentos y recoger datos. Por motivos de seguridad y de

reducción de costos el sumergible tripulado es rechazado para muchos trabajos

por lo que una de las variantes utilizadas son los AUV.

Un vehículo autónomo submarino (AUV), es un submarino que porta su propia

fuente de energía y medios de cómputo, ejecutando software y soluciones de

Page 12: Actualización de la arquitectura de hardware del CIDNAV-AUV

INTRODUCCIÓN

2

control que le permiten la ejecución de una misión sin intervención humana.

Durante la misión se pueden cambiar las instrucciones pre-programadas

potencialmente modificables, dependiendo de los datos obtenidos por los

sensores de abordo (Guerra, 2010).

En la navegación submarina se utilizan sensores acústicos como son las

sondas acústicas o ecosondas y el sonar, que registran las ondas sonoras y

ultrasonoras, permitiendo conocer la profundidad a la que se encuentra el lecho

marino, su naturaleza y configuración; así mismo, situar a otros navíos en la

superficie o sumergidos, lo que permite navegar en un ambiente relativamente

estructurado.

En el caso de la investigación que nos ocupa no se cuenta con dichos

sensores, por lo que la navegación por debajo de la altura de periscopio se

dificulta ya que no sabemos con exactitud el entorno que nos rodea, por lo que

es de vital importancia lograr soluciones de navegación fiables que solo

requieran información de los sensores instalados abordo.

Con el transcurso de los años se han perfeccionado los métodos de

navegación autocontenidos destacándose las técnicas de navegación inercial

como variante autocontenida de mayor popularidad, no obstante la misma no

es válida para la operación independiente por largos períodos de tiempo debido

a los errores que acumula. Es por esta razón que nuevas variantes de

navegación inercial asistida han surgido, dichas técnicas involucran el uso de

sensores como el DVL (Doppler velocity log) o el uso del modelo matemático

de la planta (Lin and Wei, 2004; Hegrenaes, Hallingstad et al. 2007).

En países como Cuba, la población reside cerca del mar, y este constituye una

fuente de alimentos, recursos minerales y atracción turística, por lo que la

utilización de estos vehículos autónomos en distintas funciones de exploración

y supervisión se hace necesaria. De ahí, que el Centro de Investigación y

Desarrollo Naval (CIDNAV) , le hace la solicitud al Grupo de Automatización

Robótica y Percepción (GARP) de la Universidad Central ”Marta Abreu” de Las

Villas, de dotar de capacidades autónomas a uno de los vehículos diseñados

por dicho centro.

Page 13: Actualización de la arquitectura de hardware del CIDNAV-AUV

INTRODUCCIÓN

3

El CIDNAV es un centro con experiencia, que se ha ocupado del diseño y

construcción naval de varios tipos de vehículos sumergibles, mientras que

GARP ha trabajado en el desarrollo de varios vehículos autónomos y el

modelado matemático de distintos tipos de plantas (Pineda, 2009; Cañizares,

2010).

En la actualidad, y gracias a la colaboración entre ambos centros se puede

afirmar que se dispone de un prototipo de AUV. Los resultados obtenidos hasta

el momento pueden ser agrupados en las siguientes publicaciones:

Arquitectura de hardware y software de bajo nivel (Guerra, 2010; Martínez,

Rodríguez et al. 2010), Software de supervisión y control, (Martínez, Rodríguez

et al. 2010; Rodríguez and L.Ramos 2011), Instalación de sensores (Martínez,

Rodríguez et al. 2010), Modelo dinámico del HRC− AUV (Cañizares, 2010),

Estrategia de control de rumbo diseñada a partir del modelo del HRC−AUV

(Hernández, Valeriano et al. 2011), Software de navegación y guiado en tiempo

real para Vehículo Autónomo Sumergible (Lemus, 2011). Estos resultados se

basan en pruebas experimentales que suman más de 30 horas de trabajo,

lográndose resultados satisfactorios (Martínez, Rodríguez et al. 2010;

Hernández, Valeriano et al. 2011; Rodríguez and L.Ramos, 2011).

De acuerdo con lo planteado anteriormente la situación del problema reside

en continuar trabajando en la arquitectura de hardware y software del

CIDNAV-AUV para lograr una navegación autónoma de mayores prestaciones,

dadas las carencias detectadas en la medición de rumbo y revoluciones del

motor principal del AUV.

Por lo hasta aquí expuesto el objetivo general de la investigación es:

Incluir en la arquitectura de hardware del CIDNAV – AUV sensores

complementarios que asistan la medición de rumbo y revoluciones del

motor principal.

En consecuencia, los objetivos específicos son:

Analizar el sensor Vetus fluxgate compass mediante ingeniería inversa y

desarrollar la interfaz de acople al hardware ya implementado.

Page 14: Actualización de la arquitectura de hardware del CIDNAV-AUV

INTRODUCCIÓN

4

Construir el sensor de rpm basado en principio óptico (infrared).

Validar las mediciones de ambos sensores y comprobar su integración al

resto de los sistemas de hardware y software.

La presente investigación está estructurada en: introducción, tres capítulos, los

cuales están organizados de la siguiente manera:

CAPÍTULO I: Se presenta un acercamiento teórico y conceptual que guía el

proceso investigativo; ello incluye además, la estructura general para el

CIDNAV-AUV, así como la importancia de la inclusión del Vetus Fluxgate

Compass y las principales formas de implementar el sensor de rpm según los

requisitos del sistema.

CAPÍTULO II: Descripción de los aspectos relacionados con la arquitectura de

hardware diseñado e implementado para la unidad DsPIC. Se exponen los

medios de cómputo utilizados en la misma, incluyendo las principales

características que dieron lugar a su selección, el análisis del sensor Vetus

Fluxgate Compass mediante ingeniería inversa y la implementación del sensor

de rpm.

CAPÍTULO III: Se aborda lo relacionado con la arquitectura de software a

utilizar y la validación de las mediciones de ambos sensores, así como

comprobar su integración al resto de los sistemas de hardware y software.

A las conclusiones y recomendaciones le siguen las referencias bibliográficas y

anexos.

Page 15: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I

Page 16: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

5

1. MARCO TEÓRICO REFERENCIAL

En este capítulo se abordará lo referente al estado actual de los AUV en el

mundo, así como los métodos de navegación existentes para justificar el uso

de los sensores a diseñar, ya que estos son importantes por la información

que los mismos brindan en el contexto del método de navegación

seleccionado. Se analizarán los principales modos de implementar los

codificadores para el cálculo de las rpm y se llegará a la conclusión de cual es

el más óptimo para la aplicación; de la misma forma se expondrá con que

sensores se obtiene el rumbo a partir del conocimiento del campo magnético

terrestre y como se incluirán los mismos a la arquitectura del hardware ya

diseñado.

1.1 Desarrollo de los AUV a nivel internacional.

Los vehículos sumergibles autónomos son objeto de investigaciones a nivel

mundial debido a su utilidad y áreas de aplicación. En la actualidad sirven para

la inspección subacuática visual, supervisión de áreas específicas y

cumplimiento de misiones en lugares de difícil acceso (Fossen and Ross,

2006). La necesidad de explorar las fuentes de recursos naturales marítimas se

ha vuelto imprescindible, dado que los mismos se han ido agotando sobre la

tierra. Por esta razón se realizan grandes esfuerzos para gestionar la

extracción de estos desde el lecho marino.

Los AUVs forman una nueva generación de vehículos robóticos para la

exploración, poseen su propio suministro de energía y no tienen ningún tipo de

liga física con la superficie; utilizan una computadora o alguna clase de

controlador o procesador electrónico para controlar el vehículo durante su

misión. Además, cuentan con sensores conectados a la computadora, los

cuales obtienen información de la navegación como profundidad, velocidad y

tiempo de la misión, etc.

Los sonares permiten a estos vehículos evitar obstáculos y mapear el fondo.

Pueden también, utilizar cámaras de video para capturar y almacenar

imágenes del viaje. Finalmente, cuando el AUV ha terminado de realizar su

Page 17: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

6

misión descarga toda la información recolectada, si así se desea, en una

computadora que se encuentra en la superficie (buque madre).

Existen algunas desventajas en los AUVs dentro de las cuales se encuentran:

1) la cantidad de energía disponible es limitada, 2) los sensores no

proporcionan información lo suficientemente confiable, 3) la falta de

computadoras y programas capaces de procesar las grandes cantidades de

datos generados en tiempo real por los sensores.

Las mejoras futuras tanto en baterías como en sensores podrán ayudar a que

los AUVs sean la herramienta principal de los exploradores y de los científicos

del sector oceanográfico.

1.1.1 Definición.

Los vehículos autónomos sumergibles se encuentran dentro del grupo de

vehículos sumergibles no tripulados (UUV Unmanned Underwater Vehicle), son

vehículos que se desplazan en un medio acuático y efectúan diferentes

misiones sin la necesidad de llevar a bordo operadores humanos. Su

capacidad de navegación autónoma le permite ejecutar tareas previamente

programadas, los mismos poseen una fuente de energía propia e interactúan

de manera autónoma con el entorno (Fjellstad, 1994).

Los AUVs son controlados automáticamente y toda la inteligencia está

almacenada a bordo en los sistemas de cómputo. Como existen variadas

tareas que los mismos no pueden realizar de forma autónoma pre-programada

pueden ser dirigidos desde estaciones remotas ubicadas para su monitoreo.

1.1.2 AUVs en desarrollo o explotación en la actualidad.

Numerosos centros de investigación cuentan con AUV para realizar

experimentos y recoger datos. Entre los proyectos de mayor significación que

pueden citarse están las implementaciones UROV-2000, AROV, AE 1000,

Ocean Voyanger II, Large-D UUV, ODIN II, Theseus, REMUS, Solar AUV,

SAUVIN, Kerang(Clam), Tiram(Oyster) y Sotong(Squid), todos estos

organizados cronológicamente desde los años 1990 a 2006 (Guerra, 2010).

Page 18: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

7

Figura 1.1: Ejemplos de algunos AUV.

1.1.3 Aplicaciones.

Los AUVs durante su desarrollo se han convertido en una herramienta muy

importante en las operaciones en el mar, esto se ha hecho posible debido a

que han aumentado su rango de operación y su profundidad. A esto se le

añade la posibilidad de supervisión y cumplimiento de misiones en lugares de

difícil acceso, en los cuales la vida del hombre puede estar en peligro. Por lo

que cuentan con una gran variedad de aplicaciones como son:

Aplicaciones científicas y medioambientales. Inspección del fondo marino.

Estudios de la biología marina.

Recolección de datos de temperatura y variabilidad de las corrientes

oceánicas.

Investigaciones ambientales e hidrográficas.

Aplicaciones industriales y comerciales. Comunicaciones submarinas, instalación e inspección de cables.

Inspección de estructuras submarinas (oleoductos, diques, puertos).

Page 19: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

8

Mapeo con precisión del fondo oceánico para proyectos de cable y

tubería submarina.

Monitoreo de volcanes marinos.

1.2 Métodos de navegación autocontenidos de los AUV.

La capacidad de navegar, entiéndase estimar la posición del vehículo en cada

momento, es inherente a los AUV. Existen varios métodos de navegación

autocontenidos, cada uno con sus características particulares y sensores que

miden las variables necesarias sin la necesidad de utilizar métodos de

navegación que estén basados en el seguimiento de marcas, la cual es una

técnica que consiste en la detección de determinados elementos del entorno

que ayudan al proceso de localización de lugares relevantes para la tarea de

navegación. Una de las ventajas que ofrecen los sistemas de navegación

autocontenidos es que no necesitan del uso de referencias externas y trabajan

exclusivamente con sensores integrados en el vehículo como codificadores,

giróscopos, brújulas, acelerómetros, etc.; y sin ningún tipo de información

externa.

Desde los inicios los sistemas AUV han realizado una navegación

prácticamente a ciegas debido al reducido número de sensores operativos en

el ambiente subacuático. Es por esto que se han desarrollado sistemas

acústicos que dan una significativa ventaja al evitar posibles golpes o choques

contra el fondo o en la evasión de obstáculos.

Actualmente se va un paso más allá y se implantan sistemas de navegación

inercial combinados con sonar que ofrecen un sistema de navegación preciso y

de mayor frecuencia de actualización que los sistemas acústicos, pero a

cambio de una gran precisión también hemos de prever un aumento del costo.

1.2.1 Dead reconning.

Dead reckoning (navegación por estima), es una expresión que se deriva del

término náutico deduced reckoning (cálculo basado en inferencia), y es un

procedimiento matemático que utiliza fórmulas trigonométricas para inferir la

ubicación actual de un navío haciendo cálculos basados en el rumbo y la

Page 20: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

9

velocidad de navegación a lo largo de un período. La amplia mayoría de los

sistemas robóticos móviles que se usan hoy en día, utilizan dicha técnica como

columna vertebral de su estrategia de navegación, siendo su principal limitante

la necesidad de eliminar los errores acumulados con continuos ajustes

provenientes de varios sistemas de ayuda a la navegación.

El dead reckoning es el sistema de navegación básico más utilizado en los

AUVs, el mismo hace referencia a la combinación de brújulas, sensor de

profundidad, y sensores de velocidad. En estos sistemas el compás que se

utiliza es de alta precisión, ofreciendo una estimación bastante exacta de la

trayectoria de los AUVs. La profundidad es medida con un sensor de presión a

bordo, y la altitud sobre el lecho marino es medida por el eco - sondeo acústico

(Kapaldo, 2005).

Una de las implementaciones más sencilla posible de esta técnica

habitualmente implica un cuentarrevoluciones a bordo del vehículo. Una técnica

común para implementarlo consiste en utilizar codificadores ópticos

directamente acoplados a los motores de propulsión. El problema principal que

presenta este método es la dificultad de saber el error que se comete, lo que

provoca que a medida que se desplaza el vehículo se van acumulando los

errores, provocando errores de posicionamiento (Salinas, 2006). A pesar de

estas limitaciones, se piensa en este método como una parte importante de los

sistemas de navegación y, así mismo, las tareas de navegación se

simplificarían mucho si la precisión de este método mejorara.

Con el uso de este método si se conoce la posición de partida y se navega

cierta distancia a un determinado rumbo y a una determinada velocidad, se

puede en cualquier momento, encontrar la posición con una construcción

geométrica.

Los errores en la estima resultan de muchos orígenes, incluyendo

conocimientos inexactos del punto de arranque del vehículo, una mala

alineación del sensor de rumbo y efectos de sincronismos entre los diferentes

sensores. Cualquier error presente en las condiciones iniciales se propagará

desde el principio hasta el fin de la trayectoria del vehículo. De forma

Page 21: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

10

semejante, un compás desajustado causa una descompensación continua de

todas las mediciones y se traduce con el tiempo en una trayectoria aproximada

de dirección que se desvía de la verdadera del vehículo. A su vez, también

pequeñas variaciones de velocidad (provocadas por las corrientes oceánicas o

medios de propulsión) pueden retrasarlo o adelantarlo sensiblemente; también

puede haber desviaciones hacia la izquierda o derecha del camino prefijado.

Ello sumado a que dichas alteraciones pueden no haber sido constantes, da

como resultado que el punto obtenido como posición no es más que una

aproximación de la situación real del vehículo.

Cuando la navegación se realiza sobre una superficie pequeña del globo

terrestre hasta unas 300 millas o en latitudes altas, el cálculo de la estima se

hace sobre una aproximación al suponer la superficie plana.

1.2.2 Modelo básico.

El modelado es una tarea importante requerida en el proceso de la

implementación de un AUV. Dicho modelo es vital para la navegación, la

mayor parte de los resultados y el cumplimiento satisfactorio de las misiones

dependen de la precisión y exactitud del mismo. Con el uso del modelo se

puede obtener el estado de la navegación teniendo como entradas a la planta,

las rpm del motor de propulsión y los ángulos de timón.

El movimiento de un submarino en el mar se describe respecto a un sistema de

referencia inercial. Normalmente se supone que la aceleración respecto a tierra

de un punto en la superficie puede ser despreciada por vehículos marinos. Esta

aproximación es válida a partir de que la rotación de la Tierra afecta muy poco

a los vehículos marinos de baja velocidad.

En la figura 1.2 se representan los sistemas de coordenadas y la definición de

los movimientos de traslación y rotación del vehículo así como la notación

utilizada.

Page 22: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

11

Figura 1.2: Notación para vehículos subacuáticos (Fossen, 1994).

El modelo del vehículo se dividió en tres subsistemas como los analizados en

la tesis de Julio R. Cañizares (Cañizares, 2010) para poder obtener los distintos

parámetros que lo componen, una vez encontrados los mismo se planteó un

modelo de 6GDL en el que a partir de las entradas de rpm y ángulo de timón es

posible estimar velocidades y posición del vehículo tanto angulares como

lineales acorde a la ecuación en espacio de estado 1.1 obtenida por Martínez

(Martínez, 2012).

1 1 1

(1.1)0 0

r rv vM C D M G M

J

Donde M matriz de inercia incluyendo masas añadidas, C matriz de Coriolis

incluyendo masas añadidas, D es la matriz de amortiguamiento, G matriz de

fuerzas y momentos relacionados a la fuerza de gravedad y la flotabilidad del

vehículo y τ es la matriz de mandos generada a partir del producto de las rpm

y los ángulos de los timones con un grupo de ganancias (Valeriano, Martínez et

al. 2012), así mismo en dicha ecuación se tienen en cuenta los disturbios

ocasionados por el oleaje y las corrientes marinas. Con todos estos factores es

posible desarrollar una navegación basada en el modelo obteniéndose la

posición (η) y las velocidades del vehículo (ν).

Page 23: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

12

1.2.3 Sistema de navegación inercial.

La Navegación Inercial utiliza sensores para obtener una estima de la posición.

La misma se vale de giróscopos y acelerómetros para medir las rotaciones y

las aceleraciones del AUV en su movimiento, es usada en un amplio rango de

aplicaciones incluyendo la navegación de aeronaves, submarinos y

embarcaciones de superficie.

Un sistema de navegación inercial (INS) mide el movimiento o la aceleración

del AUV en tres ejes y razones de cambio angulares del cuerpo. También,

permite la estimación de la actitud, la posición y la velocidad del vehículo,

proporcionando una solución completa del estado de navegación (Woodman,

2007).

Estos sistemas actualmente son la parte mayoritaria de los sistemas de

navegación autocontenidos y constan de (Mohinder, 2007):

Unidad de medición inercial (IMU1): Contiene al menos tres

acelerómetros y tres giroscopios, montados en una base común,

manteniendo la ortogonalidad entre los ejes.

Computadora de navegación: Calcula el efecto de la gravedad y corrige

los biases y drifts de los acelerómetros de la IMU. A su vez, debe integrar

doblemente los valores de la aceleración para obtener la posición estimada.

Los errores de la IMU son debidos a que las variables medidas no son

directamente las que conforman el estado de navegación, en el proceso de

integrar las variables por medio de la integración de los datos ofrecidos por

acelerómetros y/o giróscopos situados a bordo hasta obtener las velocidades

en los 3 ejes posibles de desplazamiento en función de los rumbos; este

proceso posibilita la obtención de la posición, acarreando un error en el tiempo

que en la mayoría de los casos siempre es superior a los márgenes de

tolerancia de la aplicación (Sosa, 2010).

1 La IMU utilizada en el CINAV-AUV es una variante que contiene

magnetómetro (Attitude and Heading Reference System IMU).

Page 24: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

13

Por tal razón, para reducir estos errores se utiliza el algoritmo de Filtro

Extendido de Kalman (EKF, Extended Kalman Filter). La fuente de corrección

más frecuente en la implementación del EKF para soluciones de navegación es

el GPS, pero debido a que no se encuentra disponible cuando el vehículo se

sumerge, se introduce para la aplicación en cuestión el Modelo Dinámico del

Vehículo para Navegación (DNVM, Dynamic Navigation Vehicle Model). El

mecanismo de navegación diseñado cuenta con cuatro etapas fundamentales:

Suavizado de las Mediciones, Mecanización Inercial, Evaluación del DNVM,

estimación y corrección de errores mediante EKF (Lemus, 2011).

1.3 Variables necesarias básicas.

Todo sistema de navegación tiene variables que son básicas para su

implementación. La navegación desde un punto a otro cuando se realiza

conociendo las variables de rumbo y velocidad a la que se desplaza el vehículo

permite estimar en todo momento, la ubicación. Este método aunque es uno de

los más sencillos no deja de ser efectivo, por lo tanto, si se cuenta con los

sensores para medir dichas variables se puede realizar la navegación y puede

servir para comprobar las posiciones indicadas por otros sistemas de

navegación.

La variable de rumbo se puede estimar realizando una medición consistente en

obtener la orientación como función del campo magnético terrestre que se

detecte en el lugar. El principal problema que tiene este tipo de

posicionamiento es que el campo magnético de la tierra es distorsionado por

distintos factores como pueden ser sustancias ferro-magnéticas o campos

eléctricos. Esto hace que el uso de las brújulas magnéticas en estructuras con

casco de acero sea difícil.

Existen diferentes métodos para este tipo de medición basándose en los

diferentes efectos físicos que se dan en relación al magnetismo de la Tierra; el

más utilizado es el de la brújula de inestabilidad que mide la componente

horizontal del campo magnético de la Tierra (Salinas, 2006). El mismo, tiene

sus ventajas: bajo consumo de potencia; no contiene partes móviles por lo que

no se ve afectado por vibraciones.

Page 25: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

14

La otra variable de vital importancia es la velocidad, la cual puede ser estimada

a partir del conocimiento de las rpm del motor de propulsión. Para su medición

se pueden utilizar codificadores ópticos, los cuales se pueden construir

teniendo en cuenta las necesidades de operación del sistema.

1.3.1 Compás magnético.

Los compases magnéticos son ampliamente utilizados para obtener el rumbo;

para ello, existen diferentes variedades basados todos en el mismo principio de

funcionamiento. Para medir los ángulos respecto al norte magnético utiliza un

pequeño anillo bobinado en el que se crea un minúsculo campo magnético al

hacer circular una corriente eléctrica; dicho campo magnético que se conoce al

crearlo mediante la circulación de una corriente eléctrica, es perturbado y

modificado por el campo magnético terrestre. Por ello, midiendo la magnitud de

esta perturbación se conocerá el ángulo que forma el sensor con el norte.

Estos brindan la información referente al rumbo. Las salidas son voltajes

analógicos, esta información se procesa y de esta forma con operaciones

matemáticas se obtienen senos y cosenos que con una combinación de

ambos se pueden estimar la variable.

El sensor debe ser instalado en un lugar alejado de otros elementos

magnéticos que pudieran interferir la medida. Se debe instalar lo más próximo

al centro de gravedad del vehículo y separado convenientemente del casco;

cuanto más cerca esté instalado del centro de gravedad, se verá menos

afectado por un cambio brusco causado por el oleaje.

1.3.2 Codificadores ópticos.

Los encoders son sensores que generan señales digitales en respuesta al

movimiento y están disponibles en dos tipos, uno que responde a la rotación, y

el otro al movimiento lineal. Cuando son usados en conjunto con dispositivos

mecánicos, ruedas de medición o motores, estos pueden ser utilizados para

medir movimientos lineales, velocidad y posición. Los mismos, pueden utilizar

tanto tecnología óptica como magnética.

Page 26: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

15

El sensor óptico provee altas resoluciones, velocidades de operaciones altas,

operación de larga vida en la mayoría de los ambientes; basan su

funcionamiento en la emisión de un haz de luz que es interrumpido o reflejado

por el objeto a detectar. Los sensores magnéticos se utilizan frecuentemente

en aplicaciones de trabajo pesado, proveen buena resolución, altas

velocidades de operación, y máxima resistencia al polvo, humedad, y golpe

térmico y mecánico.

Como la estructura del AUV es completamente metálica y el motor induce

grandes campos magnéticos, no es factible implementar un sensor con

principio magnético ya que se vería afectado significativamente por esto y las

mediciones que daría serían totalmente erróneas en su mayoría; por lo tanto

queda descartado para la implementación, la cual se realizará de forma óptica.

Los sensores ópticos están conformados por las siguientes partes:

Fuente.

Receptor.

Circuito de salida.

La fuente origina un haz luminoso, usualmente con un LED, que puede tener

un amplio rango en el espectro incluyendo luz visible e infrarroja. Para la

mayoría de las aplicaciones se prefiere las radiaciones infrarrojas, pues son las

que mayor porcentaje de luz emiten, disipan menos calor y se ven menos

afectadas por fuentes de luz externas.

El receptor recibe el haz luminoso de la fuente, usualmente es un foto-diodo o

un foto-transistor. El foto-sensor debe estar acoplado espectralmente con el

emisor, esto significa que el foto-diodo o el foto-transistor que se encuentra en

el detector debe permitir mayor circulación de corriente cuando la longitud de

onda recibida sea igual a la del LED en el emisor. El receptor recibe los pulsos

de luz en sincronía con el emisor, esto permite ignorar radiaciones

provenientes de otras fuentes. Este tipo de recepción sincrónica sólo es posible

cuando la fuente y el receptor están en el mismo encapsulado (Alvarado,

2004).

Page 27: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

16

1.3.2.1 Modos de detección.

Los sensores ópticos se colocan en tres configuraciones diferentes estas son:

detección directa, reflexiva y difusa. Las implementaciones que se llevarán a

cabo abordarán las dos primeras configuraciones con el objetivo de tener

varias salidas capaces de brindar la misma información y así poder comparar

las mediciones para tener el menor error posible y en caso de que alguna falle

tener una redundancia.

En la detección directa el emisor se coloca en frente del receptor y el objeto es

detectado cuando pasa entre ambos.

Figura 1.3: Detección directa.

En el modo de detección reflexiva el emisor y el receptor se colocan en el

mismo sitio uno al lado del otro y en frente de ellos se coloca una superficie

reflexiva, el haz de luz emitido choca contra el reflector para ser registrado por

el receptor. La detección ocurre cuando pasa el objeto impidiendo que el haz

de luz llegue hasta el receptor; esta configuración tiene la ventaja de que el

emisor y el receptor vienen en el mismo empaque. La superficie donde choca el

haz está formada por reflectores especiales o cintas reflexivas diseñadas para

que el haz regrese al foto-interruptor.

Figura 1.4: Detección reflexiva.

Page 28: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

17

1.3.3 Fuentes de error.

Las principales fuentes de error de un compás magnético vienen dadas por la

proximidad de algún elemento magnético o una mala alineación del sensor por

lo que se debe montar en un lugar libre de todo material que pudiera causar

influencias magnéticas que le afectan. El lugar idóneo se encuentra en la parte

superior con una separación óptima del casco, en el eje central de la

embarcación. La distancia entre el sensor fluxgate y posibles fuentes de

interferencia ha de ser de un metro como mínimo.

Los detectores de tipo reflexivo pueden presentar problemas cuando el objeto o

las franjas a detectar tienen una superficie que refleja el haz de luz causando

que la información llegue al detector. La mayoría de estos sensores tienen un

área ciega dentro de la cual no pueden detectar, existe una región entre el

detector y la distancia mínima de detección en la cual si un objeto se ubica o

bien el haz de luz no lo toca, o bien el haz reflejado no llega al receptor

(Alvarado, 2004).

El principal error de los sensores de detección directa es que los mismos no

queden alineados correctamente ya que el receptor no recibiría el haz de luz

emitida por el emisor. Así mismo, cuando no son de luz infrarroja y son

ubicados en un área que está muy iluminada o donde se produzcan chispas se

verán afectados y no se activarían correctamente. Otro de los aspectos a tener

en cuenta es la frecuencia de muestreo, si no es la correcta para la aplicación

no se detectan los cambios ocurridos con la eficiencia requerida.

1.4 Arquitectura del hardware para lograr la navegación.

Los sistemas AUV han evolucionado su arquitectura computacional en los

últimos años para ser capaz de satisfacer demandas de operación y de la

aplicación que realizan, con el empleo de sensores, equipos de comunicación.

Los distintos centros que investigan sobre este tema emplean diversas

estructuras de hardware, software y arquitectura sensorial para su

funcionamiento.

Page 29: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

18

Al transitar de los años la arquitectura de sistemas empotrados va quedando

definida por muchos centros de la forma computadora-microcontrolador. La PC

como medio de cómputo principal realiza básicamente, funciones de

navegación y control del sistema; el microcontrolador ejecuta funciones

auxiliares de control, adquisición de sensores e interfaces básicas de

comunicación (Guerra, 2010).

Conjuntamente a una arquitectura computacional se necesita conocer el estado

del vehículo y el entorno que los rodea en todo momento para desarrollar las

misiones. Por lo que, están dotados de una estructura sensorial que le permite

obtener la información necesaria para desarrollarlas.

Entre los sensores más utilizados para estas aplicaciones se encuentran:

acelerómetros, giróscopos, magnetómetros, altímetros, modem acústico, sonar,

sensor de presión, profundidad, temperatura, velocidad de traslación y rotación,

sistema de posicionamiento global (GPS Global Positioning System) entre

otros. En la actualidad se continúan empleando varios de los sensores antes

mencionados, los cuales se encuentran internos dentro de una IMU (Unidad de

mediciones inercial).

Para el prototipo empleado en Cuba, el grupo de automatización, robótica y

percepción (GARP), adoptó una estructura de hardware para el proceso de

creación del autopiloto del CIDNAV-AUV (Guerra, 2010), la cual queda

implementada como se muestra en la figura 1.5.

Figura 1.5: Estructura del sistema.

Page 30: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

19

Con respecto a la arquitectura se realizó una actualización en la propuesta

anteriormente como se muestra en la figura 1.6, donde se cambia la PC-103

por una PC-104 y la comunicación con el segmento remoto se realiza mediante

un Modem RS-232; así mismo, se introduce un compás magnético dando la

posibilidad de tener incluida otra variable que brinde la información del rumbo.

El sensor de rpm implementado con anterioridad era magnético y se ve

afectado por las características del ambiente en el que está ubicado. El nuevo

diseño se realizaría basado en el principio óptico de infrared.

Figura 1.6: Estructura actualizada del sistema.

1.5 Consideraciones finales.

Finalizado el capítulo, puede evidenciarse la importancia que tiene el vehículo

autónomo sumergible en el ámbito mundial tanto científico como industrial y

comercial, notando que numerosos centros de investigación cuentan con esta

tecnología.

Así mismo, se puede notar que con el transcurso de los años se han ido

perfeccionando los métodos de navegación autocontenidos, los que brindan

una información más exacta de la posición de los vehículos. Con la

combinación de varias de estas técnicas y haciendo uso de los sensores

necesarios, se pueden reducir los errores que los mismos proporcionan.

Page 31: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO I MARCO TEÓRICO REFERENCIAL

20

En correspondencia a lo antes analizado y de acuerdo con las características

del sistema en que será usado, se concluye que la implementación óptima del

sensor de rpm es el principio óptico.

Si se configura y se ubica el compás en un lugar donde las afectaciones

magnéticas sean las menos posibles, sería de mucha utilidad para comprobar

el rumbo del vehículo. Con la inclusión de ambos sensores se actualizará la

estructura del hardware para un aumento de las prestaciones del mismo.

Page 32: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II

Page 33: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

21

2. SENSORES A TRABAJAR

En este capítulo se abordará lo referente a la construcción del sensor óptico de

rpm, la ingeniería inversa del sensor Vetus fluxgate compass y el desarrollo de

una interfaz de acople al hardware ya implementado en el CIDNAV-AUV. Se

realiza un análisis de los errores de medición de los dos sensores

implementados y se da una descripción de las unidades DsPIC y PC-104 a la

que serán conectados.

2.1 Principio de funcionamiento.

Como se mencionó en el capítulo anterior se pretende realizar una navegación

asistida por el modelo matemático de la planta. Dicho modelo tiene como

entradas las rpm del motor propulsión y los ángulos de timón del submarino.

Para medirlas se utilizará el sensor óptico construido, el mismo presenta una

estructura similar a un encoder el cual a la salida entrega un tren de pulsos

con una frecuencia proporcional a la velocidad con que rota el motor de

propulsión. El número de pulsos por revolución está relacionado directamente

con el número de ranuras que posea la pieza acoplada al rotor del motor.

Actualmente para conocer el rumbo se cuenta con los magnetómetros dentro

de la IMU, pero la misma al estar dentro del vehículo se ve afectada por los

elementos ferro-magnéticos que componen el casco y los campos magnéticos

provocados por el motor de propulsión por lo cual, se le agregará al hardware

ya implementado un compás adicional ubicado en el exterior y separado

convenientemente del casco, permitiendo obtener una medición redundante

que facilitará la información de la orientación basado en el campo magnético

que se detecte en el lugar.

2.2 Implementación del sensor de rpm.

Para la implementación del sensor de rpm se utilizaron dos sensores con el

objetivo de implementar los codificadores ópticos analizados en el capítulo

anterior. Uno de ellos es basado en el integrado CNY70 y el otro se implementó

a partir de un diodo de emisión infrarroja y un foto-transistor.

Page 34: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

22

Para ello, se acopla al eje del rotor del motor de propulsión un disco similar al

que se puede observar en la figura 2.1. El mismo crea una superficie reflexiva y

un grupo de ranuras para el funcionamiento de ambos modos de detección. El

ancho de las ranuras como de las franjas oscuras solo influye en la duración

del pulso, es decir, el tiempo que está en alto la señal.

Figura 2.1: Disco de acople al rotor.

2.2.1 Modo de conteo por detección de reflejo.

El integrado CNY70 es un sensor óptico reflexivo que tiene una construcción

compacta donde el emisor de luz y el receptor se colocan en la misma

dirección para detectar la presencia de un objeto, utilizando la reflexión

infrarroja sobre el objeto. Este se compone de un diodo emisor infrarrojo y un

foto-transistor, integrados en el chip. La longitud de onda de trabajo es 950nm.

Figura 2.2: Estructura del Sensor CNY70

La figura 2.2 muestra la estructura del CNY70 que tiene cuatro pines de

conexión que se corresponden con el emisor, colector del transistor y el ánodo

y cátodo del diodo emisor. El medio reflectante es el disco que es acoplado al

Page 35: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

23

rotor del motor de propulsión, la resolución depende del número de franjas

oscuras que posea en las cuales la reflexión se interrumpirá creando así un

tren de pulsos a la salida. La distancia d no debe ser mayor de 1 cm debido a

que mientras más lejos se encuentre la superficie, la salida de corriente del

colector se hace más pequeña, por lo que la distancia óptima para el acople se

encuentra entre 0.5cm y 1cm proporcionando una salida de 50mA a 5mA

respectivamente.

2.2.2 Modo de conteo por detección directa.

Similar a lo descrito en el capítulo anterior referente a la implementacion del

codificador óptico funcionará el sensor de detección directa, el mismo revelará

las ranuras que se encuentran en la parte superior del disco. La

implementación es con un diodo infrarrojo y un foto-transistor por separado los

cuales quedan alineados y con un espacio entre ellos de 1.5cm a 2cm por el

que gira el disco interrumpiendo la señal. Esta configuración implementada es

con el objetivo de tener redundancia de hardware.

2.2.3 Circuito de salida.

Hay varias formas de implementar el circuito de salida, en la hoja de datos del

sensor se encuentran algunas configuraciones básicas. Así mismo, existen

varios tipos de salidas discretas o digitales que se denominan de esta manera

por tener dos estados (Alvarado, 2004). La señal se introducirá a un

microcontrolador como se muestra en la figura 2.3 por lo que es conveniente

pasar las salidas a través de un circuito Schmitt Trigger2 para conformar las

señales; este circuito se encuentra dentro del bloque de salida y el filtro es con

el objetivo de eliminar los picos producidos por el transistor conectado a la

salida del sensor.

2 Convierte una tensión de entrada de variación lenta en una onda de salida

con cambio brusco.

Page 36: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

24

Figura 2.3: Diagrama en bloque del sensor de rpm.

En la figura 2.4 se muestra el circuito electrónico diseñado, el cual se simuló

empleando el software de diseño Proteus v7.6 que está designado para la

simulación de circuitos electrónicos y la creación del respectivo PCB.

El circuito es igual para las dos implementaciones, tanto de detección directa

como reflexiva. En el integrado CNY70 el emisor infrarrojo emite una señal que

será reflejada por el disco haciendo que la misma llegue al foto-transistor. Al

pasar una franja negra el haz infrarrojo se corta, el transistor Q1 que estaba en

estado de saturación conectando a R5 se abre, enviando a través de R5 un

pulso al detector de flancos que es un Schmitt Trigger inversor encargado de

limpiar la señal de salida y, como resultado se obtiene un pulso nítido libre de

ruido, como es un inversor la señal se invierte otra vez para obtener un uno

cuando se detecte la franja.

Similar ocurre con el de detección directa, para obtener un uno cuando pase

una ranura se invierte la salida una sola vez, de manera que al girar el disco se

genere un tren de pulsos con una frecuencia proporcional a la velocidad con

que rota el motor, el cual es enviado al DsPIC para calcular las rpm del motor

de propulsión. La amplitud de los "1" de la salida es igual a la tensión de

alimentación que puede estar entre 5 y 12 voltios. En el circuito impreso

diseñado se puede seleccionar entre ambos voltajes mediante el empleo de

jumpers de selección.

Page 37: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

25

Figura 2.4: Diagrama electrónico del sensor de rpm.

Una vez montado el circuito electrónico se realizaron un conjunto de pruebas,

en el cual se utilizó un motor con un variador de frecuencia encargado de

cambiar las rpm del motor y un tacómetro acoplado al otro extremo del eje para

comprobar la forma de la onda a la salida del sensor implementado, el

hardware utilizado para la adquisición de los datos es una tarjeta Humsoft 614

en la cual el tiempo de muestreo escogido fue el máximo posible siendo este

de 1ms.

En la prueba pudo observarse que entre ambas medidas existía un margen de

error, debido al tiempo de muestreo que nos brinda la tarjeta de adquisición; el

tren de pulso generado como se muestra en la figura 2.5 queda bien

conformado brindando de esta forma una salida óptima para enviar al DsPIC y

realizar la programación necesaria para obtener las rpm que se utilizarán en la

navegación asistida por modelo matemático.

Para la prueba el motor rota a 900 rpm obteniéndose de un flanco de subida a

otro un tiempo aproximado de 0.017s en la implementación directa donde el

disco consta de cuatro ranuras, tal y como se muestra en la figura 2.5; en la

Page 38: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

26

detección reflexiva con dos franjas oscuras en el disco el tiempo es de 0.034s,

como se observa en la figura 2.6.

Figura 2.5: Tren de pulsos de la implementación directa.

Figura 2.6: Tren de pulsos de la implementación reflexiva.

Al obtener los tiempos que demoran las señales de un flanco al otro se puede

utilizar la ecuación 2.1 para calcular las rpm del motor de propulsión. Donde n

es el número de ranuras o franjas oscuras con que cuenta el disco y t el

tiempo.

60RPM (2.1)( * )n t60RPM RPM 60RPM 60

( * )RPM ( * )RPM ( * )n t( * )RPM ( * )RPM n tRPM ( * )RPM

2.2.4 Errores.

En la implementación del sensor analizado hasta el momento se puede

observar que las principales fuentes de error de este método son originadas a

Page 39: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

27

partir de un mal acople mecánico del disco al eje del motor de propulsión

causando esto que los sensores no queden a las distancias especificadas para

cada uno. Si la superficie no refleja suficiente el haz de luz emitido o el cambio

de la zona oscura a la otra no está definido claramente, provoca que el sensor

de una salida errónea. Teniendo en cuenta lo antes expuesto las franjas y

ranuras diseñadas deben ser simétricas y estar separadas a la misma

distancia.

Un aumento de las rpm trae consigo que el tiempo entre las ranuras disminuya,

provocando esto que el sensor tenga que ser capaz de muestrear a mayor

frecuencia por lo que es factible disminuir a dos las ranuras si se desea

aumentar la velocidad del motor a más de 1800 rpm

2.3 Ingeniería inversa del Vetus Fluxgate Compass.

Como compás adicional para la detección de rumbo del CINAV-AUV se emplea

el Vetus Fluxgate Compass, este tipo de compás utiliza un detector de

inducción magnética (fluxgate), para leer electrónicamente el campo magnético

de la Tierra. La exactitud del rumbo depende de la instalación del mismo, el

cual queda alineado con la proa del vehículo. Esta información la brindan sus

salidas con voltajes analógicos referentes a los ángulos.

El rango de voltaje de las salidas varía desde los 1.5V a 3.5V, esta variación es

la que se produce al variar la posición del instrumento de estar alineado con el

campo magnético de la tierra a estar opuesto con el mismo. La diferencia se

corresponde con los valores de los senos y los cosenos que varían en este

rango, estas variaciones son sumadas a un voltaje fijo de 2.5V para aumentar

el valor de la señal a transmitir. El compás cuenta con dos bobinas

perpendiculares, para evitar una salida ambigua en una resolución de 360⁰. El

voltaje inducido en la bobina del compás varía en función del campo magnético

terrestre.

Las salidas del sensor serán óptimas hasta un ángulo de cabeceo aproximado

de 15⁰ y de balanceo de 30⁰ estos ángulos son los que puede medir por las

Page 40: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

28

salidas cinco y siete, con una precisión de ±1.5⁰. El mismo cuenta con siete

líneas de conexión como se muestra en la tabla 2.1.

Tabla 2.1: Conexión del Vetus Fluxgate Compass.

Cableado Rango Parámetro Unidad 1 Rojo 5 V 2 Azul 0 V 3 Amarillo 2.5 V. Referencia V 4 Morado 1.5 - 3.5 Rumbo Coseno 0 V 5 Blanco 1.5 - 3.5 Cabeceo Coseno 1 V 6 Marrón 1.5 - 3.5 Rumbo Seno 0 V 7 Negro 1.5 - 3.5 Balanceo Seno 1 V

2.3.1 Obtención de los ángulos de rumbo.

El rumbo se puede estimar con una relación entre los valores de las salidas

cuatro y seis de la tabla 2.1. Las salidas analógicas de la cuatro a la siete se

comportan como se definen en las ecuaciones (2.2) y (2.3).

cos (2.2)y refV V cos cos y refV Vy refV Vy ref cos

sin (2.3)x refV V sin sin x refV Vx refV Vx ref sin

Para la obtención del rumbo en grados se utiliza la ecuación 2.4, evitando de

esta forma que se obtenga una salida ambigua.

arctan (2.4)x ref

y ref

V VV VV VV V

arctan arctan V V

arctan x refarctan x refarctan x refV Vx refV Vx refarctan x refarctan x refarctan x refV Vx refV Vx refarctan V V

arctan arctan arctan x refarctan V V

arctan arctan V V

arctan V Vy refV Vy refV Vy refV Vy refV Vy refV VV Vy refy refV Vy refy refV Vy refV Vy refV V

2.3.2 Corrección de errores.

El sensor se verá afectado principalmente por tres causas fundamentales

dentro de las que se encuentra el error provocado por una mala alineación,

objetos permanentemente magnéticos relativamente cerca y la presencia de

elementos ferro-magnéticos momentáneamente. En los dos primeros casos

es necesario un elemento externo capaz de proporcionar el rumbo para

Page 41: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

29

comprobar los mismos y corregirlos, en caso del último es necesario evitar la

presencia de esto elementos.

El error debido a una mala alienación se corrige como se muestra a

continuación con la ecuación 2.5, tomando la medición del compás y la

referencia externa de otro instrumento.

Compás Referencia Error

4° 0° +4°

98° 90° +8°

180° 180° 0°

272° 270° +2°

m xError de alineación = (2.5)2

á míne eError de alineación = á mínError de alineación = á mínError de alineación = e eá míne eá mínError de alineación = á mínError de alineación = e eError de alineación = á mínError de alineación =

Si el error es positivo se gira a la izquierda y en caso de ser negativo hacia la

derecha, para mayor exactitud se puede realizar la prueba cada 45°. Cuando

es menor de 10° es debido a un problema de precisión al ubicar el instrumento,

cuando es mayor es provocado por objetos magnéticos cerca.

Una de las ventajas de procesar la información brindada por el compás es que

si se conoce la desviación provocada por estos elementos se puede corregir la

información mediante el uso de las ecuaciones, es decir si se observa una

desviación hacia cada uno de los puntos cardinales se le suma o resta el valor

en cada uno de los cuadrantes.

2.4 Hardware de adquisición.

La arquitectura de hardware del segmento a bordo está compuesta

esencialmente por dos unidades de cómputo y una unidad de potencia. Las

unidades de cómputo son: una computadora industrial PC-104 y un sistema

empotrado basado principalmente en microcontroladores, específicamente

DsPIC33FJ64MC804 de Microchip. Estas dos unidades se dividen, el trabajo

de adquisición de datos desde los sensores y las tareas de navegación y

control (Guerra, 2010).

Page 42: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

30

La función principal de la unidad DsPIC es la adquisición de varios tipos de

sensores de origen analógico y digital. La ubicación del compás y el sensor de

rpm, se encuentra distante de la arquitectura central por lo que no es

conveniente enviar señales analógicas que serán afectadas por el motor de

propulsión. Por consiguiente, se incluirá en el propio sensor un DsPIC30F3013

para el procesamiento de las señales y enviar la información de los ángulos de

forma digital por el protocolo de comunicación RS-232, que es una variante de

comunicación serie.

DsPIC

33FJ6

4MC8

04

LED1

X1 8

MHZ

S1

DI/O1 - DI/O11

PWM1 – PWM4

Filtrado analógico

AI1 – AI8 SPI

Crista

lDI

/O

SPI

PROG1

Programación

Reset

DAC

Despl

azado

r de

nivel

SA1-SA2

± 10v

Desplazador de nivelUA

RT

RS0 – RS1

Encoder 1 - 2 SPI1-SPI2

ADC

Interface AUX

Figura 2.7: Estructura general de la unidad DsPIC.

La estructura general de la unidad DsPIC es como se muestra en la figura 2.7 a

la cual se le enviará la información del sensor de rpm por las entradas digitales

que posee la misma, este diseño consta de dos DsPIC uno es el encargado de

procesar las entradas analógicas y enviar esta información por SPI y la otra

parte es la encargada de la comunicación con los demás periféricos del CINAV-

AUV. Las señales provenientes del compás serán enviadas por comunicación

RS-232 a la PC 104 que es la encargada de la navegación.

Page 43: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

31

El microcontrolador que se incluye en el compás destaca por su capacidad de

procesamiento, versatilidad y diversidad de interfaces disponibles. Pueden

alcanzar un desempeño máximo de 30 millones de instrucciones por segundo

(MIPS), con un oscilador configurable para distintas frecuencias de ejecución.

Siendo el DsPIC30F3013 de los específicos para sensores.

El DsPIC presenta 2 KB de RAM y 1 KB de EEPROM (no volátil) permitiendo

esto almacenar el valor de corrección del rumbo, cuenta con un amplio set de

instrucciones y ocho niveles de prioridad de interrupción que permiten el diseño

de un software de altas prestaciones. Entre los periféricos incluidos presenta

tres temporizadores de 16 bit cada uno.

El DsPIC posee diez entradas analógicas con un conversor A/D de 12 bit de

resolución y velocidad de conversión de 200 Ksps (kilo muestras por segundo)

con una precisión de 0.0012V por bits, satisfaciendo las necesidades de la

aplicación. De igual manera, presenta las interfaces de comunicación serie más

comúnmente empleadas en la actualidad por los distintos dispositivos

empleados en sistemas empotrados, como son: dos módulos UART (Universal

Asynchronous Receptor Transmitter), un SPI (Serial Peripheral Interface), un

I2C (Inter-Integrated Circuit).

En la figura 2.8 se puede observar la arquitectura del DsPIC a emplear en el

sensor de rumbo donde se utilizarán dos líneas analógicas para la

comunicación con el compás, las que serán muestreadas a 1KHz y dos

digitales para incluir un sensor de presencia de agua siendo el mismo dos

electrodos, que en caso de que el agua penetre dentro se cortocircuitarán. Es

necesario incluirlos ya que el compás se encontrará ubicado en el exterior del

vehículo. Se utilizará la interfaz RS-232 para la comunicación entre el sensor y

la PC-104 encargada de procesar la información digitalizada del sensor. Para

lograr la comunicación es necesario el empleo de un integrado MAX232

encargado de trasladar los voltajes.

Sobre el desempeño del chip influye directamente la frecuencia del cristal de

cuarzo utilizado, por lo que se utiliza un cristal de 8MHz y el oscilador se

configuró para trabajar a 32 MIPS.

Page 44: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

32

Programación

ResetS1AI0-A

I5

ADC

Cristal8 MHZ

DI/O

DI/O

0-DI/O

2

RS-232

DsP

IC30

F301

3

PC-104Desplazador De Nivel

Filtrado Analógico

Figura 2.8: Arquitectura del DsPIC30F3013.

2.4.1 Filtrado de las señales analógicas.

El microcontrolador como antes se comentó posee diez entradas analógicas

con un rango de señal de 0 – 5v, de las cuales se utilizan dos en el compás

(AI0 – AI1). Cada entrada tiene un acondicionamiento analógico conformado

por un filtro de segundo orden pasó bajo con la función principal de eliminar el

efecto de “aliasing”. En la figura 2.9 se ilustra el circuito de acondicionamiento.

Figura 2.9: Circuito de acondicionamiento.

Page 45: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO II SENSORES A TRABAJAR

33

2.5 Consideraciones finales.

A lo largo de este capítulo se han sentado las bases para la implementación del

software necesario para la estructura de hardware de cada sensor a incluir en

el CINAV-AUV.

Se diseñó una estructura electrónica a partir de los sensores ópticos con que

se contaba, capaz de generar un tren de pulso con un período entre flancos

proporcional al número de ranuras del disco y a la velocidad con que rota el

motor de propulsión, quedando esto registrado en las gráficas de la sección

2.2.3.

Mediante el estudio del Vetus Fluxgate Compass quedaron definidas las

ecuaciones para la conversión de los voltajes de salidas a grados, así como el

significado de cada una de sus salidas.

Se desarrolló una estructura a partir del DsPIC30F3013 capaz de procesar la

información brindada por el compás.

Page 46: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III

Page 47: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

34

3. IMPLEMENTACIÓN Y RESULTADOS

En el presente capítulo se describe lo relacionado con la implementación del

software a utilizar y la validación de las mediciones de ambos sensores, así

como comprobar su integración al resto de los sistemas de hardware y

software, implementando la estructura del hardware para la adquisición y

procesamiento de la información proveniente del compás y el sensor de rpm.

3.1 Adquisición de la información del sensor de rpm.

En la navegación basada en el modelo matemático del AUV se requiere la

medición de la velocidad de rotación del motor de propulsión. En el capítulo

anterior se mostró el sensor diseñado con el propósito de medir esta variable,

el mismo trabaja de forma similar a un encoder. Con una interface digital

configurable a voltajes entre 5v (TTL compatible) o 12v, la señal trasmitida

corresponde a un tren de pulsos, cuya frecuencia es proporcional a la velocidad

de rotación del motor.

La arquitectura de software en la unidad DsPIC, encargada de procesar la

información del sensor, está conformada básicamente por cinco procesos

fundamentales y varios subprocesos. En el proceso de inicialización se procede

a la configuración inicial de los componentes internos de hardware y software

en el procesador, así como de los periféricos externos al mismo. De esta tarea

se deriva el posterior funcionamiento del sistema, por lo que se realiza en la

subrutina principal y se produce una sola vez en el transcurso de la misma. La

mayor parte de dichos procesos están constituidos precisamente por subrutinas

de atención a interrupción y no dependen del flujo secuencial en el programa

(Guerra, 2010).

Cada uno de estos procesos está organizado según su nivel de prioridad y el

tiempo en que se ejecuta, en algunos casos son periódicos y en otros

aperiódicos. En la figura 3.1 se ilustra el diagrama de flujo del proceso cuatro,

que es el encargado de procesar la información procedente del sensor de rpm.

La señal se introduce a la unidad DsPIC por medio del canal digital DI/O0 como

se muestra en la figura 2.7 que corresponde en el chip a la entrada del

Page 48: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

35

contador dos, y es utilizado en la medición de frecuencia. El contador es

ajustado para que produzca una interrupción cada tres pulsos, lo cual garantiza

menor tiempo de uso del procesador; en la subrutina de atención a interrupción

se realizan dos procesos esencialmente: el primero es capturar el tiempo en

que se produjo la interrupción; el segundo, ejecutar la diferencia entre el tiempo

actualmente capturado y el anterior. Con esto se obtiene el período entre

interrupciones y con la ecuación 2.4 se obtienen las rpm.

Interrupción

contador2

Diferenciar tiempos

entre interrupción

Calcular RPM

Retorno de

interrupción

Prioridad 4 Aperiódico

Figura 3.1: Diagrama de flujo del sensor de rpm.

La ventaja de la utilización de interrupciones para detectar el estado de un pin,

es que el programa no tiene que estar comprobando su estado continuamente;

cuando el pin se activa se genera una interrupción que desviará

momentáneamente el funcionamiento del programa, ejecutará el segmento de

código apropiado para ese evento y continuará la ejecución nominal del

programa.

3.2 Adquisición de la información del Vetus fluxgate compass.

El hardware encargado de procesar los datos del compás fue diseñado en el

capítulo anterior, y se basa en un DsPIC30f3013. Las entradas analógicas

serán muestreadas con una frecuencia de 1Kz y la información será enviada

por RS-232 a la PC.

3.2.1 Implementación del software.

El sistema al que se integrará el compás necesita que la información brindada

por este sea fiable, por lo que se decide agregarle un DsPIC al sensor con el

Page 49: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

36

objetivo digitalizar la información y de que sea capaz de comunicarse con los

demás medios de hardware por el protocolo antes mencionado.

La programación se realizó utilizando el entorno de programación MPLAB

brindado por Microchip. El programa cuenta con cinco etapas como se puede

observar en la figura 3.2, para la programación se muestrean las salidas cuatro

y seis que son las necesarias para el rumbo. La figura 3.2 muestra un diagrama

de flujo con las etapas del software diseñado para la unidad DsPIC

correspondiente.

Conversión a grados

Obtención del rumbo 1Kz

Inicializar conversor A/D

Programa Principal

Adquisición de señales

Enviar señal por RS-232

Retornar

Calibración

Figura 3.2: Diagrama de flujo para el Vetus Fluxgate Compass.

La primera de las etapas es la inicialización del conversor A/D siguiéndole la

adquisición de las señales desde el sensor por las entradas AI0 a AI1. Es

necesario obtener al menos por primera vez, la información del rumbo de un

elemento externo fiable para conocer el efecto del casco del vehículo, y de esta

forma poder corregir la desviación provocada. Por lo que se orientará el

vehículo hacia el norte y una vez que se encuentre ubicado en esa dirección

se enviará un código por el puerto serie para calibrar el instrumento. Donde se

calcula la diferencia entre el rumbo del sensor y el norte, luego este error será

almacenado en la memoria EEPROM del DsPIC, haciendo el proceso anterior

solo una vez, al terminar se informa a la PC-104 que la calibración ha sido

realizada.

Page 50: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

37

El diagrama de flujo de la etapa para calcular el rumbo se muestra en la figura

3.3.

R=atan(Vx/Vy)

Cálculo del rumbo

R=atan(Vx/Vy)

Vx (+)Vy (+)

R =180⁰+atan(Vx/Vy)

Si

Si

Si

No

No

SS

Vx (+)Vy (-)

Vx=2.5-AI0Vy=2.5-AI1

Fin

Vx (-)Vy (-)

R =atan(Vx/Vy)-180⁰

No

Si

Figura 3.3: Diagrama de flujo para el cálculo de rumbo.

En esta etapa se resta 2.5 menos los valores de voltaje de las entradas AI0 y

AI1 para obtener los valores entre los que puede estar el seno y el coseno

dígase de -1 a 1 y luego se procede a comparar los voltajes analógicos

obtenidos Vx y Vy con el objetivo de calcular el rumbo del instrumento, el

mismo se enviará a la PC-104 en un formato de 0⁰ a ±180⁰ para poder

comparar con la IMU.

3.2.2 Comunicación RS-232.

RS-232 es una interface de comunicación estándar y una de las más usadas

en temas de diseños empotrados, ya que permite la comunicación con

dispositivos a distancias hasta de 15m con gran fiabilidad, además de ser

utilizada en múltiples tipos de sensores y dispositivos. En el caso que ocupa a

la investigación, la comunicación con la computadora industrial (unidad PC-

104) se produce mediante esta vía.

El microcontrolador implementa lógica TTL con niveles de 0 – 5v mientras

que RS-232 tiene lógica negada, bipolar y con niveles de voltaje que varían de

Page 51: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

38

±3v a ±25v. Para establecer una compatibilidad es necesario adicionar al

diseño un componente externo desplazador de nivel (Catsoulis, 2005). Por lo

que se hace necesario el empleo del circuito integrado MAX232, el mismo

ofrece dos trasladores de nivel sin necesidad de otros componentes externos

para su funcionamiento, se energiza con 5v y trabaja con velocidades hasta

120 Kb/s.

En la tabla 3.1 se muestran los parámetros de configuración del puerto serie

para la comunicación.

Tabla3.1: Configuración del puerto.

Parámetro Configuración Aplicación

Puerto serie

(RS-232)

1-bit de parada, sin paridad,8 bits de

datos, velocidad 115200

Comunicación

con PC-104

3.3 Validación de las mediciones.

Para garantizar la fiabilidad y comprobar las prestaciones de los sensores

diseñados, se realizó un grupo de pruebas comparativas contra un grupo de

elementos profesionales de características conocidas. Para realizar dichas

pruebas se utilizaron las arquitecturas de hardware diseñadas para cada

sensor. Se obtienen los datos de esta forma y luego, se comparan con la

información brindada por los elementos profesionales, obteniéndose los errores

medios y varianza de las mediciones.

3.3.1 Sensor de rpm.

Para comprobar el correcto funcionamiento del sensor de rpm se utiliza un

variador de frecuencia LG-iG5 con el objetivo de ir variando la velocidad del

motor escogido para la prueba.

Como elemento comparativo fue seleccionado un tacogenerador capaz de

medir la velocidad con una precisión de ±0.5%, al mismo se le conecta un

voltímetro que mide aproximadamente 120V para una salida de 1800 rpm el

cual tiene una exactitud de ±0.2%. Teniendo en cuenta que el error en la

Page 52: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

39

medición es serie, se puede calcular el error total con la ecuación 3.1 por lo que

la medición tendrá una exactitud de ±0.54%.

2 21 2 (3.1)error x x2 21 2 (3.1)error x x1 2x x1 2

El sensor diseñado se conectó a la unidad DsPIC y la información fue enviada

a la PC por el protocolo de comunicación serie RS-232 el mismo cuenta con un

rango de trabajo entre 10 y 1800 rpm. Para realizar la prueba se fue variando la

velocidad obteniéndose los resultados mostrados en la figura 3.4.

Figura 3.4: Resultados obtenidos.

Con los resultados obtenidos puede observarse que existe un error entre las

mediciones del tacogenerador y la implementación diseñada, pero teniendo en

cuenta lo anteriormente expuesto sobre la exactitud del instrumento de

comparación, esta diferencia puede ser menor. La diferencia entre el modo de

detección reflexivo y el directo es de solo unas décimas.

Para calcular el valor del error cometido es necesario realizar varias

mediciones consecutivas bajo las mismas condiciones de operación, por lo que

Page 53: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

40

se energizará el motor y luego se apagará, realizando la operación entre cinco

y diez veces que es lo recomendado. En la tabla 3.2 se muestran los resultados

de las mediciones contra una señal de entrada de 900 rpm, obteniéndose un

error del instrumento de 0.75% en ambas implementaciones.

Tabla3.2: Resultados para comprobar la fiabilidad.

Parámetro Profesional Implementación diseñada Tacogenerador Reflexiva Directa

Rpm 3 900 893.3 893.5Rpm 3 900 894.6 893.1 Rpm 3 900 893.3 893.5 Rpm 3 900 892.7 893.5 Rpm 3 900 893.1 892.9 Rpm 3 900 893.3 893.5 Rpm 3 900 893.1 892.9 Rpm 3 900 892.7 893.1

X - 893.26 893.25 S2 - 0.3098 0.067

S - 0.556 0.259

Con las ecuaciones 3.2 y 3.3 se calculan la varianza y la desviación estándar

del sensor, debido a que estos parámetros dan un criterio respecto a la

precisión y fiabilidad del mismo, siendo fiable cuando las características del

instrumento no cambian apreciablemente en el tiempo y preciso cuando la

repetitividad en sus medidas conduce a resultados muy similares.

2

2 1

2

1

(3.2)1

(3.3)1

n

ii

n

ii

x xs

n

x xs

n

i 1 (3.211

i 1 (3.3)1

n

ix xix xi2x x

1

n

ix xix xi2x x

1

Con los resultados obtenidos del cálculo de la deviación estándar del

instrumento se puede observar que la implementación reflexiva tendrá el doble

de variación que la implementación directa. Esto es debido a que en la primera

Page 54: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

41

se utilizan dos franjas oscuras por vuelta para la obtención de las rpm y la

implementación directa cuenta con cuatro ranuras por vuelta. Siendo esta

ultima más fiable en la medida.

La clase de un instrumento, nos indica cual es el error absoluto máximo, el cual

se mantiene en cualquier lugar de la escala. Por lo que es importante realizar

los cálculos correspondientes para conocer dicha clase, con el uso de la

ecuación 3.4 se puede obtener la misma.

100 (3.4)XkXm

En la tabla 3.3 se muestran los resultados de las pruebas. Para calcular la

clase del instrumento Δx es la mayor separación entre el valor medido con el

instrumento y el valor real (1800-1791.4), siendo Xm (1800) el rango de

medición, por lo que se obtiene como resultado 0.47 en el peor de los casos,

teniendo en cuenta las normas cubanas la clase es 0.5.

Tabla 3.3: Resultados para comprobar exactitud.

ParámetroImplementación

Tacogenerador Reflexiva Directa Rpm 1 450 445.8 445.1 Rpm 2 600 594.8 595.0 Rpm 3 900 893.6 893.5 Rpm 4 1200 1192.2 1191.7 Rpm 5 1800 1791.9 1791.4

3.3.2 Sensor Vetus Fluxgate Compass.

Para comprobar el funcionamiento del sensor, este se conecta a la unidad

DsPIC30f3013 y se muestrean las entradas analógicas a 1Kz. Se obtuvo una

trama de los datos enviados a la PC y se simularon en MATLAB diseñando de

esta forma un filtro digital paso bajo de Butterworth, cuarto orden con una

frecuencia de corte de 100Hz, con el objetivo de mejorar la señal de salida

como se muestra en la figura 3.5.

Page 55: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

42

Figura 3.5: Señal de salida del Vetus Fluxgate Compass.

El sensor se ubicará a 1m de distancia del casco del vehículo por lo que es de

vital importancia conocer el efecto que tiene sobre el mismo. Se realiza una

prueba donde se ubica un motor trifásico a esa misma distancia, observándose

que el efecto sobre el compás es de aproximadamente 2⁰ como se muestra en

la figura 3.6. Este efecto se mantiene constante durante todo el movimiento del

sensor, es decir, si el elemento se mueve en conjunto con el sensor el efecto

es lineal en toda la trayectoria de giro del compás.

Figura 3.6: Efecto de elementos magnéticos.

Para comprobar el correcto funcionamiento del sensor, se realiza un análisis

similar al efectuado en la sección anterior y se utiliza como elemento

Page 56: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

43

comparativo los magnetómetros dentro de la IMU empleada en el CINAV-AUV.

En la tabla 3.4 se muestran los resultados obtenidos.

Tabla 3.4: Resultados para comparar exactitud.

Parámetro Instrumento

IMU Compás

Rumbo 1 30⁰ 31.4⁰

Rumbo 3 90⁰ 90⁰

Rumbo 4 180⁰ 178.8⁰

Rumbo 6 -30⁰ -31.4⁰

Rumbo 7 0⁰ 0.6⁰

Con estos resultados se observa que las medidas están cerca de los

parámetros reales, cometiéndose un error en la medición del instrumento de

±0.7% en la peor de la circunstancias; dígase 180⁰.

En la siguiente prueba se escoge un rumbo fijo y luego se varía finalizando en

el mismo punto para comprobar la fiabilidad del sensor. Los resultados

obtenidos se pueden observar en la tabla 3.5.

Tabla 3.5: Resultados para comprobar la fiabilidad.

Parámetro Instrumento

IMU Compás

Rumbo 1 30⁰ 31.43⁰

Rumbo 1 30⁰ 31.38⁰

Rumbo 1 30⁰ 31.12⁰

Rumbo 1 30⁰ 31.37⁰

Rumbo 1 30⁰ 31.42⁰

Rumbo 1 30⁰ 31.41⁰

Rumbo 1 30⁰ 31.71⁰

Rumbo 1 30⁰ 31.62⁰

X - 31.43⁰

S2 - 0.027⁰

S - 0.164⁰

Haciendo uso de las ecuaciones definidas en la sección anterior se realiza el

análisis del compás, donde se obtiene un valor de desviación estándar para la

medida de 0.16⁰ siendo este valor de gran precisión para el instrumento por lo

que realizando los cálculos pertinentes se obtiene que la clase es 0.1.

Page 57: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

44

3.4 Análisis económico.

Teniendo en consideración las características económicas de nuestro país, no

es viable la compra de un sensor que puede ser diseñado y construido en

nuestras instalaciones; de esta forma disminuye considerablemente el precio

de costo del mismo y se gana en soberanía tecnológica.

Un sensor para medir rpm compatible con TTL y CMOS puede ser obtenido en

el mercado internacional por un precio de 300USD mientras que, teniendo en

cuenta todos los recursos utilizados en la implementación del sensor diseñado

dígase: sensor óptico CNY70 (1USD); diodo de emisión infrarroja (0.5USD);

foto-transistor (0.7USD); integrado CD4093BE (0.5USD); transistores BC458

(0.25USD) y diseño del respectivo circuito impreso (5USD), el precio

aproximado para la implementación es de 10USD; por lo que queda justificado

el desarrollo del mismo debido a la disminución significativa de capital a utilizar.

Un compás magnético similar al utilizado, como el A4025 tiene un precio que

oscila cercano a los 100USD, pero en el caso que se aborda existe la

circunstancia de que ya se contaba con los sensores Vetus fluxgate pero con

una tecnología analógica y condiciones de operación desconocidas, por lo que

se realiza la ingeniería inversa y su actualización a digital, es necesario tener

en cuenta que para digitalizar la información se utilizó un DsPIC30f3013

(4.5USD) un MAX232 (1USD) para el traslador de nivel, un LM324 (0.5USD)

para la implementación del filtro analógico y el diseño del respectivo circuito

impreso (5USD) por lo que la actualización del sistema tiene un costo de

11USD siendo significativa la diferencia del costo comparado con el sensor

antes mencionado.

3.5 Consideraciones finales.

En el presente capítulo se realizó un sistema de software de bajo nivel con

características de trabajo en tiempo real para la adquisición y procesamiento de

la información del compás magnético.

Se realizaron pruebas experimentales para la validación de los sensores

implementados donde se pudo observar que los errores cometidos por estos se

Page 58: Actualización de la arquitectura de hardware del CIDNAV-AUV

CAPÍTULO III IMPLEMENTACIÓN Y RESULTADOS

45

encuentran dentro de los parámetros establecidos para el óptimo

funcionamiento del sistema y comparando los mismos con las normas vigentes

quedó definida su clase.

Tomando en cuenta todos los componentes y horas de investigación

empleadas en el desarrollo de los mismos se puede observar que la

disminución de los costos entre su adquisición en el mercado y su

implementación es significativa alcanzándose los mismos resultados.

Page 59: Actualización de la arquitectura de hardware del CIDNAV-AUV

CONCLUSIONES Y RECOMENDACIONES

46

CONCLUSIONES

El campo científico de los AUVs se ha caracterizado por una amplia riqueza

investigativa, debido a la variedad de sus aplicaciones y a la cantidad de

sistemas y sensores necesarios para realizar una navegación completamente

autónoma. Con la realización de la presente investigación se pudieron arribar a

las siguientes conclusiones:

Se toman como referencias los trabajos anteriores y hojas de datos de

los componentes electrónicos empleados para la realización del diseño,

proponiendo una solución para la aplicación en cuestión.

Se diseñó una arquitectura de hardware basada en el DsPIC30f3013

capaz de cumplir los requisitos impuestos por el sistema en la obtención

de la información procedente del Vetus Fluxgate Compass y se

comprobó la integración del mismo al resto de los sistemas de

hardware.

Se implementó el sensor óptico necesario para medir las rpm del motor

de propulsión principal; el diseño se realizó con dos sensores ópticos

con el objetivo de tener redundancia en el hardware y una estructura

similar a un encoder, el cual a la salida entrega un tren de pulsos con

una frecuencia proporcional a la velocidad con que rota el motor.

Se validaron las mediciones de ambos sensores mediante un grupo de

pruebas comparativas contra un grupo de elementos profesionales y se

comprobó la integración de los mismos al resto de los sistemas de

hardware y software.

En sentido general, se logró incluir en la arquitectura de hardware del

CIDNAV – AUV el compás magnético para la medición del rumbo y el

sensor de rpm diseñado para medir las revoluciones del motor

propulsión, ambas variables necesarias para la navegación asistida por

modelo matemático. Todo lo expuesto anteriormente permite afirmar que

se lograron cumplir los objetivos trazados al comienzo de la

investigación.

Page 60: Actualización de la arquitectura de hardware del CIDNAV-AUV

CONCLUSIONES Y RECOMENDACIONES

47

RECOMENDACIONES

A partir de la importancia que ha relevado la investigación se recomienda:

Continuar el estudio del sensor Vetus Fluxgate Compass con el objetivo

de obtener una ecuación que permita medir las inclinaciones con una

precisión aceptable.

Hacer uso de los sensores implementados para el CINAV-AUV

permitiendo de esta forma comprobar el funcionamiento de los mismos

en condiciones reales de operación.

Page 61: Actualización de la arquitectura de hardware del CIDNAV-AUV

REFERENCIAS BIBLIOGRÁFICAS

48

Alvarado, M. I. (2004). Sensores de Posición. Descripción, selección y uso.

Conferencia de Física. Universidad de lo Andes (ULA). Venezuela.

Cañizares, J. R. (2010). Modelado y control del vehículo autónomo sumergible

del CIDNAV. Trabajo de Diploma.

Catsoulis, J. (2005). Designing Embedded Hardware, O'Reilly.

Fjellstad, O. (1994). Control of unmanned underwater vehicles in six degrees of

freedom a quaternion feedback approach. Tesis doctoral.

Fossen, T. I. and A. Ross (2006). Advances in unmanned marine vehicles.

Chap. Nonlinear modelling, indentification and control of UUVs, pp. 13-

42. Vol. 69. Peter Peregrinus LTD. Great Britain.

Gorset, J. E. (2007). Nonlinear model-based control of slender body

AUVs.Doctoral thesis.

Guerra, C. E. (2010). Diseño e implementación de hardware y software de bajo

nivel para el vehículo submarino autónomo. Trabajo de diploma Trabajo

de Diploma.

Hegrenaes, O., O. Hallingstad, et al. (2007). "Towards Model-Aided Navigation

of Underwater Vehicles." Modeling, Identification and Control 28(4): 10.

Hernández, L., Y. Valeriano, et al. (2011). Modelado y control del cidnav − auv.

. In: XIV Convención y Feria Internacional Informática. X Simposio

Internacional de Automatización. MIC. La Habana.

Kapaldo, A. J. (2005). Gyroscope Calibration and Dead Reckoning for

Autonomous Underwater Vehicle. Tesis de Maestria.

Lemus, J. L. R. (2011). Software de navegación y guiado en tiempo real para

Vehículo Autónomo Sumergible.Trabajo de Diploma.

Page 62: Actualización de la arquitectura de hardware del CIDNAV-AUV

REFERENCIAS BIBLIOGRÁFICAS

49

Lin, Z. and G. Wei (2004). The Experimental Study on GPS/INS/DVL Integration

for AUV Position Location and Navigation Symposium. PLANS 2004,

Monterey, USA, IEEE Xplore.

Martínez, A., Y. Rodríguez, et al. (2010). Hardware and software architecture

for auv based on low-cost sensors. In: The 11th International Conference

on Control, Automation, Robotics and Vision,ICARCV. Nanyang

Technological University of Singapore.IEEE Xplore. Singapore.

Martínez, A. S. L. (2012). Enhancement of the mathematical linear model of a

UAV thru the use of a expectation maximization algorithm.

Martínez, M. E. (2009). Desarrollode sistemas de control para autopiloto de

avión de pequeño porte. Trabajo de Diploma Trabajo de Diploma.

Mohinder, E. G. (2007). Global Positioning Systems Inertial Navegation and

Integration. Control Systems Technology.John Wiley and Sons.

Pineda, L. M. (2009). Modelo matemático de un avión autónomo. Trabajo de

diploma.

Rodríguez, Y. and J. L.Ramos (2011). Sistema de software para supervisión y

control de vehículo autónomo subacuático. In: XIV Convención y Feria

Internacional Informática. X Simposio Internacional de

Automatización.MIC. La Habana.

Salinas, R. M. (2006). Soft-Computing and Computer Vision Techniques

Applied to Autonomous robot Navigation and Human-Robot

Interaction.Tesis Doctoral.

Sosa, R. (2010). Sistema de Navegación Inercial Asistida por Modelo Dinámico

para Vehículo Autónomo Sumergible.Trabajo de Diploma.

Valeriano, Y., A. Martínez, et al. (2012). "Dynamic model for an autonomous

underwater vehicle based on experimental data." Mathematical and

Computer Modelling of Dynamical Systems.

Page 63: Actualización de la arquitectura de hardware del CIDNAV-AUV

REFERENCIAS BIBLIOGRÁFICAS

50

Wernli, R. L. (2000). Auv commercialization-who's leading the pack?.Technical

report. SPAWAR Systems Center San Diego. California, United States.

Woodman, O. J. (2007). An introduction to inertial navigation. Technical Report.

University of Cambridge. United Kingdom.

Page 64: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

51

ANEXOS

Anexo I: Diseño del hardware del sensor de rpm.

Figura A1: PCB del diseño del hardware del sensor de rpm.

Figura A2: Layout del diseño del hardware del sensor de rpm.

Page 65: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

52

Figura A3: Hardware del sensor de rpm.

Figura A4: Diseño del hardware del sensor de rpm.

Page 66: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

53

Anexo II: Diseño del hardware de la unidad DsPIC para el Vetus Fluxgate.

Figura A5: PCB del diseño del hardware de la unidad DsPIC..

Figura A6: Layout del diseño del hardware de la unidad DsPIC.

Page 67: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

54

Figura A7: Hardware de la unidad DsPIC.

Figura A8: Diseño del hardware de la unidad DsPIC.

Page 68: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

55

Anexo III: Código fuente del programa implementado para el fluxgate.

Funtions.h

unsigned int Baud(unsigned long int,unsigned long int); unsigned int Period_ms(double,int,unsigned long); void Init_Main(void); unsigned int ADC_Read(char); void WriteUART1M(unsigned int); void Delay_ms(unsigned int);

void SendByte(char,char); // tcy ,for FCY = 25.9424 T = us unsigned int Send_Dataf(char, double); // tcy ,for FCY = 25.9424 T = us void Send_Datai(char,int); void SendfloatInChar(double ) ;

typedef struct

{

double AOinv; double *A; double *B; double C[5]; double R[5]; }Filter;

void FilterInit(Filter *,double *,double *); double FilterLowPass(Filter *,double);

Funtions.c

#include<p30f3013.h> #include <uart.h> #include <spi.h> #include <adc12.h> #include <timer.h> #include <outcompare.h> #include <ports.h> #include <string.h> #include <math.h> #include "Funtions.h" unsigned long ModemBaudRate = 115200; #define FCY 32000000 unsigned int Baud(unsigned long int baud,unsigned long int fcy)

Page 69: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

56

{ return fcy/(16*baud) -1; } unsigned int Period_ms(double period,int scaled,unsigned long fcy) { unsigned long Prx = period*fcy/(scaled*1000.0); return Prx; } void WriteUART1M(unsigned int data) { WriteUART1( data); while(BusyUART1()); } void WriteUART2M(unsigned int data) { WriteUART2( data); while(BusyUART2()); } void Delay_us(unsigned int delay) { unsigned int index; delay -= 1; for(index = 0;index <delay;index++) { asm volatile("repeat #28"); Nop(); } asm volatile("repeat #2"); Nop(); } void Delay_ms(unsigned int delay) { unsigned int index,uindex;

for(index = 0;index <delay;index++) {

for(uindex = 0;uindex <1000;uindex++) { asm volatile("repeat #28"); Nop(); } } } unsigned int ADC_Read(char chanel) { SetChanADC12((ADC_CH0_POS_SAMPLEA_AN0|chanel)& ADC_CH0_NEG_SAMPLEA_NVREF ); ADCON1bits.SAMP = 1;

Page 70: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

57

Delay_us(50); ADCON1bits.SAMP = 0; while (BusyADC12()); return ADCBUF0; } void SendByte(char Port, char Value) if (Port == 1) WriteUART1M(Value); else WriteUART2M(Value); } unsigned int Send_Dataf(char Port, double Value) { char* Data = &Value; unsigned int Cs; char Byte1; char Byte2; char Byte3; char Byte4; Byte1 = *(Data + 0); Byte2 = *(Data + 1); Byte3 = *(Data + 2); Byte4 = *(Data + 3); Cs = Byte1 + Byte2 +Byte3 +Byte4; if (Port == 1) { WriteUART1M(Byte4); WriteUART1M(Byte3); WriteUART1M(Byte2); WriteUART1M(Byte1); } else if (Port == 2) { WriteUART2M(Byte4); WriteUART2M(Byte3); WriteUART2M(Byte2); WriteUART2M(Byte1); } return Cs; } void Send_Datai(char Port, int Value)

Page 71: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

58

{ char* Data = &Value; char Byte1; char Byte2; Byte1 = *(Data + 0); Byte2 = *(Data + 1); if (Port == 1) { WriteUART1M(Byte2); WriteUART1M(Byte1); } else if (Port == 2) { WriteUART2M(Byte2); WriteUART2M(Byte1); } } void SendBuffer(char Port,char * Buffer,char Length) { char index; for(index = 0;index < Length;index++) { SendByte(1,Buffer[index]); } } char IntToStr(long Number,char * Output) { char Temp[12] = {0}; char Index,Index1 = 0; unsigned long quotient; if(Number < 0) { Output[0] = '-'; Number *= -1.0;Index1++; } for(Index = 11;Index > 0;Index--) { quotient = Number/10; Temp[Index] = (Number%10) + 48; Number = quotient; if(quotient == 0)break; } for(Index = Index;Index < 12;Index++) { Output[Index1++] = Temp[Index];

Page 72: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

59

} return Index1; } char FloatToStr(double Number,char * Output) { char Index,Index1 = 0; unsigned long Temp = 0; double Mantiza = 0; Index = IntToStr(Number,Output); if(Number < 0)Number *= -1.0; Temp = Number; Mantiza = (Number - Temp)*10E6; Output[Index] = '.'; Index1 = IntToStr(Mantiza,&Output[Index+1]); return (Index + Index1) ; } void SendfloatInChar(double Number) { char Float[7]; FloatToStr(Number,Float); SendBuffer(1,Float,5); } void FilterInit(Filter *F,double *Num,double *Den) { F->B = Num; F->A = Den; F->AOinv = 1.0/F->A[0]; F->C[0] = F->C[1] = F->C[2] = F->C[3] = F->C[4] = F->R[0] = F->R[1] = F->R[2] = F->R[3] = F->R[3] = 0; } double FilterLowPass(Filter *F ,double Variable) { F->R[0] = Variable; F->C[0] = (F->B[0]*F->R[0] + F->B[1]*F->R[1] + F->B[2]*F->R[2] + F->B[3]*F->R[3] + F->B[4]*F->R[4]

Page 73: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

60

- F->A[1]*F->C[1] - F->A[2]*F->C[2] - F->A[3]*F->C[3] - F->A[4]*F->C[4] )* F->AOinv F->R[4] = F->R[3]; F->R[3] = F->R[2]; F->R[2] = F->R[1]; F->R[1] = F->R[0]; F->C[4] = F->C[3]; F->C[3] = F->C[2]; F->C[2] = F->C[1]; F->C[1] = F->C[0]; return F->C[0]; } void Init_Main(void) { ConfigIntUART1(UART_RX_INT_EN & UART_RX_INT_PR6 & UART_TX_INT_DIS & UART_TX_INT_PR0 OpenUART1(UART_EN & UART_IDLE_CON & UART_DIS_WAKE & UART_DIS_LOOPBACK & UART_DIS_ABAUD & UART_NO_PAR_8BIT & UART_1STOPBIT & 0xFBFF,UART_INT_TX_BUF_EMPTY & UART_TX_PIN_NORMAL & UART_TX_ENABLE & UART_INT_RX_CHAR & UART_ADR_DETECT_DIS & UART_RX_OVERRUN_CLEAR & 0xFFE0,Baud(ModemBaudRate,FCY)); ConfigIntTimer1(T1_INT_PRIOR_2 & T1_INT_ON); OpenTimer1(T1_ON & T1_GATE_OFF &T1_PS_1_1 & T1_SOURCE_INT,Period_ms(1,1,FCY)); OpenADC12(ADC_MODULE_ON & ADC_IDLE_CONTINUE & ADC_FORMAT_INTG & ADC_CLK_MANUAL & ADC_AUTO_SAMPLING_OFF & ADC_SAMP_OFF , ADC_VREF_AVDD_AVSS & ADC_SCAN_OFF & ADC_SAMPLES_PER_INT_1 & ADC_ALT_BUF_OFF & ADC_ALT_INPUT_OFF, ADC_SAMPLE_TIME_1 & ADC_CONV_CLK_SYSTEM & ADC_CONV_CLK_32Tcy,ENABLE_AN0_ANA & ENABLE_AN1_ANA ,SCAN_NONE ); }

Fluxgate.c

#include<p30f3013.h> #include <uart.h>

Page 74: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

61

#include <spi.h> #include <adc12.h> #include <timer.h> #include <outcompare.h> #include <ports.h> #include <string.h> #include <math.h> #include <libpic30.h> #include "Funtions.h" _FOSC( CSW_FSCM_OFF & XT_PLL16 ); _FWDT( WDT_OFF ); _FBORPOR( PBOR_OFF & BORV_45 & MCLR_EN ); _FGS( CODE_PROT_OFF ); #define FCY 32000000 #define FlagIntUart1 IFS0bits.U1RXIF #define FlagIntTimer1 IFS0bits.T1IF #define COM1InterruptEvent __attribute__((__interrupt__,auto_psv)) _U1RXInterrupt #define Timer1InterruptEvent __attribute__((__interrupt__,auto_psv)) _T1Interrupt Filter Butter4th; const double Num[5] = {5.484742791517482e-006 , 2.193897116606993e-005 , 3.290845674910489e-005,2.193897116606993e-005 , 5.484742791517482e-006}; const double Den[5] = {1.000000000000000e+000 , -3.738957332360378e+000 , 5.250405121733584e+000,-3.281469562839659e+000 , 7.701095293511172e-001}; double W2Vcconverter = 5.0/4095.0; double SignalSineV = 0.0; double SignalCosV = 0.0; double SignalSineVF = 0.0; double SignalCosVF = 0.0; double ArcT = 0.0; double Rudder = 0.0; double RudderF = 0.0; double RudderN = 0.0; double Pi = 3.1415926535897932384626433832795;

Page 75: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

62

unsigned char Cs; unsigned int Norte; unsigned char BOT = 0xFA; unsigned char NewTrama = 0; unsigned char Index = 0; unsigned char Trama[3] = {0}; unsigned char Calibrar = 0; double Error = 0; void COM1InterruptEvent(void) { unsigned char ByteReaded; ByteReaded = U1RXREG; if(ByteReaded == 'A') NewTrama = 1; if(NewTrama == 1) { Trama[Index++] = ByteReaded; } if(Index == 3) { NewTrama = 0; Index = 0; if(Trama[0] == 'A' && Trama[1] == 'B' && Trama[2] == 'C' ) Calibrar = 1; } FlagIntUart1 = 0; } void Timer1InterruptEvent(void) { SignalSineV = (double)ADC_Read(0)*W2Vcconverter - 2.5; SignalCosV = (double)ADC_Read(1)*W2Vcconverter - 2.5; ArcT = atan(SignalSineV/SignalCosV)*180.0/Pi; if(SignalSineV >= 0.0 && SignalCosV >= 0.0 ) Rudder = ArcT; else if((SignalSineV >= 0.0 && SignalCosV < 0.0) ) Rudder = 180.0 + ArcT; else if (SignalSineV < 0.0 && SignalCosV < 0.0) Rudder = ArcT - 180.0; else Rudder = ArcT; RudderF = FilterLowPass(&Butter4th,Rudder); RudderN = RudderF + Error;

Page 76: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

63

SendByte(1,BOT); SendfloatInChar(RudderN); FlagIntTimer1 = 0; } int main() { Init_Main(); FilterInit(&Butter4th,Num,Den); while(1) { if(Calibrar) { Error = 0.0 - RudderF; Calibrar = 0; BOT = (BOT == 0xFA)?0xFB:0xFA; } Delay_ms(100); } return 0; }

Page 77: Actualización de la arquitectura de hardware del CIDNAV-AUV

ANEXOS

64

Anexo IV: Parte del código fuente del programa implementado para el sensor

de rpm.

#include<P33FJ64MC804.h> #include<timer.h> UINT32 Difference = 0; Int groove = 2; void Timer3InterruptEvent(void) { UINT32 CycleNow = 0; static UINT32 LastCycle = 0; UINT16 Hold = TMR4; CycleNow = TMR5; CycleNow <<= 16; CycleNow |= Hold; if(!FlagIntTimer5) { Difference = CycleNow - LastCycle; } else { FlagIntTimer5 = FALSE; Difference = 0xFFFFFFFF + CycleNow - LastCycle; } LastCycle = CycleNow; DIO5L = ~DIO5L; FlagIntTimer3 = FALSE; } void RefreshSpeedValue(UINT32 TimeReg) { Analog.SpeedMotor = ((double)(60.0/((double)TimeReg/FCY))) ; Send_Datai(1,(UINT16)(Analog.SpeedMotor*10.0)); } INT main() { ConfigIntTimer3(T3_INT_PRIOR_5 & T1_INT_ON); OpenTimer3(T3_ON & T3_GATE_OFF &T3_PS_1_1 & T3_SOURCE_EXT,groove); InitMainSystem(); while(TRUE) { RefreshSpeedValue(Difference); Delay_ms(100); } return 0; }