Hikrobot Tote Robots Cut T50 Fleet 30% as HAPS Picking Reaches 900 Items an Hour

The Analysis

Three numbers came out of Hikrobot's 29 October launch, and two of them look like a contradiction until you set them side by side. The upgraded STRP tote storage and retrieval system runs with 30 per cent fewer T50 robots, and yet capacity goes up and task completion rate goes up with it. The HAPS picking system, a mobile robot carrying 3D vision and an articulated arm, works across four modes at up to 900 items an hour and 99.99 per cent accuracy.

Fewer robots, more throughput. That is not a paradox, it is a diagnosis. If you can pull 30 per cent of the fleet out of a system and the system gets faster, the robots you removed were not working. They were waiting. Somebody has finally measured how much of a tote robot's cycle is spent queued behind another robot or behind a lift, and the answer was large enough to delete a third of the fleet.

I want to do two things with this. I want to build the queueing model that explains why removing robots adds capacity, because the same model tells you which number to ask your third-party warehouse for. And I want to name the parameter that decides the whole thing: not robot speed, not arm speed, but the share of the cycle spent waiting, and what happens to that share once the buffer you have just built gets filled up with stock.

Start with what actually changed in the layout, because the announcement buries it. In the previous generation of this kind of tote system, the aisle-end robot had to reach into the aisle. It met the shuttle somewhere inside the corridor, took the tote, and carried it out to a pick station. Two classes of vehicle sharing one narrow piece of floor. In the new configuration the STU unit owns the whole in-aisle task, from the storage position all the way to a buffer position at the aisle end, and the T50 only ever touches the tote at that buffer. The two subsystems now meet across a rack instead of inside a corridor.

That rack is doing more than holding totes. The announcement says the buffer positions double as storage, and that high-frequency goods are given fixed positions there. So the decoupling point between the two subsystems is also, physically, inventory. Hold that thought, because it is where the model turns.

Alongside it come three scheduling features: automatic wave continuation, slot recommendation, and smart queuing. In plain language, the system starts feeding the next wave before the current one closes, decides where a tote should live based on how often it moves, and orders the queue so that two robots are not dispatched to the same place in the same minute. All three are wait-time features. None of them makes a robot drive faster.

Why does this land on 29 October, and what is upstream of it? Three things, and they compound.

Labour, to begin with. Warehouse labour in every market where Chinese cross-border sellers hold stock has become more expensive and harder to find at peak, and the peak is four weeks away. A vendor releasing a picking system at the end of October is releasing it into the budget window for the next peak, not the one in front of us.

Maturity. Tote-handling robots stopped being a novelty in Chinese e-commerce warehouses a couple of years ago. Once a technology stops being new, the buying question stops being whether it will run and becomes what one robot-hour costs, which is a throughput question and not a capability question. A 30 per cent fleet reduction is a cost-per-location answer wearing a capability announcement as a coat.

Component cost. An articulated arm guided by 3D vision that can pick 900 items an hour at 99.99 per cent is a statement about cameras, compute and grippers getting cheap enough to bolt onto a moving base. That cost curve, not the algorithm, is what moved this from a demo to a product.

Now the model, because this is the part nobody writes down.

Treat the T50 fleet as a closed queueing system. Take the plainest form of Little's Law: the number of robots in the fleet equals the throughput you need multiplied by the cycle time each robot takes, where cycle time includes waiting. Write it as N equals X times T. If you need X tasks an hour and each robot completes one task every T hours, you need N robots.

Split the cycle into two pieces: the part where the robot is doing useful work, call it W, and the part where it is waiting, call it Q. The cycle is W plus Q. In a fleet sharing a constrained aisle, Q is not a constant. It grows with the number of robots, because more vehicles in the same corridor means more blocking, more yield events, more time spent nose to nose with another machine.

Here is the arithmetic that produces a 30 per cent fleet cut. Suppose your pick stations demand 1,200 tote moves an hour. Suppose a T50 in the old configuration spends 90 seconds of useful work per cycle, travelling to the aisle, interfacing, travelling to the station, dropping, travelling back, and 40 seconds waiting because it is sharing the aisle with the shuttle. Cycle 130 seconds, which is 27.7 moves an hour per robot, so 40 robots deliver 1,108 moves an hour against a demand of 1,200. Completion rate is 92 per cent, and you are short.

The instinct at that point is to add robots. Adding robots makes the aisle denser, Q rises again, and each extra robot buys less than the one before it. That is the classic congestion curve, and every operation I have seen has found it by accident, usually during peak, usually with a fleet that was sized on a spreadsheet which quietly assumed that robots never interfere with each other.

