[HN Gopher] The Mythical Non-Roboticist
___________________________________________________________________
The Mythical Non-Roboticist
Author : robobenjie
Score : 74 points
Date : 2024-03-14 18:29 UTC (4 hours ago)
(HTM) web link (generalrobots.substack.com)
(TXT) w3m dump (generalrobots.substack.com)
| jvanderbot wrote:
| I am fond of saying there are only two hard problems in robotics:
| Perception and Funding. If you have a magical sensor that answers
| questions about the world, and have a magic box full of near-
| limitless money, you can easily build any robotic system you
| want. If perception is "processing data from sensors and users so
| we can make decisions about it", then there isn't much robotics
| left.
|
| Got a controls problem? forward predict using the magic sensor.
|
| Got a planning problem? just sense the world as a few matrices
| and plug it into an ILP or MDP.
|
| What did the user mean? Ask the box.
|
| etc etc. Distilling the world into the kind of input our
| computers require is immesnely difficult, but once that's done
| "My" problem (being a planning expert) is super easy. I'm often
| left holding the bag when things go wrong because "my" part is
| built last (the planning stack), and has the most visible
| "breaks" (the plan is bad). But it's 90% of the time traceable up
| to the perception, or a violated assumption about the world.
|
| TFA is spot on - it's just not clear how to sense the world to
| make "programming" robotics a thing. In the way you'd "program"
| your computer to make lines appear on a screen or packets fly
| across the internet, we'd love to "program" a robot to pick up an
| object and put it away, but even a specious attempt to define
| generally what "object" and "put away" mean is still 100s of PhD
| theses away.So it's like we invent the entire ecosystem from
| scratch each time we build a new robot.
| contingencies wrote:
| Cute quote - added to https://github.com/globalcitizen/taoup :)
|
| I would add supply chain, however.
| jvanderbot wrote:
| An honor! Pleased to contribute.
| transitionnel wrote:
| It's so great to read genuine yet experienced insight like
| this.
|
| Like last night on Twitter I saw an opening for Robotic
| Behavior Coordinator at Figure. I know for sure, having
| analyzed this problem with "nothing else" to do for 20 years, I
| would crush it with humility, and humanity would profit in
| orders of magnitude.
|
| But they are not set up to hand me control of the rounding
| error of $40M I'd like [and would pay forward], *nor would
| their teams listen to me, due to human nature and academ-
| uenza*.
|
| Such is our loss.
|
| (as you ~say, "reinventing the ecosystem from scratch...")
| transitionnel wrote:
| Ah, sorry if I sounded like a douche.
|
| Have my Y-C idea now.
|
| here we gooooo ..!.. ;)
| yakz wrote:
| _even a specious attempt to define generally what "object" and
| "put away" mean is still 100s of PhD theses away_
|
| Is this part still true? There are widely available APIs (and
| even running at home on consumer level hardware to some extent)
| that can pick an object out of an image, describe what it might
| be useful for and where it could go.
| kaibee wrote:
| > that can pick an object out of an image
|
| You have to do it in real time, from a video feed, and make
| sure that you're tracking the same unique instance of that
| object between frames.
| lukan wrote:
| Robots could make a short stop or go slower to process an
| unclear picture, that is probably not the problem - but the
| image processing itself, is still way too unreliable. Under
| ideal condition it mostly works, but have some light fog in
| the picture or strong sunlight and ... usually all fails.
|
| Otherwise the Teslas would have indeed full self driving
| mode, using only cameras.
| thfuran wrote:
| >Robots could make a short stop or go slower to process
| an unclear picture
|
| The costs of doing so are hugely dependent application.
| It is not, for example, an attractive strategy for an
| image-guided missile, though it's probably fine for an
| autonomous vacuum cleaner.
| YeGoblynQueenne wrote:
| And then you need to grasp it.
| ska wrote:
| It's definitely not a solved problem in general, especially
| in realtime.
|
| It's a _lot_ easier to get started on something interesting
| and maybe even useful than it was even 10 years ago.
|
| A lot of the "ah we can just use X API" falls apart pretty
| fast when you do risk analysis on a real system. Lots of
| these APIs are do a decent job most of the time under
| somewhat ideal conditions, beyond that things get hairy.
| jvanderbot wrote:
| Imagine you program a robot to "put away" a towel. Then it
| opens the door and finds there's a cup in the place already.
| Now what? Or a mouse. Or a piece of paper that looks like a
| towel in this lighting. Or a child.
|
| Imagine the frustration if the robot kept returning to you
| saying "I cannot put this away". You'd get rid of the robot
| quickly. Reasoning at that level is so difficult.
|
| But then imagine it was just a towel all along - oops, your
| perception system screwed up and now you put the towel in the
| dishwasher. Maybe this happens 1/1,000,000 times, but that
| person posts pictures on the internet and your company stock
| tanks.
| kajecounterhack wrote:
| Most robotic companies today still use traditional tracking
| and filtering (e.g. kalman filters) to help with associating
| detected objects with tracks (objects over time). Solving
| this in an fully differentiable / ML-first way for multiple
| targets is still WIP at most companies, since deepnet-to-
| detect + filtering is still a strong baseline and there are
| still challenges to be solved.
|
| Occlusions, short-lived tracks, misassociations, low frame
| rate + high-rate-of-change features (e.g. flashing lights)
| are all still very challenging when you get down to brass
| tacks.
| transitionnel wrote:
| That language sounds borne of hair-pulling disbelief.
|
| If they can put ImageNet on a SOC, they can do it. [probably
| too big/watt]
|
| Better yet: ImageNet bones on SOC, cacheable "Immediate
| Situation" fed by [the obvious logic programming that
| everyone glances past :) ]
| ska wrote:
| Really there are three problem in robotics: Perception,
| Funding, and Cables :)
| etrautmann wrote:
| Connectors imo :)
| taneq wrote:
| And fasteners. I swear any automation system is 90% cables,
| connectors and fasteners by weight.
| smoldesu wrote:
| Only one of them is fun to manage.
| glenngillen wrote:
| I love this perspective.
|
| It's also made me draw parallels between the experiences with
| actual people, especially others in my household. With young
| children who are at the early parts of "doing household chores"
| of development there is basically constant refinement on what
| "clean the floor", "put things away", etc. _really_ means. I
| know my wife and I have different definitions on these things
| too. Our ability to be clear and exhaustive enough upfront on
| the definitions to have a complete perception and set of
| assumptions is basically non-existent. We're all only human!
| But our willingness to engage in fixing that with humans is
| also high. If my kids repeatedly miss a section under some
| chairs when vacuuming we talk about it and know it will
| improve. When my Roomba does it it sucks and can't do its job
| properly. Even thinking about hiring professional trades people
| to come do handiwork it's rarely perfect the first time. Not
| because they're bad, just because being absolutely precise
| about things upfront can be so difficult.
| BWStearns wrote:
| > once they are programming a robot, I feel they become
| roboticists
|
| Yes! I am not a roboticist (or at least a good one in any sense)
| but I was having a similar discussion regarding enabling non-
| technical users do data analysis. Once they start doing anything
| more complicated than `SELECT COUNT(*) FROM blah WHERE
| foo=otherblah` it's going to get real real quick. You can't just
| give them some cheap point and click stuff because their
| questions will immediately overrun the extent of what's
| practicable. Asking interesting questions of data is roughly as
| difficult as phrasing the questions in SQL (or any other formal
| query language) and anyone who can do the first can do the latter
| easily enough.
|
| (or the point and click stuff _is_ really powerful but it's some
| proprietary non-googleable voodoo that requires a month long
| training course that costs $5K/week to get a certificate and
| become middlingly powerful)
| marcosdumay wrote:
| Yep. The entire article is the low-code fallacy applied to
| robot programing.
|
| It will be the same in any branch of programing you look.
| feoren wrote:
| > low-code fallacy
|
| I like it that we have a name for this now. Let's keep
| calling it the "low-code fallacy", because I'm tired of
| explaining over and over the same idea that semicolons and
| for loops are not what makes programming hard.
| paulsutter wrote:
| Robotics has been completely transformed in the last six months,
| check out this Figure video from yesterday
|
| Robotics is dead. Long live robotics.
|
| https://x.com/Figure_robot/status/1767913661253984474?s=20
| yakz wrote:
| It's easy to make a cool looking demo with robots, even one
| that runs right in front of you in person. Making a video is
| basically nothing, though, too much cherry-picking. Anyone that
| works with robots will just assume you have burned a lot of
| time repeating takes to cover up all of the failures. For the
| rubber to meet the road you chop that scope way, way,
| waaaaaaaaaaay down to make a robot do something useful.
|
| Maybe this new ML wave will bring about a more generally useful
| robot, it certainly feels like it will at least open up a ton
| of new avenues for R&D.
| transitionnel wrote:
| That's fake man. But yeah, I checked out those jobs ;) They
| certainly know _what_ to do. Just not _how_.
| DoctorDabadedoo wrote:
| Loved the TFA.
|
| I've been working on robotics pretty much my whole career and
| people usually miss how complicated it can get even for simple
| things once you consider what can go wrong AND it's a meeting
| place for a multitude of areas: hardware, software, mechanical,
| electrical, machine learning, computer vision, control, driver,
| database, etc. An issue can hide in between any of those for
| months before it shows up with bells and whistles.
|
| What is sometimes difficult to get across to people is that
| building robots is not only difficult per se, but the base of
| comparison is unusually unfair: if you build an e-commerce
| website you benchmark it against other e-commerce websites, maybe
| Amazon, maybe ebay; for robots usually the benchmark is against
| people, the most adaptable and fault tolerant machine that
| exists, every robot will suck compared to a human doing the same
| task, but that's what we compare it to every time.
| lukan wrote:
| "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?
| DoctorDabadedoo wrote:
| 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.
| gertlex wrote:
| 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)
| stonemetal12 wrote:
| Those aren't robots they are industrial automation. :)
|
| As soon as it gets practical it stops being robotics.
| ska wrote:
| > As soon as it gets practical it stops being robotics.
|
| This idea co-evolved in "AI"
| dlivingston wrote:
| 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.
| readenough wrote:
| My personal view, as an industrial control systems engineer, is
| that so much of the world's production software requires teams of
| software professionals to monitor it and keep it working. When
| these same software professionals look at systems which
| physically interact with the real world on a real time basis then
| a different dynamic comes into play.
| varjag wrote:
| There's certainly that. Noone cares about that hot stack when
| your distributed system needs to work 24/7/365 for a couple
| decades with 0 SREs.
| Animats wrote:
| This is just a phase. The Internet went through this. It was
| criticized in the early days as requiring "too many PhDs per
| packet". Eventually, with standardization and automation, we got
| past that. Now anybody can connect.
|
| Rethink Robotics went bust because they couldn't solve this
| usability problem. It's a problem at a much higher level than the
| author is talking about. If you're driving your robot with
| positional data, that's easy to understand, but a huge pain to
| set up. Usually, you have very rigid tooling and feeders, so that
| everything is where it is supposed to be. If it's not, you shut
| down and call for a human.
|
| What you'd often like to do is an assembly task like this:
|
| - Reach into bin and pull out a part.
|
| - Manipulate part until part is in standard orientation.
|
| - Place part against assembly so that holes align.
|
| - Put in first bolt, leave loose.
|
| - Put in other bolts, leave loose.
|
| - Tighten all bolts to specified torque.
|
| Each of those is a hard but possible robotic task at present.
| Doing all of those together is even harder. Designing a system
| where the end user can specify a task at that level of
| abstraction does not seem to have been done yet.
|
| Somebody will probably crack that problem in the next five years.
| samatman wrote:
| There are only three timeframes for tech forecasts:
|
| - one year (someone is building this)
|
| - five years (no one knows how to solve this problem but a lot
| of people are working on it and y'know, eventually you get
| lucky)
|
| - ten years (this isn't forbidden by the laws of physics but
| it's bloody impossible as far as anyone knows)
| Animats wrote:
| It's more that robotics can now mooch off the AI boom. All
| that money going into adtech and surveillance produces
| technology that can be used to solve practical problems.
| hospadar wrote:
| > All that money going into adtech and surveillance
| produces technology that can be used to solve practical
| problems.
|
| Problems like "how do we build better automated
| surveillance robots? it's so inconvenient to have to
| actually have a human remotely piloting the kill-bots"
| transitionnel wrote:
| Yes please. Just gotta make a convincing case, and ideally
| make sure all the folks "losing jobs" have a good pivot.
|
| Which is the other, equally shiny part of the coin.
|
| Elder care, anyone? They're as cool as you and me (+30yrs)
| :)
| buildsjets wrote:
| I'll still be waiting another 10 years for my flying car, but
| at least CostCo has robots that can automatically wash your
| hiney hole on sale for just $300 this week.
| bende511 wrote:
| - twenty years (this is forbidden by the laws of physics)
| transitionnel wrote:
| You're right, that's why I'm surprised Honda has not done more.
|
| Shoulda teamed up with the Nintendo folks, probably.
| ska wrote:
| > Somebody will probably crack that problem in the next five
| years
|
| Nothing in your list has really changed in the last 5 years.
| What makes you think we are significantly closer now?
|
| NB: I'm not saying we aren't making strides in robotics. A lot
| of these problems are really tough though; smart people have
| been working hard on them for the last 4+ decades, and making
| some headway. We are definitely enjoying the benefits of that
| work, but I don't have any reason to think we're "nearly there"
|
| What I do think is much improved in the last decade or so is
| the infrastructure and vendor ecosystem - you can get a lot
| done no with commodity and near-commodity components, there is
| less need to start "from scratch" to do useful things. But the
| hard problems are still hard.
| Animats wrote:
| > Where are we closer?
|
| Vision. Computer vision keeps getting better. Depth sensors
| are widely available. Interpretation of 3D scenes kind of
| works. A decade ago, the state of the art was aligning an IC
| over the right spot and a board and putting it in place.
|
| > What I don think is much improved in the last decade is the
| infrastructure and vendor ecosystem - you can get a lot done
| no with commodity and near-commodity components, there is
| less need to start "from scratch" to do useful things.
|
| Very true. Motors with sensors and motor controllers alone
| used to be expensive, exotic items. I once talked to a sales
| rep from a small industrial motor company that had just
| started making controllers. He told me that they'd done that
| because the motor and the controller cost about the same to
| make but the controller had 10x the markup.
| ska wrote:
| > Vision. Computer vision keeps getting better. Depth
| sensors are widely available. Interpretation of 3D scenes
| kind of works. A decade ago, the state of the art was
| aligning an IC over the right spot and a board and putting
| it in place.
|
| I disagree, at least with this as evidence for your 5 year
| timeline - computer vision has been improving, yes, but
| nothing earth shattering in the last 5 years that I've
| seen. We've seen good incremental improvements over 30
| years here but they don't seem to be approaching "good
| enough" yet, at least not in a way that would give me
| confidence we're at an inflection point. Most of the most
| recent interesting improvements have been in areas that
| don't push the boundaries - they make it easier to get
| closer to state of the art performace with _less_ - fewer
| sensors, less dimensional & depth info, etc. But state of
| the art with expensive multiple sensor setups isn't good
| enough anyway, so getting closer to it isn't going to solve
| everything.
|
| Same with the 3D scene stuff still people have been
| plugging away at that for 30 years and while I think some
| of the recent stuff is pretty cool, still has a long way to
| go. Whenever you start throwing real world constraints in
| the limitations show up fast.
| jebarker wrote:
| > Design your APIs for someone as smart as you, but less tolerant
| of stupid bulls*t.
|
| This is definitely applicable outside of robotics. For example, I
| work on a large-scale LLM training framework and tend to think
| this way when thinking about design decisions.
| serf wrote:
| as someone that messes with every low cost robotics _thing_. this
| part stuck out as painfully true :
|
| "Oh yeah, if you try to move the robot without calling enable()
| it segfaults. That's a safety feature... I guess? But also if you
| call it twice, that also segfaults. Just call it exactly once,
| ever."
| woah wrote:
| Interestingly, a lot of these things are the same challenges that
| no-code platforms face
| AndrewKemendo wrote:
| The goal of computing is, and has always been, controlling the
| behavior of machines the same way or easier than we do with other
| agents in the world toward some measurable end
|
| So, to what level of granularity do you have to specify a system
| task in order for it to do the thing you want it to do, at the
| level of accuracy that you wanted to operate in?
|
| That all depends on how accurate you can specify what you want to
| do
|
| which means you have a sense of all of the systems that interact
| with, and impede the successful task of the set of systems
|
| We can build abstraction layers we can build filters, but at some
| point somebody has to map a set of actions with a set of inputs
| and outputs, in order to sequentially build this set of tasks,
| which rolls out into the function of a physical manifestation of
| some sort
|
| Add to that the complexities of mobile actuation complex
| environments and just the general state of power, computing,
| routing, etc. and you have a 15 body problem simply to have
| anything that someone would look at as benefit to humanity
|
| Only a couple of disciplines can totally encapsulate all that and
| none of them are available to study anymore primarily
| cybernetics, and all of the interactions necessary to fully build
| a human machine symbiotic system
| AtlasBarfed wrote:
| So if LLMs are so great, I would think binding black box robotics
| hardware with apis would lead to a revolution in robotics.
|
| That sort of one step implementation seems to be a sweet spot for
| llm
|
| Problem is a lack of available examples for training?
| reason-mr wrote:
| Traditional machine vision developers: I have 10,000 problems.
| You can't do this.
|
| Neural network people: watch this space, I have a shotgun.
| atoav wrote:
| As someone who runs a medialab at an art school it is fascinating
| how many people believe because they understood the general
| principle of a thing, it is therefore simple to just do it.
|
| Many people seem to long for a magical technology that you could
| just pour over things and they will work out in the ways you
| wanted, while miraculously sensing the ways you didn't.
|
| Those with the edge on the new tech will always be those who have
| a good understanding of it's limitations, because once a new
| thing comes around they immediately see the possibilities.
___________________________________________________________________
(page generated 2024-03-14 23:00 UTC)