[HN Gopher] Boston Dynamics' Stretch robot can move 800 heavy bo...
___________________________________________________________________
Boston Dynamics' Stretch robot can move 800 heavy boxes per hour
Author : pseudolus
Score : 89 points
Date : 2021-12-29 11:48 UTC (1 days ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| andrew_barger wrote:
| Seems like this is a competitor to my company's ULTRA Loader:
|
| https://www.bastiansolutions.com/assets/1/6/ultra_cutsheet_3...
|
| I work in a different division, so I can't really speak to how
| this was developed. But, it's interesting to see the different
| design decisions, particularly the decisions to integrate or not
| integrate conveyor with the robot itself.
|
| Our robot is much larger due to the integrated conveyor, but from
| what I understand this simplifies navigation. We remain
| stationary on the outside of the trailer, so we sidestep the
| problem of navigating in an arbitrary trailer. This is a big
| challenge according to some of the AGV vendors I've spoken to.
| Maybe it comes down to mapping techniques - not my area.
| jcims wrote:
| Any interesting design or engineering challenges that the HN
| crowd might not be aware of (but certainly are willing to opine
| on :)?
| geijoenr wrote:
| Finally Boston Dynamics is releasing a robot that looks like a
| regular industrial robot.
|
| It seems the pressure to generate sales is forcing them to
| produce more down to earth products that can be marketed easily.
| lp0_on_fire wrote:
| I'm curious how this works on the other side of the warehouse -
| in shipping. Especially once you start thinking about the games
| of tetris that are played when loading the container. Boxes are
| often not uniform in dimensions or weight, nor should they be
| loaded like they are in the picture if it can be avoided. They
| need to be interlocked (assuming non-cubic boxes) so that the
| entire load doesn't come crashing down if it shifts.
| narrator wrote:
| Perhaps we can use the golden hammer of deep learning for this?
| Maybe the input layer would be a 3d tensor with a 1 for the of
| space taken by each box, or the edge of each box, and a zero
| for everything else. The output layer would be a quality score
| that would be the result of a simulation of how badly the boxes
| were damaged given the truck shifting wildly. Then the model,
| when sufficiently trained, could be used by the packer robot to
| iterate solutions on the boxes it had for packing to achieve
| the best predicted quality score?
| b9a2cab5 wrote:
| You don't need (unreliable, prone to out of distribution
| breakage) deep learning for this. Bin packing is a well known
| problem in optimization literature and there are established
| algorithms for solving it with bounds on distance to
| optimality.
| candiodari wrote:
| But when it comes to actually controlling the putting of
| the boxes in the truck the way the bin packing algorithm
| wants, you need deep learning. In case the robot slips a
| bit, changing direction a bit, on someone's handkerchief on
| the floor or whatever.
| b9a2cab5 wrote:
| There exist methods to guarantee robustness within a
| certain L_p ball on your parameters (in this case the box
| positions). I'm sure with only a few hundred boxes they
| would be tractable to solve to optimality.
|
| The actual robotics part is definitely deep learning
| though.
| Jensson wrote:
| > The actual robotics part is definitely deep learning
| though.
|
| Why? Moving machine arms smoothly has been a thing for a
| long time.
| candiodari wrote:
| If you can provide exact coordinates of every box, then
| yes, mostly* (including correct guesses of where the box
| can be grabbed without ripping it. Of course exact
| coordinates are required even when the box is moving. If
| it shifts when you're grabbing/lifting/putting it down,
| you still have complete the action correctly). Or to put
| it more in engineer wording: it's going to be far more
| robust to environment changes.
|
| And I would argue that whilst the machine learning way is
| pretty complex it's still simpler than 3d motion planning
| of moving robot platforms. And one machine learning
| solution can adapt to many robots with just retraining,
| without redoing the formulas from scratch.
|
| * technically on a moving robot platform it hasn't
| entirely been solved, but good enough solutions do exist.
| Jensson wrote:
| Ah, right, image recognition for the boxes. But I don't
| think they would use it for moving the arm.
|
| > And I would argue that whilst the machine learning way
| is pretty complex it's still simpler than 3d motion
| planning of moving robot platforms.
|
| On what grounds do you think this? 3d motion planning
| isn't complex in these scenarios.
|
| > And one machine learning solution can adapt to many
| robots with just retraining, without redoing the formulas
| from scratch.
|
| You don't redo the formulas from scratch, you just plug
| in the specs of the robot and then you have it.
| Positioning and moving arm parts is a solved problem.
| Redoing machine learning for every arm seems much more
| cumbersome.
| mattlondon wrote:
| The article mentions this - TL;Dr: not yet for the robots due
| to planning complexities that you mention.
| sb057 wrote:
| Speaking from experience, there's two main strategies:
|
| 1) Diligence, care, time, and luck on the part of the loader,
| carefully stacking boxes in such a way to make sure there isn't
| any room for the boxes to shift in transit or fall over when
| unloading.
|
| 2) Just throw it all in a big pile and hope nothing breaks.
|
| Both are roughly equally common.
| tomcam wrote:
| Yeah, I use UPS too
| awofford wrote:
| I used to work at a factory that was doing this (loading the
| trucks for shipping with a robot). It took much longer to
| implement than expected, but eventually worked pretty well. In
| the beginning, we would test by driving the loaded truck on a
| typical route and then checking the contents. The first few
| times were a disaster with boxes thrown all over the trailer.
| It was very cool to watch the robot work.
| Animats wrote:
| That's routinely done by automatic palletizers. Here's a
| standalone robotic palletizer for mixed pallets.[1]
|
| Here's an entire automated distribution center.[2] This is more
| traditional automation. Pallets come in, are broken apart, and
| items put into storage. Then items are assembled to fill
| orders, and stacked on pallets. They even call it "automated
| Tetris". They try to stack the items to match a retail store's
| planogram, so the people doing shelf restocking usually have
| what they need next on top. Objects are lifted from the bottom,
| or sometimes grabbed from two sides, so they don't rely on
| super-strong cardboard.
|
| The forklifts that empty and fill trucks with pallets are still
| human-driven in that system. Automated forklifts do exist.[3]
| They're still rare, though.
|
| All this gear seems to come from more advanced countries that
| don't have an underclass for cheap labor. New Zealand, Germany,
| the Scandinavian countries.
|
| [1] https://www.youtube.com/watch?v=bMtH19n3CzE
|
| [2] https://www.youtube.com/watch?v=aB9T-I7Fh7U
|
| [3] https://www.youtube.com/watch?v=QxEEmukZ4R4
| BbzzbB wrote:
| I find the introduction video [0] better shows what it does/can
| do. So... I guess inserters [1] are a thing, wonder how long
| until we get the tech for fast and stack inserters. Glad we
| skipped the burners, good strategy as it is such a mess to
| reconfigure.
|
| 0: https://www.youtube.com/watch?v=yYUuWWnfRsk
|
| 1: https://www.youtube.com/watch?v=FLb8TJ6-Z2M
| p_l wrote:
| On one recent project we had a stacking robot arm we nicknamed
| inserter-zilla.
|
| It was large, powerful (800kg max moved mass), and it killed
| few bits of industrial machinery before we patched in enough
| interlocks.
| Stevvo wrote:
| Is it meant to get distracted by dancing with another robot
| after 60 seconds of work?
| [deleted]
| matsemann wrote:
| I work with the systems on a warehouse where robot arms similar
| to these are doing stacking of boxes. It's not really that
| efficient. Using robot arms is the natural improvement when
| automating a previously manual step, but rethinking the whole
| process instead yields a much bigger boost.
|
| At least that's what we hope with our new process soon up and
| running.. If anything, the new automation process is much simpler
| at least, there are sooo much that can go wrong with big robot
| arms. They look cool, though, great for recruiting.
| AussieWog93 wrote:
| >rethinking the whole process instead yields a much bigger
| boost.
|
| Reminds me of a Tom Scott video where he checks out the Ocado
| warehouse in the UK:
| https://www.youtube.com/watch?v=ssZ_8cqfBlE
|
| It's crazy; they've rethought the entire system to have it
| navigable by machine.
| ozim wrote:
| I have never seen driving robot arm.
|
| Ones I have seen were always mounted in place.
|
| If this one can drive around as I understand -"omnidirectional
| mobile base"- with a box it is different game from my point of
| view.
| matsemann wrote:
| True. But given the complexity and also safety considerations
| for a stationary arm, I'm not envying those having to deal
| with a mobile one, heh.
| deadmutex wrote:
| > but rethinking the whole process instead yields a much bigger
| boost.
|
| This is pretty underrated, IMO. There are some good examples of
| Robots being outdated by simpler processes: e.g. the new
| process for building Teslas is vastly simpler than having so
| many precisely calibrated giant robots joining different parts.
| hitekker wrote:
| That's quite intriguing to hear. Do you have a link that
| offers more details?
| ibejoeb wrote:
| Similar to Energy Vault and other potential energy storage
| schemes. Conceptually it's sound, but the implementation is
| weak with respect to real-world constraints.
| thamer wrote:
| Is this a sponsored article? It reads like an advert, gushing
| over this technology with no mention of downsides, limitations,
| or competitors. It's all great and perfect and the future is
| awesome.
|
| I believe the term "advertorial" applies pretty well here.
| [deleted]
| pickler_85930 wrote:
| Shameless plug: we are working on solving trailer load and unload
| at Pickle Robot and we're hiring rapidly. Feel free to reach out
| to me if you'd like to learn more--I really love working at
| Pickle and I'm always happy to connect.
|
| Email: adam at picklerobot dot com
|
| Jobs: https://www.picklerobot.com/jobs
| LeifCarrotson wrote:
| I'd love to learn a little more; I'm unlikely to move family
| from Michigan to Massachusetts but I'm professionally curious.
|
| What's your stack like? Are you building your own motion
| control gear to run on off-the-shelf manipulators, running ROS,
| RoboDK, or similar on commercial arms, or something in the
| middle?
|
| I've got lots of experience with "off-the-shelf" robotic arms
| like Fanucs, Densos, and Epsons, as well as experience with
| embedded and general-purpose programming languages like C, Lua,
| C#, and Python. Achieving reasonable fault tolerance and
| flexibility is hard enough in controlled environments of the
| automation cells I've built, but I estimate that fully
| automated trailer load/unload would be almost completely
| intractable without access to a general-purpose programming
| language.
|
| The disparities between the two fields have lead to lots of
| frustration with the hamstrung vendor development environments
| that either make it impossible to type text at all, or restrict
| you to idiosyncratic Basic-but-not that's been chained to a
| slow-moving manufacturer since the 80s. It almost makes me want
| to throw out the vendor's kinematics and IO to just hook the
| servos directly to an EtherCAT bus, or to throw out the robot
| controller replace it with a generic CNC controller. Have you
| finally done that? Programming robots in Python as you describe
| would be blissful in comparison to some of the vendor tooling
| I've used!
|
| The arm in your videos looks a little like the Tormach ZA6 arm
| that I've been following; is that the OEM you are using?
| pickler_85930 wrote:
| Our stack is exclusively Python, which has been working out
| beautifully, and we use off the shelf robots from Kuka and
| Universal Robots. In my opinion, the vendor kinematics for
| these robots is pretty good, and we get nice control over our
| motion.
| klyrs wrote:
| Sounds cool, but I'm only doing remote work going forward.
| analognoise wrote:
| Same. Remote or bust.
| nightshift1 wrote:
| They have some videos on their youtube channel:
|
| https://youtube.com/playlist?list=PLlL_rsmcRMZd4EgwMU5kHy_pr...
| mattfredfry wrote:
| Can all boxes be safely picked up by suctioning the top? Seems
| like most packaging is designed to be supported from the bottom.
| malcolmwhite wrote:
| Not all, but enough to make this a viable product. There are a
| lot of high volume, low-sku warehouses where each product is
| light enough for Stretch's arm.
|
| As with any robotics project, there are a lot of ways that this
| might fail, but my money is not on boxes being too heavy or
| flimsy.
| ruste wrote:
| I don't think this is as much of a constraint as you'd expect.
| Imagine you manage to pull 1 psi over a 10x10" patch of box.
| That's 100lb of lifting force. If you're worried about whether
| the cardboard can handle it spread the area and lower the
| pressure more. I don't think 1lb per square inch of cardboard
| would be an issue and it looks like they have more surface area
| for suction than that.
| BugsJustFindMe wrote:
| Without bottom support, contents might fall through an
| inappropriately supportive box.
|
| The answer is "no, not all boxes, but yes some boxes".
| dijonman2 wrote:
| Last time I moved I spent a fortune on double corrugated
| boxes. I bought a cardboard stapler and taped it.
|
| Heavy boxes still needed support from the bottom.
| smegsicle wrote:
| idk what kind of sci-fi cardboard they're working with, but
| here they're picking up boxes from a single side:
|
| https://www.youtube.com/watch?v=yYUuWWnfRsk
| robocat wrote:
| Yeah, it seems like such a terrible constraint. Maybe okay for
| loading in a factory where:
|
| * in a factory the boxes can be changed to suit the robot
| (limited by how automated the box loading and top sealing is).
| If the boxes need changing then it makes selling the robot far
| more difficult.
|
| * in a factory the contents are of a predictable weight, and
| the boxes are predictable sizes
|
| * in a factory the loads are not mixed
|
| * the factory doesn't palletise their boxes
|
| Is there a marketplace where you can bet against the success of
| an individual product? Although given than most products fail,
| then either (a) the odds are poor e.g. win 10% more than your
| stake, or (b) you pay out huge amounts if the product succeeds
| (similar to how you can lose a lot of money shorting a stock).
|
| They talk about a fence around the robot, which is only viable
| if the robot needs help very rarely. If the robot needs help a
| lot (boxes over 23kg, boxes of unsupported sizes like TVs)
| safety issues would quickly arise, and liability kills the
| product.
| [deleted]
| toss1 wrote:
| Yes, I wondered that from the first demonstration months ago.
| I've got no doubt that sufficient suction can be generated for
| the needed lifting forces, but indeed, will the packaging
| tolerate it?
|
| While my shop doesn't do a huge amount of shipping and is not a
| big shipper, and most boxes can tolerate it, I can definitely
| think of both outgoing and incoming boxes I wouldn't want to
| see picked up by the top... .
| Kinrany wrote:
| They could be stored in small containers.
| xfour wrote:
| Seems super practical for something that likely is difficult to
| create a one-size fits all conveyor.
| miki_tyler wrote:
| I saw the video and it can move the boxed out, but, can it grab
| boxes from the conveyor and pile them inside the container?
| amelius wrote:
| How useful is this when e.g. opening the boxes takes 10x the
| amount of time? Wouldn't it make more sense to first put robots
| where the bottleneck is?
| daenz wrote:
| I'm getting real factorio vibes[0] from this
|
| 0. https://wiki.factorio.com/Fast_inserter
| dukeofdoom wrote:
| I thought it was going to be a robot for cleaning toilets .
| hellbannedguy wrote:
| tyrfing wrote:
| It's a little unfair to call this 80% of a solution, but it
| pretty much is.
|
| The demonstrated speed is awful, which is alright in theory since
| you can just run more of them in parallel, but it does pose an
| issue if it's added to a facility that is running near capacity
| and can't put more trailers on doors.
|
| 50 lb limit is below state of the art (humans), but some
| companies have that as a limit. It's ok.
|
| The real deal breaker is that it seems to be designed solely for
| cube volume, and not just any cubes, perfectly regular cubes. The
| demo videos also seem to be very light stuff (10-20 lbs?) and
| have a lot of impermeable surface like tape, I'd guess that 50
| lbs is only doable under very good circumstances. Maybe even
| dusty boxes would be a problem.
|
| edit: 40-50lbs is plenty for cardboard cubes to warp, flex, start
| breaking apart, etc depending on the contents. This happens even
| with a human holding onto opposite corners, relying on a single
| flat surface just isn't very robust.
|
| I think grip is the big problem. When a robot can reliably toss
| poly bags, strapped printer paper boxes, and tubes, it's going to
| get a lot of use. I've seen that sort of stuff for smaller
| things, but it seems to be extremely hard to scale up to heavier
| weights.
|
| It's a bit funny, but this is probably 5x as useful in reverse,
| loading trailers and pallets.
| AaronM wrote:
| They say they aren't planning to replace humans, instead of one
| human unloading one truck, it will be one human supervising
| robots unloading 4 trucks. Sure seems like a replacement to me.
| PhileinSophia wrote:
| mandeepj wrote:
| > unloading one truck
|
| The Stretch robot (shown in the article) can't unload a truck.
| It's not designed to lift itself up and enter a truck.
| Although, the other robots from BD (shown in the dancing video)
| might be able to do so.
| drusepth wrote:
| A truck with some mild modifications (a belt on the floor,
| for example) could probably queue a full load of
| boxes/contents to a reachable position for unloading. Stretch
| looks like it's got a pretty tall/long acquisition range.
|
| Obviously wouldn't work OOTB, but definitely seems doable in
| some niche truck modifications (and likely little-to-no
| Stretch modifications).
| Victerius wrote:
| What you're missing is that each human who used to move heavy
| boxes will be replaced by 4 robots.
|
| No business wouldn't want to increase their total productivity.
| chillingeffect wrote:
| >"Typically, you'll have two people unloading each truck.
| Where we want to get with Stretch is to have one person
| unloading four or five trucks at the same time, using
| Stretches as tools."
|
| GP is correct. 1 supervisor + 8 robots replaces 8 people.
| vinayan3 wrote:
| Many people would not want to or can lift boxes all day, like
| people with back problems. The robot supervisor job could be
| appealing to more people. So it's not replacing but creating a
| different job which more people could work.
___________________________________________________________________
(page generated 2021-12-30 23:00 UTC)