Bitacora - Edelmeyder/TP2F4 GitHub Wiki
| Fecha | ¿Qué se hizo? | Problemas |
|---|---|---|
| 18/08/22 | En clase el profesor nos mostró el funcionamiento actual del sistema. 
|
No aplica |
| 20/9/22 (Prof.) | Pueden utilizar como referencia y para verificación de lo construido los esquemas de interconexiones que les envié por correo, como éste 
|
verificar lo construido con los esquemas y reconstruir los esquemas con el nuevo hardware, tal como se indica en la evaluación del Plan de Proyecto |
| 20/9/22 (Prof.) | También documentar aquí qué hardware se utiliza vía biblioteca y qué hardware directamente manipulando pines, para luego también poder identificarlo rápidamente en el código fuente | Lo que originalmente son 2 proyectos del IDE van a ser uno solo, se recomienda poner en diferentes .cpp del mismo proyecto cada conjunto de funciones (o función) que maneja un módulo de hardware (si no se entiende, consultar en clase |
| 20/09/22 | Refactorizando el código existente. Avance subido a branch edelmiro. | |
| 21/09/22 | Testeado y debugueado del código del Arduino UNO, todo funcionando en el robot. Al día en branch edelmiro.Video El funcionamiento es casi el mismo excepto que ahora hay un pequeño delay luego de instrucciones de dirección o bocina para evitar que el envío de varios comandos seguidos de esas categorías se ejecuten como uno solo.. | Feliz día del estudiante! |
| 22/9/22 (Prof.) | Verificar partes de hardware. En el branch ya están los .h y .cpp y creo que con eso quedará bien a menos que veamos algo diferente en el transcurso del desarrollo | Enumerar harwdware disponible y faltante para completar en clase. Enumerar/describir las conexiones de pines y bibliotecas a usar o usadas en el proyecto |
| 03/10/22 | Testeado nuevo codigo de Arduino UNO. Subido a la rama yair. Se agregó la funcionalidad del sensor de proximidad. Cuando se detecta un objeto delante a menos de 30 centimetros, se procede a frenar inmediatamente. Se evita así las colisiones. Video donde se aprecia el funcionamiento | |
| 4/10/22 (Prof.) | Con la inclusión del sensor de proximidad creo que ya queda completo todo el hardware que van a manejar al menos para un primer prototipo del sistema con la WeMos. Al menos en el corto plazo se concentrarían directamente en el reemplazo de Arduino+ESP8266 por una única placa | Para la fecha del informe de avance "fijen/consoliden" el código en la rama principal, así queda claro a partir de dónde siguen en la siguiente etapa. |
| 4/10/22 (Prof.) | Tal como comentamos ayer en clase, pueden tomar dos alternativas de continuación a partir de lo que ya hicieron (sería post-entrega del informe de avance de octubre): a) probar individualmente las partes a partir de la interfaz web, haciendo la migración incremental por partes, o b) dedicarse a la integración directa de todo el sistema, sin pruebas individuales de cada módulo/breakout de hardware | Definir la estrategia a seguir entre las dos mencionadas o si tienen alguna otra, la documentan y avanzan (al menos post-entrega del informe de avance). |
| 16/10/22 | Empezamos a migrar los componentes y el código para funcionar en la WeMOS. Pudimos hacer funcionar la interfaz entre el control remoto y la placa y hacer funcionar el motor hacia adelante y la bocina. | No funciona el servo (creemos que es porque el servo tiene lógica de 5V) no funciona el marcha atrás porque el pin no se setea en low cuando debería, no sabemos porqué. |
| 16/10/22 | Se solucionó el problema con el servo (error de codigo). Se realizó la migracion de los demas componentes de hardware, todo funcionando adecuadamente.Video del prototipo en funcionamiento. | Debemos arreglar un problema de inicializacion de la placa cuando se conecta por primera vez, esto ocurre si el pin de PWM del puente H se encuentra enchufado. |
| 17/10/22 (Prof.) | Comentamos en clase algunos detalles de la placa que pueden ser confusos y/o no documentados. En particular, la relación de analogWrite()-PWM y timers que tiene Arduino-ATMEL y que no tienen las placas basadas en el ESP8266 como la que se está usando en este proyecto. Lo documentado de Arduino tiene relación con las interferencias entre pines y timers: https://www.arduino.cc/reference/en/language/functions/analog-io/analogwrite/ https://www.arduino.cc/en/Tutorial/SecretsOfArduinoPWM. Lamentablemente no encuentro ahora la documentación entre los pines de PWM de arduino y los timers. De todas maneras, esto no termina de explicar el comportamiento anómalo que me comentaron (o lo que yo entendí, al menos) de un pin digital... Es posible que estos comentarios estén relacionados: https://forum.arduino.cc/t/timer-interrupts-and-pwm-pins/316380 https://www.tutorialspoint.com/timer1-based-pwm-in-arduino-uno |
a) Agregar una foto de la placa que están usando para que nos quede de referencia, porque es de las placas que menos se usan en el mercado, de las que menos información disponible hay. b) Si es posible, documenten el comportamiento anómalo del pin digital que me comentaron en clase. |
| 17/10/22 (Prof.) | Asumimos que la comunicación combinando 3.3v con 5v para Rx-Tx va a seguir funcionando, como en el proyecto original, que tenía conectados el Arduino UNO con un ESP8266-01 de manera directa | Comunicar sin divisores ni adapatadores de tensión para Rx-TX |
| 17/10/22 (Prof.) | Comentaron en clase sobre el comportamiento anómalo del pin Vin de la placa. | Documentar el comportamiento con código + video (ambos reducidos a reproducir problema). (*) |
| 18/10/22 (Prof.) | Continuando con la búsqueda de información que podría producir problemas en la salida digital de pines por una combinación "incorrecta" de PWM-timers, está la documentación sobre la función tone(), que también utiliza timers y puede generar problemas con el pwm de algunos pines. https://www.arduino.cc/reference/en/language/functions/advanced-io/tone/ "Use of the tone() function will interfere with PWM output on pins 3 and 11 (on boards other than the Mega)." De todas maneras, eso no termina de explicar el funcionamiento anómalo de la salida del pin digital y además se debe seguir recordando que la placa no tiene un procesador Atmel de base como las que se documentan en el sitio de Arduino. |
Se mantiene (*) |
| 23/10/22 | Se agrego la funcionalidad para enviar datos a traves del path /data, junto con un script para pedir esos datos y procesarlos (Video de demo). Los datos se almacenan en la placa por medio de la libreria ArduinoJSON, una vez que son requeridos se pasa el JSON a formato string y se envia por HTTP. | Se podria modificar el timestamp ya que esta en formato UNIX y no es muy practico para la lectura , por ahora solo envia el historial de comandos recibidos, habria que agregar mas info |
| 27/10/22 (Prof.) | Confirmé que se puede hacer búsqueda de señal de WiFi configurando WiFi como AP & STA | Puede ser incorporado al vehículo |
| 27/10/22 (Prof.) | Fue enviado por correo de plataforma que incorporen a la bitácora lo conversado en clase | Incorporar lo conversado |
| 27/10/22 | Respecto de el comportamiento anómalo del pin de entrada Vin encontramos que en realidad no tiene que ver con Vin al final; lo que estaba pasando es que usábamos el pin D4 conectado a un periférico que establecía un valor no bajo durante boot lo que frizaba la placa como se explica en esta página con la nueva organización de los pines ya todo arranca bien. | En breve hacemos un nuevo gráfico de conexiones |
| 27/10/22 | Sustituimos definitivamente el arduino uno ocupando su lugar con la WeMOS  WeMOS D1 r2: 
|
- |
| 27/10/22 | El lunes hablamos sobre los datos que se van a censar con la api. Decidimos almacenar la distancia recorrida, el historial de comandos y los AP cercanos. También hablamos de la base de datos, pensamos utilizar una MongoDB. | Para guardar la distancia recorrida necesitamos leer el encoder continuamente, para eso pensamos hacerlo por interrupción pero la primera vez que probamos no funcionó. Vamos a trabajar sobre eso. |
| 28/10/22 | El auto responde con delay a los comandos, a veces el delay es minimo y a veces es de ~1s. Esto empeora si se le mandan muchos comandos seguidos en poco tiempo | La pagina parece no ser el problema, ya que probamos con la antigua y pasa lo mismo, ademas el codigo no difiere mucho del original, pensamos que esto ya estaba pasando y no nos dimos cuenta. Por ahora le pusimos un timeout a las request pero tenemos que ver como podemos mejorar esta situacion |
| 31/10/22 (Prof.) | Es muy interesante esto que reportan/documentan sobre el delay de respuesta a los comandos, sobre todo que el delay no es "constante", lo cual puede indicar un posible bug que estaba desde la primera versión. No queda muy claro a qué se refieren con "timeout a las request"... | Mientras se responda a todos los comandos, el "bug" no es necesariamente crítico por el tipo de proyecto que estamos desarrollando (si no se entiende, consultar en clase). Con el objetivo de identificar mejor el posible problema, pueden documentar (puede ser con videos cortos, si es posible) en qué tipo de comandos o secuencias de comandos se dan los delays. También es bueno que miren en detalle en el código dónde aparecen llamadas a la función "delay()" para evaluar si tiene alguna relación con el delay en la ejecución de los comandos |
| 04/11/2022 | Probé leer el encoder por interrupciones con un arduino uno, primero hize un programa básico con un led y un botón y comprobé que la rutina de interrupción andaba bien. Después hice un programa que activa el motor, usa el encoder para el pin de la interrupción, dentro de la interrupción se incrementa una variable y en el main se escribe en el serial la variable cada un segundo (tuve en cuenta de no usar para el pwm el timer 0 que lo usa la función delay) y lo que encontré después de probar es que el encoder está mandando aproximadamente 500 pulsos por segundo cuando el motor no está girando. | Todavía no sé porqué será, estaría bueno poder ponerle un osciloscopio a la salida del encoder |
| 05/11/2022 | Ahora se escanean las redes wifi (SSID + RSSI), la info de las mismas se envia junto con la lista de comandos, el servidor se encarga de almacenarla sin que se repitan en la base de datos, ya que el micro las guarda repetidas en un vector | |
| 05/11/2022 | Para debuguear el encoder fuimos por partes. Primero saqué el encoder y lo probé con el mismo programa con el que ayer probé las interrupciones con el botón: código, funciona prefecto: video - Después para comprobar que no esté interfiriendo el PWM, agrego un led encendido con PWM y pruebo devuelta: código, video; sigue andando perfecto - Lo siguiente es agregar el motor y alimentar todo desde la fuente (el código es el mismo, el motor está conectado a los pines que antes estaba el led), encuentro que la vibración del motor causa que el encoder mande pulsos falsos: video - Luego de esto soplé el sensor infrarrojo (seguro solucionó todo) y lo puse devulta en su lugar pero agregué una espuma para amortiguar un poco la vibración, también cambié el código para que cambie el estado del led cada 30 pulsos (una vuelta) y probé, todo parece andar. código, video | Falta agregar el código a lo anterior y comprobar que funcione con todo conectado y además migrarlo a la wemos |
| 07/11/2022 | Descubrimos que el problema del retardo en la ejecución de las tareas era debido a la función pulseIn() que se encuentra en el pooling del sensor de proximidad. Esta función espera a que el pin de echo (Pecho) pase del estado bajo a alto, luego inicia un cronometro y espera nuevamente a un flanco de bajada, en este momento detiene el cronometro y devuelve el tiempo transcurrido. Debido a que a veces los obstaculos se encuentran a mas de 4 metros (maxima distancia medible por el sensor), la funcion pulseIn() se queda esperando la señal de rebote, la cual nunca llegará. La funcion tiene un parametro de timeout que indica el tiempo maximo que esperará el comienzo de dicha señal, por defecto este valor es 1 segundo. Nosotros no contemplabamos esta situacion y en muchas situaciones obteniamos latencias de alrededor de 1 segundos (que coincide con el valor por defecto antes mencionado). Al comentar el codigo del pooling vimos que el problema se arreglaba, con lo cual concluimos que la cuestion era esa. Para solucionar este inconveniente, colocamos un valor de timeout acorde al tiempo de ida y vuelta de la señal emitida. La ecuacion para encontrar ese valor sale de lo siguiente : (400cm(dist. max) * 1us / 0.0343cm(vel. sonido))*2 (ida y vuelta) = 23,32 ms ==> tomamos 30ms por si acaso para el timeout del echo... De esta manera el plazo maximo de ejecucion de la tarea de pooling del sensor de proximidad sera de alrededor de 30 ms. Documentacion sobre la funcion PulseIn: https://www.arduino.cc/reference/en/language/functions/advanced-io/pulsein/. La imagen  muestra el peor caso donde se ve que la distancia es 0 (porque se superó la maxima medible por el aparato, en este caso al vencer el timeout la funcion devuelve cero) y el tiempo de ejecucion de la funcion PulseIn() es 30204 us. Codigo de prueba prueba_sensor_prox.txt
|
- |
| 07/11/2022 | Codigo subido a la rama adapt-code-to-wemos, problema con el sensor de proximidad solucionado, se agregó timeout de 30 ms. | - |
| 08/11/2022 (Prof.) | Respecto del encoder: yo no "confiaría" en la amortiguación mecánica... quizás lo mejor (al menos por ahora) sigue siendo lo que estaba en el código original y conversamos en clase: descartar/"filtrar" por tiempo entre interrupciones o cambios de estado del pin que corresponde al encoder. Al margen: debo reconocer que soplar el infrarrojo es completamente original... | Sea con interrupciones o directamente con "polling" se deben descartar los pulsos/rebotes que no corresponden de acuerdo al tiempo entre orificios y la velocidad de giro de la rueda. Todo lo que no genere problemas de tiempo real/interferencias con otras actividades puede considerarse satisfactorio, solo documéntenlo |
| 10/11/2022 | Ya agregamos la interrupcion del encoder que permite calcular la distancia recorrida a la WeMOS (la habiamos probado en el Arduino), al principio la interrupcion generaba problemas y hacia que la placa se reinicie constantemente y no levante WiFi, lo solucionamos con la informacion que encontramos en esta página. Ademas, aqui aclaran que hay problemas con las interrupciones en los pines D3 y D4. En esta otra página tambien comentan sobre problemas con las interrupciones en ciertos pines, para tener en cuenta. | Quedaria agregar la funcionalidad para leer distancia y enviarsela al servidor |
| 12/11/2022 | El escaneo de WiFi ocupa bastante a la CPU, incluso configurandolo para que lo realice asincronicamente. Pudimos ver que en los momentos en los que escanea el wifi la placa responde con mucho retardo a los comandos, pero es por un periodo pequeño de tiempo (ademas la placa escanea cada 30 segundos el wifi, por lo que es poco probable que envies un comando justo cuando esta escaneando). En la siguiente imagen se puede ver la respuesta del servidor a los comandos, la que esta en rojo es en el momento en el que escanea. 
|
Como no hay mas forma de configurar lo que respecta al modulo de scaneo de wifi (lo maximo que pudimos hacer es establecer el escaneo de forma asincronica) suponemos que no queda otra que comerse ese retardo de vez en cuando |
| 18/11/22 (Prof.) | Dependiendo de cómo hayan implementado las respuestas HTTP, el tiempo de respuesta debería ser más "constante", en principio. Las diferencias pueden identificar algún problema posible de tiempo real... Un experimento interesante a realizar para comprobar que las variaciones son debidas al escaneo de wifi es: a) no iniciar el escaneo de wifi, b) tomar los tiempos de respuesta como los del 12/11/22, c) comparar ambos tiempos. Incluso para ser más específicos, pueden tomar los tiempos de la misma secuencia de comandos, con y sin búsqueda asincrónica de wifi | Experimentos de tiempos de respuesta para comparar y evaluar si realmente la búsqueda de wifi es la que introduce demoras "aleatorias" |
| 29/11/22 | Estuvimos revisando el código para confirmar que funcione todo bien y no haya errores, ya que agregamos ciertas funcionalidades como: escanear wifi cada 10 metros, guardar las fechas en formato legible (antes estaba en formato UNIX). | No encontramos problemas por el momento |
| 29/11/22 | Le cambiamos el chasis al auto y colocamos todos los modulos en una placa perforada, se redujo de esta manera el exceso de cableado:   Imagen del conexionado( + = 5V ):  Medidas:
|
- |