Puesta a punto y optimización de un software de control lateral para un prototipo de vehículo autónomo

Trabajo fin de M´ aster M´ aster en Ingenier ´ ıa de Telecomunicaci´ on Puesta a punto y optimizaci´on de un software de control lateral para un prototipo de veh´ıculo aut´onomo Autor: David Manso Fern´andez Tutores: Juan Carlos Aguado Manzano Adri´an Mazaira Hern´andez Septiembre 2024 T ´ ıtulo: Puesta a punto y optimizaci´on de un software de control lateral para un prototipo de veh´ıculo aut´onomo Autor: David Manso Fern´andez Tutor: Juan Carlos Aguado Manzano Departamento: Teor´ıa de la Se˜nal y Comunicaciones e Ingenier´ıa Telem´atica Tribunal Presidente: Ignacio de Miguel Jim´enez Secretario: Ram´on de la Rosa Steinz Vocal: Jes´us Mar´ıa Hern´andez Mangas Fecha: 26 de septiembre de 2024 Calificaci´ on: 1 Agradecimientos Me gustar´ıa dedicar unas palabras de agradecimiento a todas aquellas personas que han sido fundamentales en este proceso. En primer lugar, quiero agradecer profundamente a mis padres, Ramiro y Lola, por su apoyo incondicional, su paciencia y por haber estado siempre a mi lado, brind´andome la fuerza necesaria para seguir adelante. Su amor y dedicaci´on han sido el pilar sobre el que he construido cada logro. A mis hermanos, Jaime y Mar´ıa, por ser siempre una fuente de inspiraci´on y por acompa˜narme en cada paso de este camino. Vuestro cari˜no y ´animo constante han sido fundamentales para mantenerme motivado en todo momento. Quiero expresar mi gratitud tambi´en a mis tutores, Juan Carlos Aguado y Adri´an Mazaira, por su gu´ıa y sus valiosas ense˜nanzas a lo largo de este proyecto. Sus consejos han sido esenciales para que este trabajo pudiera alcanzar el nivel que esperaba. A Ignacio Royuela y ´ Oscar P´erez, por su apoyo en los momentos m´as complejos del proyecto, por compartir sus conocimientos y por estar siempre dispuestos a ayudar. Sin vosotros, este proyecto no habr´ıa sido posible. Tambi´en quiero agradecer de coraz´on a toda la gente que de una manera u otra ha contribuido a que este proyecto se haya materializado. A todos los que me hab´eis brindado vuestro tiempo, apoyo y comprensi´on durante este proceso, os estoy eternamente agradecido. Por ´ultimo, este trabajo est´a dedicado con todo mi amor a Lucas y Carmela. Aunque todav´ıa sois peque˜nos para entenderlo, sois una fuente de alegr´ıa inmensa en mi vida. Que este logro sea un ejemplo para vosotros de que con esfuerzo y dedicaci´on todo es posible. 2 Resumen Este Trabajo Fin de M´aster ha consistido en la mejora, reestructuraci´on y simplificaci´on de la arquitectura y sistemas de un prototipo de veh´ıculo aut´onomo. Al comienzo del proyecto el prototipo veh´ıculo aut´onomo estaba inoperativo, faltaban varios m´odulos electr´onicos por incorporar a la arquitectura y el esquema el´ectrico era deficiente. Las tareas realizadas han incluido la modificaci´on completa del cableado auxiliar del veh´ıculo para convertirlo en aut´onomo, el redise˜no de un controlador electr´onico para el acelerador, la incorporaci´on a la arquitectura de varios controladores electr´onicos todav´ıa no incluidos, entre los que destacamos el control de marchas y el control de acelerador, y la mejora del control lateral a trav´es de la modificaci´on de la aplicaci´on de control. Palabras Clave: Renault Twizy, TwizyContest, Veh´ıculo Aut´onomo, Control Lateral, Acelerador, Caja de cambios, Python, Arduino. Abstract This Master Thesis consisted of improving, restructuring, and simplifying the architecture and systems of an autonomous vehicle prototype. At the beginning of the project, the autonomous vehicle prototype was inoperative, several electronic modules were missing to be incorporated into the architecture and the electrical schematic was deficient. The tasks performed included the complete modification of the vehicle’s auxiliary wiring to make it autonomous, the redesign of an electronic controller for the accelerator, and the incorporation into the architecture of several electronic controllers not yet included, among which we highlight the gear control and the accelerator control, and the improvement of the lateral control through the modification of the control application. Keywords: Renault Twizy, TwizyContest, Autonomous Vehicle, Lateral Control, Throttle, Gearbox, Python, Arduino. 3 ´ Indice general 1. Introducci´on 9 1.1. Motivaci´on .......................................... 9 1.2. Objetivos ........................................... 11 1.3. Fasesym´etodos ....................................... 11 1.4. Recursos............................................ 12 1.5. Estructuradelamemoria .................................. 14 2. Revisi´on del proyecto TwizyLine 15 2.1. Introducci´on.......................................... 15 2.2. El Renault Twizy como concepto de movilidad sostenible . . . . . . . . . . . . . . . . 15 2.3. Funcionamiento y evoluci´on de los veh´ıculos aut´onomos . . . . . . . . . . . . . . . . . 17 2.4. TwizyLine: estado del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.1. ProyectoTwizyLine ................................. 20 2.4.2. Arquitectura y Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3. Conexionado el´ectrico y de comunicaciones 25 3.1. Introducci´on.......................................... 25 3.2. EstadoInicial......................................... 25 3.2.1. Partedelantera.................................... 25 3.2.2. Partetrasera ..................................... 26 3.2.3. Comunicaciones.................................... 26 3.2.4. Alimentaci´on ..................................... 27 3.3. Modificaciones ........................................ 28 3.3.1. Partedelantera.................................... 28 3.3.2. Partetrasera ..................................... 30 3.3.3. Comunicaciones.................................... 31 3.4. EstadoFinal ......................................... 32 3.4.1. Partedelantera.................................... 32 3.4.2. Partetrasera ..................................... 33 4. Controladores 36 4.1. Introducci´on.......................................... 36 4.2. Control de la Caja de Cambios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. ControlLongitudinal..................................... 39 4.3.1. Investigaci´on de un nuevo sistema . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.2. Desarrollo del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.3. Implementaci´on del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4. ControlLateral........................................ 48 4.4.1. Caracter´ısticas Principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.2. Modos de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.3. Alimentaci´onEPOS4................................. 52 4.4.4. Software........................................ 53 4 5. Software 55 5.1. Introducci´on.......................................... 55 5.2. Identificaci´on de los dispositivos conectados . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.1. Mapeo persistente dispositivos USB . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.2. Uso de variables de entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3. ProgramaPrincipal...................................... 57 5.4. Controllateral ........................................ 58 5.4.1. Estados de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.4.2. MemoriaCompartida ................................ 62 5.4.3. Alternativa al uso de Memoria Compartida . . . . . . . . . . . . . . . . . . . . 62 5.5. Simulaci´onenMATLAB................................... 63 6. Conclusiones y l´ıneas futuras 67 6.1. Conclusiones ......................................... 67 6.2. L´ıneasfuturas......................................... 68 5 ´ Indice de figuras 1.1. Logo del concurso TwizyContest 2020 ........................... 9 1.2. Logo del concurso TwizyLine ................................ 10 1.3. RenaultTwizy ........................................ 11 1.4. HummingBoardCBi..................................... 13 1.5. Receptor GPS Garmin GPS18x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6. Controladora EPOS4 Maxon Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1. RenaultTwizy ........................................ 15 2.2. Dise˜nodelRenaultTwizy .................................. 16 2.3. InteriordelRenaultTwizy.................................. 16 2.4. Radio de giro de Renault Twizy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5. EntornovistoporelLiDAR................................. 18 2.6. Entorno visto por las c´amaras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.7. Nivelesdeautonom´ıa..................................... 19 2.8. Pilares del proyecto TwizyLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.9. Implementaci´on del TwizyLine Parking . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.10. Sistema de guiado del veh´ıculo dentro del parking ..................... 21 2.11. Implementaci´on del conjunto del motor, los engranajes y el soporte en el Twizy. . . . . 22 2.12. Conjunto de im´agenes del proceso de guiado . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1. hub USBinicial........................................ 26 3.2. Esquema de la disposici´on original del OBD . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Bater´ıas en Renault Twizy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Controladordemarchas ................................... 28 3.5. Esquema final de la disposici´on del OBD . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6. Imagenfrontal ........................................ 29 3.7. PowerBox ........................................... 30 3.8. Esquema el´ectrico PowerBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.9. Esquemadelaredlocal ................................... 31 3.10. Disposici´on final del controlador del acelerador . . . . . . . . . . . . . . . . . . . . . . 32 3.11. Esquema implementado del cableado del veh´ıculo . . . . . . . . . . . . . . . . . . . . . 33 3.12. Disposici´on final de los elementos en el rack ........................ 34 3.13. Estado final del rack junto con el router yelinversor................... 34 3.14. Esquema final objetivo del cableado del veh´ıculo . . . . . . . . . . . . . . . . . . . . . 35 4.1. Botones RND del Renault Twizy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2. Instalaci´on del controlador de marchas . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3. Circuito el´ectrico del controlador de marchas . . . . . . . . . . . . . . . . . . . . . . . 38 4.4. Implementaci´on del control del acelerador . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.5. Diagrama de bloques del acelerador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.6. Conector de 6 pines del acelerador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.7. Circuito del pedal del acelerador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.8. Circuito el´ectrico completo del sistema del acelerador . . . . . . . . . . . . . . . . . . . 42 4.9. Sistema del acelerador simplificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6 4.10. Rango de voltajes te´orico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.11. Gr´afica de la variaci´on de Vout1yVout2........................... 44 4.12. Esquema el´ectrico del controlador del acelerador . . . . . . . . . . . . . . . . . . . . . 46 4.13. Dualidad del controlador del acelerador . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.14. Dise˜no final de las placas de prototipado . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.15. Esquema de la comunicaci´on M´odulo de Control - Motor . . . . . . . . . . . . . . . . . 48 4.16. Controladora EPOS4 70/15 y motor EC 60 flat . . . . . . . . . . . . . . . . . . . . . 49 4.17. Gr´aficas de los par´ametros del modo de posici´on . . . . . . . . . . . . . . . . . . . . . 50 4.18. Gr´aficas de los par´ametros del modo de velocidad . . . . . . . . . . . . . . . . . . . . . 51 4.19. Comparaci´on de velocidad y aceleraci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.20. Esquema el´ectrico de la EPOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.21. Modelado del circuito el´ectrico de la entrega de potencia a la EPOS . . . . . . . . . . 52 5.1. Esquema de procesos en el m´odulo de control . . . . . . . . . . . . . . . . . . . . . . . 58 5.2. Diferentes estados de funcionamiento de la EPOS4 . . . . . . . . . . . . . . . . . . . . 59 5.3. Diagrama de flujo del control lateral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.4. Ruta a realizar en la simulaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.5. Simulaci´onpara6km/h ................................... 65 5.6. Simulaci´onpara8km/h ................................... 66 5.7. Simulaci´on para 8km/h sin retardo de imagen . . . . . . . . . . . . . . . . . . . . . . . 66 7 ´ Indice de tablas 4.1. Tabla de ´ordenes y funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Tabla l´ogica de modos de funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3. Tabla de valores de Vout1yVout2en funci´on del pedal ( %). . . . . . . . . . . . . . . . 44 4.4. Tabla de valores te´oricos de nuestro sistema. . . . . . . . . . . . . . . . . . . . . . . . . 48 8 Cap´ıtulo 2 Revisi´on del proyecto TwizyLine 2.1. Introducci´on La revoluci´on de los veh´ıculos aut´onomos ha capturado la atenci´on del mundo, prometiendo transformar nuestra forma de transporte de una manera nunca antes vista y emergiendo como un ´area de investigaci´on y desarrollo que promete transformar radicalmente la industria. Entre los diversos modelos de veh´ıculos que se han utilizado como plataformas de experimentaci´on, el Renault Twizy, un autom´ovil el´ectrico compacto dise˜nado para la movilidad urbana, ha surgido como un candidato interesante que gracias a su simplicidad lo convierte en un lienzo ideal para explorar las posibilidades de la conducci´on aut´onoma. En este cap´ıtulo revisamos el estado del proyecto TwizyLine, que ser´a nuestro punto de partida, explicando su idea general y funciones implementadas hasta el momento. 2.2. El Renault Twizy como concepto de movilidad sostenible El Renault Twizy (ver figura 2.1) es un veh´ıculo el´ectrico fabricado por el fabricante franc´es de autom´oviles Renault. Se lanz´o al mercado en 2012 como un modelo de movilidad urbana, dise˜nado para ofrecer una alternativa compacta y eficiente para desplazamientos cortos en entornos urbanos congestionados. Con su dise˜no peculiar y su naturaleza el´ectrica, el Twizy captur´o la atenci´on de los consumidores y los entusiastas de la movilidad el´ectrica en todo el mundo. [9] [10] Figura 2.1: Renault Twizy El Twizy tiene capacidad para dos personas, con asientos dispuestos en t´andem, lo que significa 15 que uno se sienta detr´as del otro. Esta disposici´on compacta le permite al Twizy ocupar menos espacio en la carretera y facilita su manejo en entornos urbanos estrechos y concurridos. Adem´as, su dise˜no abierto y sin ventanas laterales lo hace perfecto para climas c´alidos y soleados. (ver Figura 2.2) [11] Figura 2.2: Dise˜no del Renault Twizy En t´erminos de rendimiento, el Twizy est´a equipado con un motor el´ectrico que ofrece una potencia modesta pero adecuada para la conducci´on en la ciudad. Se puso a la venta con dos motorizaciones [12] [13]: Twizy 45: Tiene un motor de 7.6 kW o 10 CV que alcanza una velocidad m´axima de 45 km/h. Twizy 80: Tiene un motor de 12.6 kW o 17 CV que alcanza una velocidad m´axima de 80 km/h. Figura 2.3: Interior del Renault Twizy Su bater´ıa el´ectrica proporciona una autonom´ıa que var´ıa seg´un las condiciones de conducci´on y la motorizaci´on, llegando hasta los 90 km y 100 km respectivamente en funci´on de la versi´on. De todos modos, el Twizy est´a pensado para recorridos cortos y desplazamientos urbanos.[12] [9] Una de las caracter´ısticas m´as destacadas del Twizy es su enfoque en la sostenibilidad y la eficiencia energ´etica. Al ser completamente el´ectrico, el Twizy no produce emisiones de escape, lo que 16 lo convierte en una opci´on respetuosa con el medio ambiente para la movilidad urbana. Adem´as, su dise˜no ligero y compacto, ya que tiene unas dimensiones de 2.3 m de largo y de tan solo 1.2 m de ancho, permitiendo un radio de giro desde 3.4 metros como se muestra en la figura 2.4. [13][12] Figura 2.4: Radio de giro de Renault Twizy A lo largo de los a˜nos, el Twizy ha ganado popularidad en el mercado de veh´ıculos el´ectricos y se ha convertido en una opci´on atractiva para aquellos que buscan una alternativa econ´omica y sostenible para desplazamientos urbanos. Comenz´o fabric´andose en Valladolid, aunque desde finales de 2018, su producci´on se traslad´o a Corea. En total, desde su lanzamiento hasta junio de 2023, la marca gala ha comercializado 33.340 unidades del Twizy en 55 pa´ıses, con un especial ´exito en Francia, Alemania, Corea del Sur e Italia. [12] 2.3. Funcionamiento y evoluci´on de los veh´ıculos aut´onomos El funcionamiento de los veh´ıculos aut´onomos se basa en una compleja combinaci´on de tecnolog´ıas, incluyendo sensores, sistemas de procesamiento de datos y algoritmos de control. A lo largo de los a˜nos, hemos sido testigos de una r´apida evoluci´on en estas tecnolog´ıas, desde los primeros prototipos de veh´ıculos aut´onomos hasta los sistemas altamente sofisticados que vemos hoy en d´ıa en desarrollo. Cada nuevo prototipo trae consigo mejoras significativas en la capacidad de percepci´on y toma de decisiones de los veh´ıculos aut´onomos, acerc´andonos cada vez m´as a un futuro de transporte completamente aut´onomo. El funcionamiento de un veh´ıculo aut´onomo se puede simplificar en tres partes: Percepci´on del entorno: Gracias a la variedad de tecnolog´ıas de sensores, entre las que destacan c´amaras (Figura 2.6), esc´aneres LiDAR (Ver Figura 2.5) y radares de diferente tipo, nos permiten percibir el entorno y poder detectar obst´aculos, peatones, se˜nales de tr´afico y otros veh´ıculos en la carretera. Adem´as, los veh´ıculos aut´onomos suelen contar con alguna tecnolog´ıa de geolocalizaci´on, que ayuda a completar la propiocepci´on. Procesamiento de los datos obtenidos: Los datos recopilados por estos sensores se procesan a trav´es de sistemas de inteligencia artificial y algoritmos de aprendizaje autom´atico, que analizan la informaci´on y toman decisiones en tiempo real sobre la navegaci´on y el control del veh´ıculo. Estos algoritmos son capaces de reconocer patrones en los datos sensoriales y anticipar posibles escenarios de conducci´on, lo que permite que el veh´ıculo tome decisiones seguras y eficientes en la carretera. 17 Figura 2.5: Entorno visto por el LiDAR [14] Actuadores: El ´ultimo pilar de los veh´ıculos aut´onomos son los actuadores que controlar´an el movimiento del veh´ıculo. Fundamentalmente, son los actuadores relacionados con el movimiento lateral y longitudinal, esto es, volante, acelerador y cambio de marchas (si el veh´ıculo no es autom´atico, aunque la mayor´ıa de veh´ıculos aut´onomos ya incorporan el cambio autom´atico). Figura 2.6: Entorno visto por las c´amaras [14] La evoluci´on de los veh´ıculos aut´onomos tambi´en ha sido impulsada por la creciente demanda de soluciones de movilidad m´as seguras, eficientes y accesibles. Con la promesa de reducir los accidentes de tr´afico, mejorar la eficiencia del transporte y proporcionar una mayor autonom´ıa a personas con movilidad reducida, los veh´ıculos aut´onomos representan un ´area de investigaci´on y desarrollo de gran importancia para la industria automotriz y la sociedad en su conjunto. [15] [5] A lo largo de las ´ultimas d´ecadas, hemos sido testigos de una r´apida evoluci´on en estas ´areas, lo que ha permitido el desarrollo de sistemas de conducci´on aut´onoma cada vez m´as sofisticados y capaces. En las primeras etapas de desarrollo, los avances se centraban principalmente en funciones b´asicas de asistencia al conductor, como el control de crucero adaptativo y el estacionamiento asistido. Sin embargo, en los ´ultimos a˜nos, hemos visto un avance significativo hacia veh´ıculos completamente aut´onomos, capaces de operar sin intervenci´on humana en una amplia variedad de entornos y condiciones de conducci´on.[16] [15] 18 Driver is fully responsible for driving the vehicle while system provides momentary driving assistance, like warnings and alerts, or emergency safety interventions. Level 0 Momentary Driver Assistance You drive, you monitor. Level 1Driver is fully responsible Driver for driving the vehicle while Assistance system provides continuous assistance with either You drive, acceleration/braking you monitor. OR steering. Level 2Driver is fully responsible Additional for driving the vehicle while Driver system provides continuous Assistance assistance with both You drive, acceleration/braking you monitor. AND steering. Level 3 Conditional System handles all aspects of Automation driving while driver remains available to take over driving if System drives, you must be available system can no longer operate. to take over upon request. Level 4When engaged, system is fully High responsible for driving tasks Automation within limited service areas. A When engaged, human driver is not needed to system drives, operate the vehicle. you ride. Level 5When engaged, system is fully Full responsible for driving tasks Automation under all conditions and on all roadways. A human driver is When engaged, not needed to operate the system drives, you ride. vehicle. Levels of Automation Figura 2.7: Niveles de autonom´ıa [15] Dada la diversidad de soluciones a las que se puede llamar veh´ıculo aut´onomo, se ha llegado a un consenso sobre c´omo categorizar los veh´ıculos aut´onomos en niveles dependiendo del grado de autonom´ıa que realmente es capaz de dar. Los niveles de autonom´ıa de los veh´ıculos son (Ver Figura 2.7) [15]: Nivel 0: Sin automatizaci´on. El conductor es responsable de todas las tareas de conducci´on. Nivel 1: El veh´ıculo puede realizar algunas tareas. Estas tareas pueden ser el control lateral (mantenimiento de carril) o longitudinal (Control de Velocidad) pero las realiza de manera independiente y nunca de manera simult´anea. Nivel 2: El veh´ıculo puede controlar ambas tareas de manera simult´anea. Un ejemplo puede ser el asistente de aparcamiento en el que el conductor no tenga que tocar ni el volante ni los pedales. Nivel 3: El veh´ıculo puede realizar la mayor´ıa de las tareas de conducci´on. Percibe el entorno y puede actuar en funci´on de ´el. Este modo requiere supervisi´on constante del conductor. Algunos 19 veh´ıculos actuales ya incorporan el nivel 3, como los Mercedes Clase S, que con su sistema Drive Pilot pueden moverse de manera aut´onoma, aunque de momento est´a aprobado por las autoridades a ir a un m´aximo de 60 km/h. Nivel 4: El coche puede realizar todas las tareas de la conducci´on, pero solo en dominios operacionales previamente definidos. Cuando el dominio operacional no se cumple, o bien el veh´ıculo entra en modo seguro y se detiene o bien solicita la toma de control por parte del conductor. El proyecto TwizyLine se enmarcar´ıa dentro de este nivel. Nivel 5: El coche ya no tiene ni pedales ni volante, ya que disponen de la automatizaci´on total y no depende del ser humano. 2.4. TwizyLine: estado del proyecto 2.4.1. Proyecto TwizyLine La cuarta edici´on del concurso TwizyContest, con el que se comenz´o el proyecto TwizyLine, puso el foco en la movilidad de los Juegos Ol´ımpicos de Par´ıs 2024. La idea no solo era ayudar al transporte de los atletas y periodistas de los Juegos de una manera limpia y eficiente, sino que adem´as se pretend´ıa buscar una revoluci´on en el ´ambito de los coches compartidos. Planteando una visi´on futurista de las ciudades inteligentes en la que no haya problemas de contaminaci´on y de aparcamiento. [2] Figura 2.8: Pilares del proyecto TwizyLine La idea principal presentada en TwizyLine consist´ıa en el dise˜no de un parking inteligente en el que los coches se aparcaran de manera aut´onoma dentro de ´el sin necesidad de ning´un conductor. El veh´ıculo entra en modo aut´onomo en el momento que el conductor abandona el veh´ıculo a la entrada del parking (Leaving Zone 2.9) y este sigue por s´ı mismo una banda magn´etica en el suelo hasta su plaza de aparcamiento, en ella se cargar´a el coche mediante un sistema de carga inal´ambrica por inducci´on. De igual manera, cu´ando se requiera los servicios de este coche, se dirigir´a de manera aut´onoma a la salida (Pick up Zone 2.9) siguiendo las l´ıneas donde estar´a esperando el conductor. [17] Figura 2.9: Implementaci´on del TwizyLine Parking 20 Los coches para poder moverse de manera eficiente dentro del parking cuenta con un sistema de guiado en un trazado de l´ıneas (representadas en la figura 2.10 como l´ıneas de colores) en las que decide por cu´al ir en el punto de decisi´on: L´ıneas representadas en verde: Es la l´ınea de espera de los veh´ıculos que no tienen ning´un problema y pueden ser utilizados inmediatamente. L´ıneas representadas en amarillo: Tiene como destino la zona de cargadores d´onde los veh´ıculos se recargar´an por inducci´on y la zona de reparaci´on. Figura 2.10: Sistema de guiado del veh´ıculo dentro del parking 2.4.2. Arquitectura y Software Para que el Twizy sea aut´onomo 100 % necesita poder moverse por s´ı solo, esto incluye tanto el control del movimiento longitudinal como el lateral. Adem´as, requiere de un sistema de guiado o similar que le permita al veh´ıculo saber su posici´on actual o poder ver hacia d´onde tiene que ir. Las soluciones a cada una de estas necesidades han evolucionado con el tiempo. En las siguientes subsecciones se realiza una breve revisi´on a dicha evoluci´on hasta el estado del veh´ıculo justo antes del inicio de este proyecto. Control Longitudinal El control longitudinal solo se ha aplicado sobre el acelerador del veh´ıculo. Hasta el momento no se ha intervenido el freno, debido a que se trata de un sistema mec´anico que requerir´ıa a˜nadir un motor de control. Para ser capaces de acelerar el coche, ha sido necesario interceptar el circuito el´ectrico que va desde el pedal del acelerador hasta el motor del veh´ıculo. Desde el origen del proyecto se instal´o un circuito electr´onico controlado por un Arduino que era capaz de habilitar dos estados posibles: control manual del acelerador, dejando el circuito electr´onico original del veh´ıculo en su configuraci´on original, y control electr´onico del acelerador, en el que el Arduino realiza un bypass del pedal mec´anico y controlando dos potenci´ometros en el circuito electr´onico dise˜nado simula la presi´on del pedal mec´anico. A fecha de inicio del este proyecto exist´ıan dos versiones del circuito controlador del acelerador. Este punto se ver´a con m´as detenimiento en el apartado 4.3. Adem´as, dentro del control longitudinal tambi´en se ha desarrollado un dispositivo para el control de las marchas autom´atico del veh´ıculo. Este dispositivo, aunque estaba originalmente previsto, fue una adici´on posterior al prototipo original de TwizyLine y no ha sido convenientemente probado en el veh´ıculo. Este punto se ver´a con m´as detenimiento en el apartado 4.2. 21 Control Lateral Uno de los principales problemas de veh´ıculo Twizy es que no cuenta con direcci´on asistida. Esto significa que no era posible desarrollar una soluci´on software que utilizar´a dicha asistencia para el control lateral. Por ello, desde el primer prototipo se opt´o por una soluci´on que se basa en actuar sobre la columna de direcci´on del coche [6] con un motor de la compa˜n´ıa Maxon (ver Figura 2.11, sacada de [6]), en concreto el Maxon Motor EC60, junto con la controladora EPOS4, que ser´a con la que nos comuniquemos para hacer trabajar el motor de Maxon y as´ı poder girar el volante sin necesidad de intervenci´on humana. Figura 2.11: Implementaci´on del conjunto del motor, los engranajes y el soporte en el Twizy. Para acoplar el motor Maxon a la columna de direcci´on del veh´ıculo se a˜nadi´o una rueda dentada sujeta a dicha columna que transmiten directamente la potencia del giro del motor Maxon al eje de la direcci´on y as´ı poder girar las ruedas. La controladora EPOS4 es la que recibe las ´ordenes del m´odulo de control y hace trabajar al motor de control lateral en consecuencia. Guiado El guiado original del veh´ıculo estaba previsto realizarlo mediante unas bandas con propiedades magn´eticas que, junto con el sensor magn´etico en la parte delantera del veh´ıculo, permit´ıan que se pudiera seguir dicha l´ınea. Este sensor era capaz de detectar la distancia respecto al centro de la banda y as´ı poder determinar hacia d´onde y cu´anto girar el volante. Los resultados de control no fueron lo suficientemente estables, dado que los requerimientos de control eran excesivamente estrictos (el veh´ıculo no pod´ıa desplazarse m´as de 7 cm a izquierda o derecha de la l´ınea magn´etica) por lo que finalmente se opt´o por buscar una alternativa al sensor magn´etico. Finalmente, se decidi´o implementar un sistema de reconocimiento de im´agenes que es capaz de reconocer una l´ınea a seguir gracias a una c´amara que se ha acoplado en la parte delantera del veh´ıculo, junto a la tapa de carga del coche. Esta c´amara apunta al suelo y, junto con un procesamiento de las im´agenes capturadas por esta, es capaz de reconocer la l´ınea y determinar la distancia respecto al centro de la misma. Las bandas magn´eticas se sustituyeron por unas bandas de goma pintadas en color azul para que sean f´acilmente reconocidas por la c´amara. En la figura 2.12 se muestra el proceso que tiene una imagen capturada por la c´amara, este proceso consiste en una transformaci´on de la 22 (a) Imagen procesada que muestra la l´ınea a seguir (b) Imagen filtrada (c) Imagen transformada (d) Imagen real capturada por la c´amara Figura 2.12: Conjunto de im´agenes del proceso de guiado perspectiva y un filtro que resalte el color azul de la banda del suelo. Para que el veh´ıculo conociera mejor el entorno, se a˜nadieron un array de sensores de ultrasonidos, tres en la parte delantera, concretamente: uno en el centro y los otros dos en los extremos laterales. Estos sensores permiten al coche detectar obst´aculos que se encuentren delante del veh´ıculo y as´ı poder evitar posibles atropellos cuando este vaya sin conductor. El trabajo realizado por Carlota G´omez consist´ıa tambi´en en el uso del LiDAR como sistema de guiado. La idea principal era disponer de un mapa 3D capturado previamente con el LiDAR con el objetivo de ser capaz de ubicar el veh´ıculo en ese mapa a partir de la nube de puntos capturada en tiempo real. Este m´etodo no se lleg´o a incorporar debido a la dificultad de alimentar la librer´ıa de partida con las se˜nales que solicitaba y a la dificultad de la localizaci´on del veh´ıculo a partir de un mapa pregrabado, cuesti´on que el software con el que se trabajaba no resolv´ıa.[5] Procesado Para hacer posible todo lo mencionado en este apartado, se necesitaba de un ordenador que recibiera todos los inputs capturados por los sensores y tomara decisiones al respecto. Para esto, se opt´o por el uso de la microcontroladora HummingBoard, que es similar a una Raspberry Pi. Esta es capaz de procesar la informaci´on recibida por los sensores, determinar si estamos siguiendo correctamente la l´ınea o, por el contrario, si nos estamos desviando, y corregir el fallo. Adem´as, puede detectar si hay 23 un obst´aculo cerca gracias a los sensores de ultrasonidos y detener el coche si es necesario. Para ejecutar las ´ordenes, se comunica con los Arduinos, tanto para recibir la informaci´on de los sensores como para actuar sobre el acelerador. Tambi´en se comunica directamente con la controladora EPOS4 mediante USB para girar el coche. Control Remoto Una de las ideas de este proyecto era que el cliente pudiese solicitar el servicio del Twizy mediante su aplicaci´on, por lo que se necesitaba que el coche estuviera conectado a Internet para que pudiera recibir las ´ordenes del servidor que se comunicaba con el smartphone del cliente. Por esto, se necesitaba de un m´odem 4G y de un servidor MQTT para la comunicaci´on Veh´ıculo-Smartphone. Para la optimizaci´on de recursos y un mejor aprovechamiento, se opt´o por incluir una nueva HummingBoard (M´odulo de Comunicaciones) que se encargara de todo lo relacionado con las comunicaciones externas y actuara como intermediario entre el m´odulo de control e Internet. A este m´odulo se le conectar´an el m´odem 4G y el receptor GPS v´ıa USB, mientras que, por otro lado, el m´odulo estar´a conectado a un servidor MQTT por el que recibir´a las ´ordenes externas para actuar en consecuencia. El servidor MQTT estaba alojado en una Raspberry Pi situada fuera del veh´ıculo, pero actualmente el servidor se ejecuta en un PC externo dentro de la misma subred del coche, como se detallar´a m´as adelante. Cableado El conexionado del veh´ıculo en el momento de partida de este proyecto se tratar´a con una mayor profundidad en el cap´ıtulo siguiente. 24 A A B B 1 1 2 2 3 3 TITLE: PowerBox Schematic REV: 1.0 Date: 2023-11-16 Sheet: 1/1 Drawn By: Company: David Manso Fernandez FuseBox AMPERIMETER Mod-Com Mod-Con Router X EPOS4 X PowerBox Battery 12V Figura 3.8: Esquema el´ectrico PowerBox suelo que ha de seguir. 3.3.3. Comunicaciones Eth Eth Twizzy Mod-Com Mod-Con MQTT Envío de mensajes MQTT MQTT PC Servidor MQTT SSH SSH Figura 3.9: Esquema de la red local En cu´anto a las comunicaciones, con el objetivo de evitar la comunicaci´on RS232 con los m´odulos de control, se ha decidido realizar esta conexi´on mediante el protocolo SSH. Este protocolo nos ofrece 31 la posibilidad de conectarnos a los m´odulos sin ning´un cable, solamente es necesario estar en la misma red local. Para que esto sea posible se ha incluido en el rack trasero del veh´ıculo el router, que se alimentar´a de los 220 V que nos da el inversor de corriente DC/AC. Adem´as, ambos m´odulos est´an conectados mediante cables Ethernet al router que, junto con mi ordenador y un smartphone conectado v´ıa Wifi, disponemos de todos los elementos necesarios en la misma red local para poder comunicarnos con el veh´ıculo y enviarle los mensajes MQTT. En la figura 3.9 se representa esta red local. 3.4. Estado Final El estado final del veh´ıculo se detallar´a a continuaci´on y su esquema se representa en la figura 3.11. 3.4.1. Parte delantera Finalmente, debido a diferentes contratiempos (descritos a continuaci´on), se ha optado por conectar los componentes de la siguiente manera: Al hub USB se conectar´an los sensores de ultrasonidos y RFID, as´ı c´omo la c´amara y el controlador de marchas. El controlador del acelerador se conectar´a directamente al m´odulo de control debido a que al pasar por el hub se produce una ca´ıda de alimentaci´on, provocando que seamos incapaces de poder activar los rel´es que est´an en el interior del controlador. Este problema no nos permit´ıa hacer el bypass entre el pedal y la se˜nal de salida del Arduino del controlador. En la figura 3.10 se muestra la disposici´on final del controlador en el veh´ıculo. Figura 3.10: Disposici´on final del controlador del acelerador El cable USB de comunicaci´on de la EPOS4 va directamente conectado al m´odulo de control como ya hac´ıa anteriormente. La EPOS4 se alimentar´a finalmente desde la bater´ıa de servicio, como se hac´ıa anteriormente. Esto es debido a que la controladora necesita una determinada alimentaci´on y al querer introducir un interruptor entre medias para poder controlar el encendido y apagado, este introduc´ıa una ca´ıda de tensi´on que provocaba que la EPOS4 entrase en modo de fallo por error en las condiciones de alimentaci´on. Este tema se explicar´a m´as adelante en el apartado 4.4.3. 32 12V Batería de Servicio POWER BOX GPIO MOD-COM MOD-CON GPS HUB USB USB EPOS4 Sensor Ultrasonidos Sensor RFID Control Marchas Control Acelerador CAN BUS OBD Pin SPYBOX CAN Parte delantera Parte trasera 12V DC ETH USB BUS CAN DB9 DB9 DB9 Pin ProtoBoard GPIO Amperímetro Cámara ETHERNET Router 58V DC 220V AC Inversor DC-AC 58V DC Batería Vehículo Transformador 12V 12V 220 V AC Figura 3.11: Esquema implementado del cableado del veh´ıculo 3.4.2. Parte trasera Debido al problema con la alimentaci´on de la EPOS4 que veremos en la secci´on 4.4.3, los 12 V procedentes de la bater´ıa de servicio se van a destinar a la EPOS4, mientras que para alimentar el resto de componentes conectados a la PowerBox se va a utilizar el inversor de corriente alterna que estaba en el rack del coche. Inicialmente, este inversor est´a pensado para alimentar el PC Fusi´on en implementaciones futuras, pero de momento se va utilizar para alimentar la caja de conexiones. La forma de hacerlo es conectando un transformador de 12 V y 1 A a la salida del inversor de 220 V para obtener corriente continua y alimentar la PowerBox. En la figura 3.12 se muestra la disposici´on de las Humming junto con la PowerBox en el nivel inferior del rack. A esta disposici´on habr´ıa que a˜nadirle el hub como veremos en la figura 3.13. Inicialmente, el router se alimentaba directamente del inversor con el transformador, como si se enchufase a la red el´ectrica. Pero ya que hab´ıa tomas de conexi´on restantes en la PowerBox se decidi´o conectarlo directamente el router a esta PowerBox para tener todos los dispositivos electr´onicos en una misma caja de conexiones y de paso, obtener la medici´on completa del consumo de todos ellos. En cuanto a la bater´ıa de tracci´on del veh´ıculo, se le conectar´a el inversor de DC-AC para convertir los 400 V de corriente continua de la bater´ıa a 220 V en corriente alterna. Este inversor alimentar´a al PC m´aster en una futura implementaci´on. Del router saldr´an dos cables Ethernet que se conectan con las Humming Board, el m´odulo de control y el de comunicaciones, creando una red local cableada. 33 Figura 3.12: Disposici´on final de los elementos en el rack El m´odulo de comunicaciones, mediante los pines GPIO que tiene en su interior, enciende y cambia de color los led que se encuentran encima del volante, con el objetivo de tener una indicaci´on visual del modo en el que est´a el veh´ıculo. [7] Adem´as se le conectar´a el cable USB procedente del GPS que se situara en el techo del veh´ıculo. Figura 3.13: Estado final del rack junto con el router y el inversor Por ´ultimo, el bus CAN parte del puerto OBD del veh´ıculo que se sit´ua en la guantera izquierda. De aqu´ı sacamos 3 cables que contienen los buses CANL, CANH y GND necesarios para la comunicaci´on CAN. Estos cables llegan a un hub CAN, que se situar´a justo detr´as del asiento del piloto de manera vertical, mediante el conector DB9 y de este hub, saldr´an dos buses que conectar´an con ambas Humming Board. Teniendo una topolog´ıa de bus al que est´an conectados los m´odulos de control y comunicaciones junto con todas las comunicaciones CAN del veh´ıculo. Para tener una visi´on m´as completa de la nueva implementaci´on podemos ver en la figura 3.13 como est´an colocados los componentes en el rack, as´ı como el router en la balda superior y el espacio libre destinado al PC fusi´on. A modo de resumen cabe destacar que se ha pasado de un sistema cuyo cableado era muy fr´agil, 34 propenso a fallos y desordenado a un cableado que resulta f´acil de trazar, mucho mejor desplegado evitando fallos y adem´as se tiene una caja de conexiones con la que poder controlar los dispositivos que est´an encendidos, aportando un mejor control del consumo en el veh´ıculo y un mejor control de qu´e dispositivos queremos que funcionen dependiendo de la prueba a realizar. El esquema el´ectrico objetivo que se quiere conseguir en futuras implementaciones es el mostrado a continuaci´on en la figura 3.14. Para lograr este esquema se necesitar´an interruptores adecuados para la PowerBox como se explicar´a en cap´ıtulos siguientes, en concreto en el apartado 4.4.3. 12V Batería de Servicio POWER BOX GPIO MOD-COM MOD-CON GPS HUB USB USB EPOS4 Sensor Ultrasonidos Sensor RFID Control Marchas Control Acelerador CAN BUS OBD Pin SPYBOX CAN Parte delantera Parte trasera 12V ETH USB BUS CAN DB9 DB9 DB9 Pin ProtoBoard GPIO Amperímetro Cámara ETHERNET Router Figura 3.14: Esquema final objetivo del cableado del veh´ıculo 35 Cap´ıtulo 4 Controladores 4.1. Introducci´on En este cap´ıtulo vamos a ver los diferentes controladores que se han tenido que modificar para poder cumplir los requisitos del proyecto. Para poder cambiar la marcha del coche de manera aut´onoma se ha continuado con el proyecto de Mohammad Kanaan [8] que implement´o un circuito controlador de marchas y se ha desarrollado el software de control e instalado en el veh´ıculo. Para el control longitudinal se esperaba partir del circuito desarrollado tambi´en en el proyecto de Mohammad Kanaan, pero debido a que no hab´ıa dejado un programa de control que explicar´a el funcionamiento del circuito y que, adem´as, no parec´ıa funcionar adecuadamente, se ha tenido que desarrollar uno nuevo desde cero. Por ´ultimo, para el control lateral se ha trabajado con la controladora EPOS4 de la compa˜n´ıa Maxon Motor, que como se ha mencionado anteriormente, gracias a un motor y unos engranajes, permite girar la columna de direcci´on y controlar el giro de las ruedas. En este caso se decidi´o cambiar el modo en el que la controladora realizaba el giro de las ruedas, cambiando del modo de posici´on al modo de velocidad, como veremos m´as adelante, con el objetivo de poder girar las ruedas a una mayor velocidad lo que nos permita aumentar la velocidad del veh´ıculo y seguir la l´ınea con una mayor facilidad. 4.2. Control de la Caja de Cambios Uno de los objetivos de este proyecto consiste en la integraci´on de un controlador de marchas autom´atico, el cual ha sido dise˜nado y fabricado en el proyecto de Mohammad Kanaan [8]. Este controlador, al igual que ocurrir´a despu´es con el acelerador, permite trabajar en dos modos. Por un lado, el modo manual, en el que el veh´ıculo funciona como si no se hubiera incorporado un nuevo controlador y, por otro lado, el modo autom´atico, en el que el controlador de marchas instalado realiza un bypass del control manual anul´andolo y pasando a ser controlado por el nuevo controlador, tal y como se explica en la figura ??. Este coche tiene una caja de cambios RND que significa que las marchas disponibles son ´unicamente Drive,Reverse yNeutral. El objetivo de este controlador aparte de los mencionados anteriormente es que sea capaz de permitir la conducci´on aut´onoma, introduciendo la marcha requerida mediante el m´odulo de control, as´ı c´omo la conducci´on manual por parte de un conductor, habilitando el cambio de marcha mediante los botones RND que el coche trae de serie, ver figura 4.1. 36 Figura 4.1: Botones RND del Renault Twizy En cuanto a la instalaci´on del controlador, se ha optado por ubicarlo junto a la guantera izquierda, mirando hacia abajo y sujetado por velcro, como se muestra en la figura 4.2. Por su parte, la botonera est´a conectada al controlador del motor de tracci´on del veh´ıculo a trav´es de un conector situado detr´as de ella. El controlador se va a colocar al medio de este conector a trav´es de sus dos salidas, una que se conecta con el controlador del motor de tracci´on y la otra que conecta con la botonera RND. Adem´as, se tiene un cable USB que conecta con la Humming. (a) Instalaci´on frontal del controlador de marchas (b) Instalaci´on lateral del controlador de marchas Figura 4.2: Instalaci´on del controlador de marchas Por ejemplo, la idea principal en los inicios del proyecto es que llegue el veh´ıculo conducido por un conductor a la entrada de un parking, lugar en el que el conductor abandona el veh´ıculo y este se pondr´ıa en modo aut´onomo para dirigirse a su lugar de aparcamiento realizando los cambios de marchas necesarios electr´onicamente. Otra utilidad del control de marchas que se ha planteado es que a la hora de frenar el veh´ıculo, 37 dado que el veh´ıculo no tiene un sistema de freno controlable electr´onicamente, se introduzca la marcha Ry acelerar para reducir la velocidad. Esto requiere que la caja de cambios del coche cambie de manera aut´onoma. Para lograr esto se utilizar´a el controlador de marchas dise˜nado por un Mohammad Kanaan [8] que integra un Arduino Nano, microcontrolador encargado de habilitar las se˜nales pertinentes para realizar el control del cambio de marchas. Kanaan no dej´o ninguna instrucci´on o programa que indicara c´omo funcionaba el controlador, as´ı que hubo que analizar el mismo y se program´o un nuevo c´odigo para pasar de modo manual a aut´onomo y para cambiar las marchas en funci´on de las necesidades que requiera el programa principal del veh´ıculo. El controlador est´a conectado con el m´odulo de control mediante USB y este es el encargado de decidir c´omo tiene que actuar envi´andole comandos por el bus serie. En funci´on de los comandos recibidos, el controlador puede actuar de la siguiente forma: Comando Funci´on Manual Control Manual Automatic Control Autom´atico Go Marcha: D Reverse Marcha: R Neutral Marcha: N Tabla 4.1: Tabla de ´ordenes y funcionamiento. Figura 4.3: Circuito el´ectrico del controlador de marchas [8] La circuiter´ıa interna del controlador de marchas se basa en un Arduino Nano que controlar´a los estados y las acciones a trav´es de los pines D13,D7 yD8. En concreto, el pin D13 act´ua sobre el rel´e U3, mostrado en la figura 4.3, que en funci´on del voltaje que reciba por el pin 1 provoca que el controlador act´ue como pasarela o tenga el control sobre las marchas del veh´ıculo. Los pines D7 y D8 38 son los que act´uan sobre el resto del circuito que representar´ıa el actuador, permitiendo el bypass de la botonera para poner el veh´ıculo en modo aut´onomo y el control de las se˜nales el´ectricas que recibe la caja de cambios para cambiar la marcha. La tabla l´ogica de estos pines es la siguiente: Pin 13 Pin 7 Pin 8 Modo 0 X X Manual 1 0 0 Aut´onomo / Mantiene marcha 1 0 1 D 1 1 0 R 1 1 1 N Tabla 4.2: Tabla l´ogica de modos de funcionamiento. La idea es que si el pin D13 est´a en baja, el controlador act´ue como pasarela entre lo que entra por los botones del veh´ıculo y la caja de cambios. Mientras que si est´a a ‘1’ la se˜nal que entra al veh´ıculo es la que se env´ıa por el Arduino en funci´on de lo que reciba del m´odulo de control. 4.3. Control Longitudinal El sistema del pedal del acelerador en un veh´ıculo, tanto de combusti´on como el´ectrico, controla la cantidad de combustible o energ´ıa el´ectrica que se env´ıa al motor para aumentar la velocidad. Cuando el conductor presiona el pedal del acelerador, se env´ıa una se˜nal al sistema de gesti´on del motor, que interpreta esta entrada y ajusta la cantidad de combustible o energ´ıa el´ectrica suministrada al motor, aumentando as´ı la velocidad del veh´ıculo. En un veh´ıculo de combusti´on interna, esta se˜nal se traduce en la apertura de la mariposa del acelerador, permitiendo que entre m´as aire y combustible al motor. En un veh´ıculo el´ectrico, la se˜nal del pedal del acelerador controla la cantidad de energ´ıa el´ectrica enviada al motor el´ectrico. Figura 4.4: Implementaci´on del control del acelerador En cuanto a nuestro sistema, tenemos en la figura 4.4 la implementaci´on del bypass que nos permite actuar sobre los valores que enviar´ıa el pedal del acelerador en un funcionamiento “normal”. El sistema cuenta con dos potenci´ometros cuya salida se conecta directamente a la ECU que controla la cantidad de energ´ıa suministrada por el motor. Estos potenci´ometros se controlan mediante un Arduino a trav´es de comunicaci´on SPI, que a su vez este se encuentra a la espera de las peticiones del m´odulo de control para actuar sobre el sistema de aceleraci´on del veh´ıculo. [7] 39 Durante el proceso de poner en marcha un veh´ıculo de manera aut´onoma, se detect´o que el controlador del acelerador dise˜nado por Kanaan no funcionaba, probablemente porque uno de los potenci´ometros hab´ıa fallado, impidiendo el control longitudinal del veh´ıculo. Dado que no se contaba con documentaci´on adecuada, fue necesario investigar desde cero el funcionamiento del sistema para comprender el sistema del acelerador y diagnosticar el problema, as´ı como dise˜nar de nuevo un controlador que nos permitiera actuar sobre la aceleraci´on del veh´ıculo. 4.3.1. Investigaci´on de un nuevo sistema Para poner en contexto como funciona el acelerador, en la figura 4.5 se muestra el diagrama de bloques del acelerador. Tenemos como entrada la presi´on que se ejerce sobre el pedal, esta act´ua sobre dos circuitos diferentes que contienen un potenci´ometro y resistencias cada uno, cada circuito entrega un voltaje a su salida conocido como Vout que llega a la ECU que controla la energ´ıa que debe desplegar el motor. % Pedal Pedal Vout1 Circuito Potenciómetro 1 Vout2 Circuito Potenciómetro 2 ECU Vdd GND Figura 4.5: Diagrama de bloques del acelerador Durante la investigaci´on, se descubri´o que, aparte de haber un microcontrolador defectuoso, la configuraci´on de pines de salida Vout1yVout2dise˜nada por Kanaan era incorrecta, ya que los pines de salida Vout1yVout2(mostrados en la figura 4.6, sacada de [8]) estaban intercambiados, ya que la disposici´on correcta es el pin 1 para Vout2y el pin 4 para Vout1. Figura 4.6: Conector de 6 pines del acelerador Por lo tanto, se decidi´o rehacer por entero el controlador de acelerador, investigando desde cero el funcionamiento de acelerador en el veh´ıculo. Una v´ıa de investigaci´on era medir las resistencias que 40 Vout-Pedal Pedal Vref ECU Vref Vout-Pedal Controlador Vout-Pedal Pedal Vref ECU Vref Vout-Pot Controlador Figura 4.13: Dualidad del controlador del acelerador de modificar los valores de resistencia del divisor de voltaje y tener el voltaje de salida Vout−P ot que queramos. Este voltaje de salida oscila entre el voltaje VayVb, siendo Va=Vref yVbser´a tierra. 4.3.3. Implementaci´on del sistema Por ´ultimo solo queda implementar nuestro dise˜no y montarlo en una placa de prototipado, el resultado final es el que se muestra en la figura 4.14. Para comprobar su correcto funcionamiento antes de instalarlo en el coche se ha de comparar el voltaje de salida de ambos potenci´ometros con el que produce el circuito interno del pedal (figura 4.7). Figura 4.14: Dise˜no final de las placas de prototipado 47 Los valores te´oricos de voltajes que entregar´ıa nuestro controlador son los mostrados en la tabla 4.4. Se puede ver que son valores similares, aunque se aprecia que hay un peque˜no offset en los valores con respecto a las mediciones. Este offset se puede deber a diferentes motivos cuya afectaci´on en el funcionamiento del sistema es residual, por lo que se pueden considerar despreciables. Pedal ( %) Vout1(V) Vout2(V) 0 1.65 1.00 3 1.87 1.14 6 2.09 1.27 9 2.32 1.40 12 2.54 1.54 15 2.77 1.67 18 2.99 1.80 21 3.21 1.94 35 4.26 2.56 50 5.38 3.23 65 6.50 3.90 80 7.62 4.56 90 8.36 5.01 95 8.74 5.23 99 9.04 5.41 100 9.11 5.45 Tabla 4.4: Tabla de valores te´oricos de nuestro sistema. A la hora de la inicializaci´on del controlador, nos encontramos con un problema y es que la primera vez que se activa el bypass fija una tensi´on de salida del controlador comparable a como si se ejerciera una presi´on de alrededor del 37 % sobre el pedal que, a pesar de enviar las ´ordenes para fijar la tensi´on de salida al m´ınimo posible, el sistema no act´ua en consecuencia. Este problema desaparece cuando volvemos a desactivar el bypass y, a partir de aqu´ı, cada vez que volvamos a activar el controlador, el sistema va a reaccionar a nuestras ´ordenes y funcionar correctamente. Por ´ultimo, cabe destacar que cuando activamos el bypass provoca que en el cuadro de mandos del coche, se encienda el testigo de color naranja ´unicamente cuando el acelerador est´a siendo controlador por nuestro sistema. 4.4. Control Lateral Para el control lateral, como se ha mencionado en ocasiones anteriores, se necesita de la combinaci´on de diferentes componentes para poder hacerlo posible. Estos componentes son en nuestro caso la controladora EPOS4 70/15 de la compa˜n´ıa Maxon Motor, as´ı como su motor EC 60 flat, ver figura 4.16 sacada de [6]. Para poder transferir la potencia de giro desde este motor a la columna de direcci´on del Twizy se hace a trav´es de un sistema de engranajes. EPOS4 MotorMod Con USB Figura 4.15: Esquema de la comunicaci´on M´odulo de Control - Motor 48 Figura 4.16: Controladora EPOS4 70/15 y motor EC 60 flat El control del motor lo realiza la controladora EPOS4, a la que se le env´ıa ´ordenes desde el m´odulo de control, como se muestra en la figura 4.15. El m´odulo de control enviar´a ´ordenes de alto nivel, como por ejemplo establecer un n´umero de vueltas objetivo, velocidad, aceleraci´on, etc. Adem´as, la controladora interpretar´a estos datos para controlar el motor a trav´es de pulsos, intentando cumplir los objetivos marcados por la orden de alto nivel. 4.4.1. Caracter´ısticas Principales La controladora EPOS4 (Easy Positioning System) de Maxon Group est´a dise˜nada para controlar motores de corriente continua (DC) con y sin escobillas (brushless DC), motores de corriente continua con codificador y motores lineales [21]. En particular, el modelo 70/15 permite un voltaje de operaci´on de 10-70 V y un m´aximo de 15 A de corriente continua. Adem´as, permite la comunicaci´on a trav´es de diferentes protocolos, como pueden ser CANopen, EtherCAT, USB, RS232, y Ethernet, lo que la convierte en un dispositivo de gran utilidad para muchos sistemas. [22]. Este dispositivo permite controlar el giro del motor con varios modos de funcionamiento, ya sea el modo de posici´on, velocidad yhomming entre otros.[23] Tambi´en dispone de una serie de entradas y salidas configurables, tanto digitales como anal´ogicas que permiten al sistema actuar en consecuencia de estas se˜nales que, junto con su capacidad de ser programada mediante software externo, como puede ser EPOS Studio o mediante el uso de scripts en C++, otorgan a este dispositivo un amplio abanico de posibilidades.[24] 4.4.2. Modos de funcionamiento La EPOS4 ofrece varios modos de funcionamiento para adaptarse a distintas aplicaciones y necesidades de control. A continuaci´on se hace una breve descripci´on de los m´as importantes. Modo de Posici´on En el modo de posici´on, la controladora EPOS4 se encarga de mover el motor a una posici´on espec´ıfica con gran precisi´on. El control de posici´on se realiza mediante retroalimentaci´on del sensor, generalmente un codificador (encoder) que mide la posici´on actual del eje del motor y la compara con la posici´on objetivo. 49 Figura 4.17: Gr´aficas de los par´ametros del modo de posici´on En cu´anto a los modos de posicionamiento, tenemos dos maneras de trabajar con ellos, ver figura 4.17: Posicionamiento absoluto: El motor se mueve a una posici´on absoluta definida en funci´on de una referencia previamente fijada, como puede ser la posici´on 0. Posicionamiento relativo: Permite mover el motor la cantidad de pasos indicada desde su posici´on actual. La velocidad con la que se puede mover el motor viene definida por el usuario, incluyendo una velocidad m´axima, as´ı como su aceleraci´on y deceleraci´on. Adem´as, el perfil de velocidad se controla mediante un perfil de velocidad que puede ser trapezoidal (ver figura 4.17) o sinusoidal, lo que garantiza los movimientos suaves y precisos. Por ´ultimo, este modo tiene dos perfiles de movimiento, derivados de los perfiles de velocidad previamente mencionados, como son el trapezoidal y sinusoidal. Vamos a destacar el primero, ya que comienza con una aceleraci´on constante hasta que alcanza la velocidad deseada y se mantiene hasta que comienza a decelerar hasta llegar a la posici´on objetivo. Modo de velocidad El modo de velocidad permite mantener una velocidad espec´ıfica bajo diferentes situaciones sin importar las variaciones de la carga que tenga que soportar. Este modo nos permite trabajar en un rango amplio de velocidades, ya que es capaz de trabajar a velocidades muy bajas hasta velocidades muy altas. Adem´as, la velocidad de giro se puede especificar en revoluciones por minuto (RPM) o en radianes por segundo (rad/s). Esta velocidad de giro es constante como se aprecia en la figura 4.18 y el sentido de giro y de la aceleraci´on viene determinado por la velocidad objetivo, como viene descrito en la demostraci´on de funcionamiento en la figura 4.19. 50 Figura 4.18: Gr´aficas de los par´ametros del modo de velocidad Este modo, a diferencia que el modo de posici´on, nos permite obtener la velocidad real a la que est´a girando el motor para poder ajustarla si fuera necesario. Adem´as, mediante los par´ametros de aceleraci´on y deceleraci´on se puede cambiar la velocidad de manera controlada. Figura 4.19: Comparaci´on de velocidad y aceleraci´on Modo Homming El modo Homming se utiliza para determinar una posici´on de referencia inicial para el sistema. Este modo es esencial cuando se necesita una posici´on de partida antes de comenzar con la operaci´on normal. Este modo lo que hace es realizar una b´usqueda de la posici´on de referencia. La secuencia de b´usqueda puede ser girar en una direcci´on hasta que la corriente supere un cierto umbral, identificando de esta manera el fin de carrera. Si se sabe la carrera total, entonces es posible fijar una referencia. Otra forma es mediante el uso de sensores que sean detectables por el motor y cuya posici´on conocemos que nos permitan determinar la posici´on en la que se encuentra el motor. Una vez esta b´usqueda ha finalizado, el sistema determinar´a la posici´on final como la posici´on de referencia del sistema (posici´on cero). 51 4.4.3. Alimentaci´on EPOS4 La arquitectura original con la que empez´o este proyecto ten´ıa a la controladora EPOS4 alimentada directamente desde la bater´ıa de servicio, algo que en esta nueva implementaci´on quer´ıamos cambiar. Uno de los objetivos de este proyecto era agrupar la alimentaci´on de todos los dispositivos electr´onicos en la PowerBox entre los que se incluye la EPOS4. Las razones para hacerlo as´ı se dieron anteriormente, pero la fundamental es que aunque el resto de dispositivos est´en apagados, la EPOS sigue funcionando, agotando la bater´ıa de servicio. Como veremos a continuaci´on, la alimentaci´on de la EPOS a trav´es de la PowerBox ha dado algunos problemas no esperados. POWERBOX Batería de Servicio EPOS4 General EPOS Figura 4.20: Esquema el´ectrico de la EPOS Como vemos en la figura 4.20, el objetivo final es que la alimentaci´on de la EPOS pase por dos interruptores que se encuentran la caja de conexiones, en primera instancia tenemos el interruptor general que alimentar´a la PowerBox y despu´es tenemos el interruptor espec´ıfico de la EPOS. Este dise˜no se ha llegado a implementar y el sistema funcionaba correctamente en casi todas las situaciones, el ´unico problema es que cuando la EPOS se encuentra en las situaciones m´as extremas como puede ser el cambio brusco de orientaci´on de giro o cuando llega a las posiciones finales en los que el sistema ofrece una gran resistencia. En estos casos, la EPOS llegaba a desconectarse y no permit´ıa seguir operando el motor. Analizando los mensajes de error que devolv´ıa la EPOS descubrimos que se trataba de un problema de alimentaci´on, que no era suficiente para lo que requer´ıa en esas situaciones. Sin embargo, se sab´ıa que no pod´ıa ser un problema de la fuente de alimentaci´on, ya que si alimentamos la EPOS directamente desde la bater´ıa de servicio, esta funciona perfectamente hasta en las situaciones m´as complejas, por lo que el problema deb´ıa residir en las modificaciones que se hab´ıan hecho en la nueva versi´on. R interruptorR cable R cable 14V Impedancia EPOS V entregada + - Figura 4.21: Modelado del circuito el´ectrico de la entrega de potencia a la EPOS Analizando las especificaciones de la EPOS y del motor, descubrimos que la EPOS, una vez fijada un voltaje inicial de alimentaci´on, es capaz de soportar variaciones de voltaje de 1 V como m´aximo: ∆V = 14 V −Ventregada <1 V Dado que la EPOS estaba conectada a la fuente a trav´es de la PowerBox que estaba varios metros alejada de la bater´ıa, el problema estaba en que el cable utilizado introduc´ıa una ca´ıda de voltaje en 52 funci´on de la corriente solicitada. El modelado el´ectrico del cable junto con la PowerBox se puede ver en la figura 4.21. El voltaje m´aximo que caer´a en la resistencia del cable y del interruptor se puede calcular a partir de la corriente que circule por ellos, y teniendo en cuenta que conocemos la potencia m´axima que se puede entregar al motor, encontramos que esta corriente se puede calcular f´acilmente: I=100 W (14 −1)V = 7,7 A Analizando nuestro circuito representado en la figura 4.21 tenemos que calcular la resistencia m´axima en serie que podemos admitir: Rserie = 2Rcable +Rinterruptor <1V 7,7A = 0,13Ω Por lo tanto, lo primero que se hizo fue considerar que la resistencia del interruptor era nula y calcular un cable con una secci´on que nos asegurara una ca´ıda baja de voltaje, teniendo en cuenta que el cable total med´ıa 5 m. Decidimos utilizar un cable AWG12, que se corresponde con una secci´on de 4mm2 y con una resistividad proporcionada por el cobre de ρ= 0,017 Ω mm2/m. De esta forma se puede calcular la resistencia total producida por el cable: Rcable =ρL S= 0,017 5m 4mm2= 0,02125 Ω En este punto se realizaron varias pruebas y se comprob´o que el problema no se hab´ıa resuelto. Despu´es de mirar varias posibilidades se lleg´o a la conclusi´on que el problema estaba en suponer que la resistencia de los interruptores era nula. Efectivamente, los interruptores tienen una resistencia de contacto, y se puede calcular la resistencia total que pueden introducir sin m´as que aplicar una diferencia: Rinterruptor ≤0,13 Ω −2∗0,02125 Ω = 0,0875 Ω = 87,5 mΩ Seg´un las especificaciones del fabricante, las resistencias de contacto de los dos interruptores en la PowerBox son menores a 50mΩ , pero que el pol´ımetro nos dec´ıa que era de alrededor de 2,5Ω. Al no cumplirse claramente los requisitos de resistencia m´axima en los interruptores, era f´acil que se produjera fallo de alimentaci´on. A d´ıa de hoy no ha sido posible introducir unos interruptores con una resistencia acorde a nuestras necesidades, por lo que de momento la EPOS sigue siendo alimentada directamente por la bater´ıa de servicio. Hasta que no se solucione este punto deberemos buscar otra fuente de alimentaci´on para dar energ´ıa a la PowerBox, por este motivo es por el que se est´a utilizando un transformador conectado al inverter que se vio en el apartado 3.4.2. 4.4.4. Software Hay dos maneras de manejar con software la controladora EPOS, una es mediante el programa desarrollado por la compa˜n´ıa Maxon, EPOS Studio, que mediante una interfaz gr´afica muy visual permite manejar la controladora, poder supervisar el funcionamiento en tiempo real, configurar la controladora ajustando los par´ametros necesarios, actualizar el software etc. [6] La otra manera de controlar la EPOS es mediante scripts en C++ y en Python, aunque estos ´ultimos utilizan las librer´ıas disponibles de C++. Esto nos aporta una mayor capacidad de personalizaci´on, ya que podemos dise˜nar programas que se ajusten a nuestras necesidades sin depender de programas de terceros. Maxon suministra una API junto con su librer´ıa para que podamos comunicarnos con la controladora y poder manejarla. Este m´etodo es el que se usa para el control lateral del Twizy. [6] Nuevo modo de funcionamiento Hasta ahora el control lateral estaba definido mediante el modo de posici´on. Como se ha visto anteriormente, este modo necesita como entradas la velocidad m´axima de movimiento y la posici´on 53 objetivo, entre otros. Pero con este modo de funcionamiento nos encontr´abamos con el inconveniente de la desconexi´on del motor. Cu´ando utiliz´abamos este modo y quer´ıamos que girase a una velocidad elevada (superior a 3000 rpm) el motor se desconectaba y se paraba la ejecuci´on. La raz´on para este comportamiento se debe a que en el modo posici´on la controladora antes de empezar el movimiento define una trayectoria de la posici´on a alcanzar en un tiempo concreto, y posteriormente, durante la operaci´on, comprueba continuamente la posici´on alcanzada, de tal manera que si en un momento determinado la diferencia entre la posici´on le´ıda por la controladora y la esperada es mayor que un margen predefinido, la controladora entra en modo error y se desconecta. Esto obligaba a trabajar a muy bajas revoluciones, lo que a su vez acababa impactando en la velocidad m´axima a la que se puede mover el veh´ıculo (5 km/h en proyectos anteriores) dado que el seguimiento de la l´ınea azul es muy dependiente de la velocidad de correcci´on con el volante. Ahora se ha implementado un c´odigo con control en modo de velocidad, que nos entrega una velocidad de giro del volante constante y no se desconecta si introducimos velocidades elevadas. La manera con la que vamos a trabajar ahora es que se va a monitorizar continuamente la posici´on del motor en tiempo real desde el ordenador de control en lugar de desde la controladora. El programa desarrollado tiene como entradas la velocidad deseada y la posici´on objetivo, el programa es capaz de comparar la posici´on actual con la objetivo para poder determinar el sentido de giro del motor. Despu´es comienza a mover el motor mientras monitoriza la posici´on en tiempo real y la compara con la objetivo. Se ha fijado un umbral en el que si la diferencia entre la posici´on objetivo y la real es inferior a este umbral, significa que ya ha llegado a su destino y se da por finalizado el proceso, deteniendo el movimiento. Este modo no es perfecto, ya que a diferencia del modo de posici´on tenemos un menor control en la b´usqueda de la posici´on objetivo. Esto significa que se pueden dar m´as situaciones de overshooting, esto es, que el motor oscile continuamente alrededor de la posici´on final deseada. 54 Cap´ıtulo 5 Software 5.1. Introducci´on En este apartado se hablar´a de los programas principales relacionados con el control de este prototipo, empezaremos con el software principal llamado mod-con.py que monitoriza la informaci´on que captan y env´ıan los sensores para procesarla y tomar decisiones en funci´on de ella. Seguidamente, se comentar´a el programa que se encarga del control lateral, veremos como gestiona las ´ordenes que recibe del m´odulo de control, as´ı como la monitorizaci´on de la posici´on y velocidad actual del motor y para terminar, haremos un repaso de las diferentes funcionalidades de las que dispone. Todo el software que hablaremos a continuaci´on est´a disponible en el repositorio de GitHub: https://github.com/GCOdeveloper/Twizycontest Pero antes de hablar del software, cabe destacar c´omo se ha conseguido solucionar una dificultad que ten´ıan en las versiones anteriores. Esta dificultad era que el m´odulo de control, cuando se inicia, no asigna en el mismo orden las interfaces USB de los perif´ericos. La soluci´on temporal era utilizar una secuencia concreta de encendido de los perif´ericos, pero a partir de ahora eso no va a ser necesario porque se va a a realizar una identificaci´on previa de los dispositivos conectados. 5.2. Identificaci´on de los dispositivos conectados 5.2.1. Mapeo persistente dispositivos USB En el estado inicial de este proyecto, los perif´ericos no ten´ıan asignado un nombre concreto en el m´odulo de control. La soluci´on adoptada era ir encendiendo en una secuencia determinada los diferentes perif´ericos conectados al hub USB para que as´ı el m´odulo de control asigne siempre el mismo identificador a cada perif´erico, por ejemplo: cuando encendemos varios perif´ericos est´an conectados a la Humming, el sistema operativo Linux asigna las interfaces USB en orden, comenzando por ttyUSB0 para el primer perif´erico que encuentra y as´ı sucesivamente. El orden en el que encuentra los perif´ericos puede variar de un encendido a otro. Este mecanismo es efectivo pero no muy eficiente, ya que necesitas disponer de un hub USB con interruptores y cada vez que reinicias el m´odulo de control tienes que repetir la secuencia de encendido. Por este motivo se ha implementado una soluci´on bastante m´as eficiente y sencilla, como es la de asignar alias o enlaces simb´olicos a los perif´ericos, tambi´en conocida como mapeo persistente de los dispositivos USB. Esto consiste en que en una primera instancia se debe averiguar cu´ales son los atributos de cada perif´erico, como son el idVendor y el idProduct. Estos son visibles mediante el comando lsusb que muestra los dispositivos USB conectados junto con su nombre e identificador que est´a compuesto por los atributos mencionados antes. Puede darse el caso en el que dos dispositivos est´en conectados mediante el mismo adaptador USB, por lo que la ´unica forma de distinguir cada perif´erico es mediante 55 el n´umero de serie individual. Una forma de obtener este serial es mediante el siguiente comando: udevadm info -a-n/dev /ttyUSBX |grep ’{ serial } ’ |head -n1 #Resultado ATTRS {serial}==" AI02POF4 " En el que indicando el nombre de la interfaz que se quiere consultar, por ejemplo ttyUSB0, te muestra el serial del dispositivo conectado a esa interfaz, el cual es ´unico para cada componente. Una vez obtenidos todos los datos de cada perif´erico, falta establecer las reglas del mapeo de estos dispositivos. Esto se hace creando un fichero en el directorio /etc/udev/rules.d, llamado 99-usbserial.rules. En ´el se incluyen para cada dispositivo su idVendor eidProduct y si fuera necesario su serial, adem´as de un alias o enlace simb´olico al que poder hacer referencia desde los programas de ejecuci´on debido a que va a permanecer inalterable. Un ejemplo de este fichero es el siguiente: SUBSYSTEM =="tty ",ATTRS {idVendor}==" 0403 ",ATTRS {idProduct }=="6001 ",ATTRS {serial }==" AI02POF4 ",SYMLINK+="USB_Marchas" SUBSYSTEM ==" tty ",ATTRS {idVendor}==" 29 fe " ,ATTRS {idProduct }=="4 d53 ",SYMLINK+=" USB_Camera " SUBSYSTEM ==" tty ",ATTRS {idVendor}==" 0403 ",ATTRS {idProduct }==" 6001 ",ATTRS {serial }==" AH02O796 ",SYMLINK+="USB_Acelerador" SUBSYSTEM ==" tty ",ATTRS {idVendor}==" 0403 ",ATTRS {idProduct }==" 6001 ",ATTRS {serial }==" AB0JPVRD ",SYMLINK+=" USB_RFID " SUBSYSTEM ==" tty ",ATTRS {idVendor}=="1 a86",ATTRS {idProduct }==" 7523 ",SYMLINK+=" USB_Sonidos" 5.2.2. Uso de variables de entorno La idea del mapeo persistente de dispositivos no dio tan buenos resultados como se esperaba, debido a que los perif´ericos conectados ten´ıan el mismo idVendor y el mismo idProduct y, por lo tanto, las reglas descritas en el apartado anterior no se aplicaban correctamente. En algunas ocasiones intercambiaba los dispositivos que compart´ıan estos par´ametros y no ten´ıa en cuenta el serial. En cambio, sirvi´o de ayuda para comprender mejor como poder interactuar con los perif´ericos conectados a la Humming. La forma en la que se resolvi´o finalmente el manejo de las interfaces USB fue la de crear variables de entorno del sistema operativo con el fin de almacenar en ellas las direcciones de los perif´ericos, como pueden ser, por ejemplo, /dev/ttyUSB0. Para hacer esto posible, se ha dise˜nado un script que va recorriendo todos los perif´ericos conectados, que dado que ahora mismo solo tenemos cuatro perif´ericos conectados al hub ir´an desde ttyUSB0 hasta ttyUSB3. Este script abre la comunicaci´on serie con cada perif´erico de manera individual y se queda esperando a que este env´ıe mensajes relacionados con el funcionamiento del controlador, por ejemplo, el controlador de marchas env´ıa un mensaje en formato de cadena de caracteres indicando la marcha en la que se encuentra. Dicho esto, la Humming comprueba el mensaje recibido y dependiendo de cu´al sea, asigna el nombre del perif´erico a la direcci´on del perif´erico actual. Por ejemplo, abre el puerto ttyUSB3 y este env´ıa continuamente los valores de los potenci´ometros del controlador del acelerador. El script crea la variable Acelerador USB con el valor de la direcci´on del perif´erico /dev/ttyUSB3. Una vez ejecutado el script, si miramos las variables de entorno con el comando printenv tenemos, entre otras, las siguientes variables: Acelerador_USB = /dev /ttyUSB0 Sonidos_USB = /dev/ttyUSB1 Marchas_USB = /dev/ttyUSB2 RFID_USB = /dev/ttyUSB3 Para poder recoger esta informaci´on desde el programa principal necesitamos utilizar las funciones de la librer´ıa os de Python como es os.environ(). En concreto, vamos a utilizar: Aclerador_dir =os.environ["Acelerador_USB"] Sonidos_dir =os.environ["Sonidos_USB"] Marchas_dir =os.environ["Marchas_USB"] RFID_dir =os.environ[" RFID_USB "] 56 Facilidad en la Comunicaci´on entre Procesos: Ahora los datos se env´ıan entre procesos Python dentro de un mismo proyecto utilizando variables globales y llamadas directas a funciones, lo que elimina la necesidad de memoria compartida. Detalles de la Implementaci´on La clase de funciones en Python incluye las siguientes funcionalidades clave: Inicializaci´on y Configuraci´on del Dispositivo: Se configura el dispositivo EPOS4 mediante funciones como open_device, que establece la conexi´on, y activate_position_mode y activate_velocity_mode, que activan los modos de control de posici´on y velocidad, respectivamente. Control de Movimiento: La clase permite mover el motor a una posici´on espec´ıfica (move_to_position_speed) o mantener una velocidad constante (move_velocity), lo que facilita la implementaci´on de movimientos complejos sin necesidad de otros procesos adicionales. Consulta de Estado del Motor: A trav´es de funciones como get_position,get_velocity, yget_current, se pueden obtener datos en tiempo real sobre la posici´on, velocidad y corriente del motor. Modo de Homing: La clase tambi´en maneja el modo de Homing (homming_mode), que permite encontrar y definir la posici´on inicial del motor. Conclusi´on Gracias a esta nueva implementaci´on en Python, se ha simplificado significativamente el sistema. Al eliminar la dependencia de la memoria compartida y centralizar toda la l´ogica en una clase de funciones, no solo se mejora la eficiencia, sino que tambi´en se reduce la complejidad del c´odigo y se facilita el mantenimiento. 5.5. Simulaci´on en MATLAB Para el modelo cinem´atico y los algoritmos de guiado del veh´ıculo se van a utilizar los descritos en el Trabajo de Fin de M´aster de Samuel Pilar [6]. En ´el, se aplica un PID sobre la controladora EPOS4 para controlar y supervisar el movimiento lateral. El PID (Proporcional-Integral-Derivativo) es un controlador utilizado en sistemas de control autom´atico para ajustar la salida de un proceso basado en el error entre un valor deseado y el valor actual, combinando tres acciones [25]: KP(Proporcional): Ajusta la respuesta en funci´on del error actual, afectando la rapidez de la correcci´on. KI(Integral): Corrige en funci´on del error acumulado a lo largo del tiempo, eliminando el error de estado estacionario. KD(Derivativo): Responde a la tasa de cambio del error, ayudando a amortiguar las oscilaciones y mejorando la estabilidad. Adem´as de estas constantes, tambi´en se va a aplicar el algoritmo de Stanley, lo que nos obliga a tener en cuenta la constante de Stanley: KST ANLEY : Ajusta la sensibilidad del controlador Stanley en el seguimiento de una trayectoria, afectando la precisi´on y la reactividad en el alineamiento con la ruta deseada. La simulaci´on tambi´en est´a regida por otros par´ametros que interfieren en el resultado de la misma. Estos par´ametros est´an relacionados con las din´amicas del veh´ıculo, como puede ser la velocidad con la que act´ua el motor de control lateral, as´ı como los retardos de procesamiento de las im´agenes capturadas por la c´amara: 63 Velocidad m´axima: Este par´ametro fija las revoluciones por minuto m´aximas a las que puede girar el motor de control lateral, que gracias a los avances mencionados durante la memoria podemos aumentar esta velocidad a 6000 rpm a diferencia de los 3000 rpm con los que trabajaba Samuel Pilar [6]. Aceleraci´on m´axima: Este par´ametro ajusta la rapidez con la que el motor de control lateral llega a la velocidad m´axima mencionada antes. En la simulaci´on se puede fijar este par´ametro como infinito si no queremos introducir ning´un retardo ligado a la aceleraci´on, como as´ı lo hac´ıa Samuel. En cambio, en este proyecto se ha buscado usar los datos m´as pr´oximos a la realidad y se ha fijado una aceleraci´on m´axima de 10000 rpm/s. Control del motor: Tambi´en se ha modificado el modo de funcionamiento del motor de control lateral, que estaba ajustado con el modo de posici´on y se ha cambiado al modo de velocidad. Retardo de procesamiento: Con este par´ametro se define el tiempo que tarda en procesar la Humming Board, la imagen capturada por la c´amara. Se ha estimado que el tiempo de retardo es de 0.2 segundos como ya estaba en el proyecto de Samuel. Periodo de Captura: Este tiempo indica la frecuencia con la que la c´amara captura la informaci´on. Que en este caso se asume tambi´en que es de 0.2 segundos. Cabe destacar que Samuel en su proyecto demostr´o que a pesar de modificar los par´ametros relacionados con la captura de video (Retardo y periodo) a valores ideales, el resultado de la simulaci´on segu´ıa sin ser el ´optimo. Por lo tanto, se confirma que control lateral, con su velocidad y su aceleraci´on, tienen un papel fundamental en el resultado de la simulaci´on que, como veremos a continuaci´on, son determinantes. Vamos a partir del simulador dise˜nado en [6] que permite dos modos de simulaci´on: ´ Unica simulaci´on: Se introducen manualmente los valores de las constantes, velocidad y radio de giro m´aximo. Barrido param´etrico: Se introducen la velocidad, radio y el rango de valores de las constantes. La simulaci´on consiste en encontrar la combinaci´on ´optima de estas constantes. Figura 5.4: Ruta a realizar en la simulaci´on En la figura 5.4 se muestra la ruta que tiene que realizar el veh´ıculo en la simulaci´on, es una ruta que contiene 4 rectas y 3 giros de 180 grados. En este proyecto la idea es conseguir duplicar la velocidad de paso del veh´ıculo con respecto al proyecto de Samuel Pilar, que era de 3 km/h [6] y uno de nuestros objetivos es conseguir ir a 6 km/h. 64 Se ha realizado el barrido param´etrico mencionado en el proyecto de Samuel [6] pero cambiando los valores extremos de las constantes. Que en este caso van a ser de: KP: [3000, 15000] en saltos de 500. KD: [3000, 15000] en saltos de 500. KS: [0.5, 4] en saltos de 0.5. El resultado de este barrido nos otorga que los valores que nos permiten tener la simulaci´on m´as precisa posible son de: KP= 6000 KD= 8500 KS= 4 La simulaci´on con estos par´ametros es la que se muestra en la figura 5.5: -25 -20 -15 -10 -5 0 5 0 2 4 6 8 10 12 14 16 Figura 5.5: Simulaci´on para 6km/h En la figura 5.5 se aprecia que el veh´ıculo puede seguir casi perfectamente la ruta marcada. La l´ınea verde indica que la trayectoria que sigue el veh´ıculo est´a dentro del margen m´aximo permitido que es de 0,085 m. A pesar de esto, los tramos en los que nos salimos de este margen suponen un error muy peque˜no que no provocan un fallo en el seguimiento de la l´ınea. El problema viene cuando intentamos aumentar la velocidad que nos encontramos con limitaciones que exceden al control lateral. Y es que el uso de la c´amara introduce un retardo que junto con el procesado de la propia imagen en la Humming hacen que el seguimiento de la trayectoria sea casi imposible cuando aumentamos la velocidad a 8-10 km/h. Como se puede ver en la figura [?], incluso habiendo recalculado los par´ametros, si ejecutamos la simulaci´on con 8 km/h vemos que el veh´ıculo pierde por completo la ruta a seguir. Los nuevos valores de la simulaci´on son: KP= 12500 65 KD= 8500 KS= 4,5 -25 -20 -15 -10 -5 0 5 0 2 4 6 8 10 12 14 16 18 Figura 5.6: Simulaci´on para 8km/h En cambio, si ajustamos los par´ametros de configuraci´on relacionados con el procesado de la imagen, asumiendo que tenemos un ordenador con un mejor rendimiento que introduce un menor retardo, se aprecia que el veh´ıculo es capaz de seguir pr´acticamente por completo la trayectoria marcada. -25 -20 -15 -10 -5 0 5 0 5 10 15 Figura 5.7: Simulaci´on para 8km/h sin retardo de imagen 66 Cap´ıtulo 6 Conclusiones y l´ıneas futuras 6.1. Conclusiones Considerando los objetivos de este Trabajo de Fin de M´aster definidos en la secci´on 1.2, se puede afirmar que se han cumplido las metas prefijadas. Este proyecto es una continuaci´on del proyecto TwizyLine que, a pesar de haber finalizado, sigue sufriendo constantes implementaciones y mejoras que hace que los alumnos que trabajen en ´el puedan aprender y desarrollar un prototipo de veh´ıculo aut´onomo. Se ha redise˜nado el conexionado el´ectrico y las comunicaciones del veh´ıculo, aportando simplicidad y claridad al cableado. Se ha partido de un veh´ıculo que estaba en una etapa de desarrollo y no funcionaba correctamente, por lo que una gran parte del tiempo de este proyecto se ha destinado a conseguir que el veh´ıculo funcionase de acuerdo con las versiones anteriores, como era la implementaci´on de Ignacio Royuela [7]. Para poder hacer esto posible ha sido necesario programar el controlador de marchas, ya que no estaba operativo y requer´ıa de una nueva versi´on de software. Cabe destacar que, uno de los mayores problemas al que me he enfrentado ha sido el controlador del acelerador ya que nos ha supuesto una p´erdida de tiempo importante debido a causas ajenas a este trabajo. Como ha sido la falta de documentaci´on y software disponible que permitieran la trazabilidad del estado actual de este controlador. Pero finalmente se decidi´o hacer un nuevo controlador desde cero y el resultado ha sido m´as que positivo. Otro punto importante del conexionado el´ectrico ha sido el dise˜no y la implementaci´on de la caja de conexiones (PowerBox). Esta caja ha permitido la agrupaci´on y el control de la alimentaci´on de todos los dispositivos electr´onicos que hacen que el veh´ıculo se pueda mover de manera aut´onoma. Permitiendo trabajar con los dispositivos de manera independiente, adem´as de incluir una caja de fusibles que otorga seguridad frente posibles picos de tensi´on que puedan da˜nar los dispositivos. En cu´anto a la colaci´on de los m´odulos de control y comunicaci´on, se ha decidido ponerlos en la parte trasera dentro del rack para poder tener un mejor acceso a ellos y evitando aglomeraci´on de cables en las guanteras delanteras del Twizy. Para las comunicaciones entre los dispositivos, he optado por incluir un router que permita la comunicaci´on SSH entre los m´odulos de control y de comunicaciones, as´ı como la posibilidad de poder conectarte con m´ovil v´ıa Wifi al servidor MQTT para enviar las ´ordenes al veh´ıculo. Esto ha aportado mayor agilidad en el desarrollo del software, ya que se dispon´ıa de comunicaci´on directa entre los m´odulos y el PC en el que se estaba desarrollando el software. Esta implementaci´on ha supuesto el cambio del modo de control de la EPOS4, pasando de un control basado en la posici´on actual del motor a uno basado en la velocidad. Esto permite un movimiento lateral significativamente mayor una vez ya hemos sido capaces de controlar los l´ımites de giro del motor. En concreto, en versiones anteriores con el otro modo de funcionamiento, el motor giraba a una velocidad de 3000 rpm que es casi la mitad de lo que puede girar ahora, que es de 5000 67 rpm. Este incremento de velocidad en el control lateral permite aumentar la velocidad longitudinal del veh´ıculo, ya que podemos seguir la l´ınea azul del suelo con una mayor facilidad, adem´as de ser capaces de corregir la posici´on con una mayor brevedad. Por ´ultimo, me gustar´ıa hacer una reflexi´on acerca de lo que me ha aportado a m´ı. En este proyecto me he enfrentado a problemas inesperados, los cuales, como hemos visto durante la memoria, suponen que un simple interruptor haga que no funcione un motor. O que trabajar sobre el proyecto de otro compa˜nero y no disponer de la informaci´on acerca de c´omo lo hab´ıa hecho me ha supuesto un retraso a la hora de poder identificar el problema y de encontrar la soluci´on. Pero a pesar de ser inconvenientes, tambi´en me han ayudado a prepararme mejor de cara a la vida laboral, ya que me han aportado constancia y capacidad de adaptaci´on a nuevos problemas inesperados. 6.2. L´ıneas futuras Este proyecto est´a en un punto en el que hay un abanico inmenso de posibles evoluciones. Ahora que la parte el´ectrica est´a claramente definida, estable y robusta permite centrar los esfuerzos en el desarrollo de software y nuevas implementaciones como puede ser ROS como ya inici´o Carlota G´omez [5] o perfeccionando el programa principal del modo aut´onomo, a˜nadiendo nuevas funcionalidades o casos de uso. Adem´as, otra v´ıa de desarrollo puede ser la inclusi´on del LiDAR y balizas de ultrasonidos que, junto con un mapa del entorno, permitan localizar el veh´ıculo y establecer su posici´on en el mapa. En cu´anto al control lateral se pueden hacer evoluciones en la parte de la obtenci´on de la posici´on de referencia, ya que no hemos conseguido obtener los resultados deseados, se podr´ıa estudiar el uso de sensores que indiquen la posici´on de referencia y mejorar el modo Homing de la controladora. Por ´ultimo, una l´ınea a seguir puede ser la de buscar soluciones al problema de la inicializaci´on del acelerador, ya que no fuimos capaces de identificar el problema. Por otro lado, tambi´en se puede prescindir de los m´odulos de control y de comunicaciones e integrarlo todo en un ´unico dispositivo que se encargue de realizar todas las tareas. Reciba la informaci´on del LiDAR, el CAN del veh´ıculo y tenga conexi´on con los distintos controladores, creando una especie de “cerebro” que gestione el modo aut´onomo del Twizy, y as´ı tambi´en se podr´ıan mitigar los problemas con el retardo del procesado del video. 68 Bibliograf´ıa [1] TwizyLine, “http://twizyline.com, 25 de marzo de 2024,” 2020. [2] M. Mart´ın Fern´andez, “http://twizyline.com/renault-and-the-university-of-valladolid-welcome-twizyline/, 25 de marzo de 2024,” 2020. [3] T-CUE, “Ganadores de la edici´on 2020 del concurso “iniciativa campus emprendedor”. https: //www.redtcue.es/campus/campus-2020/ganadores, 25 de febrero de 2024,” 2020. [4] S. Pilar Arnanz, “Back-end implementation for an automatized car parking,” 2020. [5] C. G´omez Diego, “Guiado de veh´ıculo aut´onomo mediante tecnolog´ıa lidar,” 2022. [6] S. Pilar Arnanz, “Servicios de veh´ıculo conectado y conducci´on aut´onoma en un twizy,” 2021. [7] I. Royuela Gonz´alez, “Four level autonomous vehicle for an automatized parking,” 2020. [8] M. A. Kanaan, “Autonomous vehicle control by 3d camera in a twizy,” 2022. [9] N. Gordon-Bloomfield, “Renault twizy: The ultimate big boy’s (and girl’s) eco-toy?. https://web.archive.org/web/20190129011808/https://transportevolved.com/2014/ 01/17/renault-twizy-the-ultimate-big-boys-and-girls-eco-toy/, 25 de febrero de 2024,” 2014. [10] S. Cropley, “Renault twizy review. https://www.autocar.co.uk/car-review/renault/twizy, 25 de febrero de 2024,” 2013. [11] TopGear, “Renault twizy review. https://www.topgear.com/car-reviews/renault/twizy, 25 de febrero de 2024,” 2015. [12] E. Espin´os, “Renault dejar´a de fabricar el twizy en septiembre. . . y ya se conoce su sucesor. https: //www.autofacil.es/renault/twizy/renault-dejara-fabricar-twizy-septiembre-2023/ 635486.html, 25 de febrero de 2024,” 2023. [13] Renault, “Renault twizy e-tech 100 % el´ectrico. https://www.renault.com.co/electricos/ twizy/especificaciones.html, 25 de febrero de 2024,” 2017. [14] Waymo, “Waymo driver. https://waymo.com/intl/es/waymo-driver/, 25 de febrero de 2024,” 2024. [15] NHTSA, “Automated vehicles for safety. https://www.nhtsa.gov/vehicle-safety/ automated-vehicles-safety, 25 de febrero de 2024,” 2023. [16] RACE, “As´ı son los cinco niveles de la conducci´on aut´onoma. https://www.race.es/ niveles-conduccion-autonoma, 25 de febrero de 2024,” 2022. [17] TwizyLine, “Twizyline, drawing the future. http://twizyline.com/ twizylinedrawingthefuture/, 25 de marzo de 2024,” 2020. [18] B. Jim´enez Padilla, T´ecnicas b´asicas de electricidad de veh´ıculos (MF0624 1). M´alaga: IC Editorial, 2012. 69 [19] H. Budde-Meiwes, J. Drillkens, B. Lunz, J. Muennix, S. Lehner (maiden name Rothgang), J. Kowal, and D. U. Sauer, “A review of current automotive battery technology and future prospects,” Proceedings of the Institution of Mechanical Engineers, Part D: Journal of Automobile Engineering, vol. 227, 2013. [20] C. Dunkel, “Adaption eines versuchstr¨agers und entwicklung von funktionsprototypen f¨ur automatisierte fahrfunktionen,” 2017. [21] M. Group, “Epos4 70/15, electr´onica digital de control de posici´on. https://www.maxongroup. es/maxon/view/product/control/Positionierung/594385, 25 de mayo de 2024,” 2020. [22] M. Group, “Epos communication guide.,” 2020. [23] M. Group, “Epos firmware specification.,” 2020. [24] M. Group, “Epos command library.,” 2020. [25] T. Mansour and T. Mansour, PID control, implementation and tuning. Rijeka, Croatia: IntechOpen, 2011. 70