"every robot will suck compared to a human doing the same task, but that's what we compare it to every time"

What about a factory robot, welding together a part of a car?

That would fall under the "automation" category: a very specialized customized application of robotics, doing the same set of tasks over and over, this is the kind of application where we can really see the power of robotics, but rest assured that countless hours were spent testing/improving/optimizing/safe guarding these workflows and after every section in an assembly line there will be manual inspection to flag for bad / missing weldings and potential service of the machinery involved.

Would "single purpose robot" be another reasonable term for welding robots? Just musing.

The earlier "when compared to humans" statement definitely sounds pretty accurate to me, worded as "mutli-purpose robots currently always are less robust than humans at the same set of tasks" (or similar)

>mutli-purpose robots currently always are less robust than humans at the same set of tasks

Specialization has tradeoffs. Humans are very optimized generalists but very few of us become specialist at more than one thing. Even in that case a specialized machine/robot can be far faster, depending on the task of course.

Of course humans have a lot of trade offs for their abilities as generalists... taking years to mature, requiring sleep, poor integration with computer systems are just some of them.

Those aren't robots they are industrial automation. :)

As soon as it gets practical it stops being robotics.

A potential corollary: As soon is gets practical, it also stops looking like a robot.

Once you know how many degrees of freedom are truly needed to solve a problem, you start removing unnecessary parts in the design to lower cost and assembly complexity.

Thus, once your cool new C-3PO has perfected the art of making toast, it's only a matter of time until you re-engineer it into looking like a toaster.

No, I don't think so. We already have toasters, robots are for the tasks that can't be done by such simple machines.

A toaster cannot make a toast alone. It has to be inserted and removed and put on a plate. That's what I want a robot for (one day, after I am sure, it will not accidently toast me).

The question is, is this actually worth it over a toaster with climate-controlled toast-hopper that dispenses directly onto a clean plate from a plate dispenser.

And if that feels too expensive and space-intensive for mere toast, just think of how much worse a robot would be!

It's a matter of interface: people like the idea of humanoid robots because all the interfaces are already optimized for humans, thus if robots have that form factor they can use the same devices/tools that humans do and we wouldn't have to change the designs of these machines.

The question is: how much information is lost in the process? How many layers of complexity we would add to a machine ensemble to be able to operate together at a satisfactory level? The machine learning corollary of understanding the whole picture of the problem/solution space and that leading to simpler solutions (because you don't have to optimize further) applies here. At the end of the day, cost, complexity and practicality will have the final word.

There can also be human handles and touch points and mechanical interfaces for direct manipulation.

True, but all the buzz on the humanoid robots from recently is putting the robots in the same environments human use without having to change it at all, not because it's impossible but it's a lot of effort and every minimal possible interaction needs to be mapped.

There are autonomous forklifts, but a humanoid robot that could sit in a normal forklift, regulations aside, would be almost an insta buy in logistics.

I understand I'm just designing for a world that doesn't quite exist but is technically possible.

I'm designing for a future that is as far out that I both see it and achieve on the scale of an 8 unit apartment building.

I think it will first be a kit to convert your average forklift into autonomous by retrofitting some sensors, motors for pulling cables or changing pressure on hydraulic lines electronically, and a laptop. The humanoid thing will be killer when it's out but it will be a century long boundary pushing dream to be chased.

Form factors are so important. I'm right in between robots and toasters. I see a building as the form factor for a 100 year computer.

The best illustration of this subtle difference is how I'm contemplating snow and ice management. I have the solid state idea of installing quartz IR lights around the building to control the ice and snow. I also have been working on using de-icing and pre-icing liquids with hopes of getting some droids to take over the physical part of applying the liquids and brushing away the snow.

I have settled on doing both with the building controller acting as the overall manager of the process.

I looked at the posetree.py that the author wrote and linked to and it looks like as good a place for me to start.

Form factor is critical in assigning human names and commumnicating use. I find when organizing a solution to a problem adopting a form factor too early is a hidderence.

> As soon as it gets practical it stops being robotics.

This idea co-evolved in "AI"

Do you like working in robotics? How is the work, pay, environment, and industry?

I've entertained the idea of entering that space as a software engineer. No real experience in robotics though.

Working on robotics software is still exciting to me, unfortunately that is but a small part of working in the field: supporting operations/customer support is something that can take a lot of your time due to a multitude of factors (lack of specialized knowledge, bad designs, bad components/suppliers that are hard to move away from, environmental issues that can take some investigation to uncover, etc.), handling the expectations from (usually not technical) management can be challenging as well.

Projects are usually complex in part due to having a lot of moving parts (hw, sw, mechanical), iterating (bad) designs/components is not practical due to support reasons, so you may be stuck with a known bad stack.

And copying a previous comment from me on another thread: Robotics is very niche and the market is dominated by early stage startups (since most of them go out of business a few years in), so salaries are average unless you are working specific jobs for FAANG (which is a small pool). Job hoping usually means moving elsewhere, since working close to the hardware makes it much easier, which in turn means having a good picture of what is a competitive salary sometimes is not obvious.

Overall I would say that if you are optmizing for money / career mobility robotics is not great and you can do better some place else.

Last week I stumbled onto a bug in a sensing system that has lived in our codebase for at least 16 months and wasn’t ever triggered. In being vague but the system has been used pretty heavily in a whole bunch of different environments attached to several different host (mechanical) machines. What tickled it? A counter wraparound in 3rd-party FPGA logic at exactly the wrong moment.

And per Murphy’s law, it happened for the first observed time in a relatively high-stakes situation while there were a lot of eyes on it. Naturally.

I feel you. This week we found a race condition induced segmentation fault in our lidar drivers (by Sick) that have always been there and the only reason we came across it was because we had to customize them and increase the poll frequency for a specific use case. Like you, high visibility and during a crunch.

AKA the demo effect: if you want to show something working (like to a customer, investor, boss), it won't. If you want to show something not working (like to a supplier or co-worker for refund/debugging), it will.