He mentions in the video that he saw the idea in "a math exchange post" and he also has a link to the exact post in the video description. Doesn't that count?
The point was that it's just not his invention. He attributes it extremely clearly, no one is accusing him of theft. But you don't get math prizes for presenting someone else's ideas.
I work in robotics, I understand that every robotics company builds substantially similar core autonomy for different industrial vehicles, so I definitely see the value of what you're creating. However, every company needs to figure out how their autonomy will handle their specific vehicle's dynamics and their specific physical environment. For vehicle dynamics, they have to model things like wheel slippage on rough terrain, articulating joints on multi-axle vehicles, braking distance while hauling a load. For physical environment, they have to figure out how dust, fog, and poor lighting conditions affect their sensing and perception. Do you intend to make custom sim vehicles for each of your customers? Will you simulate each customer's particular camera/lidar/other sensor in their specific environment?
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).
I only have experience working in the robotics field as it exists today, so you're right that I am probably unaware of how things are done in the software world. (I mean I read HN so I'm at least somewhat aware, but I don't have first hand experience of it in my work, so maybe I just don't know what I'm missing). So in that sense, I'm rooting for your success in launching this company -- it would help accelerate and expand the robotics field!
I think the way you're bounding your addressable problem space -- industrial vehicles operating in a closed environment -- makes a lot of sense. I also agree that certain classes of problems (like wheel slippage) would be better solved "once" by an expert team rather than repeatedly by people who are actually trying to solve a different problem of higher level autonomy as you put it.
Some random other thoughts:
- your business model and offering sound kinda similar to [Tangram Vision](https://www.tangramvision.com/about-tangram-vision), though not close enough to where you would be competitors. I'm not affiliated with Tangram at all, I've never even interacted with them, just sharing what I've come across in my research.
- How do you think about how your customers join and potentially leave your platform? In your reply you mention a certain scale and amount of success where companies may decide to start doing this themselves, or even going to other companies that specialize more than you do (e.g. Applied Intuition for sensor simulation). It might feel a bit early to think about on launch day, I'm just curious about how you think about your company's value prop for customers at different stages of growth. Are you potentially limiting your market to only niche segments and smaller players? Who is your key customer you're targetting?
I appreciate your response and candor, I'm very interested in seeing your company take off!
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).
How does your stack integrate in with that of Rio Tinto?
They have, after all, been running remote and autonomous 100 tonne dump tracks and kilometre+ long trains for seven years now, in addition to being an umbrella across one of the largest mining fleets across the globe.
Hello,
Great question, I haven't seen enough technical details on their system to be able to answer definitely. However, from what I've read of their approach, it's fairly similar to the way we do things.
Perhaps this means there's no reason for Rio Tinto to use us, and that's totally fine. There are 1000s of other, much smaller mining companies that can benefit from the same tech, likely at a cheaper price than what Rio Tinto spent developing their own version.
Also, from our experience, these sort of approaches bake in assumptions on particular vehicle types/characteristics. So even in Rio's case, perhaps they have other smaller models, or other types of equipment they haven't automated. In this case, we'd be happy to integrate with their existing command and control software stack.
Rio has full fleet (bobcat, bulldozers, loaders, trains, underground mining speciality (uphole drillers, etc)) ambitions and they're working their way through them all.
Some of their talent date back to sheep shearing robots in the early 1980s.
In the same geographic region (W.Australia) there are related automata projects such as self recharging drone clouds about tractors, agri-bots (visual identification + weed spraying), integrated geophysical air survey, etc.
I was somewhat curious as to your awareness of all this (eg: Rio's plans for a full automated "bottom up" $64 billion copper mine in the US (should it go ahead)).
Also, while we're here, do you have any in house mining | industry experience driving tractors, dump trucks, ship loading, etc. yourselves?
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.
On a technical level, I'm not sure what sheep shearing robots in the 1980s has to do with automating vehicles... but I'd love to see a video/article if you've got one! :D
As with any large opportunity, there are multiple players in the space, both new and old. As seen with the "innovator's dilemma", I'm not sure I'd place my bets on tech straight out of the 1980/90s/2000s (sheep or no sheep ;) )
not totally clear if this is the point you’re trying to make, but the US today fits that description exactly
> killing/imprisoning a lot of your own population
the US has the highest incarceration rate in the world
> creating an economic climate where it was hard to sustain your family
the cost of housing has far outgrown the median household income and in many places you need 2+ income earners to sustain a household meaning nobody has time to raise children
Your link says Autopilot, not FSD. Autopilot is highway autonomy, which is vastly easier and you can rack up many more miles very quickly. This is not at all a relevant comparison.
How is this a moat for BlockFi? Why can't a competitor do exactly the same thing as BlockFi without paying the $100M fine? Asking this question earnestly because I actually want to know more.
> In Suits at common law, where the value in controversy shall exceed twenty dollars, the right of trial by jury shall be preserved, and no fact tried by a jury, shall be otherwise re-examined in any Court of the United States, than according to the rules of the common law.
> Here’s another thing about being a private company. What if this had worked? What if Goldman hadn’t noticed anything unusual and had coughed up the $40 million? Wouldn’t Goldman have been embarrassed when this story came out? Well, no, because this story never would have come out! Even if someone had told Goldman after the fact “hey that call with YouTube was fake,” what would they have done about it? They could call Ozy and demand their money back but presumably Ozy spent it. They could sue, but how much would they be able to recover? Once you’ve been tricked into investing in a high-flying startup, the only rational move is to hope that they succeed, clean up their act and go public at a higher valuation. You’d never go around saying “we were tricked”; that just destroys value.
> Similarly, if you are an investor and board member of a hot startup, and you find out that the co-founder impersonated a customer to try to trick someone into investing, what are your incentives? If you make a big deal about it and throw around words like “fraud,” it will be hard for the startup ever to raise money again, which might make your own investment worthless. If you say, meh, unfortunate one-time event, no harm no foul, then maybe the company’s vision will end up working out and you’ll be able to sell at a profit. If you invest in a startup you are buying an option; your goal, as a board member, is not to extinguish the option value too soon. Just, you know, let it ride, see where this goes.
GDPR is about privacy and security, not interoperability. It was (and still is) a very controversial set of regulations, so shoehorning in more requirements would have made it even more unpopular.
It only concerns file format right? I interpreted the preceding conversation as talking about format in the sense of data having the same schema and maybe being interoperable, and not just file format. Nothing I read seems to indicate that seamless interoperability is a requirement [0] [1].
Interoperability seems a little difficult to enforce, like brokers that don't support fractional shares might need to start supporting them to import data from other brokers. Edit: I guess this example is poor but I just wanted to point out that schema/interop also involves data domain, validation, etc.
It's about data protection, and giving users some means of control over how their data is used online. Privacy and security just happen to be the two very salient dimensions of that. If you read the GDPR wording, you'll see the phrase "data subject empowerment" pop up in various places, which is exactly what I'm after: more empowerment over what we can do with our data.
GDPR has its warts, absolutely. But I don't think that's a reason not to strive for even greater data protection measures for citizens going forward, especially if we amend the existing regulations to fix some of its unintended consequences.
> GDPR is about privacy and security, not interoperability.
Article 20 [RIGHT TO DATA PORTABILITY]
1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where: ...
There is no requirement in that law for a specific format, it just has to be something common like csv and not a random EDI file or binary blob with no schema.
