JD.com May Hit the Power Wall in Logistics Robots Before the Chip Industry Does

I noticed an interesting detail regarding JD.com's RoboBase project in Huangpu, Guangzhou. The planned investment is 1 billion RMB, with a construction area of 190,000 square meters, but the annual output value is only 1.75 billion RMB. Calculated down, the output per square meter is less than 10,000 RMB. For a logistics base claiming "full automation," this number surprised me.

As someone with a background in chip design, my first reaction to any system-level project is to calculate power consumption. JD's RoboBase is essentially a large-scale robot cluster system. With 190,000 square meters, assuming a deployment density of one AGV per 100 square meters, that's 1,900 robots operating simultaneously. Each robot's battery capacity, based on current mainstream industrial AGV configurations, is roughly 100Ah at 48V, which translates to 4.8 kWh. If all were charging simultaneously and connected to the grid, the instantaneous power impact would be around the 1.5-megawatt level. This number doesn't seem huge, but the problem is these robots don't charge simultaneously; they are dispersed across the 190,000 sqm space, returning to charging stations randomly.

This creates a distributed load power wall problem. I've done power optimization for 5G base stations before. The biggest challenge then was keeping amplifier modules working at peak efficiency despite random fluctuations in user traffic. Logistics robots face a similar situation, but more complex—because robot movement paths aren't scheduled by communication protocols but driven by orders. If a certain area suddenly sees an order surge, all robots rush there, then collectively run out of battery and return to charge, causing that area's throughput to instantly drop to zero.

JD's solution, according to public information, involves deploying multi-level charging networks and dynamic scheduling algorithms within RoboBase. This approach is correct, but I wonder if there are more radical methods. For instance, can we push the power consumption of the robots themselves down by another order of magnitude? Currently, mainstream AGVs consume about 200 watts when running empty, spiking to over 500 watts when fully loaded. If idle power consumption could be reduced to 50 watts, batteries could be halved, charging frequency lowered, and the distributed load issue alleviated.

This is actually very similar to the "dark silicon" problem in chip design. In advanced processes, we can't let all transistors work simultaneously, or thermal density will burn out the chip. So we have to turn off some modules periodically to let them cool down. Logistics robots are the same; if they could enter a true "sleep" state when idle, instead of the current "standby" state, power consumption would drop.

But the problem is, sleep implies wake-up latency. Robots need several seconds to recover from sleep after receiving new order instructions, which is unacceptable in logistics scenarios. JD's scheduling system must guarantee millisecond-level response, so they keep robots in standby. This trade-off is like the low-power modes in smartphone chips. Apple's A-series chips achieve wake-up latencies of tens of nanoseconds, while Android chips are still stuck at the microsecond level. If JD can compress robot wake-up latency from seconds to milliseconds, the overall system efficiency will jump to a new level.

However, looking at it from another angle, the real difficulty of this JD project might not lie in the robots themselves, but in their interface with the existing logistics system. A 190,000 sqm base running fully automated means incoming/outgoing vehicles, sorting lines, and warehouse systems must seamlessly integrate with the robot system. The complexity of this interface is an order of magnitude higher than optimizing individual robot power consumption. I've worked on protocol stacks in 5G basebands; the biggest headache was always the interface protocols between different layers. Even slight timing deviations cause the entire link to drop. JD's RoboBase is essentially rewriting the entire logistics link's protocol stack while remaining compatible with the existing JD Logistics system. Frankly, the engineering difficulty here is far greater than designing a single chip.

An annual output value of 1.75 billion RMB translates to a daily throughput of approximately 5 million orders. At this volume, if handled entirely by robots, the average processing rate must be 58 orders per second. The average processing time per order, from instruction receipt to picking completion, must be under 17 seconds. For current logistics robots, this time window is quite tight. Industry data I've seen shows most AGVs take 30 to 60 seconds per pick. If JD can compress this to 17 seconds, it would indeed be a technological leap.

But the question is, does this time window include path planning time? If yes, the robot controller's computing power must be strong enough to calculate optimal paths in real-time. Stronger computing power means higher power consumption, bringing us back to the power wall problem. This cycle is like the "power-performance-area" triangle in chip design; JD must find a balance point between power, speed, and cost.

I noted the news says the project won't go into production until 2029, with full capacity reached in 2030. This timeline suggests JD has a sober understanding of the technical challenges. Five years is enough to optimize robot power consumption to the extreme and smooth out interface protocols. But I think what truly determines the success or failure of this project might not be the technology itself, but whether JD can...

Original Link: https://www.tmtpost.com/8074740.html