Managing robots from the cloud: step one is getting devices connected

I spent two days trying Qingcheng Intelligence's cloud-based robot swarm control intelligent management platform. "Trying" really means helping a friend who does warehouse automation take a look. He has three mobile bases, usually one person with a laptop connecting to each one, and wanted to see if they could be managed centrally on a web page.

First, let me clarify what this thing is. A swarm control platform, simply put, collects the status, tasks, and logs of several robots into one web backend. You don't connect to each one individually—open a browser and you can see which is running, which is stopped, and whether dispatched tasks are being executed. Qingcheng's product category is robot software, doing onboarding, monitoring, and task dispatch.

I tried it with my friend's scenario: three bases, simulating bin transport in a warehouse. Below is the path from zero to running one task.

First, get the devices connected

Register and log in; on the left side of the console is the device list, initially empty. Click Add Device, fill in the device name and type, and the platform generates a set of access credentials—roughly a device ID string plus a secret key. These credentials are for the robot side, not for your login.

On the robot side, find the access configuration and fill in the ID and key; if the network is reachable, it will connect itself. My first one took two or three minutes, and the status in the list changed from Offline to Online. The second one got stuck for almost twenty minutes, showing offline the whole time.

The pitfall is here. At first I thought the key was wrong and checked it three times. Later I found that the base's factory firewall was blocking outbound ports, only allowing the intranet. After changing the rule and reconnecting, it went up on the first try. If a device won't connect, check the network first, then the credentials—don't reverse the order.

Once the device is online, click Task Management and create a new task. The platform provides several basic action templates, such as move to a specified point, wait in place, and return to the charging dock. I chose the simplest one: have base No. 1 move from point A to point B, stop for ten seconds, then come back.

When filling in target points, note that the coordinates the platform uses are bound to the map. The position you click on the map must be the same map loaded on the robot side. I didn't pay attention the first time; after the task was dispatched, the base spun in place twice and errored, with the log saying the target point was unreachable. Later I aligned the map versions, re-marked points A and B, and it went through when re-sent.

After dispatch, you can see the task status in the list: Pending, Executing, Completed. During execution you can click in to see real-time position and battery. The expected result is the robot moves and the position on the web page follows.

When running all three together, I copied the same task to all three and dispatched them five seconds apart. All executed, but one stopped halfway. The log showed it was triggered by a protection when battery fell below threshold—not the platform's fault; I hadn't set a battery check in the task.

After getting it running, the most direct feeling is saving the time of connecting to devices back and forth. Before, my friend had to plug in network cables, open terminals, and type commands one by one; now opening a web page shows the status of all three. Basic actions can be sent by dragging and filling in a parameter—lighter than I imagined.

But there are two areas I didn't get working, or couldn't find the entry for. One is simulation evaluation. These platforms are generally filling this in now; Huawei Cloud's CloudRobo has three layers—single-collection evaluation, dataset evaluation, and model closed-loop feedback evaluation—so you can validate in a simulation engine before going to real machines. For Qingcheng, I looked around and at least in the current version didn't see a corresponding module. The other is complex task orchestration; it provides fixed templates, so for conditional branches and exception rollback you still have to write scheduling outside. I previously built a pipeline with task orchestration software—that leans toward single-machine process orchestration, while swarm control leans toward aggregating status across multiple devices; they're two different things and can't replace each other.

What to try next

If you've already connected devices and can dispatch a single task, the next step I'd suggest trying two things. One is connecting tasks with external triggers—for example, a barcode scanner scan automatically dispatches a transport task; the platform has an API, but the documentation is fairly brief, so you'll have to try it yourself. The other is multi-device collaboration—for example, two bases relaying the same bin; this requires setting dependencies in the task, and I haven't gotten it working yet. I'll write more once it works.

The value of a swarm control platform isn't in the algorithms—it's in gathering scattered devices onto one interface, provided you first get the two foundational tasks of network and map right.