Migración del software de control de un vehículo a un computador dedicado

Sánchez Prieto, Victor (2017). Migración del software de control de un vehículo a un computador dedicado. Proyecto Fin de Carrera / Trabajo Fin de Grado, E.T.S.I. Industriales (UPM).

Descripción

Título: Migración del software de control de un vehículo a un computador dedicado
Autor/es:
  • Sánchez Prieto, Victor
Director/es:
  • Matía Espada, Fernando
  • Godoy Madrid, Jorge Luis
Tipo de Documento: Proyecto Fin de Carrera/Grado
Grado: Grado en Ingeniería en Tecnologías Industriales
Fecha: Julio 2017
Materias:
Escuela: E.T.S.I. Industriales (UPM)
Departamento: Automática, Ingeniería Eléctrica y Electrónica e Informática Industrial
Licencias Creative Commons: Reconocimiento - Sin obra derivada - No comercial

Texto completo

[img]
Vista Previa
PDF (Document Portable Format) - Se necesita un visor de ficheros PDF, como GSview, Xpdf o Adobe Acrobat Reader
Descargar (2MB) | Vista Previa

Resumen

Este trabajo fin de grado se engloba dentro del Programa AUTOPIA, programa llevado a cabo en el Centro de Automática y Robótica (CAR) CSIC-UPM, localizado en Arganda del Rey, Madrid. Dicho programa investiga el desarrollo de vehículos autónomos, es decir, sin conductor; tema de frecuente discusión hoy en día. Este trabajo surge de la necesidad de que los vehículos autónomos que circulan en España deben incorporar un sistema override o take-over que devuelva el control del vehículo al conductor cuando éste intente modificar la dirección o la velocidad. Este requisito está regulado por la normativa de la Dirección General de Tráfico. El documento donde quedan definidos los requisitos para la circulación de coches automatizados se recoge en los anexos del presente trabajo. El objetivo final de este trabajo es aumentar la robustez del sistema de control desarrollado por el Programa AUTOPIA para la conducción autónoma de vehículos y gestionar, de una manera más eficiente, la inicialización de los sistemas de control del freno y del volante, además de incluir el sistema take-over anteriormente explicado. Actualmente, el sistema se encuentra implementado en un PC con sistema operativo Ubuntu y se plantea migrar parte del software a un sistema dedicado. Para ello se dispondrá de una placa controladora comercial, la cual será fruto de un previo análisis de mercado. Los requisitos mínimos de dicha placa serán: - Bajo coste - Rendimiento mínimo necesario para gestionar las comunicaciones en el coche - Capacidad de lectura de mensajes CAN (Controller Area Network), típico protocolo de comunicación en los coches actuales - Comunicación USB con el ordenador principal - 2 puertos serie adicionales para la comunicación con los controladores de posición digitales del freno y del volante. El sistema final que se desarrollará para este trabajo fin de grado deberá conseguir leer los mensajes que el PC envié a través del USB con una codificación a determinar, interpretarlos y mandar las órdenes del ordenador traducidas a la comunicación propia de los controladores digitales de los motores de freno y volante. ETAPA 1: Selección de la Placa Tras el análisis de mercado, cuyos requisitos fueron detallados en el párrafo anterior, y que se encuentra redactado en el Capítulo 4 de esta memoria, se llega a la conclusión que la placa microcontroladora que mejor se adapta es la Teensy 3.2. Una vez decidido con que Hardware se va a trabajar, se puede pasar a las pruebas de validación y posteriormente al desarrollo software. ETAPA 2: Gestión de la comunicación Para la gestión de la comunicación, se ha implementado una máquina de estados, de tal manera que se le da prioridad a los tipos de comunicación que se consideran más importantes, o que tienen una frecuencia de mensajes mayor. Como ya se ha mencionado previamente, el bus CAN en el vehículo manda mensajes con una frecuencia bastante considerable, por lo que éste es considerado prioritario. Además, es de vital importancia que una comunicación no bloquee el hilo de ejecución del programa principal en la placa, la cual no cuenta con capacidad para multithreading como si tiene por ejemplo un ordenador. Para la comunicación con el ordenador, que será el encargado de decidir la referencia de posición del freno y del volante, se utilizará comunicación serie mediante USB. Además se desarrollará un protocolo de comunicación para que las comunicaciones entre el ordenador y la placa fuesen rápidas y robustas, objetivo principal de este trabajo. Al ser una tarea tan crítica, la comunicación USB también será considerada prioritaria. Por otro lado, la comunicación con los controladores digitales de freno y volante se realiza mediante el protocolo RS232, basado en comunicación mediante puerto serie. Para la comunicación tanto por bus CAN como por RS232 se necesitará de un circuito electrónico que se describirá más adelante en este trabajo. ETAPA 3: Gestión del freno y del volante Para la calibración y el posterior control de las posiciones del freno y del volante se utilizan dos máquinas de estados. El sistema se encontrará en un estado de PAUSA hasta que llegue por USB la orden de empezar la calibración. Dicha calibración busca establecer la posición cero, la cual los sistemas de freno y volante utilizarán como origen. Para la calibración del volante se utilizará la comunicación CAN para saber en qué posición se encuentra el volante en dicho momento e indicar a la controladora del motor del volante dicha posición actual. En cambio, con el propio CAN se podrá detectar cuando el freno está activo moviendo el mismo. Estableciendo el punto de conmutación como origen de posiciones del freno. Esta calibración es necesaria debido a que la controladora de cada motor funciona mediante un Encoder incremental acoplado al eje de dicho motor. Este tipo de Encoder funciona contando los pulsos recibidos en el movimiento de dicho Encoder, pudiendo registrar solo movimientos relativos, si saber la posición actual del motor. Por esto, se debe indicar a la controladora en algún momento de la calibración, cual es la posición actual del Encoder. Posteriormente, los sistemas de freno y volante, contarán con tres estados básicos que configurarán el sistema según las acciones del usuario o del sistema de control. Por defecto, los sistemas de freno y volante se encontrarán en un estado de RUNNING, en los cuales se ejecutarán las órdenes de posición que lleguen para el freno o el volante. Si pasa un determinado tiempo sin que llegue ninguna orden, se pasará a un estado IDLE, en el cual de desbloqueará el volante y se llevará el freno a la posición cero. De igual manera se procederá si se detecta la acción del usuario sobre estos actuadores provocando un override. Si el conductor pisa el freno o hace fuerza en el volante, se pasará a dicho estado OVERRIDE, desbloqueando el volante y el freno. Estas acciones del usuario se detectarán mediante un sensor de presión alojado en el pedal del freno y el par ejercido en la columna, dato que se puede obtener de la comunicación bus CAN. ETAPA 4: Pruebas del sistema. Por último se realizaron las pruebas finales para testear todo el sistema desarrollado en este trabajo fin de grado. Mediante las pruebas en pista se probó que el ordenador embarcado era capaz de trabajar con la Teensy sin grandes errores en la conducción autónoma comparado con la conducción utilizando únicamente el ordenador, así como que el sistema era capaz de detectar los overrides del conductor, tanto en el freno como el volante, y la correcta vuelta al sistema autónomo. Tras estas pruebas se concluyó que el sistema con la Teensy era perfectamente compatible y válido para la conducción autónoma junto con el ordenador embarcado, aportando como ventaja la detección del override y la reducción de carga computacional en la gestión de la calibración de los actuadores.

Más información

ID de Registro: 49205
Identificador DC: http://oa.upm.es/49205/
Identificador OAI: oai:oa.upm.es:49205
Depositado por: Biblioteca ETSI Industriales
Depositado el: 23 Ene 2018 08:05
Ultima Modificación: 26 Abr 2018 10:42
  • InvestigaM
  • GEO_UP4
  • Open Access
  • Open Access
  • Sherpa-Romeo
    Compruebe si la revista anglosajona en la que ha publicado un artículo permite también su publicación en abierto.
  • Dulcinea
    Compruebe si la revista española en la que ha publicado un artículo permite también su publicación en abierto.
  • Recolecta
  • Observatorio I+D+i UPM
  • OpenCourseWare UPM