Control de Robot en Tiempo Real Desde el Navegador Con WebRTC

Hola, mi nombre es Nick Hare. Soy un defensor de desarrolladores senior en una empresa llamada Veeam, una plataforma para conectar a los desarrolladores de software con el mundo físico. Puedes encontrar mi handle y logo en línea en la mayoría de los lugares en Hipster Brown. Me gustaría comenzar diciendo que no tengo educación formal en ingeniería embebida, robótica, o incluso desarrollo de software. He aprendido de otros que han compartido su conocimiento a través de proyectos de código abierto, presentaciones en masterclasses locales y conferencias, y en línea a través de videos y publicaciones de blog, lo que me emociona mucho estar en una posición para compartir ese conocimiento con todos ustedes hoy y espero inspirarlos a construir su primer robot.

Ahora, cuando digo robot, ¿qué imagen viene a la mente? Al crecer, pensaba en robots como Rosie o C3PO y R2D2, o incluso Wall-E y Eve. Estos son ejemplos de máquinas autónomas, inteligentes, y a veces humanoides que existen en mundos imaginarios. Mirando el mundo hoy, hay algunos robots que coinciden con lo que hemos imaginado en varias formas, atlas, dígitos, incluso figura cero uno. Pero la mayoría de la producción de robótica está en forma de brazos industriales o rovers, o realmente solo varios actuadores y sensores combinados para realizar alguna tarea específica para ayudar y asistir a los humanos en completar sus trabajos para ser más eficientes, más seguros, y hacerlo desde cualquier lugar del mundo.

Y hay bastantes funciones robóticas que requieren monitoreo y control de esas máquinas desde lejos. Esto cae bajo la categoría de teleoperaciones o tele-op. Y esto podría incluir vigilar una flota autónoma de vehículos de entrega o coches autónomos y tomar el control si se pierden o entran en situaciones inesperadas. Podría ser pilotar vehículos que están en entornos que son inadecuados para la vida humana, como en las profundidades del mar, en el espacio, o en el desierto, o experiencias de telepresencia y telemedicina. También se puede usar para crear arte único como el telegarden. Incluso esos robots humanoides más avanzados actualmente dependen de un humano en el bucle para funcionar.

Ahora, algunos robots se comunican con servidores remotos en entornos de nube. Algunos están confinados a la red local. Y otros se comunican directamente entre sí. Pero, ¿qué tipo de tecnología y protocolos podrían soportar la conexión a una máquina desde cualquier otro mundo sin exponerla a Internet público? Bueno, como se indica en el título de esta presentación, estamos hablando de WebRTC. Y probablemente hayas oído hablar de ello antes y lo hayas utilizado en alguna aplicación construida con él.

Ahora, como el nombre indica, fue construido alrededor de navegadores y proporcionando una plataforma para conectar a los clientes directamente sin necesidad de relays a través de algún tipo de aplicación de servidor central o compartido, que podría ser requerido al usar algo como WebSockets. Debido a su legado vinculado a voz sobre IP y videoconferencias, WebRTC se utiliza en gran medida para esa función exacta. Todos hemos pasado por nuestra buena parte de Skype, RIP y llamadas de Hangouts, Zoom y Teams a lo largo de los años. Algunos de nosotros incluso hemos pasado por un tutorial de mensajería de chat entre pares en el pasado también.

Pero esas son realmente solo las capacidades que WebRTC tiene para ofrecer. ¿Qué pasaría si un par no fuera otro humano, sino una máquina respondiendo la llamada? ¿Cómo podría esto ser posible? ¿El robot abre un navegador web y hace clic como algún tipo de agente de IA? Bueno, ¿y si pudiéramos usar las APIs y protocolos de WebRTC que típicamente se encuentran en el navegador, pero en un servidor, es decir, nuestro robot? WebRTC es realmente solo un conjunto de tecnologías acrónimas que permiten enviar audio, video y datos arbitrarios directamente entre dos clientes o pares. Y esto quiere decir que la mayoría de los dispositivos de computación y lenguajes de programación tienen alguna forma de trabajar con los protocolos base de IP y UDP.

Y así, las capas superiores solo necesitan ser implementadas para soportar el uso de WebRTC en esos entornos. Y existen varios proyectos para proporcionar eso hoy. A un nivel relativamente bajo, está la biblioteca libpeer escrita en C. Hay algunas opciones para Node.js y algunos proyectos maduros para Python, Go y Rust.

Genial. Así que parece que podemos usar WebRTC en el servidor, pero ¿cómo lo usamos realmente para conectar con nuestro robot? Bueno, para que WebRTC funcione, se requiere Stun para descubrir la dirección IP y el puerto de cada par desde la perspectiva de Internet público. Es como usar un satélite GPS para ver dónde estamos en relación con el mundo entero en lugar de solo lo que vemos a nuestro alrededor.

