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.
The most difficult thing about this problem is mixed size boxes. Knowing where every box is is easy when they're all the same dimension and stacked neatly, but what about when they're packed randomly, many boxes are askew, and they're all different sizes? Then you need to get into complicated time-of-flight sensors, point clouds, surface/box recognition logic/AI, etc..
The world changed quite a lot due to standardized shipping containers. It was a mess before that.
I really do think the same could be applied to shipping packaging.
There are 12 sized boxes and that's that. They need to be stacked a certain way.
Or maybe a bit of flex here and there for some things.
Nobody really has the wherewithal or power to do that, but you know ... Xi could. I can see that being something China imposes, and then it's a standard that naturally gets exported.
Amazon basically does this, I think? As a consumer, I hate it, because I end up with a huge box and loads of useless paper whenever something isn't the right aspect ratio for one of the standard boxes.
Obviously for distribution of stock you could probably be smarter about it and waste less space/cardboard since you've probably got lots of each size of item.
I think some of the time for this, is they have X of common standard sized box, and Y of less common smaller/differently shaped box, and eventually they run out of Y sized box, so they go down the list of close matches until they find a box in stock at that particular packing station. I've ordered the same thing (baby formula premix ready to drink, fairly large, fairly heavy) in sets of two for several months and it's been shipped at least four different ways that I can remember; I doubt the bin packing algorithm is changing that drastically from week to week.
Amazon has so many though [0] that I don't really think that's directly why that happens - I'd assume it's just laze (whether human or algorithmic!) in finding the optimal box, and going with one that's obviously big enough, to hand, or whatever.
I worked for Amazon in sustainability for some time. "Fitting" 'perfectly' requires literally billions of shape combinations, because multiple items ship in one box. I question whether it would save any holistic measure of energy/emissions/waste to solve that problem to any measure of 'perfectly'.
The work Amazon has done to change box types, switch to bags, etc., has reduced waste considerably per package, though I suspect the absolute amount of waste has continued to increase with business growth.
When I worked at a grocery store, our solution for re-stacking pallets of merchandise was to place the largest boxes at the bottom and build upward with smaller boxes. Obviously this wouldn't be a great way to do things in a shipping container given the amount of vertically wasted space, but it worked in a warehouse.
Of course, the reason we were re-stacking pallets is because our original managers were so bad at managing inventory that the 20ish backstock carts were full, so we would routinely have 15-25 pallets of backstock in the warehouse... when ideally the carts should only ever be half full. Saved their jobs when I took the order gun from them, lol.
The nice thing about shipping containers is that you have walls that can provide lateral stability and a bit of retention. Loading for UPS you would basically play 3D Tetris building walls of boxes. As you neared the end of each row you would pick a box 2-3 inches too wide to fit and smash it in there to lock everything up.
To unload you most reverse the process. Unless it gets busy then you just pull the whole wall down at one time and bulldoze the boxes onto the rollers.
Restacking pallets in warehouses is way harder. It’s more like building a house of cards but no card is the same size.
> place the largest boxes at the bottom and build upward with smaller boxes
I think this is actually a basic rule in packing / loading. Get the big things in first and then work around them with the small things. It's how I load my car when going on a big trip. The main exception is things that you will need quickly without having to unload everything.
'Big things first' is also why mixtures (e.g. muesli) settle in transit with the larger pieces at the top and dust at the bottom. Small things can work their way under the big things but the converse isn't true, unless the whole volume is vigorously shaken.
Yeah the type of thing Boston Dynamics does is sexy for investors / the general public obsessed with anthropomorphism, but it is very unclear whether this is the most efficient way to automate a task.
On the other hand, this sort of highly incremental "replace a human, warehouse stays the same" automation is in a weird way lower risk. Sure, the robot is hard to get right and might not work well, but you can try it out without reconfiguring the rest of your warehouse. Firms not really being pressed on labor costs, might still more "leisurly" want to to automated. They would do this less because profitability demands it, than because they are curiousn about either raising profits or cutting costs to induce more demand. (And indeed, one suspects the demand for most do-hickies amazon fullfills is highly elastic. Such "experiments" need to more low risk than high reward, and with this sort of automation, Boston dynamics doing the fancy pants robotics work absorbs all their risk. Perfect!
If we really wanted to be as efficient possible, things would have gone very differently:
- We would still be using way more rail, and industry would be clustered around that rail minimizing trip distances,
- We would apply the simple logic of containerization at multiple levels, creating smaller countainers to fit inside larger containers
- Railway switching yards would have tons of simple af crude pnumatic push and pulls, shuffling the fixed-sized boxes between containers.
This is something like the Factorio model. We probably could have done this with 1980s-level internet, barcodes, etc. Or at least 1980s tech with 1990s cheaper prices and more advanced supply chains.
A lot of people "oh, it's harder than it looks, etc. etc." I dunno. I really don't believe it: the hard parts here are mainly getting people to coordinate on the standards, label things properly, etc. Lack of complete monopolies makes that very difficult.
I think we simply don't do these things long ago not because we can't but because such coordination and physical investment-heavy automation is expensive for firms, and they only do it "on demand" when there are labor market issues. The more we automate, the weaker and cheaper labor gets, and the weaker and cheaper labor gets in a consumer economy the more sluggish everything gets as there are aggregate demand issues. Together this means we stop automating way before our technological potential.
This, to me, is the most exciting part about UBI + shrinking the work week. Make labor scarse. Make aggregate demand strong and extremely reliable. Then automating finally makes economic sense, and for shear glory (and more leisure :)) we can engineer unbridled.
There's a great example of a facility built from the ground up with a robot-first approach in Ocado, the grocery packing/delivery company, it looks very different to warehouses that have humans in mind:
It let them do a few novel things I think, most obvious is the dense packing grid, no need for humans to get around the area so they really pack in the functional units. Next is the precision they can pull off without having to worry about wiggle-room or interruptions from people, the robots move very close to eachother which would be a big no-no if you had to worry about people.
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.
Many warehouses do have the limit you mention: limited dock doors. It seems like building pallets and loading the trailer with a forktruck is a better plan than this thing. (You can build pallets anywhere inside the warehouse, not just in a trailer on a live dock. You give up maybe 6-9% of maximum volume that way, but humans/this robot aren’t packing to 100.00% either.
To hit 4.5 seconds cycle time on average, this thing is going to be cranking. I wonder what the centripetal acceleration required from the outside of the box is to let the arm complete its rotation in ~2 seconds is. That’s 180° of motion, with a start and stop ramp. Maybe I’d give them 3 seconds loaded if they can achieve 1.5 seconds unloaded. Will have to wait til after dinner to work it out, but it seems not a trivial force.
> It seems like building pallets and loading the trailer with a forktruck is a better plan than this thing
This is fine for domestic loads, but anything coming out of a container (or going in one, depending on the destination) is probably going to be stuffed for transport efficiency (or best case, slip sheeted).
Palletised contained loads are rare in my experience due to the space efficiency loss (particularly at the moment with current freight rates). Even slip sheeting generally leads to shipping too much fresh air.
6% to 9% is on the low end - I would estimate the difference is closer to 20%. It’s at least 10cm per pallet, and assuming they are double stacked, with 10cm left on top for loading, that would be 30cm of the 2.5m height which is already 12% of the container fill before you even consider the space between pallets and all pallet heights not being at the absolute maximum allowable. It takes about 8 hours to unstuff a container by hand, so you can quite easily work out the trade off against shipment costs depending on your freight costs.
We occasionally use a package called Lindo depending on what the problem is (typically unique transport optimisation problems), but try to formulate problems/solutions so they don't require a MILP solver wherever possible (it's better to remove any black boxes if you can).
One advantage of Lindo is that it has a version that lets us integrate the solver into an excel spreadsheet, which helps us share the model with clients and makes it easier to explain to them (and let's them see the workings, as it's built in a tool that the client already knows how to use).
i was looking at the grip as well. i wonder why they didn't choose something more like an inflated or some type of adjustable box to pick up the objects. what i would do is make the arm a detachable accessory and give people different grip options using something like a quick connect. that way factories can swap out the arm for something more fitting to their use case. at some point robots will have to have some hookup standards so other companies can jump in and build upon others progress.
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.
Ocado was originally an AutoStore client and then copied AutoStore's warehouse automation solution.
Based on the timeline of events, they basically copied AutoStore. I'm actually curious what the next lawsuits will bring, but i don't think it's going to be in favor for Ocado.
There was already a preliminary result and while Ocado says it's a win, i think that's a deceiving statement if you actually care to read it.
> The Norwegian company claimed in U.S. filings that Ocado infringed four patents for the robotic systems. The judge found that, while Ocado used technology covered by three of the patents, those claims failed to fulfill requirements of clearly describing the invention in a way that others can understand.
It's a huge win for Ocado. The first line of defense when charged with patent infringement is to invalidate the patents themselves. No patents, no patent infringement. So it doesn't matter if they're doing the same thing if they can get the patents invalidated, which it sounds like is the case here.
It isn't a definite conclusion. It still needs to appear before a full committee.
This temporarily one for an injunction did conclude that Ocado is using 3/4 patents. But the injuction was not granted.
Note: not an expert, but I'll probably ask one in patent law for more information to one to check if I'm correct. Because I have some stocks in AutoStore and that included rudimentary analysis of AutoStore vs. Ocado lawsuits without going deep into the actual patents.
This was an absolutely fantastic video, thanks for sharing that. I’ve ordered from Ocado before, but I never thought that the logistics behind it were so different from just a very large warehouse store…
Also... As as exercise for the reader, compare the Ocado top-down picker with the Kiva (now Amazon) bottom-up shelf lifter, and then guess which system has a better value-for-money and is faster to deploy.
No, it's not the same warehouse. The article says "The facility in Andover, Hampshire, burnt down [...]" – which is here: https://goo.gl/maps/sKC2oBkL9JJUawuY8
Whereas Tom Scott was at this location: https://goo.gl/maps/H54SKTkumd4dEyam6 (the same outside view of the location is at 0:03 in the video linked above).
You're still delivering boxes, jars and cans of ingredients to customers, to cook and prepare food at their home.
There's a lot of waste there: it would be more efficient to just feed people from centralized canteens located near living and work spaces. The problem is that you have sales taxes and tips to add to those kind of meals, plus the wastage of inconsistent demand for the restaurant generally and for individual menu items.
The other big reason for that design is storage density: it trades off fast random access for storage density (since things are all stacked up on top of each other). This makes a lot of sense for last-mile deliveries around densely populated (and thus expensive real-estate) areas. (Though as pointed out, autostore had a very similar concept for a while before).
> 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.
Discussing the frame / body construction on the model y.
“‘When we get the big casting machine, it’ll go from 70 parts to 1 with a significant reduction in capital expenditure on all the robots to put those parts together.’”
I thought they were almost throwaway items in the case of a collision these days anyway? You hear a lot about Teslas being written off even for minor cosmetic damage.
I'm sure you know, but that comes down to cost. Repair quotes from Tesla area astronomical, so it's easy to write a perfectly repairable car off just because the finance doesn't make sense to the insurance company.
The industry term is "mobile manipulator". For example the Google X robot for Everyday Robots, which I helped work on for a while, is such a robot.
https://everydayrobots.com/
Yep. I used to work in lab automation. We found that using Cartesian systems and rethinking the processes could yield order of magnitude improvements. An Arm just replaces one operator.
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.
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.
Seems typical for Boston Dynamics, heavy on marketing, light on detail, everything is awesome, no mention of customers. I'll bet they can program the movements of several robots and set it all to music, everything is cool when you're part of a team.
For companies like Boston Dynamics, the main customer is usually government contractors. And the sad truth is that those are often as easy or easier to trick than general consumers.
It's a big key to Elon Musk's success imo. See: all of Musk's hype plans that are really infeasible (e.g. hyperloop). The only plausible customers are governments yet somehow he's still managing to land incredible contracts for plans that are all hype
It reminds me when they made a big things of their robot 'mule' being evaluated by the US army/marines. It wasn't accepted. Reasons that I picked up included:
* tactically unacceptable noise
* short range before being refuelled
* not as autonomous as advertised
* Increased maintenance / oil leakages.
These issues of course won't be such a problem in the warehouse environment but I'd be keen to see an independent assessment of the thing's utility.
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.
This seems more suited for a distribution center or cross-dock/3PL use case (where you’d be dealing with non-palletized mixed-box shipments in high-enough volume for it to matter.
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.
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... .
i've only got limited experience working in a warehouse, but i think that yes, they can safely assume that any box packed loose in a shipping container or truck doesn't need to be supported from the bottom.
suction on the side or top isn't really any different from a human packer grabbing it with a hand on each side. heavier things that really need bottom support would usually be shipped on pallets.
I spent a few summers working at a distribution center for all the cold and frozen food for every Safeway in the state. Upstairs people put boxes onto conveyor belts, the system sorted them into lanes and downstairs people put the boxes onto "per store" pallets.
At least every 30 minutes someone would pickup a box of yogourt/orange juice/whatever and the bottom would fall out and they would wear the contents.
Boxes are NOT usually designed to be pickup up from above.
> isn't really any different from a human packer grabbing it with a hand on each side. heavier things that really need bottom support would usually be shipped on pallets.
That certainly explains the sad state of a couple of heavy packages I've received recently after clearly making similar assumptions and being mishandled in shipping.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Seems like with some modifications it could be a decent semi-autonomous platform for construction work. Haul/place/fasten/tape/paint drywall. Drill/set anchors/place hangers for mechanicals/drop ceiling. Might even be able to make walls with metal studs, especially if you could load it with rolls of galvanized steel and let it fold/stamp to length.
There was a big blue Yaskawa robot arm sitting in the entry hall in Google X for a while that they used to do this kind of thing with some years ago. But there was so much reshuffling it became a display piece. A lot of the engineers that worked on it were bummed it got shelved. Glad to see it is finally going somewhere, it seemed like a neat system.
In the early 90s I had a minimum wage summer job loading boxes of just manufactured aerosol cans onto pallets. The boxes were uniform and there was a prescribed stacking pattern, so that part was simple. The hard part for me was that I was not accustomed to the repetitive physical labor. I quickly learned the minimum movement required.
The challenge came when the forklift operator failed to show on time. I would have to use a pallet jack to move the full pallet so I could start stacking the next (it wasn't worth the extra movement to carry the boxes to a farther pallet). There was a conveyor that could buffer about half a pallet worth of boxes. I then worked double-time to catch up.
This would be a perfect application for this robot if the cost aligns. I assume as these robots come down in price these kinds of jobs will disappear.
> “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.”
That sounds really stressful for that one person. Great when everything runs smoothly, but the moment something breaks down you might easily get overwhelmed, unless there are more workers on-site that can be pulled in from other tasks.
Cool technology, though. Anything that reduces the necessity of people to work unpleasant jobs seems like generally a good thing.
>Cool technology, though. Anything that reduces the necessity of people to work unpleasant jobs seems like generally a good thing.
The problem there though is that companies like FedEx and UPS employ a lot of college students. Historically a part time handler position, at least here in Indiana, pays 2-3x minimum wage with sort operations frequently at night allowing people to work part time and make a nice chunk of change while going to school during the day. I'd say in Indy 60% of my high school class worked as a handler for FedEx at some point in the first few years after turning 18 because of that.
Sure, it's going to save a lot of wear and tear on people's bodies but when minimum wage is $7.25 and a package handler here in central Indiana will start around $18.45 part time... sometimes people are willing to bust their butts for one reason or another.
I keep hearing "robots will take your job" for 15 years now, yet there is shortage of truck drivers in the EU... and in Germany, floor tilers without education make more money than many software engineers.
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.
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.
Isn't that the the end goal of technology? Those of us working in the technology field have had a hand in replacing labor since the first guy that figured out how to connect a plow to an ox.
Our hope, at least mine, is that we remove drudgery and difficulty from people's lives and create new jobs to replace the ones that are lost.
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.
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).
>“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.
The perimeter of a building is limited, with the number of docks growing as the square root of the floorspace. All else being equal, your I/O scales worse than your interior production capacity. This is one of the limits on the maximum size of a facility. Speeding up I/O flow is really good because you can’t parallelize it as much as other work.
This robot is not super fast, but (assuming it works well) it is relentless. They'll get faster and better.
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?
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.
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.