Flashing, testing, re-testing on the bench needed a human. Not anymore.
Oracova is an automated test bench for firmware. Your unmodified binary runs on your real microcontroller. Oracova emulates the world around it with real-time physics, injects faults, and scores every run PASS or FAIL with captured evidence. AI agents drive the bench, so the loop runs unattended.
Your engineers or your coding agents write the change. Oracova takes it from there: it writes the tests against the change, separately, and runs them on the bench, not in a mock. You manage outcomes, not benches.
Flash the chip, run the tests, read the result, iterate, repeat. Oracova keeps going for as long as it takes. Nobody watches it work.
Every test an agent writes stays in the suite and runs on every future PR. Integration regressions get caught before anyone looks for them.
More PRs in flight? Add benches. They are cheap to replicate, and every PR gets its own.
The world around your firmware is live physics: motors spin, packs heat up, pressure builds. Your firmware reaches every test point on its own. The world drives it there: no test hooks, no forced states, no special builds. To test an over-temperature guard, the pack heats up in physics and the firmware hits the fault exactly as it would in the field. Unmodified binary, same code you ship. Common peripherals, a gyro, an LCD, a hall encoder, come as validated models from Oracova's open-source marketplace; what you build, you can contribute back.
Commutation and hall-sensor faults on real silicon: stuck hall, swapped sectors, skipped sector. All proven on the Oracova bench.
Cell over-temperature, sensor dropout, protection thresholds. The pack is physics, so protection logic is tested by reaching the fault, not by faking it.
Heaters, pumps, converters. Closed loops settle, overshoot, and fault against a plant that behaves like the real one.
Wondering what it takes to get your board on the bench? See how onboarding works →
Every run returns PASS or FAIL with captured traces, event trails, and firmware hashes. Repeatable, diffable, stored in CI. This is a real run from the bench:
A stuck hall sensor. Unguarded firmware energizes the wrong phase 8 times, 4 of them unsafe. The guarded build shuts down clean. Both verdicts came from real hardware, not a simulator.
Unmodified Betaflight flies against the bench. Production flight-controller firmware, no source changes, closed the loop against Oracova's emulated world: gyro and accel served over I2C, 4 motor outputs decoded, physics advanced, ANGLE mode holding attitude at an 8 kHz loop. Third-party firmware we cannot see inside is the hardest case. That is why we lead with it.
Zero edges on the wire. During bring-up, Betaflight's DShot motor output produced no edges at all, a DMA allocation failure on the F411. The build was green, the config said DShot600 active, every static check passed. Only the closed loop caught it. That bug class is exactly what Oracova exists for.
Real faults, scored verdicts. BLDC commutation faults on a two-MCU rig: swapped sectors FAIL (mismatch=8, unsafe=8) · hall stuck low FAIL (unsafe=4) · skipped sector FAIL (seq_fault=7) · forced invalid hall bus PASS, because the target shuts down safely. Add a guard patch and the stuck-hall case flips to PASS with unsafe=0. Every verdict has stored evidence and firmware hashes.
The same loop pattern drove a Tesla ECU over CAN.
I am a hardware and firmware engineer. I have shipped motor controllers and battery systems, and I have been the human at the bench this page describes. Oracova exists because the tools I wanted never did. If your firmware drives something real and testing it still means a person and an afternoon, I want 15 minutes.