Utilización de GPS USB en TurtleBlocks

De Proyecto Butiá
Revisión del 00:59 18 jun 2014 de Gabi235711 (Discusión | contribuciones) (→‎Referencias)

Saltar a: navegación, buscar

Integrantes

  • Fabio Ramos
  • Gabriela Gallo
  • Pablo Grill

Tutores

  • Federico Andrade
  • Andrés Aguirre

Tema elegido

Agregar un bloque en la paleta que permita utilizar un sensor gps usb.

Proceso del grupo

Tareas en proceso y finalizadas

  • Investigar funcionamiento de gps diferencial: distintos protocolos, teoría, etc
  • Revisar funcionamiento NTRIP
  • Investigar existencia de servidores NTRIP en uruguay
  • Investigar opciones para implementar GPS Diferencial con un gps dongle
  • Probar prestaciones de GPS dongle del laboratorio.
  • Compilar y generar gpsd (biblioteca para utilización del gps dongle) en las dos arquitecturas y de forma estática.
  • Generar una nueva paleta para butia.

Minuta de reuniones con tutores

2014-02-28

  • Participantes: Andrés Aguirre, Fabio Ramos, Gabriela Gallo, Pablo Grill
  • Temas tratados:
  • Se define objetivo del proyecto: Utilizar la funcionalidad de un GPS dongle en los butia, agregandole valor a sus prestaciones implementando GPS diferencial. La razón de utilizar un GPS dongle es basicamente que costo, muy inferior a otros tipos de GPSs de mejores prestaciones.
  • Pasos a seguir:
  • Investigar sobre GPS diferencial y documentar resultados.
  • Investigar bibliotecas que implementen la corrección para GPS diferencial, por ejemplo RTKLib
  • Elaborar un prototipo basado en modelo diferencial, usando lo máximo posible del estado del arte. (puede ser por ejemplo RTKLIB)
  • intefaz python y si no hay se hacen o bien por socket, o bien por binding
  • Integrar el prototipo a la Paleta butia:
  • obtener latitud y longitud como servicio básico.
  • Otras ideas:
  • grabar secuencias.
  • ir a tal punto (pasando latitud y longitud)
  • reproducir secuencias
  • tomar distancias
  • Investigar si existen servidores NTRIP en Uruguay y en particular en FING

2014-04-10

  • Participantes: Andrés Aguirre, Federico Andrade, Fabio Ramos, Gabriela Gallo, Pablo Grill
  • Temas tratados:
  • Se discute la inviabilidad de desarrollar GPS diferencial con el hardware de laboratorio (GPS USB Dongle ND-100)
  • Pasos a seguir:
  • Documentar lo investigado y plasmar las razones por las que implementar GPS diferencial no es posible.
  • Integrar el GPS a la paleta butia sin implementar diferencial.
  • Compilar gpsd para las dos arquitecturas de XO, y lograr que las bibliotecas queden instaladas bajo el directorio plugin
  • Funcionalidades de la paleta:
  • Bloque para inicializar el gps
  • Bloque para obtener latitud y longitud.
  • Funcionalidad de medir trayactoria.
Luego de indicar 'comenzar a medir', cada cierto periodo de tiempo se irá calculando en base a la latitud y longitud la distancia recorrida. El periodo de tiempo podría llegar a ser configurable desde la paleta. Este parámetro indicara cuan semejante sera el valor a la verdadera trayectoria recorrida. Los bloques necesarios serán:
- Bloque para comenzar a medir (e inicializar)-> quizá reciba como parámetro un numero indicando los segundos para calcular.
- Bloque para indicar distancia al momento.

Documentación

Motivación

El robot Butiá posee como una de sus principales características la potencialidad de incluir muchos tipos de sensores. Sin embargo, al momento, la posibilidad de poder sensar las coordenadas geográficas donde el robot se encuentra no era factible. El Sistema de Posicionamiento Global GPS es actualmente una de las principales tecnologías utilizadas para fines de orientación y la integración de esta tecnología al robot Batía puede darle un gran valor agregado. Comenzando por la posibilidad de obtener la posición, así como luego poder implementar funciones más avanzadas que hagan de Butiá un robot más inteligente y adaptable a cualquier escenario. Debido al contexto en el cual se trabaja con Butiá, espacios en general reducidos, el aporte de implementar GPS diferencial, para así obtener información más precisa, es de vital importancia, por lo que se intentará también alcanzar este punto.

