AUTOPÍA Route

El proyecto comenzó partiendo de un trabajo final de máster del año pasado que se basaba en la misma idea base, el diseño de un sistema de navegación para vehículos autónomos, usando para ello la información que ofrece el proyecto libre de mapas OpenStreetMap. En este caso, se utilizaba un ordenador a bordo del vehículo con sistema operativo Linux[15]. En la pantalla táctil se representaba el mapa de OSM para que el usuario introduzca el destino. Sin embargo, debido a un nuevo planteamiento del proyecto, se decidió que el trabajo actual continúe con la utilización de una tablet por lo que la programación del mapa y la interfaz se realiza mediante código Android.

INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP AUTOPÍA Route es una aplicación de navegación con acceso a todos los mapas de alta calidad y datos de OSM mediante la utilización del código abierto de OsmAnd. Estos mapas se descargan al comenzar la aplicación y con conexión a Internet. Una vez descargados, se almacenan en la memoria del dispositivo para su uso sin conexión.

El primer planteamiento de la aplicación se refleja en la Figura 4.4.4 donde se visualizan dos actividades, una es unicamente el mapa con el recorrido, y la otra es la división en dos de la pantalla. En la zona de abajo de la división, se visualiza el mapa con la trayectoria a seguir, en medio se refleja la velocidad del coche y arriba se ilustra la carretera y los cambios a dar durante la ruta así como los avisos o alertas de diferentes situaciones, por ejemplo la detección de un coche en un cruce, los peatones, conducir a mayor velocidad de la definida en la vía, etc. El objetivo principal de esta división es tener una zona específica que alerte al conductor de las diferentes etapas de la navegación.

Figura 4.4.4 Boceto del diseño de la aplicación.

Por otro lado, como se observa en la parte superior de la imagen, al principio el nombre de la aplicación era CSICMaps, sin embargo se decidió cambiar por AUTOPÍA Route ya que el proyecto pertenece al grupo de investigación del CSIC que lleva este nombre, Programa AUTOPIA, y que se presentó en el capítulo 2.

El boceto se diseñó utilizando el programa Balsamiq Mockupsque es un software que permite crear bocetos para aplicaciones de manera ágil y facilitando la creación de esquemas. Este programa cuenta con una aplicación nativa para OS X, además de versiones para Windows, Linux y una versión web que permite el trabajo desde cualquier lugar. Tiene bastantes imágenes cargadas que ayudan al diseño como el mapa o la carcasa de la tablet que se ven en la Figura anterior. También permite la inserción de imágenes como son la señal de ceda el paso o la de límite de velocidad. El único inconveniente es que tiene un precio de 79$ para la versión nativa y una suscripción de 12$ al mes si se quiere acceso a la interfaz web.

CAPÍTULO 4. DISEÑO DE LA INTERFAZ

Volviendo a la aplicación, la ventaja de utilizar el código OsmAnd es que no se parte de un proyecto en blanco, sin embargo, también plantea un reto ya que se trabaja con una cantidad elevada de funciones y clases que requieren de su estudio y entendimiento para ser utilizadas. OsmAnd venía ya con la programación necesaria para la descarga de los mapas, el enrutamiento de las trayectorias, la visualización de la ruta en el mapa, el recálculo automático de la trayectoria, entre otras funciones.

Una vez definidas y estudiadas las herramientas que proporcionaba OsmAnd al proyecto y como se debería proceder para su modificación si fuese necesaria, se pasó al cambio de la actividad principal para realizar la división de pantalla. Para ello, se le añadió unLinearLayout verticalcon el fin de poder controlar más cómodamente el espacio que se le adjudicaría a cada una de las divisiones.

A continuación se añadieron las primeras imágenes a la parte superior correspondientes a la vía (ver Figura 4.4.5). Luego se introdujo en medio el texto de la velocidad. Este cambio se representa en la Figura 4.4.6. Se debe destacar, que las diferentes zonas así como sus elementos (imágenes, textos, botones...), deben tener bien definidas las medidas y límites ya que sino, al ejecutar la aplicación en el dispositivo, el resultado no sea el esperando obteniendo zonas u objetos que no aparezcan.

Figura 4.4.5 Diferentes representaciones de la vía.

Posteriormente se procedió a la programación de los botones, para ello, se analizó la con- figuración de la actividad. OsmAnd tiene programados los botones superiores e inferiores en otras actividades que se incluían en la principal. Por esta razón, se modificó la actividad correspondiente a los elementos inferiores añadiendo los tres botones necesarios para lograr el resultado esperado como se muestra en la Figura 4.4.7.

