stefan8r
Joined 11 years ago
Joined 11 years ago
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.
Step 1: Collect Data, do some analysis, train a model or two Step 2: … Step 3: Profit!
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).
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!
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.
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).
Maybe we can play bocce instead of coffee?
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).