Build post
The First Research Direction
Before Oplut becomes anything broader, the first question is simple: can one robotics setup remember the hardware state that worked and detect when it changed?
The first research direction for Oplut is intentionally narrow. Can a robotics setup record the state it was accepted in, then later detect that it no longer matches?
That is the whole wedge right now. Not a marketplace of hardware. Not a general robotics platform. Not a dashboard full of every possible sensor. The first useful version should answer one question: this worked before, so what changed?
The reason this matters is that physical systems lose context very easily. A camera service can still be running while latency changes. An IMU can still return JSON while the mount has shifted. A motor can be commanded to move while the physical position is not what the software assumes. The system can look alive and still no longer be the same system that was trusted.
So the first experiment is about unit-specific baseline memory. Oplut should capture the accepted state for one real setup, then compare later behavior against that same unit's history. The important part is not just collecting more data. It is making the comparison specific to the actual machine in front of you.
For the current Northstar hardware, the camera is the main surface being watched. The IMU and motor are there to give physical context: whether the sensor assembly stayed in the same position, whether commanded movement matches measured movement, and whether a change looks physical or software-related.
That still leaves room for important future evidence types like calibration records, cross-sensor relationships, and eventually fleet-level learning. But those only matter if they strengthen the same core loop. First, Oplut has to prove that one setup can remember what working looked like and explain what changed.
That is the research goal I care about right now: hardware state as something a robot can remember, compare, and report plainly.