Objetivos

Generar en TurtleBots una paleta desde la cual se pueda acceder a servicios de un receptor GPS USB. Adicionalmente, agregar valor a sus prestaciones implementando GPS diferencial en tiempo real.

Introducción

Sistema GPS

El sistema GPS (global position system) está compuesto por una red de 24 satélites que orbitan alrededor de la tierra a unos 20200 km. Dichos satélites emiten continuamente señales para que los receptores en la tierra puedan con ellas determinar su posición. Además los satélites se encuentran coordinados de manera de que se puede mantener toda la superficie de la tierra cubierta. El funcionamiento de un receptor GPS se basa en la simple resolución de un problema matemático de determinar su posición, basándose en la de otros. Para lograr resolver dicho problema, el receptor GPS debe obtener los datos de al menos un conjunto mínimo de satélites (3 para la obtención de una posición de dos dimensiones, 4 para determinar posiciones en tres dimensiones).

Fuente de error

Los GPS, al igual que todo instrumento de medición tienen un margen de error. En el caso de las mediciones GPS, dicho margen depende mucho de la precisión y calidad de los receptores utilizados. Sin embargo también influye mucho las condiciones climáticas y el contexto en que se es este realizando la medición.

Error de sincronismo

Uno de los principales inconvenientes del posicionamiento mediante el sistema GPS, es que el exacto sincronismo entre los satélites es muy difícil de lograr. El cálculo de la posición del GPS se basa en determinar la posición de los satélites midiendo tiempo de retardo de la señal enviada por los mismos. El error surge cuando unos de los satélites involucrados no emite su señal en el mismo instante de tiempo que los demás. Esto lleva a que cuando el receptor reciba la señal y calcule el retardo de la misma, suponga para ello que se emitió en instante de tiempo determinado que no es correcta, lo que lleva a que la posición calculada no sea exacta. El error de sincronismo no está presente solo entre los satélites, sino que si el receptor no está en correcta sincronía, la posición calculada no será correcta. Para tratar de reducir este margen de error los satélites se encuentran equipados con osciladores atómicos de forma de que sus relojes se mantengan lo más sincronizados posibles. Esto hace que el primer error descripto anteriormente sea muy pequeño y casi despreciable. Sin embargo, el sincronismo que presente en el reloj del receptor depende mucho del mismo. Esto lleva a que existan receptores cuyo margen de error es menor al cm. y otros que puede llegar a ser de 10m.

Posición relativista

Debido al potencial gravitatorio de la tierra, el ritmo de dos relojes situados uno en la tierra y otro en el satélite deferirán. Para solucionar este problema los relojes de los satélites se ajustan periódicamente para esta en sincronía con los de la tierra. Sin embargo dicho ajuste no es a cada momento, por lo que dicho desfasaje repercute como error en los cálculos de posición del GPS.

Retardos a causa de la atmósfera

Como los satélites se encuentran sobre la atmosfera terrestre, las distintas capas de la misma influyen en las señales enviadas de manera que estas son retardadas. Entre estos retardos se encuentran los siguientes: Retardo Troposférico, Retardo Ionosferico.

Retardos instrumentales

Entre estos componentes se encuentran las antenas, los cables, los filtros aplicados a las mediciones etc.

Multicamino

Este error se presenta cuando una misma señal llega más de una vez a un mismo receptor. Esto sucede cuando en el entorno en el que se encuentra el receptor existen superficies que reflejan la señal. Para reducir este error existen ciertos receptores que ignoran los datos recibidos de ciertas direcciones; sin embargo la mejor forma de evitarlo es colocando los receptores lejos de superficies reflectoras. Es por esta fuente de error que los receptores GPS presenten menor margen de error en superficies abiertas que en las ciudades, ya que muchos edificios se comportan como superficies receptoras.

