"How will an LLM change the bedpans in the nursing home?""Oh.
-
@clew @Robotistry @futurebird @mxchara
(To be clear, I love robotics, it is the best job, even better than crazy radio shit)The problem is that any fix requires fixing multiple levels at once, and those levels are in different, often warring disciplines.
For instance, if you find a vendor underspecced a motor brake (they always do) now you need to reduce the length of limbs, the available torques in software, the available currents in power management, oh right that changes which constraints bind the constraint solver so I hope the controller software has hopped on to renormalizing Jacobians an' shit, also wake up the contract lawyer, negotiate building access for the vendor's technicians, and probably 3D-print some little stop widgets as well to clip onto the motor to backstop any broken brake springs, but maybe those can wait until overnight. Also the new constants for the balance controller to avoid stressing that motor cause the robot to make lots of quick stomping steps, annoying the tenants below your lab because the vibration aerated their anaerobes or something, so your landlord is also on the phone now.
Realistically no individual person in this job _can_ be a specialist in only one area; everyone needs to know enough of everything to at least talk to each other. That sort of hyper-generalist workplace is an absolute trip to work in. And it isn't going to get solved by "AI" in short-to-medium time, although several parts of it will become moderately simpler or cheaper.
@nonnihil @clew @futurebird @mxchara And I work at the autonomous behavior layer, where I just kind of assume magic is happening to keep it upright while I figure out what control signals I need to send to get it to step backwards without falling over so it can open a door. But every time something goes wrong with my behavior, there needs to be a meeting with the rest of the team to figure out which thing is either (a) not working or (b) working precisely as intended but someone made an assumption that wasn't true and now I have to decide whether not stomping is more important than opening a door or not. And every behavior introduces the same fractal interdependencies into the system as a whole, and half the stuff is only partially documented, so I end up digging into some code a grad student wrote fifteen years ago to figure out why a sensor produces this weird artifact on the third Tuesday of the month (and it turns out it's because there's a lab meeting on the third Monday so people work late and the robot battery starts a bit less full on Tuesday).
Humanoids are the worst for almost everything. Give me R2-D2 any day.
-
I had a little note in my calendar because this conversation was two years ago.
@futurebird I've been wondering about the history of how all these amazing home robots started appearing
-
@clew @Robotistry @futurebird @mxchara
(To be clear, I love robotics, it is the best job, even better than crazy radio shit)The problem is that any fix requires fixing multiple levels at once, and those levels are in different, often warring disciplines.
For instance, if you find a vendor underspecced a motor brake (they always do) now you need to reduce the length of limbs, the available torques in software, the available currents in power management, oh right that changes which constraints bind the constraint solver so I hope the controller software has hopped on to renormalizing Jacobians an' shit, also wake up the contract lawyer, negotiate building access for the vendor's technicians, and probably 3D-print some little stop widgets as well to clip onto the motor to backstop any broken brake springs, but maybe those can wait until overnight. Also the new constants for the balance controller to avoid stressing that motor cause the robot to make lots of quick stomping steps, annoying the tenants below your lab because the vibration aerated their anaerobes or something, so your landlord is also on the phone now.
Realistically no individual person in this job _can_ be a specialist in only one area; everyone needs to know enough of everything to at least talk to each other. That sort of hyper-generalist workplace is an absolute trip to work in. And it isn't going to get solved by "AI" in short-to-medium time, although several parts of it will become moderately simpler or cheaper.
@nonnihil @clew @futurebird @mxchara You should check out the Engineering Reliable Autonomous Systems conference on May 28-29! (There's a virtual option to get access to all the talks, so you don't have to fly to Zagreb.)
https://2026.ieee-eras.org -
@nonnihil @clew @futurebird @mxchara And I work at the autonomous behavior layer, where I just kind of assume magic is happening to keep it upright while I figure out what control signals I need to send to get it to step backwards without falling over so it can open a door. But every time something goes wrong with my behavior, there needs to be a meeting with the rest of the team to figure out which thing is either (a) not working or (b) working precisely as intended but someone made an assumption that wasn't true and now I have to decide whether not stomping is more important than opening a door or not. And every behavior introduces the same fractal interdependencies into the system as a whole, and half the stuff is only partially documented, so I end up digging into some code a grad student wrote fifteen years ago to figure out why a sensor produces this weird artifact on the third Tuesday of the month (and it turns out it's because there's a lab meeting on the third Monday so people work late and the robot battery starts a bit less full on Tuesday).
Humanoids are the worst for almost everything. Give me R2-D2 any day.
@Robotistry @clew @futurebird @mxchara
Yeah, we suffer hard from the software model of independent boxes that abstract complexity, while robotics is the opposite of that at every point.(Also, for sensor artifacts, nobody ever has produced the special hell that is automotive radars. I'm wildly pro-radar but those things are designed to make engineers fight.)
My personal dream is for us to abandon humanoid/vertebrate-mimic body plans _and_ sharing floor real estate with humans and just start building ceiling squids. All humans will love tentacles coming out of the ceiling to help them!
-
@Robotistry @clew @futurebird @mxchara
Yeah, we suffer hard from the software model of independent boxes that abstract complexity, while robotics is the opposite of that at every point.(Also, for sensor artifacts, nobody ever has produced the special hell that is automotive radars. I'm wildly pro-radar but those things are designed to make engineers fight.)
My personal dream is for us to abandon humanoid/vertebrate-mimic body plans _and_ sharing floor real estate with humans and just start building ceiling squids. All humans will love tentacles coming out of the ceiling to help them!
I have long felt that the upper corners of our boxy rooms are under-used. I was only going to put triangular lights in them, but clearly the lights would be more useful on tentacles.
(You know that briefly household appliances tapped into the gas lines that fueled ceiling gaslights, yes? Design precedent!)
-
@clew @Robotistry @futurebird @mxchara
(To be clear, I love robotics, it is the best job, even better than crazy radio shit)The problem is that any fix requires fixing multiple levels at once, and those levels are in different, often warring disciplines.
For instance, if you find a vendor underspecced a motor brake (they always do) now you need to reduce the length of limbs, the available torques in software, the available currents in power management, oh right that changes which constraints bind the constraint solver so I hope the controller software has hopped on to renormalizing Jacobians an' shit, also wake up the contract lawyer, negotiate building access for the vendor's technicians, and probably 3D-print some little stop widgets as well to clip onto the motor to backstop any broken brake springs, but maybe those can wait until overnight. Also the new constants for the balance controller to avoid stressing that motor cause the robot to make lots of quick stomping steps, annoying the tenants below your lab because the vibration aerated their anaerobes or something, so your landlord is also on the phone now.
Realistically no individual person in this job _can_ be a specialist in only one area; everyone needs to know enough of everything to at least talk to each other. That sort of hyper-generalist workplace is an absolute trip to work in. And it isn't going to get solved by "AI" in short-to-medium time, although several parts of it will become moderately simpler or cheaper.
“warring disciplines“: do these skirmishes make discipline boundaries seem more unavoidable, or more contingent?
-
I had a little note in my calendar because this conversation was two years ago.
@futurebird that is perfect punch line
-
@Robotistry @clew @futurebird @mxchara
Yeah, we suffer hard from the software model of independent boxes that abstract complexity, while robotics is the opposite of that at every point.(Also, for sensor artifacts, nobody ever has produced the special hell that is automotive radars. I'm wildly pro-radar but those things are designed to make engineers fight.)
My personal dream is for us to abandon humanoid/vertebrate-mimic body plans _and_ sharing floor real estate with humans and just start building ceiling squids. All humans will love tentacles coming out of the ceiling to help them!
“we suffer hard from the software model of independent boxes that abstract complexity”
And SO DO PROGRAMMERS, amirite, haw! (Try the veal pen.)
-
There’s the tech solutionist who invented leaded gas, became bedbound, invented a movement harness, and died strangled in it, right?
@clew @futurebird yeah. the tactile feedback required for the precise movement, one that is handled just below the consciousness level is simply not reproducible with the current technology. and that's just one part.
-
I suspect that future historians (if there are any) may well decide that the first Luddites were right all along, and that various First Nations and the Amish had the right idea as to how humankind should live in this world of ours.
@Fragarach @Guillotine_Jones @futurebird
"I fucking told you so" - Ted Kaczynski
-
I had a little note in my calendar because this conversation was two years ago.
-
@Robotistry @clew @futurebird @mxchara
Yeah, we suffer hard from the software model of independent boxes that abstract complexity, while robotics is the opposite of that at every point.(Also, for sensor artifacts, nobody ever has produced the special hell that is automotive radars. I'm wildly pro-radar but those things are designed to make engineers fight.)
My personal dream is for us to abandon humanoid/vertebrate-mimic body plans _and_ sharing floor real estate with humans and just start building ceiling squids. All humans will love tentacles coming out of the ceiling to help them!
@nonnihil @clew @futurebird @mxchara
My previous use for the upper corners of robot labs was hammocks on pulleys for late-night naps.
I see the error of my ways! Ceiling squids are obviously a much better solution!
-
@nonnihil @clew @futurebird @mxchara
My previous use for the upper corners of robot labs was hammocks on pulleys for late-night naps.
I see the error of my ways! Ceiling squids are obviously a much better solution!
More and better besides! Who would not want to be rocked to sleep in the arms of the ceiling squid?
-
“warring disciplines“: do these skirmishes make discipline boundaries seem more unavoidable, or more contingent?
@clew @nonnihil @futurebird @mxchara Step one is agreeing on terminology and conventions.
It took a *long* time for me to be able to communicate with the software engineers about state machine diagrams and it is *always* a struggle.
In behavior-based robotics, the behavior is an ongoing state (a circle that means "my avoid behavior is running! I am not hitting things!") and the transition edges between the circles are labeled with the events that cause the robot to switch from one active behavior to another.
For the software engineers on the team, the circle is the static condition and the edge is the action that the software takes to move the system from one static state to another.
Which is basically the opposite.
Both sides have to (first) learn this, which involves much heated discussion and confusion, and then (second) keep this in mind when having conversations, because each group will have trouble understanding the other group's notation and explanations.
It's fundamental concept mismatches like this that really highlight the discipline boundaries!
-
@clew @nonnihil @futurebird @mxchara Step one is agreeing on terminology and conventions.
It took a *long* time for me to be able to communicate with the software engineers about state machine diagrams and it is *always* a struggle.
In behavior-based robotics, the behavior is an ongoing state (a circle that means "my avoid behavior is running! I am not hitting things!") and the transition edges between the circles are labeled with the events that cause the robot to switch from one active behavior to another.
For the software engineers on the team, the circle is the static condition and the edge is the action that the software takes to move the system from one static state to another.
Which is basically the opposite.
Both sides have to (first) learn this, which involves much heated discussion and confusion, and then (second) keep this in mind when having conversations, because each group will have trouble understanding the other group's notation and explanations.
It's fundamental concept mismatches like this that really highlight the discipline boundaries!
So, ages ago, I remember edges and nodes on graphs as one of those reliably handy duals that you should switch regularly to check for lemmas (math) and bugs (programming). Would it not be possible, if less likely, for either side to have adopted the other convention?
-
Nobody wants a robot that's durable, versatile, powerful and sensitive and not too expensive (and self-repairing, obviously) more than me.
It would be so amazing if the problem were software and not software, power, design, everything.
@futurebird @mxchara PLEASE read Service Model by Adrian Tchaikovsky this summer! You will love it.
-
@futurebird @mxchara PLEASE read Service Model by Adrian Tchaikovsky this summer! You will love it.
I'm a huge fan of that book! Well Tchaikovsky in general.
-
So, ages ago, I remember edges and nodes on graphs as one of those reliably handy duals that you should switch regularly to check for lemmas (math) and bugs (programming). Would it not be possible, if less likely, for either side to have adopted the other convention?
@clew @nonnihil @futurebird @mxchara
Each interpretation makes sense for their community - it's the definition of "state" that's the core problem.
The primary thing that defines an autonomous system is the fact that it makes decisions - the purpose of using a state machine diagram in that context is to clarify when decisions about <what to do next> are made and what triggers them. A single state can go to different decisions, but each decision selects one state. So the behavior is the state and the decision is the edge.
But in software engineering (this is my best explanation as someone who doesn't use them this way!), the state is the steady state situation that running the function takes you to - the output of the function call - and the transition is the time when the program is running and the information's state is indeterminate. Different functions can be called from an output, but each function should only have one output given the previous state.
Because the two groups are using the same tool for different things, different conventions emerge. I don't think either could evolve into the opposite convention.
(Unlike the whole i/j thing. Mechanical engineers use "i" for imaginary numbers. But electrical engineers use "j", because "i" is already in use representing current - because that's what Ampere used.)
-
@futurebird
This is what I've been bullying my AI hopeful colleagues for for years.
Robotics hasn't gotten better since the 1990s because it turns out human motion is incredibly precise, adaptable, and REALLY COMPLICATED
We physically can't make an arm shaped thing that works like an arm. We can make an arm shaped thing that can do certain arm like tasks, maybe pick up an ergonomic object, press a few buttons, or I guess flip over packages for 4 hours per that one new "AI" stream. But that same arm can't do surgery, it can't drive operate heavy machinery, hell, it couldn't reach behind a couch to plug in a vacuum with near the ease we have.
I will admit, the compute is probably there. We can probably simulate the motion of a person enough that an AI scale compute system could do the math to plug in a vacuum. But motors aren't getting smaller. Not without becoming uselessly weak. We've hit the physics barrier of electromagnetism.
Hell, look at any video of an incredibly sophisticated hand and just conceptualize how many hand positions it can make. Then try to make one you know it can't. Cross your fingers. Touch your thumb to each finger tip, see how fast you can do it. You are so much more sophisticated than a robot.
And obviously, we could just, redesign the whole world to accommodate bots with just a slew of specialized tools to be a portion of human ability, but that's quite expensive since we've already built the world to our liking.
So unless we want to rebuild the world with the logic of an Amazon Warehouse, the bots aren't going to take over for a while.@nagaram @futurebird I wonder if bioengineering is part of the solution here, by growing artificial muscles in a lab or something. -
There’s the tech solutionist who invented leaded gas, became bedbound, invented a movement harness, and died strangled in it, right?
Thomas Midgley Jr. also invented Freon.
Even though his intentions seemed to have been good he was kind of an anti-Norman Borlaug in his results.
