Labor is one of the most expensive parts of running a business. So just doing the math of, if we spend X amount of money on robots and can layoff Y amount of people then it's a net gain. Especially if a single machine can replace multiple people.
Also fixed equipment / robots do not ramp up when the demand increases.
On the other hand you can always hire more
People to sort more packages. You don’t even need a building, a tent would suffice.
What these companies do is conceptually very simple. Basically sortation of items at different granularities and locations. Not comparable with manufacturing companies.
Only sometimes and costs change over time. The first robot is almost always more expensive than a human, but the second robot comes after the design is done and so it generally cheaper than the human (accountants will figure out how to amortize these costs and thus give us a better picture of costs.)
Robots also get cheaper over time because we learn. You can buy many parts in bulk including computer libraries to control them. You can find many people who know best practices who will not make some of the early mistakes that cost money.
I've picked orders. If I have to touch your purchase for 20 seconds it is a very long time. There are 180 chunks of 20 seconds in an hour. If the pay is $45 per hour it would cost 25 cents.
I blame the transit agency for those missteps though - it doesn't have to be like that.
Take for example CUMTD (mtd.org), the transit agency serving Champaign-Urbana, a college town in Illinois with about 200k people. It's an excellent bus system, everyone in the city loves it, the people running the place always embrace new technology, and they actually have a hydrogen plant setup in their depot and the plant is powered 100% by solar energy: https://mtd.org/inside/projects/zero-emission-technology/
1X is different. This is purely a hardware demo, they are doing pure teleop on the software side, no AI in the demo (except maybe RL for walking). 1X's bit thing was always their mechanically compliant safe hardware.
It's teleop, they are pretty open about it. It's not autonomous.
They do have an RL controller running for the legs, but it's just an intermediate controller and it probably get high level commands from a teleoperator. The upper body is purely teleop.
So you're paying someone to operate your robot on top of the cost of the robot?
I'm very skeptical, even if this technology worked flawlessly, that this would scale towards a profitable business. I understand that not every robot would require 24x7 human assistance, but still - this is a very optimistic business model.
Robotics has always been in competition with minimum wage labor. How long could you hire a maid before making a return on the cost of the robot? And that's assuming the robot isn't worse, which it is pretty much guaranteed to be.
Their thesis is that you cannot get the training data for a robot in the home from a lab or a simulation. You have to actually put a robot in real homes with all their messy details.
But, how to do that safely? First they build a robot with low gear ratios, low weight, pinch points covered. So, if it literally falls on you it’s low risk.
Then they have humans teleoperating it in first-person VR with 1:1 hand control.
The more times humans do any particular task through the robot, the more the robot learns to do that task in real world situations.
It’s the most thoughtful plan for robotics I’ve seen yet by far.
Considering the slew of warehouse automation robotics companies I've watched fail, trying to do much simpler tasks in highly controlled environments where they can be surrounded only by trained individuals, "ambitious" would be an understatement.
I get what they're trying to do. I'm pointing out that it's probably an order of magnitude harder to do than many other things that have consistently failed. This is like Elmo coming along and saying The Boring Machine will replace cars and trains. It's a fundamental misunderstanding of the space and how to disrupt it while selling ambitious ideas under the guise of being clever.
Teleoperation could be useful with geo arbitrage. Whats the cost difference of hiring welder, plumber, cook, maid, taxi driver, security guard, receptionist in US comparing to LATAM or SEA countries? You could pay someone 3x market price of those cheap countries and probably still this would be 2-3x cheaper than in US. I think this is still a huge market even if those robots won't be autonomous.
When Valve came out with their VR headset that had base stations, everybody thought that’d be the holy grail, that you can never achieve better localization and tracking without base stations, and a base station free method can never be better than that.
Well, Meta poured a shit ton of money into making Quest base station free and they got there. We use to use valve setup for our robotics applications but we swapped it out with Quest cause honestly Quest was as good but much more easy to setup and operate.
The bitter lesson is that don’t bet against data or compute. Also, I don’t think you’d have to train a AI model for each location at every time in the future. Things get more efficient, etc.
I am a robotics engineer/scientist and I do shit ton of visualization of all kind of high-fidelity/high-rate data, often in a streaming setting - time series at a few thousand Hz, RGB/depth images from multiple cameras, debugging my models by visualizing many layer outputs, every augmentation, etc.
For a long time, I had my own observability suite - a messy library of python scripts that I use for visualizing data. I replaced all of them with rerun (https://rerun.io/) and if you are someone who think Scipton is exciting, you should def try rerun too!
I use cursor/vscode for my development and add a line or two to my usual workflows in python, and rerun pops up in it's own window. It's a simple pip installable library, and just works. It's open source, and the founders run a very active forum too.
Edit: One slightly related tid-bit that might be interesting to HN folks. rerun isn't that old, and is in active development, with some breaking changes and new features that come up every month. And it means that LLM are pretty bad at rerun code gen, beyond the simple boilerplate. Recently, it kind of made my life hell as all of my interns refuse to use docs and try using LLMs for rerun code generation and come to me with a messy code spaghetti. It's both sad and hilarious. To make my life easier, I asked rerun folks to create and host machine readable docs somewhere and they never got to it. So I just scrape their docs into a markdown file and ask my interns to paste the docs in their prompt before they query LLMs and it works like a charm now.
> So I just scrape their docs into a markdown file and ask my interns to paste the docs in their prompt before they query LLMs and it works like a charm now.
Huh. Nice hack. I may have to give that a try for some of the more obscure stuff I deal with.
> Recently, it kind of made my life hell as all of my interns refuse to use docs and try using LLMs for rerun code generation and come to me with a messy code spaghetti. It's both sad and hilarious.
I'm really agog at this. Do your interns understand that if they're just an LLM prompt injector, their job can be done by anybody? I haven't bumped into this yet, but I think your reaction was a lot more positive than mine would have been.
I know that I certainly wouldn't be rehiring any interns that gave me that kind of grief.
I am not the hiring manager, and unfortunately a lot of interviews and hiring decisions happen at org level or at my manager level. These are mostly sophomores/juniors - folks who went through school in post-COVID, post-LLM era with a lot of virtual classes.
I tried my best to explain it to them, and nudge them to using docs. I did live debugging sessions with them to try and 'teach' them how to use docs. Ultimately, it was taking away too much of my time for little to no return. I only started working in the industry like a month ago and it's my first time having interns that I didn't pick (back in school, I had undergad research assistants that I interviewed/selected, and they were all excellent) - still learning the ropes.
We did recently add an export for LLMs[1], but weren't quite confident in how the big models handled it. The biggest issue we kept running into was that it would prefer using older APIs over the latest ones. I tested it just now with ChatGPT, and it seems to be doing a lot better!
The export is kept up-to-date with the latest contents of our docs, which update every release. Sometimes a bit more frequently, if we're doing drive-by doc fixes.
I am impressed by the AI integration and simplicity of Data Formulator from Microsoft Research which runs one click in a Codespace so can't be much easier to get started throwing things together.
Just a note: ReRun works out-of-the box for a number of uses, but I ended up switching to my own (simple, visualization-oriented) engine based on WGPU and EGUI (ReRun uses both of those as well), so I had better control over the camera, visualizations, snapshots etc.
For magnet levitation project I am dumping data to a csv on a rpi and then reading it over ssh onto matplotlib on my desktop. It works but it choppy. Probably because of the ssh.
Could I drop rerun into this to improve my monitoring?
Yes! Rerun can definitely make your life a lot easier!
Rerun natively supports the server and the viewer being on different devices (https://rerun.io/docs/reference/sdk/operating-modes). In your case, in the script you are dumping data into csv, I'd add the relevant lines to log data to rerun.
On the desktop side, you can spawn a viewer that can listen to the stream and visualize it.
> But that's not a GUI, that's notebooks. For Jupyter integration, TIL pyqtgraph has jupyter_rfb, Remote Frame Buffer: https://github.com/vispy/jupyter_rfb
I've had rerun bookmarked for a few years and this comment is enough to persuade me to finally try it out. Currently I resort to notebooks for simpler stuff and just spinning up a quick GUI for anything more, I've always found the middle-grounds just as much work as having my own UI and less powerful. Using frameworks like IMGUI, spinning up my own high-performance video and plotting was as simple as <100 lines of code, and also gives me a base of something which can be shipped to a client if neccessary.
> So I just scrape their docs into a markdown file and ask my interns to paste the docs in their prompt before they query LLMs and it works like a charm now.
i found with aider if you do README.md with a halfway decent "spec" it will try to comply in architect or coder mode. I've been messing with it idly, and i will try this tack - give it the spec for the library or whatever.
someday, and i threaten this all the time, i am going to launch a website where i put all of these little "tricks" that make sense post hoc :-)
Rerun is exactly what we have been looking for years. A game engine for the visualisation of multidimensional data without all the game 3D knowledge. I have so many questions!
(Can I access a mmap file, display it in real time with rerun and save a history at the same time?)
zip codes don't even need to be contiguous. It's a mail delivery route, not a polygon.
There are 5 cases where the assumption is violated:
- Non-contiguous areas
- Zip codes that are a single point (some big companies get their own zip with a single mailbox, e.g. GE in Schenectady, NY is zip 12345)
- Zip codes that are a single line (highway-based delivery routes)
- Overlapping boundaries (since mail routes are linear, choosing a polygon representation is arbitrary and often not unique in space)
- Residents of some zip codes are not stationary (e.g. houseboats)
In short, asking questions about the area of a zip code is a category error - zip codes do not have a uniform representation in space. And we should be highly skeptical of any geospatial analysis that assumes polygons.
They do provide a location with whatever error bars on it.
What they do not have is any sort of spatial consistency, they are a convenience for mail sorting. So if you start analyzing patterns across zip codes, you are pulling in information that is likely useless for or harmful to answering your question.
It might be true, but does it help if the x varies from "on a nearby mountain" to "within a street block", and you sometimes have every habitants closer to another zip code than theirs ?
reply