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.
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.
"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 :) )
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.
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.
All authorized shares are issued, and then the charter is amended through board action and more shares are authorized and issued at each stage.