Ruido

En esta categoría se encuentran todos los demás factores que pueden influir en la recepción de las señales y que no fueron mencionados anteriormente.


GPS Diferencial

Motivación

La exactitud que un receptor GPS puede llegar a obtener influye mucho en la calidad del mismo, repercutiendo directamente en su precio. Al analizar los distintos modelos GPS que se encuentran en el mercado a un precio accesible (aproximadamente 40 dólares), se ve que los mismos tienen un margen de error entre los10 y 20 metros. Si consideramos que dichos GPS son utilizados para la ubicación dentro de grandes sectores (por ejemplo localizar un auto dentro de una ciudad) dicho margen de error podría considerarse despreciable. Ahora, si pretendemos utilizar dichos GPS en la robótica, donde muchas veces el escenario en que se mueve el agente robótico es una habitación, un margen de error de 10 metros no es tolerable. Si bien es cierto que existen receptores GPS que reducen el margen de error a unos pocos cm, el costo de ellos es muy elevado (miles de dólares), lo cual impulso la idea de utilizar soluciones alternativas. Una de dichas soluciones es la utilización de un GPS diferencial, el cual permite corregir la posición de un GPS reduciendo el margen de error de 10 metros a un metro, llegando en ocasiones a errores de unos pocos decímetros.

 

Funcionamiento del GPS diferencial

La idea del GPS diferencial radica en dar mayor información al receptor que la que se obtiene de los satélites. Además de los 3 o 4 satélites necesarios para obtener la posición, en el caso del GPS diferencial se cuenta además con los datos brindada por una estación base. En el modelo del GPS diferencial se encuentran dos agentes particulares. Uno de ellos es el GPS, al cual se pretende disminuir su margen de error. Como típicamente dicho agente se encuentra en movimiento se denomina “rover”. El otro agente es la estación base, en la cual se encuentra otro receptor GPS. La estación base conoce además su posición geográfica verdadera, lo cual permite que la misma compare los datos verdaderos con los calculados mediante el sistema GPS. Conociendo estos 2 datos la estación base puede calcular cual es el margen de error que tiene en ese momento. El funcionamiento del GPS diferencial se basa en suponer que las fuentes del error entre la estación base y el “rover” son aproximadamente las mismas. Bajo este supuesto lo que se hace es enviar la corrección realizada en la estación base al “rover” y que el mismo lo aplique a sus datos. De esta forma los datos que recibe el “rover” pueden aproximarse mejor. Cabe destacar que toda esta teoría se basa en que las condiciones de la estación base y del “rover” son aproximadamente las mismas. Por lo tanto para un correcto funcionamiento del sistema es necesario que ambos receptores se encuentren medianamente cerca, ya que si la distancia entre ellos es muy grande (más de 200 km por ejemplo) el supuesto de que los errores a los que están sometidos no difieren mucho no es correcto y el resultado de aplicar la corrección puede no ser una mejora. Además para que se pueda implementar un GPS diferencial es necesario que exista una forma de comunicación entre el “rover” y la estación base. Los medios de realizar dicha comunicación son varios, que van desde una comunicación por radio hasta utilizar TCP o Internet para intercambiar los datos (entre los distintos protocolos utilizados para enviar las correcciones, el más utilizado es NTRIP). Otro aspecto en tener en cuenta al momento de utilizar un GPS diferencial, es en qué momento aplicar las correcciones. Considerando esto existen 2 opciones básicas: post-procesamiento o en tiempo real. En el caso del post-procesamiento los resultados alcanzados pueden llegar a obtener un margen de error de unos pocos dm., mientras que en tiempo real, el margen de error es mayor. Además para lograr un procesamiento en tiempo real es necesario tener cierta capacidad de cómputo, debido a la complejidad de los algoritmos utilizados para las correcciones.

¿Cómo implementar un GPS diferencial?

