Mobinity hands-on: get one robot running first

I spent two days trying Mobinity, Addverb's warehouse control system. It's basically the traffic control desk inside a warehouse — no matter what the racks look like, it manages who moves what, when, and along which route. These two days I didn't touch real machines; I was messing around entirely in a test environment.

This thing isn't hard. What's hard is whether you've thought clearly about what you want to verify.

The mistake beginners make most easily is opening the interface and just clicking around. I suggest writing three lines on paper first: how many devices you're connecting, what each can do, and which task flow you want to get working end to end. If you can't write those three lines, everything after that is just random clicking.

You don't need much. A device list, with model, communication method, and supported task types written clearly. A point table listing the coordinates of every pickup point, drop-off point, and charging station. An environment where you can do dry runs.

Coordinate units need to be unified in advance. That was the first pit I stepped into on my end — more on that later.

Also prepare a small fixed batch of test tasks. I've been looking at model evaluation materials recently, and Huawei Cloud's framework splits into two sub-modes. The scoring mode uses a judge model to score a single result; the comparison mode has the judge look at two outputs at once and decide which is better. Moving that to warehouse scheduling is the same idea. If you only run one task flow, all you see is how long it took this time and whether it failed. To judge whether a scheduling strategy works, you need to run the same batch of tasks with system dispatching and manual dispatching and compare. So the test task set has to be fixed — run the same batch every time after changing config, otherwise there's no way to compare before and after. One more thing: don't only include one type of cargo. If the dataset is biased, the conclusions will be too.

Start with one device.

1. Create a new test zone and import the point table. A floor plan appears in the interface, with points color-coded by pickup, drop-off, and charging. That step is done.

2. Connect the first device. Go to device management and click Add Device, fill in name, type, and communication address. For the name, I suggest "zone-type-number", like ZoneA-AMR-01. When the logs are full of random IDs, you'll thank yourself.

3. Define a task template. Pick the pickup point and drop-off point; don't worry about the path in between, the system calculates it. Expected result: a new record appears in the task list with status Pending.

4. Dry run. Don't dispatch a real task; let the robot walk through it in simulation. Once you see the trajectory line drawn completely and it isn't stuck at some corner, move on.

5. Add a second device. I added a conveyor line, binding the AMR's drop-off point and the conveyor's feed inlet to the same position — that counts as a handoff.

6. Run one complete task flow. A timing diagram appears in the interface, with time on the horizontal axis and one row per device.

There are three places where things go wrong easily. The first is coordinate units. If one device is filled in millimeters and another in meters, the system won't throw an error, and the robot will run outside the wall. My approach is to click through each one after import and check whether the position on the floor plan matches reality; if not, go back to the table and fix it.

The second is timestamps. If multiple devices' logs aren't aligned, the timing diagram will show the robot constantly waiting for the conveyor line — it looks like a scheduling algorithm problem, but really the times are just off by a few seconds. This pit costs the most time.

The third is load. The first time I went full load, tasks piled up, and the logs refreshed too fast to read. Later I changed it to three to five tasks at a time, and then problems were easier to pinpoint.

From my testing, going from connecting the first device to getting one task flow working takes half a day once you're proficient. The real effort goes into the point table beforehand and the comparison table afterward. How good the interface looks is actually the least important part.

Next step: connect a device from another vendor and see whether the task template needs rewriting. If it doesn't, that shows this abstraction holds up.

Over the next two years, competition in this kind of middleware layer will shift from how many device types you can connect to whether your scheduling strategy can be reproduced by third parties. Standardizing device interfaces is only a matter of time. Whoever can make their dispatch logic auditable and comparable is the one who can present convincing evidence. At selection meetings, what gets compared won't be feature lists — it'll be whose evaluation is cleaner.