Comment by ModernMech | Hacker News Reader

Comment by ModernMech | Hacker News Reader

Honestly wish you all the best here! Truly, it's great that you're trying to simplify the deployment of robotics, because that would be great for everyone.

One thing I have to say looking at your website, is that is has serious "Underpants Gnomes" vibes.

1. Build in sim 2. Test in sim ... 3. Deploy on a real robot

Taking something from simulation and having it work "effortlessly" (as your marketing puts it) is sort of the holy grail of robotics. It's something that has confounded researchers and roboticists for a long time, so I'm a little bit skeptical as to whether your product actually lives up to the promises made in your marketing material. It would help if you showed more demos of what this means in a practical sense. In the video on your website it shows a simulated tractor, and then a tractor moving in an open field with no obstacles. This is pretty much the best case scenario, but how does it actually perform in more realistic scenarios?

Going into your FAQ a little, it seems to suggest the process isn't so seamless:

  We’ve built Polymath with the goal of a seamless transition from sim to reality (other than necessary-but-minimal tuning of controls).

"Necessary-but-minimal" is kind of understating how difficult sensor calibration and controller tuning is. It's all the difference between a simulated world and the real world (and also necessitates the need for controls and perception experts, which your marketing seems to imply are not needed or minimally necessary with your product). I'm curious how your product makes this process easier.

It appears like your value-add is that your product simplifies the whole ROS tech stack to some degree, but to me I would imagine transitioning from sim to reality without much work would imply that you have made real advancements in simulation technology. Is that the case? Or does your product mostly address improvements in the development experience?

Hello,

You are asking about the FAQs here: https://www.polymathrobotics.com/product

We are actually a hardware and real robots company first! Our simulator efforts are for two purposes: 1. Allow more people to try out our autonomy core, and build on top of our API 2. Allow our own developers to run testing and tuning in sim.

To your point, we don't expect tuning to purely happen in sim. However, we did have our senior controls engineer just recently tune up a controller in sim for Caladan, and later deploy practically the same thing to the real vehicle, leading to much smoother steering commands. We'll write about that in detail in the future.

Our work is to ensure that API commands that are sent in sim, behave as close to identically as possible on real vehicles, thereby allowing people who build on top of us to focus on higher level software stack (business logic layer, etc). Hence, users of our API don't need to have any robotics experience, they simply command the vehicle to do something, and we ensure it gets done. (and our team is comprised of perception, controls, ML, etc engineers)

The details of how this is done will be a future writeup, but the summary is that we pass sensors through a Hardware Abstraction Layer (HAL), along with kinematic/dynamic configuration and data about the vehicle. This allows the global and local planners to plan for a more generic vehicle (ex: Ackermann steering vs differential steering), while the HAL ensures that the planners don't generate unfeasible or unsafe commands.

Let me know if the above answers your questions!

When you say this:

  they simply command the vehicle to do something, and we ensure it gets done. (and our team is comprised of perception, controls, ML, etc engineers)

Do you mean you're offering control and perception engineering as a service?

No, sorry, let me be more clear.

Users of our API can send high level commands (ex: go to GPS coordinate X), and our software (on vehicle) will ensure it gets done.

Our software is built by a team of roboticists, including ML, controls, etc. The software we write ensures that the real world vehicle responds almost identically to the simulated one.

There are of course limitations, hence we do a commissioning step where we ensure the work we've done in simulation for a particular vehicle (sensor locations, localization fusion of sensors, controls tuning due to kinematics/dynamics etc) are tested and tuned on the real vehicle. This is done before the real vehicle is put into service, and remotely monitored (collection metrics on performance, status of sensors/actuators, etc).

Cheers!

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.

Okay thanks this clears up a lot! The … in the process that I noted in my first post sounds like the handholding you’re talking about.

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.

Had to look it up [0], as I didn't know it.

Side note: I'm always happy to learn a new reference, but most of them are heavily US-centric, and for people like me who didn't grow up in the US, and live or lived in the US in their adult life, sometimes it's a bit too frustrating, because there's just too much of it going around.

The worst of all is when the reference is killed by Italian dubbers/translators (in Italy you can rarely watch TV series or movies in their original language, which is very comfortable, but deeply damages your ability to understand cultural references, which most non-US foreigners would get because they watch the original English version of everything).

Anyway, just to give all of you some new perspective of how these things are perceived by some foreigners.

[0]: https://en.wikipedia.org/wiki/Gnomes_(South_Park)

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!

Reply on news.ycombinator.com