Readers of Day 1 will remember where we stood: the one-shot learner worked, but to the chip a car key and a lighter were practically twins. The top match beat the runner-up by only 0.05 on a scale to one. That is not recognition; it is a coin toss with a head start.
This time two days belong in one article. The results became spectacularly good and, in between, spectacularly chaotic. Both deserve to be told.
New glasses for the network — Day 2
Claude explained the problem in terms even I understood. The large network on the chip was frozen and had originally been trained on ImageNet: dogs, cars and teapots. For “small dark object on my desk” it produced almost the same description every time. The chip was not stupid. It was wearing the wrong glasses.
So we made new glasses. We added a capture mode to the web interface: enter a name, press C, take a photo, rotate the object, press C again. I collected about 30 pictures per object. Then we retrained only the top feature layer on those images; the rest stayed frozen, so the Raspberry Pi itself could handle the work. Training took less than three minutes on a Raspberry Pi. I had to read that twice.
On test images the training had never seen, the margin between the best and second-best matches went from 0.05 to 0.43. We then collected the dataset again with more discipline: one zoom setting, one background, no wild combinations. The margin reached 0.47.
Then came the real breakthrough, one of those ideas that makes you ask why you did not try it sooner: remove the background. Record the empty scene once. Compare every new camera image with that reference and replace anything resembling the background with neutral grey. The chip sees only the isolated object. The recognition scores climbed above 0.9. In the video, the bars in the upper-right corner show just how much the camera-based recognition improved.
An honesty footnote: plenty went wrong. In the first training attempt the validation numbers froze at precisely the same value for twelve rounds. Claude said a normalisation component had gone to sleep; I nodded knowingly. Twice the measurement crashed with a segmentation fault. Once we accidentally trained on only half the dataset and wondered why everything got worse. Computers do exactly what you tell them, unfortunately.
A small measurement I could not forget
The same network and the same camera image ran once on the neuromorphic Akida chip and once on the Raspberry Pi 5 CPU. In this historical test, the chip ran 2.4 times faster. The Pi-side power measurement gave 22 millijoules per recognition versus 236 on the CPU, a factor of 10.7. Both calculations produced bit-for-bit identical output. We measured this on the desk rather than copying a number from a brochure; it remains a historical setup-specific result and is not a measured energy-per-object figure for VORSA INSPECT.
Reading the promise of neuromorphic hardware in a brochure is one thing. Watching the comparison happen on your own desk is another.
Day 3: pride before the kernel module
Flush with success, I intended to “quickly” connect the Raspberry Pi camera module as an alternative to the USB webcam. The next few hours were less quick. At first the camera was absent. Then it was electrically silent: the driver asked politely for its chip ID and got no answer. Then the module was supposedly dead. It was not dead after all; the cable orientation and a configuration entry pointing to the wrong port were the problem.
When the picture finally appeared, my wife had a blue face. Really. The camera library had swapped red and blue. An orange carabiner turned turquoise and my wife turned into a Smurf. That has been fixed; she has her natural skin colour again. The inconvenience produced a useful feature: a camera selector in the interface. Choose a source in a dropdown, click, and the setting is saved.
When the card sulks
The Akida card sometimes entered a state in which it simply stopped responding. There was no error and no crash. It just stopped computing, and every operation waiting for it waited forever. From the outside, the whole program looked broken. I typed a few things into the chat at that point that I will not repeat here.
The truth was one blocked point and many symptoms. The response became my favourite feature: the system now checked itself. A startup self-test verified that the card was actually computing. A watchdog checked whether runtime responses were plausible. Another guard intervened when the central lock had been occupied too long: reload the driver, restart the service and continue.
It happened that afternoon while I watched. At 12:53:52 the card froze. At 12:54:08 the guard reacted and reloaded the driver. At 12:54:18 the startup test reported 49.6 milliseconds per recognition and operation resumed. Twenty-five seconds, no manual intervention. This was the behaviour recorded that day, not a promise that every hardware fault is recoverable in that time.
What I learned about software
At the end of Day 3 we did something that first felt like defeat and was not: restore the complete Day 2 evening state and freeze it as Version 1.0 Stable. Each Day 3 feature would return individually, with a check and a backup before the next one.
If anyone wonders why software professionals keep talking about version control and backups, I learned it that weekend. Restoring took five minutes because every intermediate state existed as a file. Without those files this article would be much shorter and much sadder.
As always, correct me when I get something wrong. I learn at least as much from the comments as from building. And yes, by now I know what a segmentation fault is. I still do not like it.
The restart and power observations above refer to the historical one-card desk setup. Today the VORSA system also records card state and alarms; its full-cell energy per inspected object remains unmeasured.