Uno de los inconvenientes que surge al momento de aplicar el GPS diferencial, es en donde se realizan los cálculos de corrección. En el mercado existen ciertos receptores GPS, capaces de realizar ellos mismos el cálculo de corrección. Estos receptores típicamente tienen asignado un puerto por el cual escuchan las correcciones. Sin embargo el costo de estos receptores es muy elevado. La otra alternativa es realizar las correcciones en un computador. Lo que en este caso se hace es tener un programa que reciba los datos de la estación base y del “rover”. Dicho programa efectúa todos los cálculos necesarios emitiendo los datos con las correcciones aplicadas mediante un medio conocido.

RTKLib

Al investigar las posibles implementaciones de GPS diferencial por software, encontramos que una alternativa era utilizar RTKLIB. RTKLIB es un paquete de open software, el cual incluye funcionalidades para el procesamiento diferencial del GPS. En el paquete se incluyen bibliotecas para C y aplicaciones que permiten el cálculo diferencial. La mayoría de las aplicaciones están además disponibles tanto para Windows como para Linux. Entre las aplicaciones que vienen incluidas, se encuentra el RTKNAVI (Windows) y RTKRCV para (Linux). Estas herramientas permiten realizar los cálculos relacionados con las correcciones del GPS diferencial en tiempo real. Para poder utilizar la herramienta anteriormente comentada, es necesario configurar los inputs y los outputs de la misma. Entre los input se debe especificar por cual vía se obtendrán los datos del “rover” y de la estación base. Además se debe especificar por donde se emitirá la salida (output). Una vez realizadas las configuraciones necesarias e inicializada la herramienta, si todo funciona correctamente se obtendrá en el output los datos con las correcciones ya efectuadas. Otra ventaja de este software es que soporta un gran número de medios para recibir los input y para emitir los output. Entre ellos se encuentran Serial, TCP client, TCP server, NTRIP Server, FTP, HTTP. Además soporta un gran número de formatos de datos entre los que se encuentran RINEX 2.10, 2.11, 2.12 OBS/NAV/GNAV/HNAV/LNAV/QNAV, RINEX 3.00, 3.01, 3.02 OBS/NAV, RINEX 3.02 CLK, RTCM, RTCM, BINEX, NTRIP 1.0, RTCA/DO-229C, NMEA 0183, SP3-c, ANTEX 1.4, IONEX 1.0, NGS PCV and EMS 2.0 Por otro lado, RTKNAVI y RTKRCV necesita recibir la “raw data” del GPS para realizar los cálculos necesarios para las correcciones, debido a que utiliza una técnica denominada “double differencing”. Esto es un inconveniente ya que el protocolo NMEA (muy popular entre los GPS) no brinda la “raw data”, lo cual hace imposible utilizar la librería con receptores GPS que solo emiten sus datos en dicho protocolo.

Receptor GPS Dongle

El receptor GPS dongle para computadoras es un receptor GPS compacto y bastante preciso con bajo consumo de energía que se conecta al puerto USB. Este receptor es adecuado para todas las aplicaciones de un receptor GPS tradicionales. Todo lo que se necesita es: (1) receptor dongle; (2) una computadora, (3) software de navegación GPS. El receptor GPS se alimenta de energía de la PC a la que está conectada, por lo que no se necesitan alambres o cables adicionales.

Sumado a esto, es un hardware de bajo costo, rondando a la fecha en un valor de unos 35-40 dólares.

GPS nd-100

En el laboratorio de robótica contamos con un receptor GPS dongle, del modelo ND-100, fabricado por Globalsat Technology Corporation. La siguiente tabla corresponde a las especificaciones técnicas particulares de éste dispositivo.

GPSd

GPSd es un demonio que recibe datos de un receptor GPS, y proporciona los datos a múltiples aplicaciones. Es decir, proporciona una interfaz unificada a los receptores de diferentes tipos, y permite el acceso simultáneo de múltiples aplicaciones

GPSd administra uno o más GPSs o receptores AIS conectados a un equipo central a través de puertos serie o USB, y todos los datos de posición, velocidad, etc., de cada uno de los sensores quedan disponibles para ser consultados en el puerto TCP 2947 del host. Con GPSd, múltiples aplicaciones cliente basadas en la localización (como el software de navegación y wardriving) pueden compartir el acceso a los receptores sin contención o pérdida de datos. También, GPSd responde a las preguntas con un formato que es sustancialmente más fácil de analizar que el NMEA 0183 emitida por la mayoría de GPSs.

