След разгръщането на 100-то устройство за събиране на носими данни, нашият роботизиран тръбопровод за данни тихо започна да се отравя. За AI Robotics, това масло може да идва от носими устройства за събиране на данни, разгърнати в реални домове.Тези "ръкавици" улавят данни за висококачествени бимануални манипулации, които се използват за обучение на следващото поколение роботи, задвижвани от AI. Въпреки това, тъй като скалирахме от 10 прототипа до 2000 единици, ударихме стена.Нашият производствен процес беше бъркотия от скицирани Python скриптове, ръчни YAML файлове и, най-лошото от всичко, персонализиран фърмуер за всяка една ръкавица. Ето как се използва и да преминем от крехък, само от инженери процес към безумен хардуер DevOps жизнен цикъл, който директно подобри нивото на успеваемост на задачите на нашия робот. Уебсайт Уебсайт Кошмарът "Hardcoded": Защо фирменият софтуер като идентичност се проваля Когато се присъединих към екипа, нашият процес на регистрация за тези носими устройства за събиране на данни беше фундаментално мащабен: 
 
 
 
 
 
 Свържете устройството към компютър. Изпълнете Python скрипт (в зависимост от конкретните локални среди и драйвери). Модифицирайте кода на фърмуера в C, за да включите специфичните метаданни на устройството (Hardware ID, хардуерна версия, версия на фърмуера и дали устройството е ляво или дясно). Ръчно извършване на хардуерни идентификатори и данни за калибриране в Git хранилище с помощта на YAML файлове. Създайте и флаш уникален, еднократен двоичен за това конкретно устройство. Въздействието на човешките грешки Този процес беше поле за размножаване на несъответствия. Ние се сблъскахме с неправилно оформени версии, дублирани хардуерни идентификатори и неправилни метаданни. В хардуерния свят това не са просто бъгове, а отрова за данни. Когато ръкавица в дом на разстояние 2000 мили изпраща данни с неправилно оформена версия, нашите по-нататъшни AI тръбопроводи се счупват.Намерихме се да пишем хакерски скриптове за почистване на данни, само за да направим събраните данни използваеми.По-лошото, неправилните данни за калибриране пряко засягаха моделите, които обучавахме мълчаливо, намалявайки успеваемостта на задачата без очевидни признаци за това, което се обърка. Архитектурната промяна: Интернет като "фабричен инструмент" Моментът, в който кликна за мен, беше, когато разбрах, че има и API, наличен в уеб браузъри, базирани на Chromium, който позволява на уеб фронта да комуникира с устройства, свързани с USB. Също така осъзнах, че фърмуерът върши работа, която няма бизнес. Метаданни като хардуерни версии и данни за калибриране могат да се съхраняват в облака и да се извличат динамично чрез защитени API повиквания, когато е необходимо. Също така преместихме към модел, където всяка ръкавица работи с точно същия фърмуер, а уеб браузърът действа като мост между физическия хардуер и нашата облачна инфраструктура. Уебсайт Уебсайт Софтуер за производство с нулева инсталация и незабавно глобално разгръщане Използвайки WebSerial API, ние премахнахме проблема "не работи на моята машина".Нашите екипи за производство и QC вече не се нуждаят от управление на Python среди или драйвери.Те просто отварят URL в Chrome, свързват ръкавицата и браузърът се справя с комуникацията на ниско ниво с персонализираната PCB на ръкавицата. Тъй като целият интерфейс е Single Page Application (SPA), сега управляваме нашата физическа монтажна линия със същата гъвкавост като нашия облачен софтуер. Използваме стандартни CI/CD тръбопроводи, за да задействаме изграждания и да ги разгръщаме към скучен доставчик на статичен хостинг на файлове. Ако подобрим алгоритъма за калибриране или добавим нова проверка на QC, просто натискаме кода и оставяме автоматизираните тръбопроводи да направят останалата част. Техниците, работещи на монтажната линия, не трябва да имат достъп до Git repos. Тази промяна ни позволи да разширим мащаба до вътрешен производствен екип от 7 души без кодиране на фона, което би било невъзможно, ако всяка единица изискваше инженер, за да изгради ръчно и флаш уникален фърмуер. Мостът на идентичността: WebSerial среща WebUSB Мислех, че WebSerial е всичко, от което се нуждая, но открих, че не работи както очаквах поради техническо ограничение: WebSerial сам не може да извлече USB сериалния номер. За да постигнем истинско "One-Click" провизиониране, разработих хибриден хеуристичен подход за свързване на два независими API. Използвайки стратегия "искане и тестване", можем да проверим дали потребителят е избрал едно и също физическо устройство както в WebUSB, така и в WebSerial. По-долу е пример за това как можете да постигнете това в прост случай (всъщност го направих по-удобно за потребителя и по-интегрирано с нашите специфични работни потоци, но това е илюстрация на концепцията). 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];
}
 Това не е документирано никъде.Това е малко хакерство.Но това работи и ни позволява автоматично да свързваме физическия хардуер с конкретния му облачен запис, без да се изисква операторът ръчно да избира или въвежда сериен номер. Разделяне на идентичността от фирмения софтуер Вместо да се вмъкват уникални метаданни във всяко устройство, решението, базирано на уеб, революционизира потока: 
 
 
 
 Разпознаване на самоличността: браузърът идентифицира устройството с помощта на USB сериен номер чрез WebUSB/WebSerial heuristic. Поддържане на метаданни в облака: По време на процеса на регистрация този уникален идентификатор заедно с свързаните с него метаданни се качват в облачна база данни по време на процеса на регистрация. Възстановяване по заявка: Когато ръкавицата се разгръща, всяко приложение или услуга може да използва API за динамично извличане на метаданните по ID. Фирменият софтуер остава глупав и надежден, докато облакът служи като единствен източник на истина. Резултати: По-чисти данни, по-добри роботи Преходът към уеб-центричен хардуер DevOps модел е трансформиращ: 
 
 
 
 Демократизирани операции: Интерактивен екип от 7 души сега се занимава с целия процес на регистрация и QC, освобождавайки стотици инженерни часове. Интегритет на данните: Ние премахнахме неправилно оформените заглавия и грешките в метаданните.Нашият тръбопровод за данни сега е "чист по дизайн" във всичките 2000 единици. Ръст на успеха на задачите: Прецизната и последователна калибриране в целия парк доведе до измеримо увеличение на производителността на нашите модели за бимануални манипулации. Заключението Като комбинирате WebSerial и WebUSB със стандартния уеб CI/CD, можете да преодолеете пропастта между хардуера и облака, като гарантирате, че всеки хардуер е толкова гъвкав и актуален.

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

Read My Stories

Това аудио е създадено на оригиналния език на историята!

Как съм фиксирал производството за AI роботика с WebSerial

About Author

КОМЕНТАРИ

ЗАКАЧВАЙТЕ ЕТИКЕТИ

ТАЗИ СТАТИЯ Е ПРЕДСТАВЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps