stefan8r

I seem to recall a time when they all left earth and thanked us for all the fish...

In fact, during our interview with TechCrunch we let Kirsten drive our unmanned test vehicle from her browser at home!

I'd challenge this assertion. Rio Tinto has been on the forefront of automation, but there's a long list of equipment they operate that they don't have an immediate pathway to automate.

To my knowledge, the main players automating ultraclass mining trucks are Caterpillar, Komatsu, Hitachi, and ASI. CAT has been working on autonomy for a long time, and to my knowledge only offers full driver-out autonomy on a handful of models. Sandvik also has some really cool see-and-repeat autonomy in underground mining. It doesn't surprise me if Rio Tinto is talking about a full zero entry mine (worth it just because no people to hit = faster driving vehicles = more production/yr), but to my knowledge they buy their autonomy from others and no one I know of (besides us) would automate all the various types of equipment that go into running a mine.

A different large mining co had an initiative to build their own autonomy, but the project got cancelled when it wasn't making fast enough progress and the CEO was replaced with someone more Caterpillar friendly.

We don't have in house mining experience - but again we're not building autonomy just for mining. We're building generalized basic autonomy so the folks starting mining-specific autonomy projects don't get stuck re-building the basic autonomy wheel.

I always liked this reference as I thought it applied to a lot of ML stuff.

Step 1: Collect Data, do some analysis, train a model or two Step 2: … Step 3: Profit!

Thanks so much! Glad to see you’re doing well!

Spot on. Except we’re just the onboard software (BYO HW)

Thanks - appreciate that. And thanks for reading my response in the right tone (I was nervous no inflection might do me a disservice).

I’m not familiar with Tangram, but thanks for sharing. I’ll take a look!

There is definitely a world where customers “graduate out” of using Polymath, people do the same with Stripe (I know Uber has been at that decision point in the past). There’s probably a reasonable cap on how much we can charge a customer as a result (more likely pegged to the cost of 10-100 FT roboticists) and in time we’ll have to offer enterprise level SLAs.

So far we’ve seen traction with startups, tech consultants who are servicing big industrial co.s, OEMs, and the large industrial co.s themselves.

My hunch is that as we stop “doing things that don’t scale,” we’ll stop serving the big industrial companies themselves (and leave them to our other customer groups).

Thanks so much for the kind words!

1) We are mostly built on ROS (for better and worse) and are starting to migrate some containers to ROS2. Down the road I see an architecture that has some ROS, some ROS2, and maybe some homemade stuff (or maybe even other frameworks).

2) Ilia should be able to give you a better spec overview, but we we’re generally trying to be as stack agnostic as sanely physically possible. Roboticists have really strong preferences when it comes to hardware (often shaped by which components previously ruined demos in their life), and we want to be able to work with whatever you want to work with.

Reach out re:internships! No promises, but now that we have a stack you can build on for free that will definitely affect our decision process!

To double click on the Twilio API example:

In most robotics applications teams are building the equivalent of new speculative phone networks, building specialized infrastructure, acquiring specialized hardware companies to ease computer:phone connections, and running out of money before they can find product market fit for mass texting some sort of consumer.

Sure, they can still integrate Twilio poorly and fail. Or they can build a use case that no one cares about - but at least they won’t need 5 years to get to that point.

Might be a bit of a misunderstanding here. We’re not providing a sim world for you to do ML training on. Caladan would actually be a pretty terrible tool for that - it’s a static low-res environment without any other agents.

In Caladan we’re giving you a whole autonomous robot (in sim) that you can order around via a simple API.

In our use case the 5-10% that I’m talking about is really hard, but most teams / projects run out of funding before they get to that point (because making the robot, and making it autonomous, is so time and cost intensive it dominates the project).

Thanks for sharing Jaybridge. I hadn’t come across them but will reach out / try to dig into them.

Thanks so much for the note and the kind words. Would love to grab a coffee or something! My email is first @ polymathrobotics.com, but I'll reach out as well!

Maybe we can play bocce instead of coffee?

This is a good, well thought out point that I 60% disagree with (respectfully, of course). I think you're absolutely accurate in describing how robotics is today, and you're definitely partially correct about how it will remain, but I think you're biasing towards thinking robotics (as a field) is exceptional to the types of progress that have happened in software.

To unfairly simplify that assertion, it reminds me of a founder who once told me that "robotics will never be as easy as software. It's just harder and will always be so."

I don't know if I think each autonomy company needs to figure out vehicle dynamics any more than I think each company needs to figure out their cloud infrastructure. At a certain scale (and amount of success) you will certainly need smart people thinking about it, but you can get pretty far on a 90% standard AWS instance. Things like wheel slippage are challenging, but their challenging in similar ways across vehicle types (but different from other tasks you need to work on when building that higher level autonomy).

Similarly, if you assume you can safely stop when there's danger, there are a relatively finite number of environmental conditions you should operate in - which we can build, maintain, and improve "once" as opposed to making every mining OEM or Ag autonomy shop build from scratch. In time, there might be certain portions of this stack that you can swap out with your own (or with some other company that's better at seeing in the fog, for example); but I fundamentally don't believe that every robotics company needs to solve all of these hard problems well on their own for every application.

