Despois de implantar o 100o dispositivo de recollida de datos wearable, o noso tubo de datos de robótica comezou silenciosamente a envenenarse. No mundo da robótica de IA, os datos son o novo petróleo.Para a robótica de IA, ese petróleo pode provir de dispositivos de recollida de datos wearables implantados en fogares do mundo real.Estas "luvas" capturan datos de manipulación bimanual de alta fidelidade que se usan para adestrar a próxima xeración de robots alimentados por IA. O noso proceso de fabricación foi unha confusión de guións de Python esbozados, ficheiros YAML manuais e, o peor de todo, firmware personalizado para cada guante. Aquí está como usei e para pasar dun proceso fráxil e só de enxeñeiros a un ciclo de vida de DevOps de hardware que mellorou directamente a taxa de éxito da tarefa do noso robot. Webserie Páxina web O pesadelo "hardcoded": por que o firmware como identidade falla No momento en que me unín ao equipo, o noso proceso de rexistro para estes dispositivos de recollida de datos wearables era fundamentalmente inescalable: 
 
 
 
 
 
 Conectar o portátil a un PC. Execute un script de Python (dependendo de ambientes locais e controladores específicos). Modifique o código de firmware en C para incluír os metadatos específicos do dispositivo (ID de hardware, versión de hardware, versión de firmware e se o dispositivo é esquerdo ou dereito). Compromete manualmente os ID de hardware e os datos de calibración nun repositorio de Git usando ficheiros YAML. Construír e flash un binario único e único para ese dispositivo específico. O impacto dos erros humanos Este proceso foi un alicerce para as inconsistencias. enfrontámonos a cadeas de versións malformadas, IDs de hardware duplicados e metadatos incorrectos.No mundo do hardware, estes non son só bugs, senón veleno de datos. Cando un guante nunha casa a 2.000 millas de distancia envía datos cunha cadea de versión mal formada, as nosas canles de IA descendentes rompen. atopámonos escribindo scripts de limpeza de datos hacky só para facer que os datos recollidos sexan usables. O cambio arquitectónico: a web como "ferramenta de fábrica" O momento que me tocou foi cando aprendín que había e máis API dispoñible en navegadores web baseados en Chromium que permiten que o front-end da web se comunique con dispositivos conectados a USB. Tamén me dei conta de que o firmware estaba a facer un traballo que non ten negocio. Metadatos como versións de hardware e datos de calibración poden ser almacenados na nube e recuperados dinamicamente a través de chamadas de API seguras cando sexa necesario. Tamén mudamos a un modelo onde cada luva executa exactamente o mesmo firmware, e o navegador web actúa como a ponte entre o hardware físico e a nosa infraestrutura de nube. Webserie Páxina web Software de fabricación de instalación cero e implantación global instantánea Usando a API WebSerial, eliminamos o problema "non funciona na miña máquina".Os nosos equipos de fabricación e QC xa non precisan xestionar ambientes ou controladores de Python. Simplemente abren unha URL en Chrome, conectan o guante e o navegador xestiona a comunicación de baixo nivel co PCB personalizado no guante. Debido a que toda a interface é unha aplicación de páxina única (SPA), agora xestionamos a nosa liña de montaxe física coa mesma axilidade que o noso software en nube. Usamos pipelines CI/CD estándar para desencadear construcións e desprazalos a un aburrido provedor de aloxamento de ficheiros estáticos. Se melloramos un algoritmo de calibración ou engadimos unha nova comprobación de QC, simplemente empuxamos o código e deixamos que as pipelines automatizadas fagan o resto. Os técnicos que traballan na liña de montaxe non precisan ter acceso ao reposto de Git. Simplemente refrescan a páxina web para obter a última versión aprobada pola enxeñaría da nosa ferramenta de fabricación. Esta mudanza permitiunos escalar ata un equipo de fabricación interno de 7 persoas sen fondo de codificación, o que sería imposible se cada unidade requirise un enxeñeiro para construír manualmente e flash firmware único. A ponte de identidade: WebSerial atopa a WebUSB Pensei que WebSerial era todo o que necesitaba, pero descubrín que non funcionaba como esperaba debido a unha limitación técnica: WebSerial só non pode recuperar o número de serie USB. Para lograr a verdadeira provisión de "un clic", desenvolvín un enfoque heurístico híbrido para conectar dúas APIs independentes. Usando unha estratexia de "reclamación e proba", poderíamos comprobar se o usuario seleccionou o mesmo dispositivo físico en ambos os prompts WebUSB e WebSerial. A continuación está un exemplo de como podes lograr isto nun caso simple (eu realmente o fixen dun xeito máis fácil de usar e máis integrado cos nosos fluxos de traballo específicos, pero esta é unha ilustración do concepto). async function openUsbSerialPort(
  interfaceNumber: number,
  serialOptions: SerialOptions
): Promise<[USBDevice, SerialPort]> {
  // 1. let the user pick a USB device and claim the interface for serial communication
  const device = navigator.usb.requestDevice();
  await device.open();
  await usbDevice.claimInterface(interfaceNumber);

  // 2. let the user pick a serial port
  const port = await navigator.serial.requestPort({
    filters: [{ usbVendorId: usbDevice.vendorId, usbProductId: usbDevice.productId }]
  });

  // 3. Test: If the user selected the same device, we shouldn't be able 
  // to open the serial port yet because it's already claimed.
  const serialPortOpened = await port.open(serialOptions).then(() => true).catch(() => false);

  if (serialPortOpened) {
    await port.close();
    throw Error("Selected different devices");
  }

  // 4. Match confirmed. Release and open for real.
  await usbDevice.releaseInterface(interfaceNumber);
  await port.open(serialOptions);

  return [device, port];
}
 Isto non está documentado en ningures.É un pouco de hack, pero funciona e permítenos conectar automaticamente o hardware físico ao seu rexistro de nube específico sen que o operador necesite seleccionar ou escribir manualmente un número de serie. Desconectar a identidade do firmware En lugar de descargar metadatos únicos en cada unidade, a solución baseada na web revolucionou o fluxo: 
 
 
 
 Recoñecemento de identidade: O navegador identifica a unidade usando o número de serie USB a través da heurística WebUSB/WebSerial. Manter os metadatos na nube: Durante o proceso de rexistro, ese identificador único xunto cos metadatos asociados son cargados a unha base de datos na nube durante o proceso de rexistro. Recuperación a petición: cando se implementa o guante, calquera aplicación ou servizo pode usar unha API para recuperar os metadatos por ID de forma dinámica. O firmware permanece parvo e fiable, mentres que a nube serve como a única fonte de verdade. Resultados: datos máis limpos, mellores robots O cambio a un modelo de DevOps de hardware centrado na web foi transformador: 
 
 
 
 Operacións democratizadas: Un equipo interno de 7 agora xestiona todo o proceso de rexistro e QC, liberando centos de horas de enxeñaría. Integridade de datos: Eliminamos os encabezados malformados e os erros de metadatos.O noso tubo de datos é agora "limpo por deseño" en todas as 2.000 unidades. Taxa de éxito de tarefas: A calibración precisa e consistente en toda a frota levou a un aumento mensurable no rendemento dos nosos modelos de manipulación bimanual. Conclusión Se está escalando hardware IoT ou Robotics, trate os navegadores web como o seu orquestrado de procesos. Ao combinar WebSerial e WebUSB con CI / CD web estándar, pode romper a brecha entre o hardware e a nube, asegurando que cada unidade de hardware sexa tan áxil e actualizada.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Este audio está producido na lingua orixinal da historia!

Como fixen a fabricación para a robótica de IA con WebSerial

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Web3 Community!

HackerNoon Decoded 2024: Celebrating Our Remote Work Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

R Systems BlogBook—Chapter 1: Round 3 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Web3 Community!

HackerNoon Decoded 2024: Celebrating Our Remote Work Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

R Systems BlogBook—Chapter 1: Round 3 is Now Open for Submissions🎉

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps