Turning Novel Research into Useful Products

Author: Kevin Sylvestre

At Perceptive Automata, we’re constantly improving our core technology with the latest scientific research from the fields of computer vision, machine learning, and psychophysics. But, as Isaac Asimov once wrote in his own book of quotes,

Science can amuse and fascinate us all, but it is engineering that changes the world.

In other words, the groundbreaking experimentation and exploration our research team does is great and all, but the real magic is in the engineering since the result of their efforts need to be applied to produce any real impact. As an engineering team leader at Perceptive Automata, I’m particularly focused on how we can rapidly and reliably bring our novel approaches to market so that customers can harness the power of our innovations.

Customer Problem + Unique, Innovative Solution + ???? = Profit

We believe our technology, properly applied, has huge potential to affect the human condition, and, indeed, to change the world. We’ve demonstrated that our innovative approach can help solve a variety of important and challenging customer problems. But applying those innovations can be a tricky proposition.

For one thing, we’re currently applying our technology to problems in Autonomous Vehicles (AVs). This is a nascent technology, under active development, where customers provide a steady stream of new requirements to track and to satisfy. Moreover, this is a highly fractured space, where each major player is developing its own unique, proprietary approach to solving this very complicated problem. This means each new integration brings a new set of unique considerations and challenges.

Additionally, just wrangling and harnessing our cutting edge technology in our internal efforts can be challenging as well. We’re fusing together elements of computer Vision, Machine Learning, and Psychophysics — more nascent sciences, with new ideas and research coming in all the time, and more moving targets to hit (and then integrate into production). Achieving stable, consistent, reliable performance in the face of this deluge of innovation is no small feat.

Integrating our novel and steadily improving product into a continuously evolving space requires managing the complexity that arises from these internal and external factors.

???? == Solid Engineering Practices

Managing all this complexity can be a tall task for a startup, but can be greatly simplified by using certain basic engineering best practices in the development of our software and releases, including:

• Use common design patterns wherever possible to minimize cognitive overhead
• Identify and understand the technical risks so you can build in flexibility where it is needed and minimize the difficulty of accommodating changing requirements or approaches.
• Reduce coupling between components, particularly between internal and external systems

One example of an engineering choice guided by these best practices is the conversion of our internal ML models to Open Neural Network Exchange (ONNX) format. This format serves as a “hub” format and decouples the model development software stack from the model deployment constraints, meaning the model development team is free to try whatever crazy ideas they want, while the deployment team can focus on streamlining and deploying in whatever format is most efficient or convenient. As the best practices above suggest, we understand that our ML models require lots of flexibility in how they’re composed, and that this poses technical risk. Using a common design pattern which everyone understands, the ‘hub and spoke’ or ‘mediator’ pattern, we can cut down on coupling between the components.

Another example of such a choice is our decision to wrap our ML models and some other useful tools into a C++ Service application which is pre-compiled for the customer’s platform(s). This Service is accessed via a highly configurable, but dependency-light, Client API which we can further tailor to different deployment scenarios. This deployment strategy, which uses the simple and common ‘client-server’ pattern, lets us decouple our software dependencies from the customer software dependencies, giving both of us maximum flexibility in selecting our software stacks. Using IPC and a separate Service process can provide extra peace of mind for customers since the Perceptive processing is largely segregated from the rest of the system, reducing the risk of failure that all systems must consider when integrating third-party libraries.

The More You Know

Using these basic engineering best-practices (and many others like them) to guide decisions, we are able to provide a robust, stable solution for a variety of integration platforms, while focusing our limited development time on a relatively small number of high-quality software components, and continuing to release new improvements and features at an ever-accelerating rate.

Now that you have these non-secrets to success, you too can profit from the work of scientists! Or better yet, come work with us! We’re hiring!