The Plan.
We are not starting from a finished laboratory. We are starting from a software research project that has reached the point where the next interesting questions increasingly belong to real hardware.
This page keeps the claims separated: what we have actually run, what other people already sell, what we propose to build, and what could still prove the idea wrong.
Concept imageWhat we have actually done.
Our RK3588 project asks whether several inexpensive system-on-chips can be made to behave more like parts of one larger machine.
The project has progressed through a series of deliberately narrow experiments using four independent ARM64 Linux guests. The current master guide records V10 as proven: a small mutable execution state can be parked on one guest, transferred, checked for the correct owner and generation, resumed exactly once on another guest through a real kernel wait/wake path, while a deliberately stale wake is rejected and the old host is prevented from continuing the transferred generation.
The final V10 binary passed twenty fresh migration boots, the migrate/stay comparison, an independent Internal-VM reproduction and a separate frozen clean-room rerun.
The limit is just as important: QEMU ARM virt is not an RK3588 hardware emulator. Those runs do not tell us real PCIe throughput, real DMA latency, signal integrity, heat, power, NPU behaviour or cache-maintenance cost on a physical Rockchip board.
V11 is the next software-contract step: hide the already proven handoff beneath an ordinary application task/continuation operation. In parallel, the hardware branch still needs two real RK3588-class boards in root-complex ↔ endpoint mode and real measurements.
We are assembling known powers, not pretending the pieces are new.
Computer-controlled electronics instruments are mature. Affordable USB scopes can be scripted. Logic analysers have automation APIs. Bench power supplies and electronic loads can be controlled remotely. Thermal cameras can return temperature data for every pixel. Industrial production lines already use fixtures, switching matrices and automated test sequences.
By 2026, instrument companies are even beginning to expose interfaces aimed at AI clients. Open-source frameworks already provide sensible concepts for running hardware tests and storing their measurements.
That is good news. It means the project should spend very little time reinventing an oscilloscope.
Our proposed contribution is the layer that knows the board, the software, the fixture and the experiment at the same time; keeps hard safety limits local; aligns measurements honestly; and preserves enough history that a test can be repeated somewhere else.
The market question remains open: perhaps a product already covers most of this. If we find one, the correct response is to integrate it or narrow our project, not invent a fake category distinction.
The expensive part begins after the demo works.
Robotics and edge-compute teams often prove an idea quickly with development boards, then discover that making one dependable product requires several disciplines to meet at once.
A working robot may contain a Jetson or RK3588 board, a separate controller, a CAN adapter, cameras, storage, a network switch, power boards and a nest of cables. Turning that into one reliable machine means custom carrier electronics, software support, thermal work, test fixtures, sourcing, manufacturing and eventually conformity work.
Our customer research in robotics and embedded communities repeatedly surfaced this seam: the prototype can be quick; productisation is where schedules stretch and specialist knowledge becomes expensive.
That is why the commercial first use of the Lab may be inside a small productisation practice. Customers would buy a solved hardware problem. The automated laboratory would be how a small team does more careful work with fewer repeated manual steps.
Prove the loop before polishing the box.
Inventory a normal bench
Write adapters for the programmable instruments already available. One command should produce one evidence bundle instead of five disconnected files.
Three senses in one run
Electrical measurement + software/log state + visible or thermal observation. The acceptance test is simple: one event can be inspected across all three.
Add thermal as real data
Register the camera to the board and record temperature traces for components or board regions, not merely colourful screenshots.
Put safety below the agent
Current, voltage, temperature and allowed actions are enforced by local software/hardware that still works when the high-level process disappears.
Make one repeatable fixture
Remove the board, put it back, and prove that the important measurements remain repeatable without hand-rebuilding the setup.
Let the system choose one next test
Not “optimize everything.” The agent must identify a real ambiguity, propose the smallest safe experiment that distinguishes it, execute after approval, and update the evidence.
Use the RK3588 project as Case Study Zero
Answer a physical question that the current simulation cannot answer. That is the first moment the Lab changes our own hardware design decision.
Rev A → failure → Rev B → verified fix
This is the major credibility test. Fabricate a real board, discover a measurable weakness through the system, change the design, fabricate the next revision and show the same test no longer fails.
Repeat it in another lab
A second Crowdmaking node receives the test package and reproduces the result on another physical specimen.
Thousands of thoughts. A few boards.
A software agent can cheaply consider enormous numbers of alternatives. A fabricated board still costs money and days. The architecture has to respect that difference.
Open questions are part of the plan.
Is this just industrial automated test with a nicer interface?
Possibly, if the board-awareness, low-cost integration and next-experiment reasoning do not create enough value earlier in the engineering cycle. Our first demo has to prove a difference beyond language control.
Can cheap instruments be synchronized well enough?
Not for every measurement. We need a hierarchy of shared hardware triggers, local event timestamps and honest software alignment. If useful work requires PXI-class timing everywhere, the accessible commons idea becomes much harder.
Does thermal imaging belong in version one?
It is visually compelling and often useful, but it may be too expensive or slow for the minimum product. We should measure how often it changes a diagnosis before treating it as mandatory.
Will every new board become a custom integration project?
This is a central product risk. Board manifests, fixture conventions and EDA import must reduce setup cost dramatically or the business remains ordinary bespoke test engineering.
What is the business?
Possibilities include assembled/calibrated Lab hardware, fixtures, support, enterprise adapters, productisation services and shared test infrastructure. The commons can remain open while reliable physical execution and integration are paid work.
Keep the boundary visible.
This is a project-governance model, not legal advice. Exact product-law obligations depend on the device and how it is supplied or put into service.