Durante este proceso, el cliente también puede reunir métodos potenciales para conectarse a cada par a través del Establecimiento de Conectividad Interactiva o candidatos ICE. Si no pueden conectarse directamente entre sí debido a restricciones como cortafuegos, los clientes pueden recurrir a usar TURN o servidores de retransmisión. Ahora, esta es una opción de último recurso ya que añade latencia a la conexión, costos de mantenimiento y un posible punto de falla para la experiencia. Durante este proceso de recopilación de información de Stun e ICE, dos pares necesitan la forma de compartir esa información entre sí antes de que se pueda establecer una conexión directa.

Y esto se conoce como señalización. Sin embargo, la especificación en sí no requiere ningún detalle sobre cómo llevar a cabo la señalización. Y así, esto es una especie de espada de doble filo al intentar construir una aplicación peer-to-peer. Así que la mayoría de ellos tendrán algún tipo de componente del lado del servidor que retransmite mensajes entre los pares usando web sockets o incluso llamadas HTTP simples. Cualquier método o tecnología que uses, solo necesita haber alguna forma para que dos o más pares establezcan una conexión e intercambien esa información inicial para que suceda.

Una vez que están conectados, entonces se puede usar un canal de datos compartido para una mayor negociación en el proceso. Entonces, ¿cómo funciona esto para un robot? Conceptualmente, tratamos nuestro servidor, como nuestro robot, como un respondedor listo para recibir llamadas. Un cliente, como nuestro navegador, es un llamador. El servidor de señalización empareja llamadores con respondedores para que puedan intercambiar información y esperar establecer una conexión. Así que cuando un robot está activo y en línea, informará al servidor de señalización cuando esté disponible para recibir llamadas. Cuando una aplicación cliente llama a un robot a través del servidor de señalización, entonces el programa en el robot aceptará esa oferta, proporcionará una respuesta y escuchará cualquier canal de datos que se abra para establecer esos patrones de comunicación adicionales.

Muy bien. Entonces, ¿qué hacemos una vez que tenemos esa corriente de datos disponible? Podríamos enviar mensajes de cadena arbitrarios, incluso stringify JSON, y asegurarnos de que nuestro robot sepa cómo responder a cada mensaje. Sin embargo, esto sería bastante tedioso y propenso a errores a medida que construimos tanto la lógica del robot como la aplicación web. Ayudaría tener algún tipo de formato estructurado para enviar comandos desde la aplicación cliente que se ejecuten en el robot sin especificar, ya sabes, qué son exactamente o incluso solo poder especificar la respuesta esperada para cada comando. Ahora, este es un caso de uso perfecto para llamadas a procedimientos remotos o RPC. Básicamente, esto proporciona una especificación de una forma agnóstica de comunicarse entre servidores y clientes que crea una especie de fachada que parece que estás llamando a un método en el cliente que se ejecuta en el servidor sin realmente preocuparte de cómo esos datos llegan allí y de vuelta.

Es posible que hayas oído hablar de frameworks RPC explícitos como gRPC, tRPC y JSON-RPC, donde el servidor y los clientes están claramente definidos. Algunos usos implícitos de RPC están ganando popularidad para aplicaciones de JavaScript de pila completa llamados acciones o funciones del servidor, y estos están muy acoplados con HTTP. En nuestro caso, queremos algo que pueda adaptarse a nuestro canal de datos bidireccional, y esa es la transmisión que proviene de nuestra conexión peer-to-peer. Genial.

Con todos los requisitos establecidos, construyamos una prueba de concepto utilizando JavaScript de pila completa. Estableceremos esto y lo lograremos utilizando principalmente APIs integradas para el navegador y Node.js junto con algunos paquetes. Lo desglosaremos pieza por pieza antes de juntar todo, comenzando con la señalización. En lugar de construir y alojar un servicio personalizado para realizar esta tarea, quería centrarme solo en nuestro código peer. Así que, he optado por una solución suficientemente buena para la mensajería PubSub llamada Notify. Este es un servicio de código abierto que proporciona una API REST para enviar y recibir mensajes sobre temas específicos. No se requiere registro.

Y Notify tiene algunas formas programáticas de suscribirse a mensajes a través de su API, utilizando ya sea puntos finales HTTP o WebSockets. Puede parecer natural usar WebSockets, pero realmente solo se utilizan para suscribirse a temas en lugar de la conexión bidireccional para la que normalmente los usamos. Así que, esto es un poco más de sobrecarga de la que me gustaría para mi prueba de concepto. Me quedaré con uno de los puntos finales HTTP para adaptarse mejor a mis necesidades. Ahora, los eventos del lado del servidor son una buena manera nativa del navegador de suscribirse a mensajes a través de HTTP. Sin embargo, necesito algo más para Node.js si no quiero agregar otra dependencia más. ¿Qué tal los flujos JSON?

