According to a report by Tractica, the global robotics market is expected to grow from $31 billion in 2020 to $245 billion in 2025, with the adoption of automation and artificial intelligence (AI) driving much of this growth. With such a significant opportunity for innovation and disruption, it’s no wonder that robotics companies and funds are on the rise. However, as with any new technology, there are risks and challenges to navigate
As specialized software developers for robotics, me and my team often work with early-stage robotics companies to help develop their first product releases. This allows us a unique vantage point to observe the strategy, hustle and some shortcomings in some cases up close. On the development front alone, building a robotics product comes with a myriad of challenges. Working at the edge of technology in the field ranging from hardware design to AI, miscalculations regarding development timelines, and over/under optimism regarding the underlying technology to name a few.
In an earlier post, I documented some pitfalls that robotics businesses face. In this blog post, we’ll explore some common mistakes that founders should avoid when starting up with autonomous robots.
1. Launching too many variants
One common denominator among successful businesses has been having a singular focal point of development. So has been its corollary. An unfortunate common practice of some startups has been an active effort to work on multiple robot platforms in parallel. The underlying assumption is treating them as equivalent and replaceable problem statements from a software point of view.
Think of an example where the goal is to build a robot to mow grass in the home’s backyard. It may seem reasonable to assume that if this problem is solved then commercial grade lawn mowing problem is solved as well. No!
It might require you to position and control your robot with greater precision for the backyard to cover every nook and corner within the said perimeter. An open field would be much more forgiving with accuracy so long as repetitive motion cuts all the grass. The difference in weights, controllability, reliance on GPS, battery management, and the list goes on — these problems are far from the same. A timely consulting, or meticulous analysis of underlying differences can save millions of dollars and several years of effort.
2. Too many features for the first deployment
Forcing perfection in the first release can drag you toward a downward spiral where nothing gets done. I recently had a development request for <2 cm navigation accuracy and <0.5 cm docking accuracy within…3 months of development time! The most valuable insight you can get for your robotic system is gaining access to real-world data for your application. Perfection might take years.
Consider a case where the goal is to deploy 5 robots for material movement on a factory floor to replace the efforts of 20 manual operators. Such a deployment is best undertaken in phases. What if one robot malfunctions? What if there is a loose cable or a malicious human actor in the loop?
How about deploying 4 robots in addition to five manual operators who can also provide basic on-field troubleshooting? It allows customer operations to continue without interruptions while providing the necessary data and time to improve the system.
3. Lack of data collection and analysis tools
Robotics businesses rightly focus on developing the core technology that powers the autonomy of robotic systems. Systems for OTA updates, data logging, and analysis are often put on the back burner. An autonomous robot consisting of LiDAR and multiple cameras generates 100s of gigabytes of product data daily. Some of this data can provide critical insight into system health, performance over time, and perhaps more importantly — legal cover in case of a hazard.
Unfortunately, not enough companies prioritize data collection, analysis, and storage.
4. Doing everything in-house
Autonomous robots are a relatively recent phenomenon. Some of the problems that are considered “solved” in the research domain don’t solve the use case at hand for real-world robots. It isn’t just a case of putting together already working pieces in a suitable order to fulfill your application. Each domain-specific robotic application has its own unique set of problems. For an arm robot, it could be a case of fail-proof grasping, for indoor AMR it could be a case of reliable localization, for an outdoor vehicle it could be making the system fully safe. All of these are problems never fully solved before in their respective domains.
The diversity of underlying technology that makes robotics an appeal to scholars is precisely what makes it a graveyard of several young businesses. To assume that a singular newborn entity can master the development of mechanical design, power circuits, core software, systems engineering and post-deployment infrastructure (telemetry, issue resolution, etc) is peevish. Start by developing as little as possible, purchase an out-there robot base if that serves the purpose, and write as little and necessary software as possible.
Conclusion
Starting a robotics startup is a challenging and rewarding journey. While there are several other aspects around cross-country regulations, legalities, liabilities, and frankly, just the sheer act of running a really deep tech business in a dynamic environment; this article focused on some technical aspects that are overlooked by first-time robotics entrepreneurs.
If you’re en route to starting your robotics product journey and facing challenges on your development journey, reach out to us!
.jpg)