Now remove the aisle interaction. The T50 never enters the aisle; it meets a tote at a buffer. Useful work per cycle falls to 70 seconds because the in-aisle leg is gone, and waiting falls to 14 seconds because the buffer absorbs the shuttle's variance. Cycle 84 seconds, which is 42.9 moves an hour per robot. To hit 1,200 you need 28 robots. Twenty-eight against forty is a 30 per cent reduction, and it falls out of the model rather than out of a brochure.

The rest of the announcement follows from the same arithmetic. Those 28 robots at an 84-second cycle have a ceiling of 1,200 moves an hour, against the old fleet's 1,108, so capacity rises by about 8 per cent while the fleet shrinks by 30 per cent, and completion rate goes from 92 per cent to 100 per cent because the backlog stops existing. Cost per storage location falls because you bought twelve fewer machines and got more moves out of the ones you kept. Capacity up, completion up, cost per location down: four results from one change, which was deleting the wait.

Keep the forty robots in the new layout and the ceiling becomes 1,714 moves an hour, a 55 per cent jump. That is not the configuration being sold to you, and the reason is informative: twelve of those robots would be idle most of the time, and idle robots are the most expensive kind of inventory.

Which parameter moves everything? Q, the wait. In the example above, useful work fell by twenty seconds and waiting fell by twenty-six. The waiting term did more work than the hardware, and the waiting term depends on layout and fleet size rather than on anything in a spec sheet. Any vendor conversation that spends its time on drive speed, lift speed and arm cycle time while saying nothing about queue discipline is measuring the wrong variable.

There is a second-order effect worth naming, because it is the one that bites. Q is not linear in fleet size. As density rises, blocking events grow faster than the fleet does, so there is a utilisation level past which adding robots makes the system slower. The fix is counter-intuitive and it is exactly what this announcement describes: take robots out.

The thing nobody put in a headline, and the thing I would push back on hardest, is the sentence about buffer positions doubling as storage.

Decoupling works because the buffer is empty enough to absorb variance. The shuttle can drop a tote and turn around without waiting for a T50 to arrive, but only if there is a free slot. If you use those slots as storage, and the announcement explicitly says high-frequency goods get fixed positions there, you are converting queue capacity into inventory density. That is a real trade, and it is not free. In queueing terms you are shrinking the buffer of a two-stage tandem queue, and the closer the buffer runs to full, the more the two stages re-couple and the more of the wait you just deleted comes back.

There is a threshold here and you should ask for it: at what buffer occupancy does throughput start to fall? If a vendor cannot answer, they have measured a demo and not a system. My own expectation, taken from the shape of these curves rather than from any data on this product, is that trouble starts somewhere above 70 per cent occupancy and gets serious above 85. Treat that as a question to put to them, not as a number I am handing you.

The second thing the coverage did not do is put the accuracy figure next to the rate figure. Ninety-nine point nine nine per cent sounds like nothing at all. At 900 items an hour it is 0.09 mis-picks an hour. Over a 20-hour operating day that is 1.8 a day, and over 300 operating days that is about 540 a year. That is a real number, and it belongs on the cost side of your business case rather than on the benefit side of a slide.

Price those 540, with assumptions you can replace. Suppose half are caught at packing: 270 a year, four minutes of a worker's time each to re-pick and re-pack, at 25 dollars an hour fully loaded, which is 1.67 dollars each and 451 dollars a year. Suppose the other half ship: 270 a year, a return label, a reshipment and an hour of customer service, call it 15 dollars each and 4,050 dollars a year. Total around 4,500 dollars a year against equipment that costs orders of magnitude more. The honest conclusion is that accuracy at this level is not the deciding variable. Availability and throughput are. Which is another way of saying that buying this for the accuracy number is buying it for the wrong reason.

Here is the parameter that decides everything, and it cuts both ways: utilisation.

A robot working one shift takes twice as many years to pay back as the same robot working two. Every investment case therefore wants utilisation high. In a queue, though, waiting time rises non-linearly with utilisation. At 50 per cent a queue is short. At 85 per cent it is long. At 95 per cent it explodes, and the relationship is the familiar curve that runs asymptotic as utilisation approaches one.

Put those two facts together and you have the actual design problem. The same number that makes your payback work is the number that destroys your response time. You cannot set utilisation at 95 per cent to satisfy the finance case and then ask the floor for four-hour order turns, because at 95 per cent the queue will not give you four hours. This is why the 30 per cent fleet cut matters more than the figure suggests. It is a vendor telling you the old configuration was running too hot, and that the answer was not faster robots but slack.

