Hey HN,
I’m Stefan, one of the founders of Polymath Robotics (https://www.polymathrobotics.com) and formerly of Starsky Robotics (YC S16). My co-founder is Ilia Baranov, a career roboticist. We’re building general autonomy software for industrial vehicles.
We’ve just come out of stealth with a full autonomy stack freely available in sim online. Whether it’s a tractor on a farm or a 400t dump truck in a mine, we make it easy for you to make it driverless. Where before you would need an industrial vehicle, $25-150k in sensors + compute, and 6-18 months of building time, now you can start building applications that command autonomous robots right away.
See a demo here: https://www.loom.com/share/852d54744d45452d926b9016f61f5e43.
Two big things are hard about automating industrial vehicles: first, robotics is deceptively hard. But also, industry is nitpicky. These two together are too much for most startups. That is, if you put all your energy into the first—the noble effort of getting the robots to actually work— the second will end up killing you. We learned this the hard way at Starsky, and what we’re currently working on at Polymath is a way out of this dilemma.
At Starsky, we were working on autonomous trucks. We knew that was a hard product to build, but I didn’t really have perspective until I went and hung out with SaaS companies afterward. My SaaS friends use horizontal services at every layer of the stack. Payments? Just plug in Stripe. Messaging? Twilio. Libraries and tools exist for everything. Your thing goes a lot faster when you can just buy the rest of the stack.
Contrast that with Starsky, where we were building our own robotics stack completely from scratch. That meant the autonomy itself (our actual product, and really complicated on its own), but also custom teleop, a drive-by-wire system, hardware abstraction layer, and fleet management system to orchestrate all the trucks via an API. Each of those things could be a company in itself! Imagine trying to debug a stack like that when something’s not working.
That’s sort of just how robotics is today. Like software in the 80s, everyone’s rebuilding the whole stack for each new project. So the tech gets super complex, brittle, and unadaptable. In fact, an open secret in the robotics world is that most demo videos you see are “cooked,” because the robots are so unreliable in the field.
I got to know many of the folks building industrial autonomy vehicles from 2016 onwards, and saw a depressing pattern. Brilliant, mission-driven engineers would get a start with a healthy seed round from investors who thought it was “just” an execution problem. After 18-30 months the teams would have a prototype that somewhat worked, but what they wouldn’t have yet was the commercial traction needed to justify more fundraising.
That brings us to the other half of the dilemma: industrial customers are nitpicky. When it comes to scaling an autonomous vehicle POC (proof of concept) with a large industrial company, they’re surprisingly unimpressed with autonomy. Sure - the first time they see a driverless vehicle their jaws drop and they ask about safety. But like everyone else, they quickly assume it “just works” and start asking whether it will integrate with their Oracle instance. Then they start nitpicking the specific way the tractor drives across the field / the luggage tow stops on the apron / the dump truck pulls up to the processor / etc etc.
In other words, after the initial POC, industrial autonomy stops being sexy-super-hard-technical and starts looking like Enterprise SaaS. Except by then the team has spent 2 years heads down making autonomy (the hard part!) actually work rather than talking to customers. As a result, they’re not up on the top 20 things customers care about and they don’t end up with product market fit. Few startups make it out of that pincer squeeze.
All this to say … what we’re building at Polymath is a shortcut to autonomy for industrial vehicles. We make it so you spend less time building / maintaining undifferentiated basics, and focus instead on the 5-10% of the application that’s hyper specific to your industry / vehicle / customer. Just like our friends in SaaS.
Since we’re just building the autonomy layer, we can focus on getting the tech reliable, stable, and scalable. Our users can build their own custom behaviors, or integrate with apps, or whatever it is that makes their robot actually useful, on top of the Polymath autonomy core.
The software can be installed on virtually any large outdoor vehicle, as long as it operates in a controlled environment. Focusing exclusively on closed environments is partially a cheat code. It lets us assume the vehicle can come to an immediate stop if there’s trouble, or be teleoperated by a human in dicey situations—all the constraints that mean we don’t have to be Waymo or Cruise.
Polymath autonomy includes localization, navigation, controls tuning, obstacle avoidance, and a safety layer. Importantly, we also built a hardware abstraction layer, which lets the whole thing work across different vehicles and sensors.
One thing we’re doing differently this time around is buying (rather than building) parts of our solution wherever possible. Again, part of that “make robotics more like software” thing. So we’re using Formant for teleop, Gazebo for sim, and for customers that need hardware installation, we have a partner called Sygnal that does awesome integration and retrofit work. (And, almost obviously, we’re built on top of ROS [Robot Operating System, the standard framework for building robots).
We also have our own demo vehicle, a tractor affectionately nicknamed ‘Farmonacci’, that we use to run unmanned testing daily. You can see a shiny demo video of it here: https://youtu.be/bP0mNG53bVw
And now the part I’m most excited about… You can start building on top of Polymath autonomy today, for free, in sim, with a tool we built called Caladan (yes, the name is Dune-inspired).
Caladan is a set of simulated vehicles and environments where you can interact with Polymath’s autonomy via Rest API. That means you can build autonomous vehicle behaviors and applications in your preferred programming language, without having to touch ROS. So, even non-roboticists can build an autonomous vehicle application pretty easily. To my knowledge, we’re the first to build an autonomy product that’s this accessible, and especially something that you can use for free (it’s funny that roboticists, a group least interested in talking to sales people, is super forced to).
We built Caladan by bringing our autonomy code into a standardized Gazebo environment, with a Rest API that allows you to command it in any language (without needing to know anything about ROS).
The cool thing is, you can transfer the same code you write with Caladan to a real vehicle. We’ve tested it out with Farmonacci, and we’ll select people who are hacking on top of our simulated vehicles and give them testing time on Farmonacci as well. Part of the idea for Polymath is to take robotics off of ‘hard mode,’ and help teams build robots that are stable and reliable right from day one.
For now, it’s entirely free to use Caladan. Since each instance is a cloud-GPU, in the next couple of weeks we’ll ask people to pay if they want consistent access (but there will always be a free version). We want to make our money automating your actual robots, and we’ll also charge if we have to do too much custom stuff for you in sim. But, of course, we have startup-friendly pricing if you talk to us.
So please, sign up for Caladan at polymathrobotics.com and mention that you came through HackerNews (we’ll prioritize spinning up your instance if you do). We can’t wait to see what you all build. We’ll be around in the thread and look forward to your comments, ideas, and feedback!
