Software > Software

Distributed algorithms

(1/5) > >>


I am researching a 'distributed design' for a robot. See also this thread for my question on the hardware.

The idea is to divide a big problem (of all the functions a robot might have) up in autonomous small problem. So suppose we have a walking robot where each leg has its own MCU managing just that one leg. All these slave controllers are connected onto a bus to receive high-level commands and/or send back events (leg stuck, too much force etc.). The central brain (MCU) - also connected to the bus- only has to deal with these high level commands and events. It orchestrates /coordinates the operations of all these intelligent slave MCU's.

The idea is to use very simple/small MCU for each slave controller and use a multi-tasking MCU as the brain. I haven't decided yet on which exact brands/types/models to use. I assume I will be programming in C++ (or perhaps C#/.NET micro). So some overhead will require a minor increase in available (programming) memory.

My question is, what algorithms or (code) design patterns would be appropriate for this type of design.

I have some idea's of my own but I was wondering what you guys think.


This topology has been used a lot in robotics. ROS has significant support for this topology, for example.

In general, where you put your smarts has a lot to do with economics. Building reliable busses to communicate status and commands with low latency adds cost, and support functions for a MCU (power regulation, filtering, etc) also adds cost.

Most systems that go for this approach end up putting one controller per separately-built or separately-sold item. For example, if you build a vision sensor, you end up building image processing into that sensor and selling it all as a single device.

The example of one MCU per leg is a little stretched, because the processing power needed for IK and servo control is trivial even for the cheapest microcontrollers today. Running four legs from a single MCU ends up being cheaper, and often more robust, for current systems. If you want a system that has some degree of autonomy even when the executive functions are disabled ("reflexes") then you'd want an MCU per extremity, though. So, it depends on what requirements you have and what you want to pay for.

I understand the economics and efficiency part of this design. The 'one MCU per leg' was only and example to clarify what I meant (clearly you got it ). At this moment I am only researching the possibilities and options. The decision on how many MCU per 'part' will be made later.

One of the reasons why I am researching this design is to make things modular. Now I know that there are other ways to do that (and it is not the only reason) but those other ways always seem to involve a limited amount of 'connectors' on the main board - only allowing you to connect so many legs/wheels/sensors etc.

The way around that is to use a bus that can address each attached 'device'. Each 'device' board would have the connectors to connect to the next 'device' - so at least 2 connectors.

Another reason is just for the fun of it. I want to explore the implications of using a distributed design (rule 1 of distribution: don't do it ;-) and in this particular post I am asking for the software implications.

What are the commonly used practices for communicating with other MCU's and how do you let multiple MCU's accomplish one task? What can you do when one or more 'node' are offline? That sort of stuff...


--- Quote from: jwatte on April 23, 2013, 11:51:44 AM ---This topology has been used a lot in robotics. ROS has significant support for this topology, for example. [..]

--- End quote ---

I just looked up ROS (Robotic Operating System) and it runs on Linux! That is not quite the level I was aiming for. I was aiming on a more small scale, lower level solution. So not quite as professional probably :-P

But a good source of 'inspiration' - no doubt.

You could implement your own non pre-emptive scheduler straight onto the tin. It's just a loop with a clock variable and a set of priorities. When clock % priority = 0, then run the associated task. Keep the tasks small and quick, and it's a very efficient paradigm.


[0] Message Index

[#] Next page

Go to full version