When your robot joints start "chatting": things about microservice data sharing

Imagine you are assembling a six-axis robotic arm. The servo motor rotates accurately, the servo responds promptly, and everything is perfect—until a certain joint suddenly "gets stuck" because the data from another module has not yet been transmitted. The production line stopped for three seconds, and the entire rhythm was disrupted.

Is this scene familiar? In automation projects, data flow is like a nerve signal. If it breaks in one place, the whole body may freeze.

Data silos: not a technical problem, but a collaboration problem

In traditional systems, modules often work independently. The visual detection unit calculated the coordinates, but the motion control unit had to wait hundreds of milliseconds to get the data. It’s not that the computing power is not enough, but that the transmission path is too convoluted. This is like letting two people communicate by writing letters in the next room. Of course, the work will be done slowly.

"We use the latest hardware, why can't the overall efficiency improve?" Many teams ask this question repeatedly. The answer often lies not in the torque or speed of the motor itself, but in those invisible data chains.

Microservices are here, but how do you “handshake” data?

The microservice architecture breaks down the large system into independent small modules, just like breaking down an entire control panel into several specialized small modules: one is only responsible for path planning, one is dedicated to processing sensor signals, and the other is responsible for torque control. It's flexible, but how do they share data between them?

There are several common modes:

• API pull: Like asking "do you have new data?" every few minutes. Simple, but inevitably delayed.
• message queue: The module "throws" the data into an intermediate channel, and whoever needs it can get it. It's asynchronous, but the order may be messed up.
• event driven: Once the data is generated, it is "broadcast" immediately. Modules that care about this event can respond in real time. It's a bit like a neurological reflex - when the stimulus comes, the action happens immediately.

Which one to choose? Depends on your scenario. Is it high real-time joint synchronization, or status monitoring that allows a slight delay?

kpowerThe solution: Make data as natural as “conversation”

We have thought about it for a long time and feel that ideal data sharing should not be a mechanical request and give, but should be closer to a smooth conversation. So, inkpowerIn the product logic, we have made some different designs.

Establish a “common language”. Different modules may come from different vendors and have a variety of data formats. The first thing we do is define a lightweight, general "data envelope". Regardless of the contents, envelopes are formatted consistently and unpacking is easy.

Add "context" to data. Simply transmitting a location coordinate is not enough, you must also include a timestamp, source module ID, and even a priority label. In this way, the receiver knows whether the coordinates are the historical value five minutes ago or the real-time command at this moment. This avoids malfunctions caused by stale data.

Allow "selective listening". Not all modules require all data. The motion control core may require real-time position streaming, while the fault diagnosis module may only care about alarm events. Our model allows modules to subscribe to the data topics they really care about, reducing unnecessary traffic and processing burden.

For example: In an AGV car project, the navigation module publishes position events in real time, and the driving wheel steering gear subscribes to them to achieve tracking; the battery management module only subscribes to voltage and temperature events, and triggers a deceleration alarm if there is an abnormality. Each takes what they need without interfering with each other.

What changes has this made?

The most direct feeling is "shun". The previous subtle lag while waiting for data disappeared, and the actions of the entire system looked more coherent and "smarter". Just like every musician in the band can not only look at the conductor, but also hear each other's melodies, and the cooperation will naturally be tacit.

It is easy to maintain. If there is a problem with any module, its data flow will immediately show abnormalities, making it much faster to locate the fault point. Upgrading or replacing a module will have no significant impact as long as it follows the same "dialogue rules".

Of course, there is no perfect solution. This model requires higher network stability and requires the team to spend more time planning the "topics" and flow of data in the early stages of design. But compared to troubleshooting data congestion in intricate code later, this upfront investment is usually worth it.

So, how to get started?

If you're choosing a solution for a new project, or are troubled by the sluggishness of your existing system, start by sorting out your data flows. Draw a diagram to indicate what data each module generates and what data it requires. See whether they are tightly coupled real-time dependencies or loosely coupled asynchronous notifications.

Then, try it on a small scale. Select a relatively independent functional unit, such as the link between visual positioning and the grasping arm, and reconstruct its data sharing in an event-driven manner. Feel the change in latency and the simplicity of the code.

Technology is just a tool, and the purpose is always to make machine collaboration smoother and allow your ideas to be implemented faster and more steadily. existkpower, we believe that good data flow can make every servo motor and every steering gear seem to have life-like coordination. This may be another look of smart manufacturing.

Established in 2005, Kpower has been dedicated to a professional compact motion unit manufacturer, headquartered in Dongguan, Guangdong Province, China. Leveraging innovations in modular drive technology, Kpower integrates high-performance motors, precision reducers, and multi-protocol control systems to provide efficient and customized smart drive system solutions. Kpower has delivered professional drive system solutions to over 500 enterprise clients globally with products covering various fields such as Smart Home Systems, Automatic Electronics, Robotics, Precision Agriculture, Drones, and Industrial Automation.