iliabara

In practice, for YC or similar Bay area US startups, they are the same.

All authorized shares are issued, and then the charter is amended through board action and more shares are authorized and issued at each stage.

Ya, I'd appreciate pointers if there are errors :)

This is US centric, it's mentioned on the first page, along with the notes and links.

Reinvesting is a minority, edge case. I can't think of a single VC company in the Bay area that can have founders reinvest shares and not cause issues raising.

Ya for sure, and even paid account is very cheap, few dollars a month

Thanks! :)

Depends on the outcome.

If it's a positive outcome, then preference has no role.

This game models good outcomes, with warnings for things like down rounds

Hey thanks!

There are a ton of edge cases, but the goal was to serve as an intro, and to get a grasp of the basics.

Links in the intro to a more serious look at things.

Quick honest question: What benefit did Viam bring that isn't brought by ROS for this project?

Hey all, this is from a team member of mine at Polymath Robotics.

Ask/comment away!

Absolutely part of the plan, there will always be strange situations that the vehicle can't adapt to. So it has to stop and phone home.

Our current test vehicle uses remote operation a lot!

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

To answer 2. in some more detail: We generally like to have GPS, cameras and lidar. Optionally, we add in IMU, radar and close in sensors (ie ultrasound).

We are approaching the ML problem somewhat differently, we try to give the robot an understanding of navigability of a space. This is done with semantically segmented images, overlayed with depth data where needed.

Once we have this, we flatten it into a 2d costmap of areas where kinematically (ie: ground clearance, terrain handling ability, allowable areas, etc) the vehicle is allowed to go. This is fed to our planner, which in turn generates valid paths for the vehicle to take.

The particular cameras and lidars used are abstracted away in a Hardware Abstraction Layer (HAL) that I've described a bit elsewhere on this page.

Cheers!

"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 :) )

There's always room for one more simultaneous startup ;)

Thanks, we sure hope so!

This is exactly correct, Caladan from Polymath Robotics is just a cheap and easy way to get a bunch of developers to try out our (fairly basic so far) API, and to start thinking about the business logic and applications that could be built on top of this.

Our actual product is autonomy on real vehicles.

We don't plan to ever build any kind of high fidelity sim, just sticking to basic Gazebo or similar.

That's a great way to think about it, you are describing it exactly correctly.

Ah ya, debugging in real environments is a very difficult question, particularly in robotics where the system is complex, and not always with the best internet connectivity.

The approach we are taking to this is two fold: 1) Robust self monitoring and metrics, ensuring we measuring system performance (we are using Prometheus to allow us to scale to (hopefully) millions of devices. 2) Ensuring we tie those metrics to a rolling buffer of the last 90 seconds (or so) of data. When an issue occurs, we automatically save to disk, and allow remote operators to pull the raw sensor data as needed.

With the raw data, we can (and do!) play this back through our stack and step through the behavior tree and control outputs, comparing them to what actually happened on device. The system is certainly deterministic enough to allow this sort of debugging and testing!

We will have a set of articles on this approach in the future!

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.

Hey all, Ilia here.

I just did a quick follow up with a demo of our API driving our real tractor, and simulated tractor, simultaneously.

The API used is the same, and we are sending the same commands at the same time to each vehicle.

Check it out here: https://youtu.be/86pBFbTHPOA

Hey,

No, we haven't looked into formal tools like that, good suggestion! TBD on if these approaches bode well for real world robotics, (due to model complexity and model/real world fit problems) but at least there seems to be some applications to path planning and controls: https://ieeexplore.ieee.org/document/5509686

I'll pass it on to the controls team!

Hey!

We don't train in simulation (if you are talking about ML training). Our ML training is done purely using real world data.

The simulator is to allow developers to "test drive" our autonomy core and API for free.

We have real vehicles as well, but you can imagine it's more expensive, time consuming, and generally slower to let people test on real hardware. Hence, if people like what they see in sim, they can get in touch with us to deploy their code to real machines on a case-by-case basis.

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!

Thanks for the kind words, and awesome that you were on a DGC team!

Absolutely, there is a ton of really interesting controls, ML and general software quality work for us to do.

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!

Hey, Ilia here :)

This could be built, but unsure it'd make sense in terms of required compute on each small robot. What would be the use case you are interested in?

Hey, Ilia here :)

Not sure if the question is about the simulator Caladan, or about our autonomy core.

For Caladan, we don't support playback of data currently. Do you have a use-case need for this?

For the autonomy core, the localization, costmap generation, and path planner are all probabilistic to a more or less degree, so we can't guarantee determinism to any highly accurate degree. However, if the same data is played back over and over, the vehicle would react in basically the same way (perhaps not navigating to the exact same spot, but within a small tolerance). Same question here; what is your need/use case to have guaranteed determinism? Is it a safety question? (We can have a much longer chat there)