Repository navigation
Objetivos y problemas encontrados
Todos estos problemas, se exponen junto con la solución encontrada para cada uno de ellos, sin embargo se implementarán los cambios en futuras versiones.
Problema: a la hora de realizar el diseño, se crean unos guardabarros laterales que finalmente no se incluyen en el proyecto final. Esto es debido a un problema de medidas, ya que en diseño no se tuvo en cuenta la altura de las cadenas de la oruga
Solución:
Rediseño de piezas para poder elevar ligeramente los guardabarros.
Problema:
Debido al diseño del Hardware, los cables salen del interior del tanque por la parte trasera y tienen que recorrer una distancia determinada para conectarse a los diversos actuadores. Sin embargo el cable que llega a la ESP32, a pesar de poder conectarse sin problema, es al girar el servo cuando el cable empieza a tensarse. No es lo suficientemente largo como se tenía en cuenta en un principio.
Esto también está relacionado en parte a un error de medida en la abertura mostrada en la siguiente foto:
La idea inicial del diseño consistía en que el cable de la ESP32 se introdujera por ese hueco junto al del servo que sale del interior de la pieza, sin embargo, el extremo blanco de plástico del cable tiene una distancia mayor a la de la obertura del hueco. Es por ello por lo que se ha encontrado un hueco para pasar el cable en la parte superior, aprovechando el diseño de la pieza del kit. Sin este problema, el cable podría realizar más recorrido.
Solución:
Se pueden realizar diversos cambios en el diseño, el más evidente sería rediseñar la pieza y agrandar este hueco. Sin embargo, si se quiere que la torreta pueda girar sin problemas, los cables tendían que salir del centro del chasis, muy cerca del servo para permitir un mayor recorrido de giro. Por lo que se tendría que rediseñar la pieza y crear un agujero nuevo.
Problema:
Debido a un fallo de la impresión 3D, la medición de los agujeros a los que se atornilla la ESP32, no coincidía con la del soporte de la propia cámara. Es por esto por lo que no se encontraba forma de usar ningún tipo de tornillo ya que, a pesar de atornillarse al soporte de la cámara, no podían sujetarse a la torreta debido a que los agujeros de la torreta eran demasiado grandes en comparación.
Solución:
Se emplea como sujeción de la cámara, el hueco resultante entre las torretas y la parte trasera de la torreta, además del uso de dos piezas 'pin.stl' que actúan como una especie de tornillos. Evidentemente, esto es una solución improvisada, la solución óptima consiste en el rediseño de la pieza para que esta parte trasera de la torreta sea algo más fina y los tornillos puedan entrar mejor, además del correcto tratamiento de la pieza para la impresión 3D, de esta manera esos orificios medirán lo mismo que los del soporte de la cámara.
Problema:
Debido a la orientación del servo, tal como vemos en las especificaciones del datasheet del servo
El servo SG90 está diseñado para seguir señales de PWM (modulación por ancho de pulso), donde el rango de pulsos es de 1 ms a 2 ms. Esto corresponde al movimiento de 0 a 180 grados.
- 1 ms (~1.0 ms): Mueve el brazo del servo a la posición más a la izquierda (aproximadamente -90° en el rango del servo).
- 1.5 ms: Coloca el brazo del servo en el centro, que se denomina posición "0°" o posición media.
- 2 ms (~2.0 ms): Mueve el brazo del servo a la posición más a la derecha (aproximadamente +90°).
Tal y como se ha implementado el diseño de la pieza a la que se une nuestro servo, en el momento de seguir personas, solo opera en su lado derecho, es decir, solo puede girar desde el apuntado hacia delante, hasta el apuntado atrás del todo. Sin embargo solo se realizan los giros por el lado derecho.
Solución:
Este problema puede tener diversas soluciones, las cuales todas llegan al mismo resultado: orientar el servo para que cuando apunte recto, este sea el punto medio y desde ahí, 90º a cada lado.
La solución más óptima consistiría en girar la pieza sobre la que se atornilla el servo, para ello habría que rediseñar esta pieza y situar los huecos de tornillos en los lugares necesarios, una vez sea rotada 90º.
En un primer momento, nuestra idea era que el robot estuviera teleoperado y detectando personas al mismo tiempo. Sin embargo, al intentar mezclar estos códigos no funcionó. Inicialmente pensábamos que era porque la placa ESP32 no soportaba WiFi y Bluetooth al mismo tiempo. Pero al buscar en la hoja de especificaciones de esta placa, vimos que ambos protocolos estaban soportados de forma simultánea.
Tras esto, nos pusimos manos a la obra para intentar remediar el problema. En este proceso, nos dimos cuenta de que el problema venía a raíz de que las bibliotecas de Bluepad32 y la biblioteca del WiFi no son compatibles, ya que, cuando intentas usar el Bluetooth con el WiFi, este no envía imagen, y si intentas usar el WiFi con el Bluetooth, da un error al flashear el código a la ESP32. Esto ocurre porque, al flashear los códigos a la placa, en la configuración de la misma tienes que seleccionar una distinta en cada caso.
Para esta versión del código, aún no hemos encontrado ninguna solución aplicable. Pero está previsto para futuras versiones el desarrollo de una librería única capaz de conectarse a controladores remotos y transmitir imágenes de forma simultánea.