El primero y el segundo botón denominadosMANUALyAUTONOMOUSson los encargados de modificar el modo de conducción de autónomo a manual y viceversa respectivamente. Esta comunicación se realiza mediante el envío al vehículo por el LCM de un uno si se pasa a modo autónomo o un cero si se pasa a manual. La información es enviada en el canal denominado

"DRIVE_MODE". Cabe destacar que el primer botón no aparece visible ya que la conducción comienza en modo manual por defecto. Se decidió utilizar dos botones en posiciones distintas para evitar confusiones y saber en todo momento en que modo de conducción se encuentra ya que los botones se van alternando según sea el caso.

INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP

Figura 4.4.6 Paso de la actividad principal de OsmAnd a la de Autopia Route.

Finalmente el último botón es el que produce la aparición de la división de pantalla o del mapa, permitiendo al usuario pasar de una visión detallada a otra en la que se ve unicamente la trayectoria a seguir y las indicaciones como en los sistemas de navegación convencionales. Este hecho se apreciará mejor en las imágenes del capítulo 5 aunque la visualización de esto se representa en la Figura 4.4.8. El texto de este último botón cambia deMAPaMAINdependiendo de lo que se esté visualizando para volver al estado anterior.

Figura 4.4.7 Colocación de los botones.

CAPÍTULO 4. DISEÑO DE LA INTERFAZ

Se debe resaltar que al comenzar la aplicación, la división y los botones no aparecerán hasta que se haya programado la primera ruta y empiece su simulación. Sin embargo, cuando se pase a ver unicamente el mapa, el texto de la mitad seguirá visible en la zona superior como se visualiza en la Figura 4.4.8.

Las visualización de las alarmas se colocó fuera del anterior LinearLayout vertical para que estuviesen visibles siempre durante el transcurso de la navegación. Para la explicación de la colocación de las imágenes correspondientes a cada alerta, se ha representado su posición en la Figura 4.4.8. Por un lado, en la esquina superior izquierda se encuentra la señal del límite de velocidad de la vía y en la zona media se dibujarán las diferentes señales de aviso, en el caso de la imagen, se ha representado una señal de STOP como ejemplo.

Figura 4.4.8 Colocación de las alarmas y avisos.

La representación de las alertas en cada situación se ha realizado con las imágenes que se muestran en la Figura 4.4.9 donde se observa que se han contemplado cuatro posibles escena- rios, la detección de un semáforo, de una señal de ceda el paso, de una señal de STOP y de un obstáculo como un peatón o un vehículo acercándose en un cruce. Con respecto a esta última situación, adicionalmente a la señal se mostrará en la carretera la imagen correspondiente a cada objeto, es decir, en el caso del peatón se representará un paso de cebra en la carretera y una dibujo de una persona en color naranja, si el obstáculo es un coche, aparecerá en el carril correspondiente del cruce.

Por otro lado, cuando el vehículo supera la velocidad permitida en la vía, el fondo del medio cambia y se vuelve rojo con el fin de llamar la atención del conductor. Así mismo, la velocidad máxima de la vía se obtiene mediante la información del mapa y se envía por LCM al vehículo con el fin de que el controlador de velocidad del bajo nivel la tenga como referencia.

INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP En el capítulo 5 se visualizarán mejor todas las representaciones de cada situación.

Figura 4.4.9 Alertas de alarmas captadas por el sistema de percepción del vehículo.

Respecto a la programación, si se detecta el aviso de una alarma, se analiza su número de identificación para distinguirla y ejecutar la operación correspondiente como cambiar la visibilidad de la imagen que la define. La operación de interpretar cada caso se realiza en un hilo secundario ya que la verificación de la llegada de una alarma es una acción continua. Por otro lado, la modificación de la interfaz se ha realizado mediante el método propio de Android

runOnUiThread ya que esta función solo ejecuta una acción especifica desde un hilo que se esté ejecutando sobre un componente del hilo principal.

Por otro lado, se visualizaran una serie de alertas obtenidas desde el tratamiento del mapa. Estas alarmas se corresponden al aviso de la existencia de cámaras de tráfico, fronteras, resaltos, señales de STOP, señal de tren y pasos de cebra. Así pues, su visualización se ejecutará por encima de los botones inferiores del mapa. La imagen correspondiente a cada aviso se visualizan en la Figura 4.4.10.

Figura 4.4.10 Alertas de alarmas captadas por el tratamiento del mapa.

CAPÍTULO 4. DISEÑO DE LA INTERFAZ

