What I Learned about Machine Vision from Writing Video Games
My business partner Andy Thyssen and I have a somewhat non-traditional background when compared to other machine vision integrators in that we both spent over a decade working in the videogame business as software engineers. People usually say, “Wow, that sounds like such a fun job...why did you leave?” And to date, the best answer I’ve heard is the answer given by Andy: we were tired of watching 25 million dollars and two years of our lives go down the tubes on a product that nobody needed. So as much as we really enjoyed the technical challenges of making games such as “The Hobbit,” “All Star Baseball,” and (dare I say it) even “Southpark,” we are now in a career that we truly believe ultimately benefits society.
Having said that, the career we had creating videogames turned out to be an excellent training ground for the work we’ve been doing here at Nagle Research since 2003. You see, there are certain characteristics a machine vision system must have in order to be successful, and it turns out they are largely the same characteristics that videogames must have before a publisher will permit a game to be sold.
1. It MUST be robust and stable
Before a game ships, it is tested rigorously by professional testers…not just “players,” people who actually try to make the game crash. In machine vision, we try to apply that same “what if” mentality to try and think of all the corner cases that can cause problems in the final system.
When we were doing games, our games were burned onto cartridges or CDs, and once they shipped there was never any possibility of fixing a bug. If a “bug” (software error) made it through, it was there forever. Fortunately we do have the option of making changes and updates in our projects after deployment, but we prefer to keep the mindset that when we deploy, it’s done.
2. It MUST be easy to use
In videogames, our users were largely children with no special technical education. Games are (or at least were) expected to be extremely intuitive to casual players. Anyone should be able to pick up a controller and play the game.
In machine vision systems, our HMIs need to follow the same convention. A lot of the time, the people interacting with our systems are non-technical laborers, and our interface is simply a tool they must interact with in their daily work. If we make it complicated or confusing, it will ultimately impact the bottom line of our customer, either in lost time or product that is not properly inspected.
3. It MUST have high performance
In videogames, we were tasked with making thousands of things move on the screen, each obeying the game’s physics model, collision attributes and artificial intelligence. But all of these calculations had to happen in 1/60th of a second. If we had an extraordinary amount of objects, we could live with 1/30th of a second. But keep in mind, the consoles of the day were less powerful than your iPhone is now.
For our machine vision systems, we keep that high-performance “bit wrangling” mentality. One recent customer had an existing system that required four servers to process data from four cameras, and three seconds to perform the analysis. We re-engineered the system and demonstrated it on my laptop connected to all four cameras, and the analysis took a little over 0.5 seconds. (Andy is a master at optimization.) As a result, an outflow conveyor was shortened by at least 10 feet, saving precious floor space and improving cycle time.
These three “game” philosophies have become the guiding principles by which we develop our projects. Hopefully you can apply these principles and earn the “high score” with your customers.
