¡Robot Araña Hexagonal revisado!

Para Google I / O este año, utilicé la biblioteca JWT de Google Cloud Arduino para producir una demostración en la que algunos pequeños robots araña hexbug se controlaron mediante Google Cloud IoT Core. Puede leer la publicación de mi blog para obtener más información sobre lo que se debe y no se debe hacer para la demostración y también puede ver la presentación completa en YouTube:

La demostración se limitó de varias maneras, la mayoría de n o tably la biblioteca funcionaba sobre HTTP en lugar del protocolo MQTT más receptivo. A partir de la versión de Arduino v1.0.5 y posteriores, ahora hay un cliente MQTT que funciona con la placa Esp8266. Para la ciencia, decidí migrar la demostración a la biblioteca actualizada. Esta publicación cubrirá mis observaciones.

La migración

Pude migrar el código HTTP a MQTT en menos de una hora gracias a haber participado en las actualizaciones de la biblioteca y estar familiarizado con el código Hexspider. Podría enumerar todos los cambios en las esencias, pero probablemente le resulte más fácil seguirlos si echa un vistazo a las diferencias en esta solicitud de extracción.

El primer cambio fue eliminar el encabezado HTTP y colocar el encabezado MQTT de los ejemplos de Esp8266. Esto requirió cambios en el archivo .ino principal del proyecto para eliminar el método de configuración HTTP ( setupWifi ) y agregar dos nuevos métodos de configuración:

El siguiente cambio fue eliminar la función de sondeo, getHexConfig , y reemplazarla con un captador para la respuesta actualizada devuelta por MQTT. También agregué un método de devolución de llamada, spiderMessage , y lo agregué al código MQTT. La devolución de llamada se activará cada vez que el puente MQTT de Cloud IoT envíe un mensaje MQTT. Debido a que el mensaje ya no necesitaba ser decodificado en base64 (vienen como texto para MQTT), pude reemplazar el analizador con String.toInt . El único problema fue que la implementación de Arduino de toInt devuelve 0 en caso de falla, un código de mensaje que ya estaba usando. Incrementé los códigos de mensaje y luego pude usar 0 para indicar falla.

Después de realizar todos los cambios de protocolo en la demostración, los mensajes de registro se volvieron demasiado frecuentes, así que los eliminé. Además, el robot se volvió demasiado receptivo al transmitir sus datos de telemetría (el tiempo para grabar y transmitir la telemetría después de mover la cabeza del robot dependía de la latencia HTTP), por lo que agregué un retraso de 200 ms después de transmitir los códigos IR para girar la cabeza del robot.

Con todos estos cambios implementados, la demostración volvió a funcionar y se ejecutó en MQTT.

Los resultados

En el siguiente videoclip, puede ver algunos aspectos destacados de las mejoras de rendimiento al usar MQTT en lugar del sondeo HTTP:

En los primeros 15 segundos aproximadamente del video, los robots no están conectados a los controladores. El robot con sombrero de plumas usa MQTT, el sombrero cuadrado es HTTP. Si observa los patrones de parpadeo en los sombreros, el LED del robot de cabeza cuadrada parpadea con menos frecuencia y tiene puntos en los que el LED permanece encendido. Cuando el LED del robot HTTP está encendido, es porque el punto de encendido del LED es antes de que el robot devuelva la solicitud de extracción de configuración. Observe cómo el robot MQTT parpadea de forma rápida y constante; esto se debe a que las actualizaciones de MQTT se realizan de forma asincrónica y rara vez bloquean la ejecución del código del robot.

En la siguiente sección del video, los robots están completamente conectados y responden a los cambios de configuración enviados a los dispositivos. Ambos robots responden al cambio de configuración inicial, pero hay un retraso notable entre los tiempos de respuesta de los dos robots en el segundo cambio de configuración. Esto se debe a que la solicitud anterior bloqueó el robot HTTP mientras se producía el cambio de configuración.

Conclusiones

Si está usando HTTP en un dispositivo que podría estar usando MQTT, realmente debería considerar cambiar. La capacidad de codificación de MQTT es simplemente mejor porque elimina la preocupación de rastrear si se transmitió una nueva ID de configuración a su dispositivo y le permite alejarse del sondeo para un mejor rendimiento. Ya no es necesario crear una nueva conexión para transmitir datos de telemetría, lo que también mejora el rendimiento del dispositivo.

Para mejorar aún más la capacidad de respuesta de la demostración, puede migrar el código para utilizar en su lugar la función beta de Comandos, que permite actualizaciones mucho más frecuentes en su dispositivo y no sobrecarga la funcionalidad de configuración del dispositivo. Si realmente quisiera apostar por el rendimiento, podría usar un microcontrolador de doble núcleo y dedicar uno de los núcleos a manejar la comunicación MQTT y podría ver un aumento significativo en la capacidad de respuesta de sus robots a través del cable.

Actualización : a partir de 2018-12-05, la función de comandos está disponible de forma general.