Una vez definidos todos los aspectos gráficos que se visualizarán en la aplicación, se procede a la programación del envío de datos de la navegación, desde la tablet al coche, es decir, la ruta a recorrer por el coche, el modo de conducción mediante los botones de la actividad principal y la velocidad referente a la calle por la que debe circular el vehículo.

Con respecto al primer bloque de datos, se aprovecha el procesamiento de OsmAnd y de la información que utiliza para crear la ruta de navegación. La aplicación guarda en un array los datos más relevantes de cada vía a seguir en la trayectoria y la información de los nodos que la componen y que intervienen en el recorrido. Así pues, se recogen de esa lista de datos el identificador que define la vía y cual es el nodo inicial y el final que se recorre. Esta información se transmite cada vez que se calcula la ruta a seguir, ya sea la inicial o la redirección al equivocarse en el seguimiento de la trayectoria. Cada vía se exporta del array y se manda por separado a través de LCM por el canal "RUTA".

Cuando se lanza la aplicación, el modo de conducción es manual por defecto por lo que, en el centro se encuentra el botón correspondiente para cambiar a modo autónomo. Al hacer click en dicho botón, se envía por el canal "DRIVE_MODE.el_{valor 1 refiriéndose a su cambio a}

autónomo, desaparece el botón del centro y aparece otro a la izquierda el cual, al hacer click manda un 0 para volver a modo manual, desaparece y vuelve a surgir el primer botón.

Para la velocidad de la vía, se obtiene el dato también del procesamiento realizado por OsmAnd y se envía por el canal"STREET_SPEED". Se tiene en cuenta que, cuando sucede una alarma de velocidad, es decir, que el vehículo detecta una señal, es la lectura de este dato el que se envía al planificador del vehículo y no la definida en el mapa pues este puede estar desactualizado o que la modificación de la velocidad proceda de una señal colocada en la vía de forma temporal por obras u otras circunstancias.

El proceso de envío de datos se realiza como se indica en el siguiente código, es decir, se procede a la activación de una instancia del LCM, a continuación se procesan los datos codificándolos a bytes y se introducen en el buffer cuyo espacio se ha dejado guardado al crearlo, finalmente se publica indicando el canal, el array de variables a enviar y el inicio y final de la lectura del array, en este caso se desea desde la primera posición hasta la longitud del array ya que sólo contiene las variables deseadas. Para la realización del envío se han creado hilos secundarios ya que debe ser continuo y saturaría el hilo principal.

1 ...

2 new Thread(new Runnable() { 3 @Override

4 public void run() {

5 LCM lcm = LCM.getSingleton();

6 // Serialize component data

7 // The size changes depending on the type and number of ...

variables to send.

8 ByteBuffer buffer = ByteBuffer.allocate(Long.BYTES + ...

Integer.BYTES);

INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP

10 buffer.putLong(variable1); 11 buffer.putInt(variable2);

12 lcm.publish(Canal, buffer.array(), 0, buffer.array().length);

13 }

14 }).start(); 15 ...

Finalmente, el ícono y el logo final que definen a la aplicación son los que se muestran en la Figura 4.4.11 de derecha a izquierda respectivamente.

Figura 4.4.11 Autopia Route.

Capítulo 5

VALIDACIÓN

_/

RESULTADOS

Validar el correcto funcionamiento de la aplicación es un punto principal sin embargo, no se ha podido probar con el coche real debido a la falta de los sensores y equipamiento necesario para el testeo de las diferentes situaciones planteadas. Por ello, se ha decidido hacer la simulación de un recorrido utilizando una lista de datos grabados y modificados que harán el rol del vehículo.

En este capítulo se explicarán con detalle las diferentes situaciones estudiadas y simuladas que se han realizado y se demostrará que las respuestas a los avisos se realizan correctamente por parte de la aplicación.

5.1

Simulación de alarmas

Como se ha explicado anteriormente, debido a que no se va a poder validar la aplicación en el vehículo, se han programado una serie de alarmas mediante un pequeño programa en phyton. La programación se ha realizado de tal forma que estas señales lleguen al dispositivo Android por el LCM con el mismo formato que el resto de información enviado por el log grabado del vehículo.

Las alarmas se encuentran definidas mediante la estructura que se adjunta a continuación, por lo que tienen un identificador que indicará el tipo de alerta, la posición del objeto identificado por coordenadas geográficas (latitud y longitud), el nivel de alerta que se corresponde a la prioridad y por último el flags que se utiliza para definir otro parámetro que se requiera por ser una alarma específica.

1 struct alarma { 2 double longitud; 3 double latitud; 4 byte nivel_alerta; 5 byte id; 6 byte flags; 7 } 57