The Mythical Non-Roboticist: Wouldn't it be great if everyone could do robotics?

It's not just muting, it's that it's either going to show me big honking unread counts begging for my action, or I have to mute the channel and As Far As I Know mute all notifications from it, even when someone explicitly pings me.

Ooh! Ooh! Lemme guess! Are we talking about… Deepin Linux? Or is it Elementary OS? I hope it’s not Pop OS, I’m on that now but haven’t seen COSMIC yet

I remember when software was supposed to remove pain points in my life, but now I'm not so sure. I often contemplate whether switching from Spotify to the CD player in my car will save me time, but I'm fairly certain it will save me aggravation.

We use SO MANY interfaces every day-- every screen on every app and every webpage you use... text messages, ATM, ordering terminals, shopping carts, ad infinitum-- and using those is almost universally intuitive enough to be invisible. Designers use things like implied lines, gestalt, type variance, value contrast, and things like that to make a sane data hierarchy and give users signals for what's happening in the program and what they need to do to influence that. Good practices say they should then test and refine their designs for various kinds of users to make the best interface possible. If the UI design is invisible and users can just solve their problem without having to think about it, that's good design.

When design "sticks out," it's usually for the wrong reasons. While bad designers exist, 99% of all "bad design" decisions cited by developers when talking trash about modern UI design were probably not made by designers-- they were likely made by project managers or developers that insisted their way was better, or they didn't need to check with the designer to modify something because they can make it "looks designed." If the interface looks "cluttered", they might remove useful things probably just needs to be organized. That's bad design.

https://i.imgur.com/z8BnaTn.png

I question how smart this "very smart user" actually is.

Strong disagree here - let me use a real world example.

On older Lexus models, the car stereo screen had play and pause buttons.

It always bugged me. Why have BOTH a play button and a pause button? The play button doesn’t do anything if you click on it when a song is playing, and the pause button doesn’t do anything if the song is already paused.

What Lexus should have done instead was have one button that changes state depending if something is playing or paused. It would take up less screen space and less cognitive load trying to move the cursor while I’m driving 75mph.

And on a personal note, Teams is a horrid interface. But I’m not here to argue that today.

One of my examples is the change to the button on the side of iPhone 15 used to switch between vibration and sound-on. I press it all the time by accident just by grabbing the phone. And, often enough, I have no idea I did. So, the phone doesn't ring.

Same with the ringer volume up/down buttons. Can I disable them in the lock screen? I don't think so. Once again, the ring volume is modified and you have no clue.

The other one, which is a UI issue in the sense that there does not seem to be an obvious way to deal with it, is what happens when I connect my Plantronics single-ear headset. The volume is reduced to around 15%, which is fine. However, when I turn it off, the volume does not return to the prior setting. Which means that EVERY TIME I use the headset for a call I have to remember to raise the volume or the ringer will not be loud enough when the phone is in my pocket.

My criteria has become simple these days: If you have to google how to do something with the UI of a piece of software or hardware, something could be wrong. I am not including complex tools like Maya, Solidworks, etc. Let's call those, professional tools. Anything else just needs to make sense. Not sure how anyone thought that not restoring a phone to the pre-headset level was a good idea, or having live buttons in lock mode that you cannot disable (or at least alter the way they respond in some reasonable way).

About ROS: that's fair, but to be fair, it was an ambitious first attempt that began hmm decades ago? and has some great parts (the 3d simulator, the robot construction, the python interface) and some less great parts (bags). It's a great place to make the next generation from.

Unfortunately, the scope of robot design pain is even larger than TFA! the definition of "robot" is so broad it includes factory robots with hardly any sensor requirements and intelligence, as well as devices with intense vision input, or even large network requirements, micro devices, stationary devices, mobile truck-like things, robotic systems composed of numerous robots, humanoids, etc.

Attempts to make robots easier to program in industry involve "teach pendants" and schemes where you push the robot through the desired motions to record a path. This works in well-organized work cells. Outside that, not so much. Amazon, despite major efforts, still hasn't deployed robotic bin picking much. Their AGVs, though, work great. Amazon is building a thousand units a day of those little Kiva moving platform robots that carry stuff around their warehouses.

There was Rod Brooks' "Rethink Robotics", with their semi-intelligent "cobots". That was a flop. But it did lead others to make better small robot arms.

There are host of companies, both extant and deceased, who attempted to do just that.

I don't think any ROS developer has ever made the claim that ROS makes building a robot "easy", "easier" yes, but "easy", certainly not. ROS is simply a collection of tools that people have built over the years to get their work done faster by not re-inventing the wheel. Many ROS packages have decades of real-world deployment behind them. Some ROS packages, like Nav2 and MoveIt, are incredibly helpful, other packages are difficult to use and poorly documented, just like in any open source ecosystem.

> Which in their quest to make robotics simple; made json a programming language

JSON, in ROS? I don't think that's how it works.

> massive ecosystem of abstracted complexity that breaks in undebuggable ways

If you have a solution for this I think you solved the problem of software engineering in general.

From this, yes, there are many ways that creating a simplified API in a conventional programming language seems useless.

But as an argument against any "turn a hundred newbies loose", it seems not right. It seems plausible newbies to robotics could find paradigms that don't currently exist. I mean, robotics seems to be in the state that pre-deep-learning computer vision generally was in. Nothing worked "out of the box" and you needed experts to make the random smattering of approach that did exist work. Now we have an out-of-the-box working approach and I'm pretty sure it didn't come from existing experts.

