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.

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.

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.

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.

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

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

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

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.