Home
¡Hola!
Soy Julia López Augusto, alumna de 4º de carrera de Ingeniería Robótica Software de la Universidad Rey Juan Carlos en el campus de Fuenlabrada (Madrid) y mi tutor es Julio Vega
Has llegado al apartado de mi wiki que usaré para ir contando todo el proceso que voy a llevar acabo para realizar mi TFG.
Se va a dividir a su vez en 2 apartados muy importantes:
En este apartado se va a detallar los mínimos avances obtenidos según se desarrolla la investigación. Dentro de cada desplegable podrás encontrar toda la información al respecto.
- Septiembre 2023
- Octubre 2023
- Noviembre 2023
- Febrero 2024
- Marzo 2024
- Abril 2024
- Junio 2024
- Julio 2024
- Agosto 2024
- Septiembre 2024
- Octubre 2024
- Noviembre 2024
¡Despliégame!
Primero de todo contaros que tengo un problema: me gustan todas las ramas de la robótica y nose hacia dónde enfocarme; por lo que, se está complicando la decisión final del tema de mi TFG. Sin embargo, lo que sí que no puedo discutir es acerca de que me gustaría proporcionar una solución low-cost a la sociedad.
Me gustaría tomar alguna de las siguientes líneas:
- Educación: Desde pequeña siempre me ha gustado la docencia y el arte de saber enseñar. De siempre me ha gustado hablar y poder transmitir mis conocimientos al resto de personas. Para poder hacer pruebas, en mi antiguo instituto me han dado la oportunidad de poder hacerlas allí.
- Agricultura: Vengo de un pueblo, el campo y los cultivos han sido algo muy presente en mi entorno: el campo está a pocos metros de mi casa. Para poder hacer pruebas, tengo un amigo con tierras y me permite hacer pruebas allí.
- Espacio: Me apasiona el espacio y siempre he soñado con trabajar para la NASA. Sin embargo, veo más complicado poder encontrar aplicaciones e información necesaria para poder tirar hacia esta rama.
¡Despliégame!
Todavía sigo indecisa con cerrar un tema en concreto para poder empezar a tope con el TFG pero este mes me tengo que decidir sí o sí.
Hasta ahora he encontrado las siguientes posibles aplicaciones/lineas de investigación de los siguientes temas:
-
Educación: De esta es la que más he encontrado. Julio, mi tutor, le encanta todas las ramas pero la educativa es la que más ha tocado y su web me parece la mar de interesante y ya estoy tomando algunas ideas de ahí como su robot Pibot. También en la línea de poder hacer un robot educativo low-cost que pudiese mapear con un laser low-cost, he encontrado mucha información al respecto.
-
Agricultura: De esta me queda mucho por investigar pero se que hay muchas aplicaciones pero muy complejas. Iré actualizando.
-
Espacio: En relación a esta no he encontrado mucho acerca de esta opción pero tras la reunión de hoy me ha comentado que existe la siguiente conferencia acerca de laprendizaje automático y las galaxias: link aquí Conferencia: Villafranca del Castillo - Machine Learning meets galaxy classification (21 y 22 de Noviembre)
-
Otras aplicaciones: Otra opción que me ha llamado la atención es el uso de un robot low-cost y conseguir hacer reconstrucción en 3D. Me ha llamado la atención y me ha pasado un enlace de una persona importante en este campo pero usando un robot de mejor calidad. Se llama Andrew Davison.
¡Despliégame!
Este mes está siendo muy agobiante porque hay muchas prácticas que entregar y también exámenes pero bueno, es lo común en esta época. A pesar de todo esto creo que YA tengo claro qué tema voy a realizar y con el que creo que voy a aprender mucho y también va a provocarme algún dolor de cabeza, pero bueno me gustan los retos y las ganas no me van a faltar.
Finalmente el tema decidido va a ser: RECONSTRUCCIÓN 3D (de todo el entorno o solo objetos: me lo tengo que pensar) USANDO UN ROBOT MÓVIL LOW-COST para profundizar en el conocimiento de técnicas de reconstrucción y poder ver el potencial que podemos sacar de un robot low cost y así poder conseguir facilitar el conocimiento a gente que no disponga de grandes recursos (como soy yo).
La idea de construir un robot low-cost lleva presente desde el minuto 0 de inicialización de TFG y ya el software o la finalidad en sí no la tenía clara hasta este mes que llevo dándole vueltas a finalmente la construcción 3D.
El nombre del robot creo que será: Pi-botJ ya que será una versión actualizada del Pi-Bot y como lo voy a hacer yo, pues para poder tener un poquito de mérito :)
Pensé 2 prototipos que dependiendo del objetivo final se parecerá más a uno u a otro si finalmente siguen el estilo de Pibot
- Real Time Simultaneous Localization and Mapping with Single Camera: En este se usa EKF para hacer que el robot se mueva lento y de forma suave. Puede ser útil cuando le de movimiento al robot ya que es el controlador más sofisticado.
- SLAM with single camera. En este caso usa las representaciones de posición y orientación con quaterniones y también comenta cosas del EKF. Lo más importante es cuando en la página 5 habla sobre conversioens de 2D y 3D y comenta que en dichas conversiones la profundidad se pierde.
- Live Dense Reconstruction with a Single Moving Camera: Se produce una introducción a teorías probabilísticas,es denso y costoso (necesita mucha GPU), se muestra la fórmula de la proyección y retroproyección y el objetivo es aplicarlo a a sistemas robóticos avanzados.
¡Despliégame!
Tras 2 meses cargados por la exigencia de 4º de carrera y provocando el impedimento de continuar con el proyecto, vuelvo con más ganas que nunca para llevar a cabo este proyecto.
Sigo con la idea de la reconstrucción 3D e investigando acerca de la hipótesis suelo y los sistemas de atención visual selectiva. También estoy familiriarizándome con el entorno de Pibot y sobretodo con su cámara que es un sensor que no había tenido la oportunidad de usar para la Raspberry.
Acabo de crear mi primer programa y he comprobado que los motores de las ruedas funcionan perfectamente. Además, he desmontado la carcasa que venía con la Raspberry pi porque era bastante molesta para colocar todos los cables y hacía que no tuviésemos suficientes puertos.
Investigando por internet he encontrado varios ejemplos:
- Reconstrucción en 3D usando un brazo robótico
- Roznere, Monika, Philippos Mordohai, Ioannis Rekleitis, and Alberto Quattrini Li. 3-D Reconstruction Using Monocular Camera and Lights: Multi-View Photometric Stereo for Non-Stationary Robots. In 2023 IEEE International Conference on Robotics and Automation (ICRA), pp. 1026-1032. IEEE, 2023.
- A Robotized Raspberry-Based System for Pothole 3D Reconstruction and Mapping
Son días de profundizar acerca de la hipótesis suelo, del modelo pin hole, de cambiar un poco el estilo de la wiki (estoy usando Markdown y los cambios los estoy subiendo en el apartado de code a Github y de hacer pruebas con la cámara y con los motores.
Finalmente, a lo largo de esos días pude finalmente entender qué es la hipótesis suelo (en el mundo 3D la Z es 0). Gracias a recuperar apuntes de la asignatura de Visión Artificial basados en Conceptos y Métodos en Visión por Comptuador, he podido refrescar conocimientos del mundo 3D y 2D. En relación a la wiki, he creido más adecuado el reestructurar la información en 2 partes: Diario y Evolución del proyecto y añadir sus respectivos índices. He podido hacer pruebas con los motores e investigar más acerca de los servo motores. Toda la información la tienes disponible aquí.
Hoy he tenido tutoría y hemos hablado de los siguientes temas:
- Software Gráfico Recomendado: Concepts (aplicación ya descargada en la tablet), Gimp e Inkscape
- Solución a los pines 5V: cuello -> 3.3V y ruedas -> 5V
- Comprobación correcta del uso de LATEX usando la plantilla.
- Recordatorio de cómo funcionaba el uso de citar las referencias en las bibliografías.
- Importante saber que me pueden prestar baterías para hacer funcionar al robot de forma más cómoda.
- Avances significativos en el entendimiento del modelo Pin hole y cómo llevarlo a cabo: parámetros intrínsecos (calibración -> ajedrez), extrinsecos (método rudimentario, cambio de la posición actual de la cámara, precisión, exactitud...), filtro de color,...
El día de hoy he aprendido a manejar Concepts para el desarrollo de gráficos potentes. Un ejemplo de imágenes es: modelo Pin hole
Debido a que necesito conseguir el modelo Pin Hole, es necesario modificar la estructura; ya que apunta hacia arriba y no podríamos tener en cuenta la hipótesis suelo. Para ello el objetivo final es conseguir imprimir las piezas usando una impresora 3D pero por falta de recursos, de manera temporal usaré una estructura de aluminio y cinta de doble cara para sujetar la cámara. Además, estoy avanzando en el modelo pin hole y más concretamente con los parámetros intrínsecos y la calibración de la cámara.
Primero usé un tutorial pero no conseguía encontrar la solución al error que me aparecía y desistí a ese tutorial. También era una versión 3 a la 4 que es mi catual Raspberry. Encontré otro y en este llegué al siguiente error cuando ejecutaba la siguiente línea:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/USR/LOCAL -D OPENCV_EXTRA_MODULES_PATH=~/usr/local -D BUILD_EXAMPLES=ON ..
Finalmente, el error fue solucionado cambiando el path donde se encuentran los módulos extra quedando como:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/USR/LOCAL -D OPENCV_EXTRA_MODULES_PATH=~/Downloads/opencv_contrib-4.5.2/modules -D BUILD_EXAMPLES=ON ..
Seguí el resto de pasos y todos fueron conseguidos con éxito pero al abrir un fichero e intentar ejecutarlo, no consigue reconoce cuando se hace un:
import cv2
Tras la tutoría de hoy, Julio me ha recomendado cambiar el proceso de instalación de opencv. Ahora estoy intentando hacerlo usando pip.
Mientras tanto, he decidido cambiar mi forma de trabajar con la Raspberry y ahora en vez de usar un monitor de una tele con sus periféricos correspondientes, he decidido conectarme a través de la Raspberry usando VNC usando el siguiente tutorial: rápido y eficaz.
¡Despliégame!
Finalmente, tras varios intentos fallidos de instalación cuya duración era superior a las 2 horas ejecutando el siguiente comando:
pip3 install opencv-python
Obtenía errores fatales de instalación (borré la terminal antes de tiempo por eso no los puedo mostrar)
Decidí usar el siguiente tutorial que seguía los siguientes pasos:
1º: Instalando los prerequisitos:
sudo apt-get install libhdf5-dev libhdf5-serial-dev libatlas-base-dev libjasper-dev libqtgui4 libqt4-test
2: Instalando OpenCV 4 en Raspberry Pi
pip3 install opencv-contrib-python==4.1.0.25
En cuestión de pocos minutos, opencv funcionaba correctamente.
Prueba de ello:
Hace semanas de este tutorial extraje el código correspondiente a la calibración y al procesamiento para obtener los parámetros intrínsecos y la matriz de distorsión para poder probar el código en mi raspberry.
Hoy lo he podido probar pero debido a la instalación de la cámara, la imagen se muestra al revés
Finalmente descubrí cómo antes de operar con la cámara, darle la vuelta a la imagen con la siguiente función:
flipped_frame = cv2.flip(frame,0)Tras comprobar que funcionaba, decidí hacer el primer intento de calibración. Para ello usé el código de calibration.py para obtener imágenes en un bucle infinito cada 30 FPS y el código de process.py para detectar el patrón y obtener finalmente los valores de los parámetros intrínsecos y de la matriz de distorsión (que esta realmente no nos hace falta). Recuerdo que la idea inicial de este código lo obtuve de un vídeo de youtube.
Como tabla de ejedrez usé una plantilla
Antes del probarlo, es necesario cambiar la estructura de la cámara debido a que tiene que apuntar hacia abajo para poder obtener el modelo pin hole de la cámara y asumir la hipótesis suelo. Gracias a la ayuda de mi padre, pudimos hacer una estructura de metal temporal (ya que el objetivo final esque sea de impresión 3D):
Antigua estructura
Nueva estructura 90 grados respecto del suelo
Decidí dejarla en una posición de 90 grados con respecto al suelo para luego ir dejandola a mi gusto para que se vea más o menos el suelo.
Sabiendo los parámetros intrínsecos teóricos
Hice 3 calibraciones con la cámara en horizontal y haciendo distintas pruebas
Salida de process.py.
Valores de parámetros intrínsecos y la matriz de distorsión.
Salida de process.py.
Valores de parámetros intrínsecos y la matriz de distorsión.
Decidí indagar de nuevo en el código de calibration.py y de processing.py. He descubierto lo siguiente:
cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640)
cap.set(cv2.CAP_PROP_FRAME_HEIGHT,480)
cap.set(cv2.CAP_PROP_FPS,40)Fijan la resolución y los FPS de la cámara. Se fija este valor porque si fueran valores mayores tardaría demasiado en procesarse las imágenes y los FPS decrecerían. Sin embargo, esto genera un compromiso: si quiero agilidad (mayor número de FPS), las dimensiones de la cámara disminuyen (no tendría toda la visibilidad completa). Sólo tenemos esta franja:
Visión vs agilidad.
Sólo nos quedaríamos con la franja morada.
Salida de process.py.
Valores de parámetros intrínsecos y la matriz de distorsión.
Estos 3 tests se almacenan en Oldtests y algunas de sus imágenes han sido eliminadas porque no se permitía que se subiesen al repo.
Tras hacer estas pruebas decidí hacer una batería de 10 tests más (llamados como Validtests) pero en esta ocasión con la cámara apuntando hacia el suelo (aunque no importaba porque en este caso los intrínsecos no varían aunque se cambie la posición de la cámara).
El código de process.py fue modificado para que los valores de la matriz de intrínsecos fueran guardados en un .txt.
Tras los 10 tests, decidí únicamente almacenar en Validtests los .txt ya que las imágenes ocupan mucho espacio. Sin embargo, dentro de la propia Raspberry Pi he dejado una copia original con todas las imágenes; por si es necesario volver a consultar cualquier cosa.
Finalmente, de esas 10 pruebas pude calcular el valor medio final que lo podéis comprobar ejecutando meanintrinsicmatrix.py:
python3 meanintrinsicmatrix.py
El resultado final lo puedes ver aquí
A lo largo de estos días he estado teniendo problemas con el hecho de encontrar los valores teóricos ya que los valores iniciales no coincidían con el valor medio:
Esquema matrices del modelo Pin Hole v1.
Finalmente informándome en distintas fuentes de información como: "Multiple View Geometry in Computer Vision" (a partir página 155),photography, entre otros pude finalmente encontrar los valores adecuados. Lo puedes veraquí.
A lo largo de estos días he estado trabajando con los parámetros extrínsecos y haciendo las primeras pruebas del modelo pinHole
También estuve haciendo la siguiente investigación FALLIDA, pero bueno, es un avance:
Para probar el modelo pinHole es necesario fijar las conversiones de las coordenadas (del mundo en mm y las de la cámara en px) para hacernos a la idea de si lo estamos haciendo bien o no.
También usando reglas he estado calculando el campo de visión de la cámara en la vida real y podemos notar que el eje y no es completamente recto.
Sabiendo ya la traslación y la rotación de la cámara podemos hacer las pruebas del modelo pinhole conseguido.
Es importante tener en cuenta que al calcular el punto en 2D devolverá valores muy grandes en x,y,z y para obtener finalmente el punto 2D se normaliza dicho valor dividiendo x/z e y/z.
Si le pedía el punto (0,0,0) me tenía que devolver un punto en la esquina inferior derecha (como muestra las conversiones de coordenadas) pero me devolvía los valores de (311,231) los mismos valores que los centroides (cx,cy)
Otros valores también se notaban que estaban desplazados con respecto de (cx,cy)
Ante un buen rato sin saber solucionarlo se me ocurrió hacer una regresión lineal pero tampoco tenía mucho sentido.
Finalmente tras varias pruebas se me ocurrió hacer un desplazamiento de los valores hacia la esquina inferior derecha
Sin embargo para poder representar un punto en el eje y habrá que añadirle un signo negativo delante para poder situarlo en su lugar correcto.
Finalmente el modelo pinHole quedaría así:
El código está en pinhole.py Aquí puedes ver ejemplos de tests que he hecho:
- test 1:
- test 2:
Realmente, no se puede tomar esta investigación como válida ¡¡¡IMPORTANTE!!! porque estaba moviendo orígenes de coordenadas cuando no debía, tomando mal los giros; es decir, todo el concepto general. Julio en la tutoría me corrigió por eso digo que no lo estaba enfocando bien.
Lo incluyo para hacer un exhaustivo seguimiento de este proyecto.
Tras la tutoría y darme cuenta que el enfoque que estaba llevando no era el correcto, decidí cambiar mi visión y estudiar el código del profe para poder entender cómo lo había hecho o al menos saber cómo hacerlo.
El primer consejo que recibí y apliqué fue el de crear un filtro que detectase patrones de color. De ese filtro obtener sus coordenadas en píxeles, pasarlas a las del frame de la cámara y finalmente realizar su retroproyección. Todo este código lo hice yo.
Para realizarlo, hice varias versiones de ello: pinhole2.py y pinhole3.py
Sin embargo, no terminé de entenderlo y decidí partir de un ejemplo de Julio para poder entenderlo. Todo el contenido está en cameraPibot
Al mismo tiempo hacía medidas del entorno en la vida real.
Aquí puedes ver un ejemplo de la ejecución. Los valores no son exactos pero tienen mejor pinta que los obtenidos de pinhole.py
¡Despliégame!
Tras la última tutoría, tuve que cambiar la cámara porque dejó de funcionar.
Además, a lo largo de estos días he tenido que dividir una cartulina de tamaño DIN A3 en cuadrados de 1x1 cm para que las medidas tomadas sean más fiables. Aquí puedes ver un proceso decómo lo he ido haciendo:
Continué haciendo pruebas con los ejemplos que tenía:
El video está al x2
Como los valores no me coinciden y tras buscar información sigo sin conseguir nada, pido ayuda a Jose Miguel, un profesor que me impartió Visión Artificial en la carrera.
Además, la estructura ha tenido que ser modificada. Puedes encontrar toda la información aquí
Otra opción me dio:
- Aplicar matriz de distorsión (skew)
- Incluir el libro de referencias de Jose Miguel y leer lo detenidamente
- hacer de pixeles a 3d obteniendo la z y sacando la regla de 3
- hacer un urdf
- aprender sobre las tf
¡Despliégame!
Finales de Abril y todo Mayo ha sido muy duro porque tenía que acabar la última asignatura de la carrera (la más difícil y con los profesores más duros a mi parecer) y quería poder sacar la asignatura adelante lo mejor posible (lo que provocó que dejase de lado el TFG y por eso no hay casi actualización de dichos meses). Afortunadamente he tenido un 9 de nota final y estoy muy contenta.
Desde febrero hasta ahora he tenido que ir compaginando tanto la asignatura como el TFG además de problemas personales; lo que me hizo desanimarme con el TFG. He llegado a replantearme el proyecto varias veces y creo que ahora he encontrado una opción que me motiva mucho. Dicha opción es: "Robot low-cost que detecta irregularidades en el pavimento y facilita su reconstrucción"
Esta última semana he estado dándole un nuevo aire a la wiki y depurando mucha documentación e imágenes innecesarias. También he estado leyendo TFGs de compañeros para saber más o menos qué estructura siguen al igual que toda la normativa de TFGs para que no se me escape ningún tipo de detalle a la hora de la evaluación.
Además acabo de subir una versión de la memoria en pdf con la portada en su 80% y también he querido ya dejar listo el apartado de agradecimientos. Spoiler: más de una lagrimita he derramado.
Hoy he realizado una nueva calibración de la cámara ya que la tuve que reemplazar y cambiarla su orientación. Todo el contenido de la misma se encuentra en valid_tests y la anterior válida se encuentra en old_tests/test4. También he decidido almacenar la matriz de distorsión y calcular su media como hacía con la de los parámetros intrínsecos.
He decidido probar a sacar lo del modelo pinhole siguiendo las indicaciones que me dijo Jose Miguel.
Es importante recordar cómo funcionan los distintos sistemas de coordenadas
La he obtenido a través de esta web
Por lo tanto el sistema de coordenadas de la cámara de mi robot quedaría así:
Primero de todo es importante tener en cuenta que para la conversión de 2D a 3D existen estas fórmulas:
Dentro de la fórmula, x e y son los píxeles en 2D; cx, cy, fx y fy se obtienen de la nueva matriz de intrínsecos y finalmente d es el valor que es necesario estimar.
¿Cómo se puede hacer?
Imágenes realizadas usando Samsung Notes
Sabiendo las coordenadas de los extremos y las medidas realizadas a mano en la vida real, podemos estimar su relación usando una herramienta matemática. Esta herramienta fue complicada de encontrar ya que hay en juego 2 variables para un valor en concreto. Finalmente, tras investigar decidí usar Interpolación bilineal. Este video explica más detalladamente cómo funciona. En este libro también encontré información muy relevante. Esta web también fue de gran ayuda.
De toda la información encontrada pude llegar a la conclusión de que siguiendo la siguiente fórmula se puede llegar a obtener el valor buscado.
Por ejemplo:
Si tenemos el pixel (100,200), despejando la fórmula, obtenemos que se encuentra a 29.375 cm.
Todo el código implementado se encuentra en 2D_to_3D_using_bp
A dia de hoy, según las pruebas obtenidas todavía no consigo dejarlo perfecto pero bueno, en la tutoría espero solventar mis dudas.
Hoy me he propuesto dejar un poco de lado el modelo Pin Hole y ponerme a ser capaz de controlar el robot desde una interfaz gráfica y así facilitar la interacción humano-robot, lo más conocido como HRI. Nunca he trabajado con Raspberry pi y creando entornos web y gráficos para poder manipularla. Toda la información la encontraréis en el apartado HRI.
También he añadido ottro apartado de herramientas/datos importantes a saber.
Tamibén he inicializado otro apartado para el módulo GPS
Estos días he conseguido que funcione la Raspberry pi como servidor web y he conseguido que se mueva el robot entero. He hecho una versión 1 que está almacenada en control, usando el código de testing_motors3.py.
Todo está descrito en HRI
Como el movimiento del robot no era claro (sobre todo en los giros hacia la derecha y la izquierda), he realizado una segunda versión también almacenada en control que explico detalladamente en el apartado HRI. Además como posibles modificaciones para crear el código, decidí crear testing_motors4.py; pero en la interfaz gráfica no funcionaba. Finalmente, la versión 2 es la versión 1 pero con distinta lógica.
Sigo investigando acerca de HRI y de un movimiento fluido de los motores. Acabo de solucionar el problema de la fluidez de los motores y del por qué no funcionaban exactamente igual si se ejecutaba directamente o a través de la interfaz web. El problema era que en procesa.php se estaba usando sudo python en vez de sudo python3. También he incluido un favicon para solucionar el problema que me aparecía en la interfaz gráfica.
También he empezado a trabajar con el módulo GPS
Estos días estoy trabajando con el módulo GPS que tras varios intentos y muchos tutoriales y documentación después: por fin conseguí que funcionara y pudiese ver que los datos se reciben perfectamente.
Todo está documentado en el apartado de GPS.
Finalmente he conseguido que funcione el módulo y sea capaz de recibir datos y de mostrarlos correctamente. Ahora es el momento de hacer un tracking en tiempo real usando una interfaz gráfica. Estoy pensando en usar Google Maps API pero hay que pagar y Open Street Maps es otra opción pero no lo veo tan intuitivo.
He estado trabajando con OpenStreetMaps, Leaflets y firebase para intentar obtener el mismo resultado que con Google Maps API pero la verdad que por intentar hacer las cosas deprisa y sin ser cuidadosa leyendo todos los pasos, he llegado a cargarme el sudo de mi placa. No podía hacer nada así que la única solución que encontré fue formatear y reinstalar de nuevo el sistema operativo.
Para mi sorpresa, fue que el sistema operativo actual (Raspbian Bookworm 32 bits) era más nuevo que el que estaba usando antes y ya entendí que el problema de que algunas librerías que intentaba usar en la versión anterior estuviesen deprecated (obsoletas).
Ahora estoy en un punto que tengo 2 versiones de los sistemas operativos: la anterior y la de ahora. Así que si alguna de las 2 me da problemas, puedo tirar por la otra. Para ver si era viable el proyecto usando la nueva versión, estuve poniendo en funcionamiento cada sensor. Dentro de cada apartado tienes una referencia sobre las cosas que han cambiado con respecto de una versión a otra.
Voy a seguir con mi proyecto con la última versión del Sistema Operativo (raspbian Bookworm) y he acabado de actualizar lo que me faltaba de la wiki.
Tras la tutoría de ayer y la curiosidad que me generó el hecho de encontrar el por qué una versión de python frente a otra provocase el mal funcionamiento de los motores, ha hecho investigase al respecto pero no encontrara nada en concreto salvo lógicamente advertirme que si uso python3 es mejor ya que es la última versión.
En relación al tracking en tiempo real, voy a dejarlo por unos días porque el tiempo en mi zona no es lo más favorable y no quiero estropearlo. Además me corre más prisa dejar hecho toda la impresión 3D ya que en mi antiguo instituto me han permitido imprimirlo a lo largo del mes de julio.
Yo en mi instituto usaba Sketch up para diseñar las piezas pero en este ocasión he decidido familiarizame con Freecad ya que es una de las herramientas que he aprendido en la universidad y que gracias a mi profesor Obijuan ha conseguido despertar mi curiosidad hacia ella.
Toda la información está detallada en el apartado de Impresión 3D
¡Despliégame!
Sigo con impresión 3D: he hecho todos los planos, bocetos tanto a papel (2D), cartón (3D) y diseños en 3D. Todo está documentado en el apartado de Impresión 3D
He acabado la maqueta de cartón, ya tengo en mente el diseño completo en 3D que voy a proceder a hacerlo. Todo está documentado en el apartado de Impresión 3D
He estado trabajando con el diseño completo y estoy realizando las primeras impresiones en el instituto. Todo está documentado en el apartado de Impresión 3D.
Además he estado trabajando en la memoria del proyecto. He escrito la introducción y un poco sobre la robótica, los tipos de robots y su historia.
He tenido problemas de impresión y tengo que cambiar la lógica de usar una pieza completa a varias usando tornillos. Todo está documentado en el apartado de Impresión 3D.
Tras estar más de 2 semanas con el diseño 3d y conseguir sacar todas las medidas, finalmente lo he conseguido. Sin embargo, tras múltiples intentos de conseguir imprimir las piezas, no he podido hacerlo correctamente: se levantaba la pieza de la cama, se producía wrapping, cambiar muchos parámetros del mismo (altura de capa, relleno, temperatura de la cama, del extrusor, limpieza del cristal con acetona, calibración...), muchas horas de impresión, etc. Además no disponía 24/7 del tiempo para esstar pendiente de la impresora, solo las mañanas.
Por lo tanto, ya que el instituto cierra mañana y necesito las piezas, voy a pedir a alguien que me las imprima ya que he llegado a la conclusión que es por culpa de la impresora, no de mi diseño hecho en varias piezas.
Para poder seguir avanzando con el proyecto, he vuelto a montar el robot en su versión de metal.
Estoy profundizando en la redacción de la memoria y mi soltura con latex en este formato.
También, he empezado a investigar acerca de las IA aplicadas a una Raspberry-pi.
Hoy he avanzado más en la redacción en latex y ya he aprendido a soltarme y a tenerlo todo mucho más claro. Voy por el apartado de Robots de Campo.
Además, un amigo mío me está imprimiendo las piezas y de momento la primera tiene muy buena pinta:
Por último, he empezado la investigación sobre aprendizaje automático de detección de suelo: los actuales, desarrollos, más adecuados para la Raspberry ya que su cómputo tiene que ser liviano para hacerlo en tiempo real
Sigo con la redacción de la memoria (acabo de terminar el apartado de robots low-cost) y a la espera de que hoy paso a recoger las piezas en 3D que ha estado imprimiendo mi compañero Gonzalo.
Ya tengo el robot montado y probado todos sus sensores y actuadores (sólo no funciona la cámara: tengo que revisar).
Estoy modificando la memoria ya que se han encontrado erratas tras la tutoría y ahora se lo mandaré a Julio para que haga una revisión más detallada. Está en proceso de que la revise.
Finalmente, se conseguido construir el robot completo (con todos sus tornillos, arandelas y tuercas) en Freecad. Además, lo he documentado todo y he conseguido sacar imágenes y gifs al respecto que enriquecerán mi memoria y la presentación. Todo está documentado (tanto texto como imágenes) en el apartado de impresión 3D y puedes ver el fichero del robot completo montado en Freecad aquí
Tras bastante tiempo investigando el estado del arte de mi proyecto, he decidido decantarme por algunas de las aplicaciones.
También he estado informándome acerca del contexto del mantenimiento de las carreteras, de los organismos que se encargan de ello, etc. Lo puedes ver anotado aquí
¡Despliégame!
Nuevo mes, nuevo comienzo. Ya solo me queda la parte software para mi proyecto y Agosto va a ser la oportunidad para poder hacerlo; así como, la redacción de la memoria.
Aparte de la parte software, estoy añadiendo otro dato importante que es, identificar los tipos de irregularidades que existen y cómo arreglar los baches que es la irregularidad que he decidido hacer
He empezado refrescando conocimientos de ROS y viendo si lo que aspiro en conseguir se puede hacer con ROS2.
He empezado a intentar crear mi primer paquete y que cualquier modelo se pudiese visualizar en rviz, he tenido problemas.
He conseguido solucionar el problema del modelo visualizado en rviz. Mira los avance aquí
Me puse a probar si se veía en gazebo pero me daban muchos errores
Tras mucha investigación e intentos. he conseguido mostrar un robot de un tutorial en Gazebo. Espero conseguirlo muy pronto para el mio. Este es el repo que me ha inspirado. Mira los avance aquí
Conseguí mostrar parte del mio pero con errores.
He conseguido mostrar mi robot, a excepción de colocar la cámara correctamente y el gps. Los motores se mueven perfectamente usando cmd_vel/ pero no consigo mover el motor de la cámara. Parece ser que cómo lo estaba haciendo no se puede. Mira los avances aquí
Tras ver que no se puede mover el motor de la cámara cómo lo estaba haciendo, he decidido empezar a investigar e implementar ros2_control. Mira los avances aquí
Finalmente, tras estar muchas horas, lo he conseguido. Mira los avances aquí Ahora tengo que juntar lo que tenía con esto último nuevo.
A falta del GPS y definir límites a la cámara, lo demás está todo hecho. Mira los avances aquí
Ya tengo el robot completamente funcionando en Gazebo y con todos los topics creados para poder usarlos. Mira todos los avances aquí.
Estoy empezando a ponerlo en el robot real y a avanzar en la redacción de la memoria.
He estado terminando la redacción del capítulo 1 y solucionando la referencia de las imágenes.
La solución ha sido así:
\begin{figure}[ht!]
\centering
\begin{minipage}{0.4\linewidth}
\centering
\includegraphics[width=\linewidth]{figs/memnon.jpeg}
\caption*{\centering Estatuas de Memnon $^{\ref{note:enlace1}}$} %\cite{memnon_image}
\end{minipage}
\caption{Ingenios de la antigüedad con fines religiosos}
\label{fig:ancientrel}
\end{figure}
% Definir la primera nota al pie con el número 1
\setcounter{footnote}{1} % Reiniciar la numeración de notas al pie
\footnotetext[\value{footnote}]{\url{https://es.wikipedia.org/wiki/Colosos_de_Memn\%C3\%B3n}\label{note:enlace1}}Además, si en cualquier enlace o momento hay que incluir %, hay que escaparlo con ****. Se puede ver en la url del snippet anterior.
La memoria la puedes ver aquí
He incluido en el capítulo 1 una gráfica que la he podido conseguir gracias este tutorial
También he terminado de redactar la versión 1 del capítulo 2: Estado del arte. La memoria la puedes ver aquí
Voy a terminar de probar en el robot real que funcione ros2, de configurar ssh y todos los sensores. He conseguido configurar la cámara en ubuntu y ya aparecen sus topics. Todos los avances los puedes ver aquí
He estado intentando hacer un hardware interface para poder controlar el robot real de la misma forma que el simulado pero al usar pines GPIO, no es tan fácil poder conseguirlo. Tras mucha investigación e intentos, he decidido finalmente cmabiar mi forma de hacerlo. En este caso serán nodos publicadores y suscriptores de las distintas operaciones.
Ya funciona el nodo de la cámara, los motores y he inicializado el puerto serie. Todos los avances los puedes ver aquí
He conseguido crear un topic para el módulo gps y poder obtener la latitud y la longitud y he podido comprobar que dichos valores son correctos. Todos los avances los puedes ver aquí
También he decidido que los paquetes de trabajo son:
- pibotj_r2c: para trabajar con el robot en modo simulación.
- pibotj_rr: para trabajar con el robot en el mundo real.
Estos días estoy con la inteligencia artificial, entrenando modelos, creando topics para la cámara e intentando probarlo y que funcione todo junto. Todos los avances los puedes ver aquí
Para agilizar los cómputos, he eliminado libreoffice de la Raspberry:
dpkg --list | grep libreoffice
sudo apt-get remove --purge libreoffice*
sudo apt-get autoremove
sudo apt-get cleanYa he conseguido que funcione la primera versión del nodo de la cámara con el modelo de tensor flow lite creado. Todos los avances los puedes ver aquí en el apartado de cámaras.
También he conseguido que el topic del gps se conecte a la interfaz web y muestre en tiempo real donde se encuentra. En un futuro me gustaría fijar a cada punto que muestra, una breve descripción del tamaño del bache y su localización. Todos los avances los puedes ver aquí en el apartado de gps.
He conseguido sincronizar los motores y la cámara creando un topic que publica una string con yes o no desde el nodo cámara y los motores se suscriben a ese string para ver su estado y se mueven en linea reacta si no hay bache y si lo detecta paran de moverse.
También he estado investigando y la única solución que he encontrado para que no haya tanta latencia entre que pongo el bache y hasta que lo detecta, es usar Google Coral AI Accelerator, que es usado para este tipo de problemas. Lo voy a pedir para que me llegue lo más pronto posible; el coste es de 75€ con gastos de envio incluido.
He estado investigando y estoy poniendo en práctica un filtro de imagen, usando técnicas de OpenCV y refrescando conocimientos de la carrera, cuando se detecta el bache y se devuelvan los puntos para poder calcular su posterior área.
Estoy siguiendo este tutorial para conseguir el filtro correcto.
He estado todo el día con el filtro de imagen para conseguir las coordenadas de la imagen y ya que estoy conectada por ssh no puedo usar los deslizadores para poder probar todos los posibles valores de umbrales para Canny, lo he estado haciendo a ojo. Conectando un monitor tampoco me funcionaba, así que tuve que seguir con la táctica de probar a ojo.
Finalmente he podido descubrir un método que permite a partir de coordenadas, poder calcular el área que conlleva: Es el "shoelace method". Puedes encontrar más información aquí.
También recibí el Google USB Coral Accelerator, que para mi sorpresa (justo eso no lo miré) solo trabaja con Python entre las versiones 3.6 y 3.9, siendo el python instalado en mi Raspberry pi con Ubuntu 22.04 de 3.10. Aquí podrás ver de lo que te hablo.
He intentado usar entornos virtuales con pyenv pero me fue imposible conseguir que funcionara. También intentar desinstalar python 3.10 para usar 3.9, la terminé liando con los enlaces simbólicos y con otras dependencias de otros paquetes: python3-apt, pkg_apt not found.... Tras darle muchas vueltas e investigar mucho también, finalmente gracias a esta respuesta de un foro en concreto la última respuesta, me animó a intentar parsarme a Ubuntu 20.04 para probar si Google Coral merecia la pena ya que en mi caso la raspberry está destinada exclusivamente a esta aplicación. También ayudó que fuese compatible ros2 en ese dispositivo (aunque tendría que usar foxy en vez de humble).
Tras instalar Ubuntu 20.04 Server en mi Raspberry pi, tuve bastantes problemas sobre todo para la conexión por internet, no conseguía conectarlo por ssh. Finalmente para ver los posibles errores que podrían ocurrir, enchufé un HDMI y a través de una terminal me dejó loguearme.
Gracias al fichero:
cat /ect/netplan/50-cloud-init.yamlPude modificarlo y poder introducir la contraseña correcta. A partir de ahí pude conectarme correctamente.
Puedes ver a continuación una imagen que lo demuestra:
Otro problema que tuve es que al intentar habilitar la cámara modificando
/boot/firmware/config.txta mano (desde mi ordenador en local) pues se quedó corrupto el sistema de ficheros y me tocó reinstalar de nuevo el sistema operativo.
Otro de los problemas que ocurría era que aparecía el siguiente error:
La única forma que conseguí solucionarlo fue cambiar la ssd a otra placa y volver a ponerlo a la anterior. Posteriormente me di cuenta que era por culpa de tener conectado el gps en el puerto serie. (este error lo resolveré más adelante)
Toda la documneetacion en relación a ubuntu 20.04 está documentado aquí
¡Despliégame!
He terminado de solucionar el problema de la cámara que se encuentra perfectamente funcionando usando un modelo más complejo de yolov8 que detecta baches que ha sido adaptado para que funcione para usar edge_tpu con el USB Google Coral Accelerator. Todo está documentado aquí
También he solucionado lo del puerto serie. Todo está documentado aquí
He comenzado también a redactar el capítulo 3, en concreto el subapartado de competencias.
He encontrado razones para usar Ubuntu 20.04/ROS 2 FOXY en python 3.8.
He terminado de entender cómo funciona el nodo de camera_tfv2_node. Todo está documentado aquí
He terminado de documentar el apartado de la cámara y he terminado de entender lo que tengo hecho de pin hole desde hace meses.
También he hecho el apartado 3 y 4 de la memoria del TFG. Lo puedes ver aquí
He conseguido crear un entorno ficticio para hacer las pruebas simulando que es una carretera. Todos los avances los puedes ver aquí
He actualizado las pruebas realizadas para el modelo Pin-Hole. Todos los avances los puedes ver aquí y aquí
También he limpiado la bibliografía de la memoria de referencias innecesarias.
Finalmente he incluido aquí los avances de interfaz web y del gps para incluir varios puntos por cada punto detectado.
Ya he creado la botonera y he actualizado la interfaz web. Todos los avances los puedes ver aquí
También he realizado la versión 2 del capítulo 1 de la memoria. Todos los avances los puedes ver aquí
He realizado la versión 2 de los capítulo 2, 3 y 4 de la memoria. Todos los avances los puedes ver aquí
He actualizado la wiki, arreglado la botonera, probado a introducir la imagen en la interfaz web que he desistido, he creado un launcher paraa lanzar la interfaz web y ponerla en funcionamiento ( la cámara va aparte DE MOMENTO), he documentado todos los nodos y topics creados y usados en el proyecto hasta ahora.
También se refrecó conocimientos de sistemas empotrados y en tiempo real para intentar solucionar cuando se lanzaba todo a la vez se quedase pillado: que se solucionó usando nice. Otra opción que se trató era si era problema de voltaje al ejecutar el siguiente comando:
vcgencmd get_throttledIndependientemente si he probado con vaios cables o funetes de alimentación no me da 0x0.
Todas las soluciones encontradas e implementadas en el robot las puedes encontrar aquí.
Estuve actualizando la versión 3 de los capítulos 1, 2 y 3 y la versión 2.1 del capítulo 4. He anotado las dudas para consultarlas y arreglarlas en la próxima tutoría.
Estuve también intentando que se conectara el robot a la red de mi móvil para poder hacer pruebas pero me fue imposible hacerlo.
Finalmente fui capaz de conectar al robot a la red wifi de mi móvil. Todo está documentado aquí.
También he conseguido solucionar lo del nodo de la cámara. El problema es que el nodo \camera_tf2 publicaba imágenes de 640x480 cuando en realidad el modelo usado para tflite de Google Coral trabaja con imágenes de 192x192 y el modelo de salida es de 48x48. Ya se ha modificado el nodo para que publique 192x192 imágenes. Por ende, ya NO HACE FALTA USAR NICE
También hice las primeras pruebas en la calle y como era de esperar las ruedas no son capaces de hacerlo funcional cuando el robot se mueve fuera de casa. Estoy en proceso de probar con otras.
Aquí puedes encontrar imágenes y videos del primer experimento.
He estado haciendo pruebas para modificar el umbral de detección debido a que era muy alto. Para ello he creado una tabla para consultar los valores. Puedes consultar la tabla aquí
He creado finalmente una segunda versión de OpenCV que es completamente funcional y que realmente parte de la información detectada del modelo y nos ayuda a identificar en qué parte de la imagen se ha detectado el bache. Todos estos cambios están en camera_tfv3_node y todo está documentado aquí
He cambiado el Filtro de Kalman que tenía por una Media Móvil Exponencial que es común usarla en finanzas pero que es muy liviana computacionalmente hablando y sirve para la aplicación. Toda la información está descrita aquí
He inicializado el capítulo 5 de la memoria.
He documentado todas las cosas que me faltaba por hacer.
He actualizado lo comentado en la tutoría y sigo con la redacción del capítulo 5.
Sigo con la redacción del capítulo 5
¡Despliégame!
He recogido el material para probar otro tipo de ruedas en el robot, he actualizado el robot y probado que funciona y sigo con la redacción del capítulo 5. Los pasos seguidos están en la memoria y así queda el robot:
Sigo con la redacción del capítulo 5 que está casi completo, a falta de incluir la parte de "elección de componentes hardware".
Actualizada la memoria con nuevas versiones de los Capítulos 4 y 5.
He conseguido mezclar el código del modelo pinhole con la detección de la cámara y ya tengo los primeros valores de área usando el método de "shoelace"
He solucionado los problemas que tenía con el método shoelace y ya obtengo valores correctos. Toda la documentación la tienes aquí y aquí
Además, he conseguido que solo cuando se detecte bache, se publique las coordenadas del punto con su área correspondiente. Toda la documentación la tienes aquí
He solucionado los problemas de la interfaz web desde la consola. Toda la documentación la tienes aquí
También, he inicializado los últimos capítulos que me faltan (he creado los ficheros y he puesto las frases inspiradoras) y estoy haciendo un esquema del capítulo 6, la parte de simulación. Para ello, estoy haciendo un repaso por toda la wiki para no dejarme nada y la estoy también actualizando.
Finalmente, he conocido cuál es la profundidad media en un bache según la asociación racfoundation y se trata de 40 mm. Puedes ver más detalles aquí
Redactando el capítulo 6.1 y terminándolo.
A lo largo de estos días se ha desarrollado un filtro para que el robot se ubique en la carretera y se mueva por ella sin salirse, usando detección de las líneas blancas. Además, se ha modificado la lógica del movimiento de los motores para bajar la frecuencia de publicación y por tanto, el cambio de ciclo de trabajo. Ambas cosas se han probado y funcionan perfectamente.
Otra cosa que se ha desarrollado y probado es VFF para esquivar los baches una vez detectado.
Estoy comenzando a redactar el resto del capítulo 6.2
Terminando de redactar el resto del capítulo 6.2 y empezando el 6.3
Redactando capítulo 6.3 y actualizando detalles del código
Se terminó de redactar el capítulo 6.3 y se empezó a perfilar el movimiento de VFF.
¡Despliégame!
Se terminó de definir VFF con una versión probada en el entorno controlado, con resultados muy positivos. Se ha procedido a resumir información de los capítulos del 1 al 6.2 permitiendo tener 14 páginas para conclusiones y experimentos. Además, se ha terminado el Apéndice A (capítulo 9) con el paso a paso para configurar a PiBotJ en la vida real. También se han inicializado los 4 apartados que me faltan para terminar la memoria: experimentos, conclusiones, resumen y abstract.
Estoy actualizando toda la WIKI ya que estas últimas semanas la memoria y el proyecto, me han quitado todo el tiempo.
He escrito la mayor parte de los experimentos y anotados las fotos y vídeos que hay que incluir.
He creado las imágenes de los esquemas de nodos, he hecho algunos experimentos y sigo con conclusiones y el resumen.
Ya he terminado y actualizado el capítulo 6, las conclusiones, el apéndice y el 80% de los experimentos
He cambiado el módulo GPS ya que había dejado de funcionar y no se conseguía encender el LED. también he vuelto a apretar los tornillos y reponer las que faltan.
Estoy haciendo los experimentos que me falta: he hecho el del modelo pinhole
Ya he creado los 2 launchers y he hecho los experimentos de VFF y de EMA, solo me quedan los del modo autónomo y teleoperado. Todos los avances están en la memoria.
He terminado el experimento del modo teleoperado. El resultado final lo puedes ver aquí
En este apartado se van a incluir todos los datos acerca del proyecto que se incluirán en la memoria final.
-
Software
- Motores
- Módulo GPS
- Cámara
- IA para detección de baches y obtención de coordenadas
- Conversión coordenadas al mundo real: modelo Pin Hole
- Calcular área: método de la lazada
- HRI: interfaz web
- ROS2 HUMBLE: Creación de PiBotJ en simulación
- ROS2 FOXY: Configuración y soporte software de PibotJ en la vida real
- Electronics -> Revista
- MDPI -> Editorial
- Cite: Bibtex -> nombrar referencias
- referencia -> abstract (lo elimino)
Siempre hay que dirigirse en la redacción del TFG usando la primera/tercera persona del plural o la forma impersonal.
En cada referencia que encuentre, existe un .bib y lo que te devuelve ese .bib lo tengo que incluir en la bibliografía del apartado memoria
Ejemplo para usar las referencias bibliográficas: "Pepito (meter ahí la referencia bibliográfica) nos habla sobre ..."
Si se trata de una página web se usa generalmente @misc e incluir el campo last access. Pero es mejor usar footnote para compañías y demás (KUKA,ABB ...)
Para nombrar a una sección o una figura siempre tomarlo como NOMBRE PROPIO es decir, la PRIMERA siempre en Mayúsculas.
Las imágenes tienen que poder verse bien en tamaño DIN A4.
-
Redactar el Capítulo de experimentos (autónomo y teleoperado)
- Afinar lo de publicar cada 1s
-
Redactar abstract (me tengo que esperar a dar el visto bueno del resumen)
-
En el README.md incluir pasos para conseguir al robot
- Real: construcción y software
- Simulación: construcción
-
Revisar que los ficheros definidos en el 6.3 coinciden con los launchers de la aplicación final