Sure there is a learning curve like many other frameworks!

I think the best thing for learning robotics looks pretty similar to learning a programming language: Have a specific task in mind that the robot/programming language will help you solve. Even if its just a pick-and-place and a camera, or a shaker table with a camera over top, or a garden watering timer/relay combo. Just work on something specific with your toy robot and you'll naturally encounter much of the difficult things about robotics (spatial manipulation, control, timing, perception, drivers (GODDAMN DRIVERS), data, you name it).

Going right to a high-DOF arm or trained LLM is always cool, but the person who hacks together a camera/relay/antenna to automate some gardening task or throws some servos and slides together to make a Foosball robot is doing the most interesting things, in my opinion.

I've encouraged my kids to use their school years to try out lots of different things, and a consistent theme in all of them is getting them to just scale down their first try. Do not expect to replicate Minecraft. Do not expect to film a feature-length special-effects movie. Do not expect to create a dishwashing robot. Do not set out to write a decalogy high fantasy series. etc. The beginner doesn't know what they don't know.

Robotics has the particular problem that small-scale robotics are often frankly just not that useful. It's been a problem with the field for a long time. The learning curve is quite steep with robotics, and given that the beginner is likely to destroy some equipment along the way, expensive. There still isn't really that much the field can do about that right now. It's better than it used to be, but it's still pretty hard.

It always bums me out when people just want to look at a pretty robot drawing a line or picking up a heavy thing and ignore much more complex and difficult parts of factory automation.

That depends on what you want to learn. In assembly lines the solution very often is to constrain the inputs and limit variability on conditions. If that is what you train on that is what you will learn. You will have 101 tricks on how to QA the inputs and how to maintain the same grippyness on surfaces and so on. Which is great if that is what you want to do.

But if what you want to learn is how to make robots which can adapt to varying circumstances your best bet is to try that. In examples where failure is less costly and you can iterate quickly.

Also "robotics" is not a single thing. Even just the computer stuff has many subfields (localisation, perception, calibration, tracking, prediction, planning, control, etc etc). When learning your best bet is to pick a few of these and assume that the other things are either solved or pick a challenge where they are not needed. :) Not talking about all the "sibling subject" like electrical engineering, mechanical engineering, thermal engineering, fluid dynamics, etc. Cool cutting edge stuff usually requires innovation in more than one of these.

When you look at the latest Boston Dynamic video we all marvel at the exquisite control they demonstrate. But they also have to cool their actuators the right way otherwise the whole thing will just melt.

As a learner your best bet is to pick a stable platform made by people who know what they were doing and colour inside the performance envelope of that machine. What you make will probably won't break the state of the art but you will still learn a ton.

There is no single, clear definition of what a 'robot' is, as normal people use the term.

The moment you write a definition broad enough to encompass a roomba, an industrial robot arm, and a child's toy robot you'll find you've also included cruise missiles, 3D printers, remote control cars and Ming dynasty naval mines.

I think this is the key take away. I work in an industrial plant we have a large amount of things that are automated but I would say they are "dumbly automated".

For example we have automated cranes. This sounds fancy and sophisticated but the whole system is designed to be as dumb as possible.

The Cranes are overhead cranes that run on fixed rails. This immediately limits the degrees of freedom in which crane can move. The whole operation is to pick up object at location A, deposit it at B then travel back to A and repeat. It is always picking up the same objects, with same dimensions/weight etc.

The whole thing is designed to be as dumb as possible it does exactly one thing, I imagine if it suddenly had to pick up a different type of object with different dimensions it would require rewrites etc.

The hardware has really made strides too, easy and cheap sensors, controllers, cameras. It's awesome how quickly someone can plug-and-play a Realsense with a servomotor or pneumatic slide and start manipulating the world.

The thing that's usually underappreciated is that once you understand how to code a robot, you are barely closer to having solved a practical problem. There are lots of practical problems in the world where spending 4 hours learning how to use $PERCEPTION_API would be actually better spent spending 4 hours understanding more about the widget being perceived or the object being manipulated. Getting into robotics has never been easier, getting something useful out of robotics is still the trick.

Here's a solution: https://editor.p5js.org/jwlarocque/sketches/5tCufh3nw

> But nobody, not even roboticist, calls those things robots. You don't need a roboticist to load your dishes, or to get to the floor of your meeting, or shoot down an enemy airplane.

I guess I'm a roboticist, and yeah, I call all of those robots. Those are _tantastic_ robots that just get their jobs done.

Counterpoint: Robot vacuums

I think the real colloquial meaning is more along the lines of how constrained or hidden the movement is. Elevators stick to a track, dishwashers only move on the inside, missiles pretty much move on a straight line. On the other hand robot vacuums roam the floor, and while a robot arm is rooted to one spot it can move freely in that range.

It is not an article intended to those who know nothing about robotics and are unlikely to become roboticists as it would be the case for a "discovery channel" type article. Note that I have nothing against pop science, quite the opposite actually. But this isn't that.

You can train someone every other skill but that one - the urge to look for what can be improved, and to improve it - is the most valuable an engineer can have, and it doesn't apply to engineering alone.

The Jony Ive aesthetic made so many things harder to use.