Concretely: a system sized for 1,200 moves an hour running at 92 per cent average utilisation through a peak week receives a wave of 1,400. The excess does not get absorbed, it queues. Twenty-four hours of 1,400 arriving against 1,200 of capacity is 4,800 totes of backlog by the end of the day, and at 42.9 moves an hour per robot that wants about 14 extra robot-hours you do not have. The wave either waits for tomorrow or pulls people off other work. Peak behaviour is where a fleet sizing assumption gets audited, and it is the only test I trust.

Who this touches, and how much.

If you are a cross-border seller using a third-party overseas warehouse, the direct effect on you is nil this year and real in about eighteen months. What you should watch is the per-order fulfilment fee and the cut-off time in your contract, not the technology. A warehouse whose cost per storage location is falling has room to move on price, and the moment to ask is your renewal rather than a random Tuesday.

If you own or lease your own automated warehouse, or are about to sign for one, the effect is immediate: your sizing model is stale. Any business case written on the assumption that a robot spends its cycle working needs rewriting with a wait term in it, and the fleet count inside it is probably too high by somewhere between a quarter and a third.

By category, small uniform items that do not bruise are where 900 items an hour lives: phone accessories, cosmetics samples, folded apparel, small home goods. Irregular shapes, soft packaging, anything over a couple of kilograms, anything needing serial-number capture or battery handling, sit outside it. If 40 per cent of your assortment is irregular, your realistic rate is not 900 and no demo will tell you that.

By order structure, which is the one people forget. If your average order is 1.2 lines, every order is a trip. If it is 4 lines, orders can be batched and the same robot-hour produces four times the picks. A warehouse quoting you a per-pick price without asking how many lines per order is quoting a number that will move.

On labour, this shifts demand away from seasonal pickers and towards technicians who can keep machines alive. If your third-party operator does not have that second group yet, ask who is on call at two in the morning during peak week.

When does any of this reach you.

Zero to three months: nothing. This is a vendor announcement in peak season and no warehouse is installing anything in November. What you can do in that window is collect data, and it is the useful part. Pull your own last six months of order lines per order, your dimension distribution, and your share of irregular items. Those three numbers decide whether any of this applies to you, and only you have them.

Three to twelve months: the large third-party operators run pilots. You will see it as a changed cut-off time or a new surcharge at one site, not as an announcement.

Twelve to twenty-four months: per-order fulfilment fees start to move at the top of the market and storage location supply increases, which is when your renewal becomes a negotiation. Time your contract to end inside that window if you can.

Right now, this peak: if your warehouse installed nothing new this year, it will congest in late November exactly as it did last year. Nothing announced on 29 October changes your December.

What would flip the conclusion.

If your dimensions are not standardised, 900 is unreachable and the model shifts back to labour. Measure your top 200 items in three dimensions before you believe any rate.

If your order profile is one or two lines with a wide spread of items, the robot spends its cycle travelling, and travel is the part of useful work you cannot schedule away. Batching is the only lever, and batching adds latency, which is the same trade wearing a different coat.

If upstream supply is erratic, containers landing late, supplier fill rates under 90 per cent, quality holds at receiving, the bottleneck is at the receiving dock and no picking speed helps. This is the most common reason automation disappoints, and it is never the vendor's fault while always being the vendor's problem to manage.

If your demand is seasonal with a three-to-one peak, utilisation is low for two thirds of the year and the payback stretches. A second shift is not the answer because there is no volume to run on it. How you set safety stock against a curve like that is Grace's desk rather than mine; I only know that a fleet sized for the peak week and idle in February takes the worst of both.

If the buffer occupancy question gets no answer, assume the decoupling is being sold with numbers measured in an empty building.

What I would actually do, in order.

Measure before buying anything. Three numbers from your own operation: lines per order, share of items outside a standard tote envelope, and peak-week volume divided by trough-week volume over twelve months. If lines per order sits below two and irregular items exceed 30 per cent, this is not your problem yet.

Ask your warehouse two questions at renewal: what is the trend in your cost per storage location, and what is your buffer occupancy at peak? An operator who cannot answer the second has not modelled its own system.

Re-run any fleet sizing you hold with an explicit waiting term. Take whatever robot count a proposal offers, write the cycle as useful work plus waiting, and ask what the waiting term becomes at 90 per cent utilisation sustained for six hours. If the answer is that it does not change, the proposal is a spreadsheet.

Keep the buffer honest. If a layout put to you uses buffer positions as pick-face storage, ask what fraction stays free at peak and get that fraction into the contract.

Do not buy for accuracy. Ninety-nine point nine nine per cent at 900 an hour is about 540 misses a year, a rounding error beside availability. Buy for throughput at your own mix and for what happens in the peak week.

↑ Back to the key points

— By Ravi Chandran