El objetivo del proyecto GPSd es crear una capa sólida de la infraestructura de código abierto para los programas que se ejecutan en Linux y otros Unix de código abierto que quieren ser sensibles a la ubicación. Pretende generar interfaces simples y robustas, y una curva de aprendizaje fácil para los desarrolladores de aplicaciones.

Solución

Resolviendo los objetivos propuestos para el proyecto, se detectan dos áreas fundamentales: las funcionalidades que debe tener la paleta de TurtleBots y la implementación de GPS diferencial con los recursos disponibles.

Implementación GPS diferencial

El objetivo en cuanto a éste punto es lograr implementar con los recursos brindados por el laboratorio, un GPS diferencial en tiempo real. A priori este requerimiento es viable ya que el robot Butiá cuenta con capacidad de procesamiento para realizar los cálculos mediante el CPU de la XO. El otro punto fundamental para la implementación de GPS diferencial es contar con una estación base de la cual nutrirnos para realizar las correcciones. A propósito de esto, encontramos en Uruguay un conjunto de estaciones base del servicio Geográfico Militar que publican sus coordenadas mediante el protocolo NTRIP en una IP y puerto accesible. Esto posibilita la implementación de las correcciones mencionadas en el robot. Sin embargo, para el proyecto se cuenta con un receptor GPS Dongle N-100 (especificado anteriormente) el cual presenta la limitante de solo soportar el protocolo NMEA. Dicho protocolo es de los más básicos en cuanto a mensajería GPS. Está pensado para presentación, brindando datos previamente procesados y omitiendo los originales, que son fundamentales para la implementación de GPS diferencial. Sin ésta información es imposible realizar los cálculos de las correcciones.

Por esta razón, es inviable la implementación de GPS diferencial con los recursos disponibles.

A continuación, especificamos el proceso que seguimos para alcanzar la conclusión que exponemos. Comenzamos investigando diferentes alternativas para la implementación de GPS diferencial mediante software. Hasta donde sabemos, la implementación de GPS diferencial es mediante el protocolo RTK. De los utilitarios encontrados, RTKLib pareció ser la única opción que realizara las correcciones en tiempo real. Sumado a esto, la biblioteca es software libre y ofrece gran flexibilidad en cuanto a protocolos y medios de comunicación soportados. Además, ofrece una amplia gama de funcionalidades accesorias, como por ejemplo la configuración de url’s para estaciones base. Comenzando a diseñar una solución por este camino, surge la limitante de que RTK no admite NMEA como protocolo de entrada. Visto este inconveniente, intentamos entonces buscar la forma de traducir la información que NMEA nos brinda a uno de los posibles protocolos de entrada de RTK, no pudiendo lograrlo. A raíz de esto, revisamos los fundamentos teóricos de RTK hallando que la causante de los problemas era la falta de datos. Visto esta limitante, se cambia el alcance del proyecto, eliminando el requerimiento de implementación de GPS diferencial, e incluyendo una nueva funcionalidad en la paleta.

Paleta GPS para TurtleBots

Funcionalidades

La paleta debe ofrecer la funcionalidad de obtener la posición actual del robot. Adicionalmente, se quiere calcular la distancia recorrida en base a la diferencia de posiciones tomadas cada cierto periodo de tiempo.

Arquitectura de la solución

Para resolver la comunicación con el hardware se utiliza el demonio de GPSd y para la comunicación con el demonio, la biblioteca para Python que GPSd provee. El siguiente es un diagrama de componentes utilizados:

ACA VA LA IMAGEN

Diseño de las funcionalidades

Se desprenden de las funcionalidades requeridas los siguientes bloques a implementar:

  1. Bloque Inicializar: permite comenzar a utilizar los demás bloques de la paleta.

