[owow123]

> 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.

Ah so the thing that actually takes 90-95% of the time? "Twillo" is no good to me if I dont integrate it properly.

I struggle to see what you've built here other than gym[0] with a largely useless API (Come on, ML training doesn't suck because of lack of HTTP API's), sure its hyper focused on automating vehicle but thats something that's existed for a while - atleast for drones [1].

Shoving sensors on random devices doesn't work that easy, you know that - I dont need a PHD to tell you that. Farmers likely aren't building prod grade ML data sets (except those SWE who gave up FAANG after making $BANK)

What's the real value prop? Why shouldn't I remake the environment in Gym and just cut you out? Gym doesn't require reams of code for environments, same as you.

[0] https://www.gymlibrary.ml [1] https://microsoft.github.io/AirSim/ (2017)

[stefan8r]

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).

[stefan8r]

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.

[iliabara]

"Shoving sensors on random devices doesn't work that easy, you know that - I dont need a PHD to tell you that. "

Definitely, a lot of our work goes into ensuring our Hardware Abstraction Layer (HAL) works well across vehicle types and sensor types. Check out some of my other replies here to double click on this.

For your other notes, Stefan's already covered it, but the TLDR is that we are building on vehicle autonomy, not simulation environments or systems (Caladan is just to get people an easy way to use the Polymath API, without needing a robot first :) )