El objeto de respuesta de hacer una solicitud fetch puede tener una propiedad body que implementa un flujo de bytes. Y podemos canalizar ese flujo a través de algún tipo de transformación para convertirlo en texto UTF-8. Y podemos analizar esas cadenas JSON en los objetos de mensaje que están definidos por Notify. Y podemos envolver todo esto en una especie de clase notificador que proporciona todas las diferentes cosas relacionadas con suscribirse a mensajes, cancelar suscripciones e incluso publicarlas.

Y con nuestro método de señalización en su lugar, echemos un vistazo a establecer nuestra conexión WebRTC. Así que, necesitamos nuestra clase RTC peer connection de nuestro paquete Node.js o globalmente en el navegador. Y si solo necesitáramos conectarnos a dispositivos en la misma red, realmente no hay necesidad de servidores stun o turn bajo este conjunto de servidores ice que vemos cuando estamos creando nuestra nueva conexión peer. Pero eso no es muy útil para una demostración realista. Solo se necesita uno de estos servidores stern. Así que, la mayoría de las aplicaciones usarán los públicos de Twilio o Google.

Desde esa conexión peer, creamos nuestro canal de datos para enviar y recibir mensajes directamente entre cada par. Este canal de datos creativamente nombrado con la etiqueta de data está configurado como un canal negociado, donde el ID acordado se establece fuera de banda. Y lo que realmente significa es que está codificado en nuestro programa, ya que sabemos que siempre debería haber un solo canal con esta etiqueta. Y aquí es donde divergimos entre nuestro robot y nuestra aplicación web. Como se mencionó anteriormente, el cliente actúa como un llamador y el robot responde si está en línea. Así que, el cliente crea una oferta para conectarse. Y esto se establece como la descripción local antes de enviarlo al robot a través de nuestro servicio de señalización.

Y esto se establece como la descripción local antes de enviarlo al robot a través de nuestro servicio de señalización. Afortunadamente, la mayoría de los objetos en esta API tienen un método JSON dos para portabilidad a través de servicios de señalización. El robot recibe ese mensaje para establecerlo como su descripción remota antes de crear una respuesta para establecerla como su descripción local y luego enviarlo a nuestra aplicación web. Para completar esta parte del intercambio, la aplicación web maneja nuestra respuesta y la establece como su descripción remota. Durante todo esto, comenzamos a compartir y establecer candidatos ICE. Así que, la aplicación web llamadora escuchará este evento de candidato ICE que indica cuándo se ha identificado un nuevo candidato y se ha agregado a la conexión peer local. El llamador enviará esa información al robot a través de nuestro servicio de señalización. Y esto puede suceder varias veces a lo largo del proceso, hasta que nuestro estado de conexión ICE esté conectado. Y si un candidato es nulo en el objeto de evento, entonces esto indica que la recopilación de candidatos ICE está completa. En el robot, verifica este candidato en nuestro mensaje y lo agrega a la conexión peer local. Y esto señalará al proceso interno que intente conectarse utilizando esos detalles. Ahora, los pares utilizarán toda esta información para, con suerte, conectarse entre sí y llevar a un estado de conexión ICE de completado. Al mismo tiempo, esto debería alinearse con un evento abierto que ocurre en nuestro canal de datos para comenzar a permitir que los pares se comuniquen a través de ese transporte.

Con nuestra sesión WebRTC en su lugar, veamos cómo construir nuestro marco RPC a su alrededor. El paquete JSON RPC 2.0 proporciona nuestras clases de cliente y servidor agnósticas al transporte para enviar y recibir comandos, así como algunas interfaces de TypeScript para aquellos de nosotros que queremos asegurar cierta consistencia. Crearemos un servidor de robot y un cliente de robot y utilizaremos el canal de datos para enviar cualquier solicitud RPC a través de esa transmisión. El canal de datos puede escuchar nuevos mensajes para analizarlos como solicitudes RPC y reenviarlos a nuestro servidor y luego otras respuestas RPC para reenviarlas al cliente. Muy bien, y ahora tenemos nuestro marco de comunicación listo para funcionar. Ahora, solo necesitamos controlar nuestro hardware. Johnny 5 comenzó como una forma de escribir JavaScript para controlar varias placas Arduino a través de conexiones de puerto serie. Proporciona clases abstractas para controlar todo tipo de componentes físicos de la misma manera que jQuery proporcionó abstracciones sobre inconsistencias en las API de los navegadores. Desde su creación, el núcleo se ha ampliado a través de complementos de IO, extendiéndose para soportar todo tipo de plataformas de hardware, incluyendo computadoras de placa única basadas en Linux como la Raspberry Pi. Muy bien, creo que ahora tenemos todas las piezas que necesitamos para controlar nuestro robot en tiempo real desde el navegador. En mi escritorio a mi derecha, tengo una cámara sobre una Raspberry Pi con un LED conectado a ella. Podemos ver en nuestra aplicación web, tengo la capacidad de conectarme a un robot que he llamado Robot Dev. Ahora, el lado del servidor de nuestro proceso se está ejecutando en mi Raspberry Pi en Node.js, y esto se está ejecutando en GitHub pages en el navegador. Puedo presionar conectar y vemos que nos hemos conectado a nuestro robot. Puedo presionar conectar y vemos que nos hemos conectado a nuestro robot. Eso es bastante rápido y sin problemas. Pero podemos ver desde aquí todos los diferentes mensajes que ocurrieron para hacer que eso sucediera.

