great history. one of the hidden gems inside: "the wildly successful ROS operating system. ROS is used to this day by enthusiastic researchers and frustrated companies who can’t figure out how to migrate off of it"
ROS usage is a great quick way to evaluate the doofusness levels of an org. It's such a dumpster fire on every level, no reasonable human should be going within a mile of that thing.
I keep hearing this as some sort of "common knowledge" but no one can really lay out why. I've shipped stuff with ROS (albeit with some custom modules that needed customization).
But genuine question, has some who has actually shipped with ROS laid out what they would like it to do better?
I've tried a few times to get into ROS for personal projects. I guess I understand the gist of it, but I still don't understand it.
Suppose I've got a motor, a motor driver, and an Arduino. How does ROS work with that? There's all this message passing and distinct blocks of stuff, but how do I get my motor to turn?
I'm sure there are tutorials out there... I get tired trying to approach their docs. I typically understand things from the ground up or from the top down. Their docs seem to start in the middle and work up/down at the same time.
[edit]
What are my alternatives in this space? What is better than ROS?
> Suppose I've got a motor, a motor driver, and an Arduino. How does ROS work with that?
It does not, ROS is for much bigger systems, usually Linux-based. Some things it can give you:
- IPC for multiple independent processes. So if your navigation process crashes, your drivers and controller still operate. Can save some time if your stack is slow to start up.
- Visualizer - not the best out there, but kinda-working. And because of previous item, you can keep it off (to save CPU) and only start if needed.
- Device drivers for some devices. Those would be "research grade" - any problems would be ignored and may result in invalid data, or they can crash, or be very inefficient... But good enough to get started.
- Logging/replay - log data to file, replay later. Again, research grade - there is no schema evolution (at least in ROS 1), so the moment you add new field, throw away your old logs. You can also use it to make whole-system tests, but because there is no explicit sync, those tests would be janky and flaky.
- some pre-made modules, like localization
it's a lot of small pieces, good enough to start or for prototype, but not for the more "production" robots.
As far as alternatives... All orgs I have seen do their own. Some of them start with ROS and eventually replace every part, others start entirly from scratch.
The setup you describe, "how do I get my motor to turn", is lower level than ROS. Typically if I had a robot with a microcontroller to control a motor, I'd write some bespoke code (or find libraries, such as Adafruit's for example, probably) for my particular hardware. Most recently, I've just asked ChatGPT for such code (having done it myself the harder ways in years past, so admittedly I know reasonably well what to ask...).
Once you achieve code that moves the motor at various speeds or directions, you might e.g. connect to the Arduino from a computer (e.g. raspberry pi), write a python "ROS Node" script that listens to a ROS topic and sends serial commands from the Pi to the Arduino.
Then, if you attach a laser range-finder or 2D lidar to the Pi, and look for a corresponding ROS node for that laser hardware (on github via google), you would run that additional ROS Node...
And finally you might write the "main" script as a third ROS Node that:
- Interprets the laser data it gets from the laser node's published ROS topic
- Has some logic for the robot that interprets that data and chooses to set speed/direction of the motor.
This is all very ad hoc description but hopefully somewhat helpful... You also asked "what is ROS", to which my own typical answer is: A framework for Nodes to communicate with each other, that happens to have a lot of open source nodes available for common hardware.
(I write this with ROS1 in mind, having hardly touched ROS2)
ROS is a collection of mostly-independent components, each of which is a not-as-good implementation of existing tooling. The implementers and the users mostly haven't grasped how to use the existing tooling, and the whole community is full of the blind leading the blind. Alternatives for what? The build system? The IPC?
> Alternatives for what? The build system? The IPC?
Honestly, I don't know. I don't even know what ROS is.
I could spec a multiplatform (computing and embedded with sensors and controllers) system, and come up with something like messaging on a CAN bus between different bits of the system and compilation targets for each piece of the system... Is that what ROS is?
it's a collection of tools bound together by a common build system, set of libraries, and a messaging system with a bunch of tools for introspecting and debugging it. It is, in principle, most of the kind of stuff you want for developing a robotic system, it's just each part is not very good, and it strongly encourages a distributed architecture that more or less makes every problem harder, especially ones which are latency sensitive, like most robotics.
Unfortunately there's no unified alternative: your alternative is to basically just put together a similar system from third-party libraries. It's a bit of a pain but not fundamentally that difficult, and you can salvage what's useful from ROS with less faff than dealing with it.
Here is the sad news: That is what ROS should be but isn't.
I'm constantly wondering why the heck I would need a framework designed for distributed IPC, if I can't run ROS on my motor controllers and have ROS manage the CAN bus messaging? You'd think that I2C, SPI, CAN, LIN, etc would be the standard protocols between nodes, but nope, it's some TCP or ethernet based DDS, which is both swappable, but yet that swapping buys you nothing.
Modeling every micro controller and even the peripherals the micro controllers are connected to as nodes in a distributed system sounds like an amazingly useful concept that would be worth years of investment, but the ROS guys seem to stay very clear of anything that could be of use to someone.
ROS is the equivalent of protobuf + gRPC + Go + bazel for robotics but with some XML and bespoke C++ stuff and more academia who'll stop maintaining their project once they get their PhD and without Google or any other big funding source since Willow Garage went away.
The problem with Google's robotics acquisitions was that they fired Andy Rubin less than a year after he made them. They floundered after that.
It's clear that Google's management simply didn't have the patience to continue putting money into hardware development before the software was ready. They forced premature commercialization on BD and then dumped them on SoftBank. Strong top-level executive support could have changed that. I wonder what Google robotics could have been.
Yeah, having been there during Andy's firing I can vouch that the thunderdome era of replicant actually intensified after he left (and lasted until boston was sold off and the rest of us moved into X) but nuance is hard and less funny and I did warn folks that the history is mostly wrong... ;)
Worth remembering he was fired due to sexual harassment[0]. While Google did the right thing in firing him, they deserve far more criticism for the cover ups. Both of which are frankly unacceptable
Given the choice between having a sexual harasser on staff, or missing out on a billion dollars of profit, every company in the world will choose to keep the sexual harasser and the profit, so that can't be the only reason.
As stated in the article, it's a reference to a piece by James Iry on programming languages. From the title I expect something wrong, funny, but mildly insightful.
On rereading the thread, maybe I'm just misreading? I read your question as "they're popular, why do people think they are not" but you could also have meant "why doesn't anyone want them".
For the latter: because it's far higher friction than a phone call (or any similar tool). On the extreme end, I can walk into a meeting room and push a couple buttons and have a zoom meeting. And doing that with your computer or phone is significantly easier, often just one or two buttons whether you're a two person business or 200k.
Versus telepresence robots at the simplest: it requires charging, far more complicated UI to do anything that a video call cannot do, and is many times more expensive so you almost certainly do not have one everywhere you have a video-call-capable display. And the display is probably dramatically smaller, so you still need a separate display if you want to show anything useful. For very nearly everyone, that's just "a video call with extra baggage".
They can work just fine where those tradeoffs are offsetting vastly more expensive and higher friction things, e.g. in highly specialized surgery, and you do see them in those areas. That's just a rather small niche compared to "has a computer or phone".
Firstly: By the time your organisation is big enough that nobody will bat an eyelid at buying a $4000 gadget, it’s big enough you’ve got several buildings with several floors. Probably some doors too.
So you don’t need one robot, you need ten. And if it works really well and it’s a big hit? One per floor won’t be enough.
Secondly: The expense and maintenance burden fall on the recipient of calls, but most of the benefit is to the person making the call.
I benefit as the caller, as I can trundle over to someone's desk and interrupt them - but the benefit to them as the recipient is much more indirect.
Thirdly: Pre-pandemic, a lot of video call stuff was pretty unreliable, making the expense of a robot a risky matter. Post-pandemic, far fewer people are in a physical office - it's not like there are important in-office meetings that only have a single remote attendee.
I used to work at a research institute that had two campuses on either coast and we had those "iPad on a stick" type telepresence robots so people on one coast could attend (physical meetings) on the other. They eventually went away because more and more meetings either became virtual or were hybrid-virtual physical and so a laptop could work just as well as telepresence.
I was hoping to see a mention of Odex 1 by Odetics. I was working in a printed circuit board factory at the time (1983), and we got to build boards for it. Later on, there was a demo where it lifted one end of a small pickup truck off the ground.
I'm going through a breakup right now and really enjoying posts like this. Interesting, funny, accessible. The Grug Brained Developer also really hit the spot. Any other recommendations in this vein? Thanks!
Real answer: [1][2] From Chicago Dryer. It's boring, reliable, practical equipment for the huge laundries that service big hospitals and hotels.
The machines look big and dumb, but there are vision systems in many of them,
inspecting, separating, and finding corners. Robotic grippers grab items where necessary.
Industrial-strength dish cleaning has been demoed but does not seem to be deployed.[3]
Vision-language-action models seem to be the broad category for the best approach, which basically combines a large vision-language model with robotic actions. For example, see https://www.physicalintelligence.company/blog/pi0
if you have a good dishwasher and don't overfill it, you probably are over-washing by hand. with two dishwashers (one dirty, one clean,) and most of the problem is solved.
I've seen a lot of people claim this for 15 years, but every experience I've ever had with minimal or no handwashing of dishes before putting them in the dishwasher has resulted in visibly dirty dishes.
It's possible that the (several) dishwashers I've used have been "not good enough," but if so I suggest most people's dishwashers aren't good enough.
Father here with a family of 4. our dishwasher runs multiple times per day and we never hand wash before, and I can tell you that the dishes tend to be very dirty before they go in.
They always come out sparkling clean.
Here is what works for us:
- keep the salt tank filled as well as the rinsing agent. Don’t use these tabs which claim to have all of this in there combined.
- don’t overload the dish washer
- clean it regularly. Once per week I take out the sieve at the bottom, clean it (takes less than 5 minutes) and then I use one of these bottles of cleaning fluid with a wax cap. You put it in, start a cleaning program, the wax melts and the fluid does its work.
That’s also when I refill the salt and rinsing agent. Total time effort per week: 15 mins.
We have a low mid-tier dish washer, but I had the same results with cheaper ones.
Okay, a heated debate in my slack group is now going. We need more deets:
* When you say that you don't hand-wash, can you clarify? Does that mean you just take the dish and put it directly into the dishwasher after throwing any large chunks of food away? Or do you rinse it or even soap it, you just don't scrub it thoroughly?
* You mention washing the dishes multiple times per day. Does any food actually dry on your plates before the dishwasher gets run?
* You don't have a problem with fingerprints or lipprints on glassware?
* Do you feel like the salt tank has benefits beyond hard water mitigation?
I guess I want the robot to do all the work -- loading and unloading does take a good chunk of time everyday. Same thing with loading / unloading washing machines, and folding clothes. Just good ol' housework that should be automatable. I was wondering whether anyone has seriously tried - and what the sota is.
Just awesome stuff: "Tesla deploys thousands of their Optimus humanoids working in their automotive factories.1 The robots are slower and less productive than human workers, but make up for it by being more expensive and harder to train."
There is exactly one joke by ChatGPT. For Stability AI's CEO's prediction that there are no longer any human programmers by 2028 I liked the idea of referencing Stanford's intro to CS class which is semi-famously a bell-weather for the tech industry. My original replacement class was "Growing food for Sustenance" which kind of worked but I thought was weak. I asked ChatGPT for alternates and it gave me about 15, of which "Barter Economics and Goat Management" was clearly the funniest, and annoyingly funnier than mine.
“””
2035: AI is 10,000 times smarter than the smartest human.7 It composes “A Brief, Exhaustive and Completely Correct History of Robotics” which is much funnier than this one.
I had a dickens of a time with the ending. Having it end at the present seemed super abrupt (as it really feels like we are in the middle of a big shift) but I didn't really want to venture into my own predictions. One of my early readers had the suggestion of using prominent AI CEO/VC's predictions about the near future and treating them seriously as if they were inevitable fact, which I found very funny. And really this is all about amusing myself.
The YouTube videos will never stop.
But I think the author missed a trick by not including that time one of our Spots got shot.
https://www.cbsnews.com/boston/news/boston-dynamics-robot-do...
EDIT: And a link to the programming languages inspiration for this post if you haven't read it already.
https://james-iry.blogspot.com/2009/05/brief-incomplete-and-...
If I had known... Somehow I missed that story when it happened. Thanks for sharing. :)
Off topic ..did the CBS page heavily hijack the browser back button. I struggled to get back to this page.
great history. one of the hidden gems inside: "the wildly successful ROS operating system. ROS is used to this day by enthusiastic researchers and frustrated companies who can’t figure out how to migrate off of it"
"We should use ROS to move fast"
<first stage prototyping done>
"As we grow we need to move off ROS"
<slippery market and customers require new hires and agility>
"ROS has this thing that can replace 1000 lines of your bespoke code, and it works pretty well"
Round and round and round we go. Seen it happen first hand, will see it again.
ROS usage is a great quick way to evaluate the doofusness levels of an org. It's such a dumpster fire on every level, no reasonable human should be going within a mile of that thing.
I keep hearing this as some sort of "common knowledge" but no one can really lay out why. I've shipped stuff with ROS (albeit with some custom modules that needed customization).
But genuine question, has some who has actually shipped with ROS laid out what they would like it to do better?
I've tried a few times to get into ROS for personal projects. I guess I understand the gist of it, but I still don't understand it.
Suppose I've got a motor, a motor driver, and an Arduino. How does ROS work with that? There's all this message passing and distinct blocks of stuff, but how do I get my motor to turn?
I'm sure there are tutorials out there... I get tired trying to approach their docs. I typically understand things from the ground up or from the top down. Their docs seem to start in the middle and work up/down at the same time.
[edit]
What are my alternatives in this space? What is better than ROS?
> Suppose I've got a motor, a motor driver, and an Arduino. How does ROS work with that?
It does not, ROS is for much bigger systems, usually Linux-based. Some things it can give you:
- IPC for multiple independent processes. So if your navigation process crashes, your drivers and controller still operate. Can save some time if your stack is slow to start up.
- Visualizer - not the best out there, but kinda-working. And because of previous item, you can keep it off (to save CPU) and only start if needed.
- Device drivers for some devices. Those would be "research grade" - any problems would be ignored and may result in invalid data, or they can crash, or be very inefficient... But good enough to get started.
- Logging/replay - log data to file, replay later. Again, research grade - there is no schema evolution (at least in ROS 1), so the moment you add new field, throw away your old logs. You can also use it to make whole-system tests, but because there is no explicit sync, those tests would be janky and flaky.
- some pre-made modules, like localization
it's a lot of small pieces, good enough to start or for prototype, but not for the more "production" robots.
As far as alternatives... All orgs I have seen do their own. Some of them start with ROS and eventually replace every part, others start entirly from scratch.
ROS 1 had schema evolution (rosbag migration) 15 years ago
Regarding your edit:
The setup you describe, "how do I get my motor to turn", is lower level than ROS. Typically if I had a robot with a microcontroller to control a motor, I'd write some bespoke code (or find libraries, such as Adafruit's for example, probably) for my particular hardware. Most recently, I've just asked ChatGPT for such code (having done it myself the harder ways in years past, so admittedly I know reasonably well what to ask...).
Once you achieve code that moves the motor at various speeds or directions, you might e.g. connect to the Arduino from a computer (e.g. raspberry pi), write a python "ROS Node" script that listens to a ROS topic and sends serial commands from the Pi to the Arduino.
Then, if you attach a laser range-finder or 2D lidar to the Pi, and look for a corresponding ROS node for that laser hardware (on github via google), you would run that additional ROS Node...
And finally you might write the "main" script as a third ROS Node that:
- Interprets the laser data it gets from the laser node's published ROS topic - Has some logic for the robot that interprets that data and chooses to set speed/direction of the motor.
This is all very ad hoc description but hopefully somewhat helpful... You also asked "what is ROS", to which my own typical answer is: A framework for Nodes to communicate with each other, that happens to have a lot of open source nodes available for common hardware.
(I write this with ROS1 in mind, having hardly touched ROS2)
ROS is a collection of mostly-independent components, each of which is a not-as-good implementation of existing tooling. The implementers and the users mostly haven't grasped how to use the existing tooling, and the whole community is full of the blind leading the blind. Alternatives for what? The build system? The IPC?
> Alternatives for what? The build system? The IPC?
Honestly, I don't know. I don't even know what ROS is.
I could spec a multiplatform (computing and embedded with sensors and controllers) system, and come up with something like messaging on a CAN bus between different bits of the system and compilation targets for each piece of the system... Is that what ROS is?
it's a collection of tools bound together by a common build system, set of libraries, and a messaging system with a bunch of tools for introspecting and debugging it. It is, in principle, most of the kind of stuff you want for developing a robotic system, it's just each part is not very good, and it strongly encourages a distributed architecture that more or less makes every problem harder, especially ones which are latency sensitive, like most robotics.
Unfortunately there's no unified alternative: your alternative is to basically just put together a similar system from third-party libraries. It's a bit of a pain but not fundamentally that difficult, and you can salvage what's useful from ROS with less faff than dealing with it.
Here is the sad news: That is what ROS should be but isn't.
I'm constantly wondering why the heck I would need a framework designed for distributed IPC, if I can't run ROS on my motor controllers and have ROS manage the CAN bus messaging? You'd think that I2C, SPI, CAN, LIN, etc would be the standard protocols between nodes, but nope, it's some TCP or ethernet based DDS, which is both swappable, but yet that swapping buys you nothing.
Modeling every micro controller and even the peripherals the micro controllers are connected to as nodes in a distributed system sounds like an amazingly useful concept that would be worth years of investment, but the ROS guys seem to stay very clear of anything that could be of use to someone.
"What is ROS" is really the right question. Maybe this helps:
https://goosetaco.notion.site/Beware-of-negative-polarity-st... . It links to https://answers.ros.org/question/12230/what-is-ros-exactly-m...
ROS is the equivalent of protobuf + gRPC + Go + bazel for robotics but with some XML and bespoke C++ stuff and more academia who'll stop maintaining their project once they get their PhD and without Google or any other big funding source since Willow Garage went away.
The problem with Google's robotics acquisitions was that they fired Andy Rubin less than a year after he made them. They floundered after that.
It's clear that Google's management simply didn't have the patience to continue putting money into hardware development before the software was ready. They forced premature commercialization on BD and then dumped them on SoftBank. Strong top-level executive support could have changed that. I wonder what Google robotics could have been.
Yeah, having been there during Andy's firing I can vouch that the thunderdome era of replicant actually intensified after he left (and lasted until boston was sold off and the rest of us moved into X) but nuance is hard and less funny and I did warn folks that the history is mostly wrong... ;)
Worth remembering he was fired due to sexual harassment[0]. While Google did the right thing in firing him, they deserve far more criticism for the cover ups. Both of which are frankly unacceptable
[0]: https://archive.is/gmvI7
Given the choice between having a sexual harasser on staff, or missing out on a billion dollars of profit, every company in the world will choose to keep the sexual harasser and the profit, so that can't be the only reason.
That's a very unrealistic perspective on management. To begin with, no individual is ever seen as personally irreplaceable.
Serious question: Why would I want to read something with this title? Is this some much more abstract form of a "How Not To" article?
As stated in the article, it's a reference to a piece by James Iry on programming languages. From the title I expect something wrong, funny, but mildly insightful.
And it delivers.
Unfortunately I don't know robotics history as much as I know PL history, so I'm sure I missed most of the references.
It's humor, a robotiscist joking about their field.
If you are interested in robotics, you'll find it funny. If not, you will be confused.
Why do folks think remote telepresence never became popular, outside of the occasional appearance in sitcoms?
Because almost nobody has ever seen a telepresence robot in use.
Like, factually.
Unless you count video calls as telepresence, but I think most do not.
On rereading the thread, maybe I'm just misreading? I read your question as "they're popular, why do people think they are not" but you could also have meant "why doesn't anyone want them".
For the latter: because it's far higher friction than a phone call (or any similar tool). On the extreme end, I can walk into a meeting room and push a couple buttons and have a zoom meeting. And doing that with your computer or phone is significantly easier, often just one or two buttons whether you're a two person business or 200k.
Versus telepresence robots at the simplest: it requires charging, far more complicated UI to do anything that a video call cannot do, and is many times more expensive so you almost certainly do not have one everywhere you have a video-call-capable display. And the display is probably dramatically smaller, so you still need a separate display if you want to show anything useful. For very nearly everyone, that's just "a video call with extra baggage".
They can work just fine where those tradeoffs are offsetting vastly more expensive and higher friction things, e.g. in highly specialized surgery, and you do see them in those areas. That's just a rather small niche compared to "has a computer or phone".
Firstly: By the time your organisation is big enough that nobody will bat an eyelid at buying a $4000 gadget, it’s big enough you’ve got several buildings with several floors. Probably some doors too.
So you don’t need one robot, you need ten. And if it works really well and it’s a big hit? One per floor won’t be enough.
Secondly: The expense and maintenance burden fall on the recipient of calls, but most of the benefit is to the person making the call.
I benefit as the caller, as I can trundle over to someone's desk and interrupt them - but the benefit to them as the recipient is much more indirect.
Thirdly: Pre-pandemic, a lot of video call stuff was pretty unreliable, making the expense of a robot a risky matter. Post-pandemic, far fewer people are in a physical office - it's not like there are important in-office meetings that only have a single remote attendee.
I used to work at a research institute that had two campuses on either coast and we had those "iPad on a stick" type telepresence robots so people on one coast could attend (physical meetings) on the other. They eventually went away because more and more meetings either became virtual or were hybrid-virtual physical and so a laptop could work just as well as telepresence.
I've no idea. I just want to mourn the utter failure of my 2001 prediction that telepresence would displace business air travel. http://web.archive.org/web/20160305121400/http://www.cawtech...
Because nobody asked for it at the first place. Zoom was what people wanted.
Fundamentally it’s just easier to send an email or call.
Maybe the remotely-operated robots, no face though
I was hoping to see a mention of Odex 1 by Odetics. I was working in a printed circuit board factory at the time (1983), and we got to build boards for it. Later on, there was a demo where it lifted one end of a small pickup truck off the ground.
I'm going through a breakup right now and really enjoying posts like this. Interesting, funny, accessible. The Grug Brained Developer also really hit the spot. Any other recommendations in this vein? Thanks!
Lifting weights
Serious Q: What are the best known approaches for getting robots to fold clothes / do dishes? Doesn’t need to be humanoid
Real answer: [1][2] From Chicago Dryer. It's boring, reliable, practical equipment for the huge laundries that service big hospitals and hotels. The machines look big and dumb, but there are vision systems in many of them, inspecting, separating, and finding corners. Robotic grippers grab items where necessary.
Industrial-strength dish cleaning has been demoed but does not seem to be deployed.[3]
[1] https://www.youtube.com/watch?v=YpTuwKu5fY0
[2] https://youtu.be/7bd900ehE9M?t=41
[3] https://nalarobotics.com/spotless.html
Vision-language-action models seem to be the broad category for the best approach, which basically combines a large vision-language model with robotic actions. For example, see https://www.physicalintelligence.company/blog/pi0
Best known approach for getting robots to do dishes is commonly called a dishwasher and is widespread.
Similar to the old saying "if it works, it's not AI", we could also say "if it works, it's not robotics"
Once a physical process X becomes automated in a reliable and efficient way, we no longer consider it a robot. It's just "an X machine".
But it doesn’t load/unload itself …
Are you serious, or parodying the "reddit users claim it's not a robot because <moved goalpost>" trope in the original article?
I find joy in the ambiguity.
get two of them, and don't be afraid to rewash dishes.
That’s what I’m working on doing. Makes so much sense. I wonder why it’s not a common thing.
if you have a good dishwasher and don't overfill it, you probably are over-washing by hand. with two dishwashers (one dirty, one clean,) and most of the problem is solved.
I've seen a lot of people claim this for 15 years, but every experience I've ever had with minimal or no handwashing of dishes before putting them in the dishwasher has resulted in visibly dirty dishes.
It's possible that the (several) dishwashers I've used have been "not good enough," but if so I suggest most people's dishwashers aren't good enough.
Father here with a family of 4. our dishwasher runs multiple times per day and we never hand wash before, and I can tell you that the dishes tend to be very dirty before they go in. They always come out sparkling clean.
Here is what works for us: - keep the salt tank filled as well as the rinsing agent. Don’t use these tabs which claim to have all of this in there combined. - don’t overload the dish washer - clean it regularly. Once per week I take out the sieve at the bottom, clean it (takes less than 5 minutes) and then I use one of these bottles of cleaning fluid with a wax cap. You put it in, start a cleaning program, the wax melts and the fluid does its work. That’s also when I refill the salt and rinsing agent. Total time effort per week: 15 mins.
We have a low mid-tier dish washer, but I had the same results with cheaper ones.
Okay, a heated debate in my slack group is now going. We need more deets:
* When you say that you don't hand-wash, can you clarify? Does that mean you just take the dish and put it directly into the dishwasher after throwing any large chunks of food away? Or do you rinse it or even soap it, you just don't scrub it thoroughly?
* You mention washing the dishes multiple times per day. Does any food actually dry on your plates before the dishwasher gets run?
* You don't have a problem with fingerprints or lipprints on glassware?
* Do you feel like the salt tank has benefits beyond hard water mitigation?
I guess I want the robot to do all the work -- loading and unloading does take a good chunk of time everyday. Same thing with loading / unloading washing machines, and folding clothes. Just good ol' housework that should be automatable. I was wondering whether anyone has seriously tried - and what the sota is.
Just awesome stuff: "Tesla deploys thousands of their Optimus humanoids working in their automotive factories.1 The robots are slower and less productive than human workers, but make up for it by being more expensive and harder to train."
Halfway through and this is hilarious. Are you trying to tell me that AI originally stood for Anomalously-small Istanbulians? :D
Edit: Oh. In hindsight this (and other similarly snarky backronyms) is obviously why any time computers can do a thing it stops being “AI”.
Was this thing written by ChatGPT?
There is exactly one joke by ChatGPT. For Stability AI's CEO's prediction that there are no longer any human programmers by 2028 I liked the idea of referencing Stanford's intro to CS class which is semi-famously a bell-weather for the tech industry. My original replacement class was "Growing food for Sustenance" which kind of worked but I thought was weak. I asked ChatGPT for alternates and it gave me about 15, of which "Barter Economics and Goat Management" was clearly the funniest, and annoyingly funnier than mine.
Clearly not - it's quite funny (or at least I thought so).
Anyway, the author is a well known writer in the robotics world.
The future part didn’t land for me at all.
To me it just goes completely off the rails.
“”” 2035: AI is 10,000 times smarter than the smartest human.7 It composes “A Brief, Exhaustive and Completely Correct History of Robotics” which is much funnier than this one.
2035: Technological utopia arrives. “””
That’s okay, humor requires taking a risk.
I had a dickens of a time with the ending. Having it end at the present seemed super abrupt (as it really feels like we are in the middle of a big shift) but I didn't really want to venture into my own predictions. One of my early readers had the suggestion of using prominent AI CEO/VC's predictions about the near future and treating them seriously as if they were inevitable fact, which I found very funny. And really this is all about amusing myself.
aww thanks David.