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!
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)
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!
There is a perception stack and a controls tuning stack within that SaaS that we'd be delivering.
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.
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.
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:
"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?