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-...
Anyway, the author is a well known writer in the robotics world.
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.
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.
Like, factually.
Unless you count video calls as telepresence, but I think most do not.
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".
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.
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.
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.
* 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?
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".
Industrial-strength dish cleaning has been demoed but does not seem to be deployed.[3]
[1] https://www.youtube.com/watch?v=YpTuwKu5fY0
<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.
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?
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?
https://goosetaco.notion.site/Beware-of-negative-polarity-st... . It links to https://answers.ros.org/question/12230/what-is-ros-exactly-m...
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.
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.
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)
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.
But genuine question, has some who has actually shipped with ROS laid out what they would like it to do better?
This is just my observation and should be taken lightly.
If you are interested in robotics, you'll find it funny. If not, you will be confused.
taneq•7mo ago
Edit: Oh. In hindsight this (and other similarly snarky backronyms) is obviously why any time computers can do a thing it stops being “AI”.