Así que tenemos ofertas. Tenemos todos nuestros estados de señalización sucediendo, nuestros candidatos de recolección de ice. Podemos ver que los estamos enviando al servidor. Y eventualmente obteniendo algunas respuestas también. Con suerte, llevando a nuestros estados y conexiones de señalización estables, viendo que nos hemos conectado. Y eventualmente teniendo nuestro canal de datos abierto.

Y ahora que tenemos nuestro canal de datos, podemos enviar nuestro comando para parpadear el LED. Esto es básicamente el hello world del hardware, que es parpadear un LED. Lo vemos sucediendo en nuestra transmisión de cámara a nuestra derecha. Esto es genial. Me alegra poder verlo en la misma habitación que yo. Pero, ¿qué pasaría si quisiera verlo en otro lugar del mundo?

Bueno, usemos lo que WebRTC tiene para ofrecer, que es la transmisión de video. Tengo una cámara web conectada a nuestra Raspberry Pi a través de USB. Y así puedo comenzar a enviar esa transmisión de video desde la Raspberry Pi a mi navegador. Puedo iniciar mi video. Ahora podemos ver que lo mismo está sucediendo en nuestra cámara superior, directamente desde la cámara web USB conectada a la Raspberry Pi.

Esto es genial. Hemos terminado lo básico. Pero, ¿qué tal algo un poco más realista? Bueno, en la ciudad de Nueva York, la oficina de VM tiene un juego de garra. Y este juego de garra es un recinto que tiene una cámara arriba, adjunta al techo, así como una cámara web USB adjunta a la garra misma. Y este brazo robótico se puede usar para moverse y luego recoger bolas y dejarlas de nuevo en su lugar como cualquier otro juego de garra.

Y tenemos una aplicación web de TypeScript que se puede usar para controlarlo. Así que puedo ir y elegir una coordenada dentro de nuestra máquina de garra. Y podemos ver que sucede desde 20 millas de distancia que la garra comienza a moverse después de recibir esta solicitud. La cámara IP es un poco más lenta para actualizarse solo por las tasas de fotogramas. Y luego puedo solicitar que vaya y recoja una bola y regrese a la ubicación.

Y todo esto se extrae a través de APIs de TypeScript. Podemos ver que recoge una bola. Tuvimos un poco de suerte esta vez. Solo porque es un brazo robótico no significa que el juego de garra siempre tendrá éxito. Y traerlo de vuelta a nuestro contenedor. Y eventualmente dejarlo en su lugar. Ahora, puede que no te sorprenda saber que esta es exactamente la forma en que VM permite a los desarrolladores construir robots y otro tipo de máquinas inteligentes, junto con un montón de otras características.

El kit de desarrollo de robots es el núcleo de código abierto de este producto. Y está respaldado por los servicios en la nube para configurar, controlar y monitorear tus máquinas individuales o múltiples en el campo. El SDK tipo dos, como lo demostré con esa aplicación web, se utiliza para controlar máquinas activas, flujos de cámara o incluso consultar datos de sensores desde el navegador o entornos de Node JS. Cuando termines de revisar el código, puedes probar VM en el navegador sin necesidad de hardware en mano.

Puedes alquilar un rover gratis por un corto período de tiempo. Obtienes la experiencia de controlar, programar o incluso entrenar un robot desde la comodidad de tu computadora. Espero que estés suficientemente motivado para construir un robot para ti mismo. Así que la documentación de VM es una gran manera de inspirarte y aprender cómo hacer realidad tu idea. O explora nuestros laboratorios de código para tutoriales de extremo a extremo de todo tipo de conceptos, desde automatización de hardware hasta visión por computadora y control por voz. Puedes explorar el código de demostración de esta charla en GitHub. Gracias por escuchar. Y puedes ver lo que la comunidad desarrolladora de VM está construyendo uniéndote a nuestro Discord. Escanea el código QR para mantenerte al día con lo que estamos trabajando en VM, junto con las últimas noticias de la industria. Puedes conectarte conmigo en LinkedIn en Nick Hur o en Hips Around Most Anywhere Else. Feliz construcción.