Las acciones que realiza son:

  • Detecta cuál puerto fue utilizado por el GPS
  • Inicializa demonio GPSd
  • Lanza thread para refrescar los datos que el demonio obtiene. Esto es necesario debido al funcionamiento del demonio, el cual utiliza una cola para guardar los últimos valores obtenidos y en caso de no refrescarse esta información, el mismo devuelve valores antiguos.
  1. Obtener latitud: Retorna la latitud actual del robot.
  1. Obtener longitud: Retorna la longitud actual del robot.
  1. Inicializar medir: comienza a medir la distancia recorrida tomando los valores con cierta frecuencia.

Para realizar el cálculo de la distancia recorrida, se utiliza una serie de tomas de posición a lo largo del trayecto. Este bloque tiene un parámetro de entrada que corresponde a la cantidad de segundos entre cada toma de posición. Para el cálculo de la distancia (ver bloque ‘obtener medida’) se utiliza la fórmula de Haversine.

  1. Obtener medida: devuelve la distancia recorrida al momento.

Notar que no se resetean los contadores, por tanto este bloque puede ser utilizado varias veces seguidas.

  1. Finalizar: Indicado para cuando ya no se quiera utilizar los servicios de GPS. Mejora la performance del equipo liberando los recursos.

Se agregó además un bloque de ejecutar ejemplo para chequear que la fórmula de obtener medida (Haversine) era correcta. Este bloque calcula la distancia extrayendo los puntos desde un archivo de texto. Dicho archivo debe llamarse Ejemplo.txt y encontrarse en el mismo directorio en el que se está ejecutando TurtleBots. En dicho archivos deben colocarse los pares de punto latitud longitud (separados pos un espacio en blanco) de los puntos que se pretenden evaluar. Al final del archivo debe colocarse la palabra FIN.


Compilación de GPSD

Uno de los inconvenientes encontrados en el proyecto fue que las XO pertenecientes al plan ceibal no poseen permisos de root. Esto hace que sea imposible instalar el demonio GPSd. Como solución a este problema se optó por compilar el GPSd y generar un archivo ejecutable que permita ejecutar dicho demonio. Debido a que las XO presentan distintas arquitecturas y distintos sistemas operativos deberían generarse un archivo ejecutable para cada caso particular. En el archivo TurtleBots-24, xo se encuentra un archivo compilado que funciona en las computadoras con Ubuntu. En caso de que se pretenda utilizar la paleta en otra arquitectura deberá realizarse el siguiente procedimiento.

  1. Se deberá compilar el demonio GPSd para la arquitectura y la versión del sistema operativo deseado. Para realizar este punto puede utilizarse el comando scons de una terminal linux. Para ello se adjunta la carpeta gpsd-3.6 que contiene todos los insumos necesarios para la compilación. En particular se encuentra el archivo Sconstructor con todos los seteos necesarios para compilar el demonio lo más estáticamente posible.
  2. En la carpeta de plugins, dentro de la carpeta gpsa se debe sustituir el binario GPSd por el archivo correspondiente a la arquitectura deseada.
  3. Se debe compilar nuevamente la paleta. Para ello se debe ejecutar el comando make XO en la carpeta TurtleBots.
Limitaciones de la Paleta

Por el momento la paleta GPS asume que el receptor GPSd se encuentra en el puerto USB0. Por lo tanto queda por responsabilidad del usuario chequear que realmente el receptor GPSd se encuentra en dicho puerto.

Conclusiones

Durante el presente proyecto, se logró establecer comunicación desde TurtleBots con el receptor GPS.

Trabajo a futuro

  • Implementar GPS diferencial para mejorar la precisión de los datos, utilizando un receptor compatible.
  • Agregar funcionalidad para obtener altitud
  • Investigar posibilidad de obtener información geográfica no mediante un GPS dongle, sino comunicándose con un servicio, por ejemplo, de un Smartphone.
  • Incorporar la funcionalidad de que puerto está siendo utilizado por el GPS de forma de que no se asuma siempre el USB0

Referencias

Obtenido de «http://164.73.124.35/inco/proyectos/butia/mediawiki/index.php?title=Utilización_de_GPS_USB_en_TurtleBlocks&oldid=5347»