Introduction: Let me briefly explain that this series is a journey of discovery. I started without programming skills or a technical understanding of GPUs, CPUs or NPUs. Playing with the technology is how I am learning, and I invite you to come along.
Why I deliberately moved away from YOLO
At first, YOLO seemed the obvious choice for my image recognition project. It is well known, powerful and able to recognize many different objects. But the more I examined my real goal, the clearer it became that a general-purpose model is not automatically the best choice for a specific industrial task. A company or producer usually knows in advance what will travel along its conveyor and can design for that. I had rushed past this essential part of the project description. YOLO would also need 72 NPs, more than the Akida has, so it would require several processing passes or a reduced, adapted model. That was another argument for building a lean architecture of my own.
An industrial system normally does not need to recognize the whole world. Its product classes are defined in advance: screws, SD cards, carabiners or other components. We can use that knowledge to make the model smaller, faster and more efficient. Rather than reserve processing power for countless irrelevant classes and situations, we can train specifically for the objects that will actually occur. The logical consequence is a detector of our own.
Overlapping objects are particularly important. With strong occlusion, conventional detectors may treat two actual items as one detection or suppress one of them. Our model should be designed from the outset to handle several separate overlaps in one image and describe as many as three objects layered locally on top of one another.
That is how VORSA-M3 emerged: a compact object recognition architecture for freely defined classes, different sizes and shapes, and difficult overlaps. The technical goal is ambitious: the complete neural recognition should run on exactly one AKD1500 chip in a single hardware pass.
At every scale, distributing work intelligently makes the difference
The Raspberry Pi remains a useful part of the system. It can handle the camera, image preparation, tracking, geometry and display where those tasks are more energy efficient. The goal is not to force absolutely everything onto Akida. The goal is the best recognition performance at the lowest total energy cost. While experimenting wildly with what Akida alone could do, I lost sight of this. I overlooked the fact that its real strength comes from a sensible partnership between systems.
VORSA-M3 should therefore be more than a smaller YOLO. I want an architecture developed like an actual industrial product for a clearly defined job: specialized, compact, energy efficient and particularly good with overlapping objects.
I am now doing what I neglected on my first attempt in all the excitement: putting in a clear framework, a structure and a plan.
Implementation begins: is VORSA fast and economical?
Once we have built the detector and placed the considerably smaller, more agile model on the chip, the first tests can tell us about recognition, speed, energy consumption and overlaps. Let us work through these questions one by one and look at the first results.
Object recognition and speed
By dividing work more intelligently between Pi 5 and Akida 1500, we now get dramatically better recognition, cleaner boxes and precisely tracked contours than we had with ENGRAM, at dramatically greater speed. Tracking is almost real time, and following moving objects is no longer a problem. The Pi handles tracking, contours and geometry checks; Akida handles recognition and helps arbitrate overlaps. The simple rule is that each task runs wherever it costs least energy for the combined system.
I can check whether that calculation works: the measurement panel compares the Pi directly against Akida, and the cards report their actual power draw in milliwatts measured by the chips themselves, rather than a data sheet figure. This lets me see the value of the division of work and adjust it for each use case. It should remain flexible.
The hard part: touching and overlapping pieces
This is the part that almost drove me to despair. Nearly any system can now recognize two separated pieces. But place a carabiner so that it wraps around an SD card. To the camera it becomes one black blob. For days my system alternately made one item out of it, gave it the wrong name or swallowed one object entirely.
The breakthrough did not come from a larger model but from a simple decision: the system must explain what it thinks about every image. Every box gets a short code identifying where it came from, and a log line for each piece records which stage made the decision and with what numbers. When recognition suddenly got worse, I did not have to guess. The log said that the background beat the carabiner, 66 percent to 43 percent. I found the error in minutes: five photographs of empty background in my learning class had turned it into a classifier for everything. With a black box, I would have failed silently.
Then came an idea I am honestly proud of. During learning, the system automatically measures which of my parts have a hole. A carabiner has one; an SD card does not. If a blob in the image encloses a hole but is supposedly an SD card, that is physically impossible. The blob can be separated along the hole, and suddenly two distinct parts with the right names appear again. Simple physics beats statistics here.
What really distinguishes us from YOLO
After a few weeks I can explain the difference in a paragraph. YOLO is a single large network trained on thousands of labeled images that then finds, names and frames everything at once. Its knowledge is hidden inside millions of numbers. When it gets something wrong, you cannot ask it why, and a new part calls for a complete training run on substantial hardware.
VORSA separates the job into three simple questions. Where is something? Classical image processing on the Pi answers that without training, consistently and transparently. What is it? Akida answers that like a memory: 20 to 30 photos, one click and a few seconds, and it knows the part, on the device without a GPU or cloud. And when neither is enough, rules drawn from physical shape knowledge decide, as with the hole.
The funny thing is that there is still a small YOLO in the system, on one of the cards. It only gets a say when all the other stages fail to name a piece, and its suggestions are checked before appearing in the image. That is the reverse of the usual order, and it makes the system trustworthy to me.
Four learned objects are now running. In these test runs the naming rate is 98 to 100 percent, and touching and overlap scenes that nearly defeated me are separated into two clean green boxes. Adding a new part takes minutes rather than nights of training.
Stumbling blocks
As always, I will end with the obstacles, because they teach us the most.
Recognition worsened when I made the browser window smaller. Analysis was accidentally running on the reduced display image, where the thin carabiner tube was just four pixels wide. Fix: Recognition now always works at a fixed resolution, regardless of window size.
After one internal error, the system silently showed zero objects until restart. Fix: Every frame is attempted again, and the error is visible in a message.
The statistics counted fantasy classes such as “SD card carabiner” more than 50,000 times because the display heading was being counted as an object class. Fix: Each object is counted individually.
The carabiner disappeared altogether. The log revealed the culprit: my negative class consisted of five empty background photos, which became a shapeless shadow when cropped and matched everything. The background scored 66 percent against 43 percent for the carabiner. Fix: Empty photos are automatically excluded from learning; an empty belt does not need a negative class.
The display claimed more than 300 milliseconds of inference time, but it had measured the entire processing chain. Fix: We now time only the actual work on the card, which takes 16 to 22 milliseconds.
As soon as the fourth object was learned, the best overlap scene fell apart into four boxes. This was mathematics rather than a bug: each new class redistributes similarity scores, pushing the carabiner arcs just below the threshold. Fix: Unnamed fragments in a touching group are joined; if their silhouette encloses a hole, they receive the name of the only class with a hole.
After an update, the capture buttons appeared to vanish in learning mode. They were simply below the screen edge because my new zoom feature had taken over the mouse wheel. Fix: The wheel scrolls over the menu and zooms over the image.
The pattern behind nearly all these fixes, and perhaps the most important lesson in this installment, is to stop guessing and make the system show its decisions. Since every stage has written its numbers into the log, debugging that took days has become a matter of minutes.
What comes next
Three things are next. The small detector model will receive further training on artificially generated overlap scenes made from my real photos, so its boxes fit even with heavy occlusion. Then comes an honest test: learn from 80 percent of the photos and test on the withheld 20 percent, turning a good feeling into a number. Finally, an old webcam will provide a second opinion from the side whenever the overhead view is uncertain. I will write about that in the next installment.
The original LinkedIn article includes images and video of the overlapping-object tests. View the original media on LinkedIn ↗
The architecture and percentages above describe the author’s August 2026 work and small test runs. They do not constitute a held-out benchmark or a verified single-pass VORSA-M3 deployment. Those checks remain separate engineering work.