Machine Vision: Acknowledge the Technology Trade-offs & Reap the Rewards
Machine vision is one of the most dynamic technologies on the market today. The ever-increasing consumer demand for its applications is driving constant improvement, meaning the market is moving very fast. This is leaving all kinds of suppliers — particularly in the rapidly growing AI and automotive markets — scrambling to deliver the best technology as quickly, efficiently and as cost-effectively as possible.
This article was written in consultation with architect Enzo D’Alessandro.
The Problem…
…is checking all the boxes — those of speed, efficiency, and commercial viability– is difficult to do whilst aiming for best-in-class product quality. There are trade-offs that must be made, and a balance that must be struck. The final product will be shaped by these decisions; get them wrong, and you could lose the market. Get them right and you’ll deliver the best machine vision product possible for your budget and timescale.
The Problem, in Action
To understand how to strike such a balance, we must first identify the biggest difficulties in designing a machine vision system. As an example, let us take a robot that is trying to learn how to navigate by itself. Here, the primary challenge is ensuring efficient communication between the robot’s sensors.
The sensors that provide our robot’s vision must talk to each other, and fluently. If these sensors aren’t perfectly synchronised and the inputs perfectly correlated, the robot’s going to have a tough time understanding what’s around it. For instance, if a loud noise is picked up on the right-hand-side of the robot, and synchronisation between the back and the front isn’t working correctly, the system could infer (and react to) two separate noises. In a safety-critical environment like an automated car, this isn’t going to cut it.
To get the sensors to communicate properly, a system must be built with enough bandwidth to handle an intensive amount of data. Here we’re faced with an important choice: do we use off-the-shelf components, which we can buy and put straight to use, or do we create our own dedicated, integrated system-on-chip?
Current Technology Solutions
Currently, the most widespread use of the technology is in stereo cameras. For these basic applications there are a number of off-the-shelf components you can buy to build a self-contained device very quickly. These will provide you with enough bandwidth to collect images from two cameras, as well as some (typically CPU) processing power. For simple machine vision applications, these discrete systems can be a great option.
Simple applications won’t win you the market, though, and off-the-shelf components begin to falter when the things they’re asked to do become more complex. In a complicated machine vision system, it’s likely there are cascades of processors doing a host of things: collecting images from the sensors, doing pre-processing on the images, before passing on that information to elsewhere. You can imagine the potential latency issues between the branches of such a system.
To get the amount of computational power required to perform the more intensive tasks, you’ll have to put up with a trade-off. For example, you might have a device that will allow you one or two sensors, when you need eight — or you might manage multiple sources, but lack computation. For more complicated tasks, such as running algorithms for facial recognition systems, or correlating a heat map with an image for a security camera, the analytical power of off-the-shelf devices falls well short. In these instances, we need to consider…
More Complex Architectural Models
First among these is the slave & master approach. Here, your ‘slaves’ outside the system-on-chip do a lot of the processing for you, before passing the information on. You’d use purely discrete components for this, meaning they wouldn’t be optimised for the work you’re doing, and would therefore be hugely power-hungry.
Second is the single system-on-chip model. This allows you to build a single SoC that would perform exactly as you want it to, but would be limited in how it collects data from multiple cameras — with such large amounts of bandwidth coming in, this too is going to be very power-hungry.
Finally, the hybrid model describes using your own, specifically-designed SoC alongside several discrete components. This model will deliver the high-level processing you require.
Adding Commercial Interests to the Mix
The decision on how to best deliver your project technically would be much easier to make if it were made in isolation. As we’ve said, however, there are trade-offs that must be made, and a balance that must be struck. Each technical model comes with its own commercial drawbacks, and can only be made in context with your business model. Every company’s situation is different, and unique and nuanced solutions must be applied.
For example, imagine a company with a fantastic product who want to rush to market very quickly. They design a prototype using an off-the-shelf FPGA, and they could go straight to market; but it’s too expensive for the final customer and too power-hungry, so they decide instead to build an integrated SoC. However, the company can’t accept the technical trade-offs they run into when designing the SoC. They constantly ask for functionality to be added, drawing the design process out. By the time the chip is taped out, their once-fantastic product is already obsolete.
They could’ve gone to market with the FPGA, but that again would have required sacrifice; it would have been hugely expensive, and far more difficult to incorporate into a battery-powered device. Perhaps they would have ended up with a device that became too hot when used for the final consumer to hold. Trade-offs like these are much easier to make when you’re expecting them.
In Conclusion
The company in our example lacked the proper understanding of the relationship between their business and the technical requirements of their chip. They needed to know, from the start, that trade-offs were unavoidable, so they could decide which ones they were most happy to make. They also should’ve been provided with a clear, transparent and honest representation of the NRE costs involved in the various options.
Had the company been designing a machine vision product, this specialist knowledge would have been even more valuable. Choosing an architectural model is difficult enough without understand each comes with its own trade-offs. Going into a machine vision project with the correct knowledge can be vital for its success.
Had the company been armed with this information from the outset, their fantastic product would be a best-in-class market leader today.
Sondrel understand the balanced relationship between a business’ commercial interests and its technological aspirations. Armed with this knowledge, we can provide a nuanced and impartial solution for your SoC project.
Contact us today by emailing sales@sondrel.com, or find telephone and regional contact emails on our ‘contact us’ website page.