After deploying the 100th wearable data collection device, our robotics 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 AI Robotics, that oil may come from wearable data collection devices deployed in real-world homes. 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 the team, our registration process for these wearable data collection devices was fundamentally unscalable:
- Connect the wearable to a PC.
- Run a Python script (dependent on specific local environments and drivers).
- Modify the firmware code in C to include the device's specific metadata (hardware ID, hardware version, firmware version, and whether the device is left-hand or right-hand).
- Manually commit hardware IDs and calibration data in a Git repository using YAML files.
- Build and flash a unique, one-off binary for that specific device.
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 could 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:
- Identity Recognition: The browser identifies the unit using USB Serial Number via the WebUSB/WebSerial heuristic.
- Maintain Metadata on the Cloud: During the registration process, that unique ID along with associated metadata are uploaded to a cloud database during the registration process.
- On-demand Retrieval: When the glove is deployed, any app or service can use an API to retrieve the metadata by ID dynamically.
The firmware stays dumb and reliable, while the cloud serves as the single source of truth.
Results: Cleaner Data, Better Robots
The shift to a Web-centric Hardware DevOps model has been transformative:
- Democratized Operations: An in-house team of 7 now handles the entire registration and QC process, freeing up hundreds of engineering hours.
- Data Integrity: We have eliminated malformed headers and metadata errors. Our data pipeline is now "clean by design" across all 2,000 units.
- Task Success Rate: Accurate, consistent calibration across the entire fleet has led to a measurable increase in the performance of our bimanual manipulation models.
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.