After deploying the 100th Skill-Capture Glove, our data pipeline quietly started poisoning itself. Nothing crashed. The models just got worse.

In the world of AI robotics, data is the new oil. For Sunday Robotics, that oil comes from Skill-Capture Gloves deployed in over 500 real-world homes. With 2,000 units produced, these gloves capture high-fidelity bimanual manipulation data that is used to train the next generation of AI-powered robots.

However, as we scaled from 10 prototypes to 2,000 units, we hit a wall. Our manufacturing process was a mess of sketchy Python scripts, manual YAML files, and, worst of all, custom-built firmware for every single glove.

Here is how I used WebSerial and WebUSB to move from a brittle, engineer-only process to a fool-proof Hardware DevOps lifecycle that directly improved our robot's task success rate.

The "Hardcoded" Nightmare: Why Firmware-as-Identity Fails

At the time I joined Sunday, our registration process for Skill-Capture Glove was fundamentally unscalable:

  1. Connect a Glove.
  2. Run a Python script (dependent on specific local environments and drivers).
  3. Modify the firmware code in C to include the Glove's specific metadata (hardware ID, hardware version, firmware version, whether the Glove is left-hand or right-hand).
  4. Manually commit hardware IDs and calibration data in a Git repository using YAML files.
  5. Build and flash a unique, one-off binary for that specific Glove.

The Impact of Human Errors

This process was a breeding ground for inconsistencies. We faced malformed version strings, duplicate hardware IDs, and incorrect metadata. In the hardware world, these aren't just bugs but data poison.

When a glove in a home 2,000 miles away sends data with a malformed version string, our downstream AI pipelines break. We found ourselves writing hacky data-cleaning scripts just to make the collected data usable. Worse, incorrect calibration data directly affected the models we were training silently, lowering task success rate without obvious signs of what went wrong.

The Architectural Shift: The Web as the "Factory Tool"

The moment it clicked for me was when I learned that there is WebSerial & WebUSB API available in Chromium-based web browsers that allows web front-end to communicate with USB-connected devices. I also realized that the firmware was doing a job it has no business doing. Metadata such as hardware versions and calibration data can be stored on the cloud and retrieved dynamically through secure API calls when needed. We also moved to a model where every glove runs the exact same firmware, and the Web browser acts as the bridge between the physical hardware and our cloud infrastructure.

1. Zero-Install Manufacturing Software and Instant Global Deployment

By using the WebSerial API, we eliminated the "it doesn't work on my machine" problem. Our manufacturing and QC teams no longer need to manage Python environments or drivers. They simply open a URL in Chrome, connect the glove, and the browser handles the low-level communication with the custom built PCB on the glove.

Because the entire interface is a Single Page Application (SPA), we now manage our physical assembly line with the same agility as our cloud software. We use standard CI/CD pipelines to trigger builds and deploy to a boring static file hosting provider. If we improve a calibration algorithm or add a new QC check, we simply push the code and let automated pipelines do the rest. Technicians working at the assembly line don't need to have access to Git repos. They simply refresh the webpage to get the latest, engineering-approved version of our manufacturing tool.

This shift allowed us to scale up to an in-house manufacturing team of 7 people without coding background, which would have been impossible if every unit required an engineer to manually build and flash unique firmware.

2. The Identity Bridge: WebSerial meets WebUSB

I thought WebSerial was all I needed, but I found it didn't work as I expected because of a technical limitation: WebSerial alone cannot retrieve the USB Serial Number. It only exposes the USB Vendor ID and USB Product ID, which are identical for every unit of the same model.

To achieve true "One-Click" provisioning, I developed a hybrid heuristic approach to bridge two independent APIs. By using a "claim and test" strategy, we can verify if the user selected the same physical device in both the WebUSB and WebSerial prompts. Below is an example of how you could achieve this in a simple case (I actually did it in a more user-friendly way and more integrated with our specific workflows but this is an illustration of the concept).

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];
}

This isn’t documented anywhere. It’s a bit of a hack. But it works and it allows us to automatically link the physical hardware to its specific cloud record without requiring the operator to manually select or type in a serial number.

3. Decoupling Identity from Firmware

Instead of flashing unique metadata into every unit, the Web-based solution revolutionized the flow:

The firmware stays dumb and reliable, while the cloud serves as the single source of truth.

The Future: Web-Based OTA in the Wild

The benefits of this architecture extend far beyond the factory floor. By reusing the core logic of our manufacturing system, we are building a path for remote firmware delivery.

Traditional Over-The-Air (OTA) updates can be brittle and complex to implement reliably in home environments. With our system, a user in the field can simply connect their glove to any laptop with a Chromium-based browser. Using the same WebSerial/WebUSB bridge, we can deliver firmware updates and perform remote diagnostics directly through our web interface, ensuring that the 2,000 units in the "wild" stay as current as the ones coming off the line today.

Results: Cleaner Data, Better Robots

The shift to a Web-centric Hardware DevOps model has been transformative:

Conclusion

If you are scaling IoT or Robotics hardware, treat web browsers as your process orchestrator. By combining WebSerial and WebUSB with standard web CI/CD, you can bridge the gap between the hardware and the cloud, ensuring that every hardware unit is as agile and up-to-date.