Reading Paul Gilbert’s retrospective on 20 years with Quanser the other morning, I was struck by how our technology strategy has changed over time. While the overarching design philosophy that Paul talked about at the end of his piece has not changed over the years, especially in recent years, our focus as an R&D department has shifted as we have matured.
In the past, our focus as a fledgling company was to build out our “menu” of offerings to be as diverse and interdisciplinary as possible to capture our markets by offering something for everyone. In short, every product we released was a new adventure into yet another unexplored market. In recent years, however, we have filled our menu with almost everything our typical customers look for when they visit us. Therefore, in recent years we have developed more complex and integrated “combo” solutions that branch into new directions. Primarily, these solutions offer more flexibility and broad applicability than ever before but require a different approach to long-term maintenance to stay truly relevant. This change in solution offerings has led to a few different outcomes when it comes to the management of our technology roadmap.
When I think about what drives us to kickoff our R&D projects, some interesting aspects of practical product lifecycle management come to light. Typically, when a technology company considers product lifecycle management, the factors at play are dominated by market dynamics. The first way these dynamics can trigger a project is what I call an internal trigger. This is typically the traditional project that I described above, where an inner desire to expand our market potential leads to a true R&D project to find a brand new solution. Consider Apple, where from time to time, new technology will emerge (smartphones, tablets, smartwatches, AR glasses), and in time, they release new hardware products to capture that market.
The other classic trigger is an external change in the revenue generated by a product that leads to a redesign. Going back to our example with Apple, they release a new iPhone each year to recognize a bump in revenue as customers update their old and dated phones to the latest hotness. The cadence of these product updates is much faster than the rate of new project releases but with lower risk and a proportionally lower potential gain than a completely new platform.
Here is where the diversity of the extensive product mix that we have developed over our decades in controls, mechatronics, robotics, structural dynamics, and autonomous systems comes into play. Most of our older products were new platforms when released. Still, their focus on repeatable and robust dynamics remained relevant for investigating advanced research and teaching applications without modification for years, if not decades. In recent years, however, we have built a suite of complex integrated platforms that are used for cutting-edge teaching and research applications. These systems have a shelf-life dictated by the performance requirements of the leading teaching and research methods. Therefore, they are more traditional in terms of their requirements for lifecycle management as they need regular updates to stay relevant and valuable. Does that mean that now we only work on incremental improvements to our existing complex systems?
Quite the opposite. What this means to our technology roadmap is that we have not a single cadence of product updates driven by external market conditions and changes in our technology stack but several parallel development cycles triggered by internal and external factors. I classify these development cycles into the following categories: maintenance, evolution, expansion, and exploration. Let’s look at the history of the QBot to illustrate how these types of cycles work in our team.
The original QBot was developed in 2009 as a new direction for our company. Blending our experience in control systems, multi-platform code distribution and communication, and research-grade autonomous systems, we decided to create a mobile robot for education. At the time, this would have been an exploration project as it was a completely new technology for our team that took time to develop. Years later, we recognized that the lifecycle of the processor, sensors, and communication stack was coming to an end. This external pressure triggered an evolution project to update the internals of the system for the next generation of teaching and research. This task was not considered a maintenance project because replacing the processor architecture meant the change was not backward compatible with the existing applications.
This update saw us invest in a new mobile base, sensor suite, processor, and communications to revitalize the platform. This project was also done in parallel with a much slower-paced expansion project, as the robot was integrated into the Autonomous Vehicle Research Studio to expand the relevant teaching and research potential. As is the case with exploration projects, the expansion project was triggered internally by a desire to stretch the platform in a new direction. In other words, we did not have to expand the product into a new area of academic research, but we were driven by a desire to bring more value to our customers. The next update to the QBot came in 2017 with the QBot 2e when we completed another evolution project to transition the platform to the Raspberry Pi. Finally, last month we released the QBot 3 evolution to update the processor, sensors, and mechanical flexibility of the platform. This was an especially interesting project in that it was triggered by a new external factor that has become dominant over the past two years, a supply chain shortage. In terms of project types, I would therefore call it a maintenance project that became an evolution to resolve a supply chain shortage while improving the product performance yet again.
An alternative to the supply chain triggering an evolution project would be the spectrum of products we have updated as maintenance projects alone over the last few years, from the QUBE-Servo 2 to the ShakeTable II, Hexapod, and Q2-USB. However, the cascade from maintenance to evolution can go one step further. As we continued to grapple with global supply chain shortages earlier this year, we had to trigger a maintenance project to evolve the new QBot 3 in parallel with its release. That project has since progressed from a maintenance update not to evolution but to a full-scale expansion. I can’t talk too much about the future of our mobile robotics family today, but I will say that I’m very excited about our plans to redesign the platform from the ground up. We want to offer a revolutionary platform for teaching and research not only in mobile robotics, but mechatronics, project-based learning, machine learning, AI, and more.
As our product mix and markets continue to evolve and expand, and we continue to spin up fast-paced maintenance projects to stay floating above the stormy seas of the global supply chain, see if you can tell with each incremental update to our products what triggered the project and why. Let us know what you think on our socials or in the comments.