Re:Sim - for paying customers we are putting their specific vehicle (and sometimes their environment) as a part of the offering. We're also using sim to help figure out how to position sensors (which will be another cool thing that we want to show at some point).

Ya video summary is nothing to sneeze at - I'll take my ML tasks as easy as determining if something is a person or a pixel /s

Completely agree on decomposing hard things.

Ish. To _probably_ annoy you and everyone on this thread, I'll tell you how this works for a "large publicly traded company that has autonomous vehicles in mines."

Essentially they have a portion of the mine site designated as the "autonomous pit," which is the only place where autonomous vehicles can operate. Not all vehicles in the autonomous pit are autonomous (basically no one can automate the vast majority of industrial vehicles, which is part of what we want to solve). In order to be able to see these non-autonomous vehicles, this PubCo makes the mine buy a $20-50k transceiver to put on every non-autonomous vehicles (in addition to the $1m auton hw upgrade and $250k/yr in autonomy SaaS).

These autonomous vehicles do have sensing, but they more rely on those transceivers to tell where vehicles they shouldn't hit are.

So ya, sure, it kindof works like how you think it should. But in a worse way.

To add to what Ilia said - re: - "The machine works good enough that it can perform the task until it can't anymore and then someone remotes-in to fix it?"

The machine will work good enough for basic autonomy, but then the real application-specific work begins. Whether that work is you modifying the behaviors you're having us do, you routing those systems to humans to help out, or you complaining that our stuff sucks (and us trying to rapidly improve it).

Ilia gave you the more real (and specific answer) but I just want to call out that I love the Underpants Gnome reference. I used to cite it a lot and was frustrated by how many times I had to explain it.

Sim =/= sim =/= sim. By which I mean - when some people say "build autonomy in sim" they mean lots of different things. Sometimes they mean solve all ML and data collection problems in a simulated world. We don't mean that.

When we say build and test in sim, we really mean that for just the earliest phases. Essentially - if you wanted to build Bear Flag Robotics 2.0 you could take our example app (lightweight Python app to tell a tractor to till a field), meaningfully improve it, show it to farmers to get LOIs, raise money, buy + outfit a tractor, and then put our autonomy on that tractor.

In that end state the behaviors you built out in Sim would still mostly work on the real tractor (same API commands both) and you could end up modifying those behaviors the way you would need to make them work in the real world. We would also be working with you closely to make sure our product is working well, solving new problems, and probably doing things that don't scale to help you be successful.

To add a somewhat easy sentance here - we're our actual product is delivered as SaaS (and it's not at Gmail pricing, it's more enterprise). Were you to become a customer we'd be pretty handholding with you to get the thing actually working.

There is a perception stack and a controls tuning stack within that SaaS that we'd be delivering.

Thanks so much! We had a fantastic designer, and our marketing/ops/cust success/everything else lead is really way better than we deserve!

You should get off the sidelines! Post-Starsky I wanted to run away from HardTech / FrontierTech and just do "easy SaaS stuff."

I was deeply upset to realize I was too broken to do something that "easy." (still, really hard). As a mentor of mine, Boom's Blake Scholl, has said - it's sometimes easier to do "hard" things because it's easier to get the motivation to work on them.

Re:Launch HN - I think so? You can always do a Show HN, though!

Thanks for the kind words!

Ya - I can't imagine how hectic it was for you guys. I remember hearing Josh Switkes talk about hand building radars for pre-2010 autonomy.

Re:booms/buckets/etc: right now we're just focusing on mobility (making these systems drive from A to B), specifically because those systems are deceptively hard. FWIW I think the guys at Built Robotics have done some cool stuff on it, as have groups like Moog and FP Innovations.

Thanks! It would be lovely if posting this one time in HN single handedly kicked off that ecosystem -> so everyone reading should quit their jobs and build robots /s

More seriously - there are a surprisingly large number of groups out there building robots and looking for help. Some groups already have not-built-here syndrome, but our hope is that by being a free thing you can just initially build on people will be "Polymath Native."

Your sim question is especially poignant. Our sales line is that reconciling sim:reality is our problem to solve for you. The more real answer is that we're specifically focused on vehicles in environments that are "relatively clean" - i.e. controlled (even if, in fact, they're a landfill). We're also only really selling to technical users - who are hopefully sophisticated to solve >0% of the problems.

To add to this - a neat thing about swarm robots is splitting the compute load between robots and figuring out how different robots move in conjunction with eachchoter. We're just focusing on the software that sits on the robot itself - so any of that coordination would be above our layer

And, I should say, thanks for the kind words!

We are using Gazebo for working on controls (getting Caladan ready to launch also led to a number of big improvements in controls) but not for ML training.

The point of Caladan is more for you to be able to build specific autonomy functionality without needing a vehicle, or a large plot of land, or a team to build a basic autonomy stack that works.

They can't. Trucking is an undifferentiated / commoditized service in a fragmented market. If one company increases pay to drivers, they can't increase rates to customers because they'll just shift their demand to someone cheaper.

As a results rates can't rise very quickly, which means that trucking companies can't really afford to pay drivers any better (obviously with some and slight exceptions, and only talking about US long haul trucking).