Robus power management

The community voted and the next robot off the month will be the Robotis shield. So we start working on it and we face a BIG problem, the power management.

Problem description

L0 are boards connected together using Robus. Each L0 run a Luos core and can manage different kind of specific hardware. To simplify, for now we can consider the specific hardware as an undefined shield on L0. The power between each L0 is shared and L0 also share the power to its shield :

The questions are how to power the Network safely and how to manage different nominal voltage on different shields?

How to power the network

If we consider this network (again) :
To have something on Vin we need to have one of the shield who is a provider container.
A provider container is a L0 with a shield (a specific electronics) who can send power to the network.
For example batteries, USB, or DCInput containers are typical providers containers.
Naturally others containers such as led, button, potentiometer for example are consumer containers.

To be clear we will use a concrete example.
Marc want to make awesome robots. To begin he just want to have leds on his network (ok this is not really a robot). So he take a 12V battery container and 2 leds containers and plug them together.
In this case the battery container is a provider container and led’s are consumer containers. the Vin value will be 12V on the entire network. The consumers containers (led) have to manage the Input voltage (12v) to something usable for leds.

After that Marc want to control his leds through a computer. To do that he add an USB container to link the Luos network to his computer.
But as we seen previously the USB container is a provider container such as the battery container! If we simply link the provider to the Vin we will probably have flames and pyrotechnics effects because the 5V is linked to 12V and it’s resulting on a 7V short circuit.
To manage power conccurency we have to define rules.

Generally on the Robus link we prefer to have high voltage that allowing us to transport more power with less heat dissipation and reduce the wire voltage dropout impact. So, by default we want to prioritize the higher voltage provided by all the providers containers.
Lucky we are, we have a perfect component to do that called diode ! If we add a Diode transferring the power from the provider container to the network, the network will keep the higher voltage of all providers containers and all lower voltage providers containers will be isolated :

This is a default and safe power management, this way you can’t burn anything.
Marc being a conscientious electronics engineer, he want to reduce heat loss on power converters of led containers. To do that he prefer to use the lower power available on every provider container and he want to be able to manage that by software. To do that providers containers will need to be able to isolate themself from the network using a software controled transistor :
In this case Mark isolate the battery so leds are powered by 5v, we can choose the main power of the network by isolating all the higher providers containers!

how to apply this symbolic schematic to a real circuit ?

So we have a simple concept using diodes and a thing to cut the power, how we can do it for real ?

The thing who would use to cut the power is a Mosfet. In our case we have to use N-mosfet instead of P-mosfet as I explain it in this post : Why we use N mosfet instead of P mosfet?

Usually on electronics all ground are linked. That’s why we call it ground, because nobody can’t go down the ground, ground is the common base.
To succeed with N-mosfet we have to reverse this logic and use the positive potential as common potential.
So we can just put the diode and the N-mos on ground line :
Here the “power source” boc represent the alimentation into the provider container.

Low voltage container exception

Because of cables voltage drop and L0 power input tolerances we don’t want to provide a power less than 5V. As we seen it previously, the mosfet is used to isolate provider containers voltages. To have a given voltage you have to isolate all higher voltage source. But 5V is the minimum admissible voltage for Robus, so we don’t need to have the possibility to isolate it. You can omit the mosfet for those ones.

how to manage different nominal voltage on different shields

Now we mastering how to power the network using provider containers, we can face the other side of the problem, how to manage consumer containers.
Consumer containers don’t know the power they will have from the robus power.

power converter block

This is no big deal for small power containers such as small sensors. We can just use a small power converter to have something usable for those devices. There is no specific protection needed for those containers (except the converter).

over/under voltage protection block

The real problem come when we have to power a powerfull consumer container. In those type of container a power converter will need a big volume, a high price, and finally generate a lot of heat loss and reduce the dynamic of the consumer container by limiting the current.
To avoid this kind of power conversion we have to use directly the power provided by Robus.

To protect this kind of container from under-voltage and over-voltage we need to define protection allowing to isolate the circuit in case of trouble. The solution is to use comparator circuit for each limit.


The container Load represent the equipment to power, for example a motor or a speaker.

Now you can understand the importance to have the possibility of choosing the voltage of your Robus network. If all your motors work at 7v except one using 12V you will prefer to have your Robus voltage at 7V to be able to power them all with the same power source and power the only one using 12V separately.
In the future we will be able to make an “isolator container” that have 2 robus interfaces without common voltage on connectors. The result is 2 diferent network tension on each side able to communicate anyway.

As I said at the begining of this post, we face the power problem when we start designing the Dynamixel shield. Robotis have container managing power on the motor network. So the dynamixel Luos container can be a power source for the Robus network. If it can self power itself, it is a provider container, but we also want to be able to use the Robus power to run a non powered Robotis chain, in this case it is a consumer container!
As you can see here we face a really strange configuration. This container will need the electronics needed for providers containers but also needded by consumer container.

how to detect provider or consumer container mode

Hybride containers like the Dynamixel one will need to have provider container electronics and consumer container electronics combined together with a logic allowing to switch from one to another. To choose witch is the mode to enable we need to detect if we have a power source on the shield or not.

power source detection block

To switch from one to another we need to detect if we have a power source in the container or not, here is a solution to do that :
The action of plug the power into the shield is represented here by the button called plug.
This is simply a power plug detector, out is 1 if there is a power plugged and 0 if not.
This circuit is usefull if we have a power entry in the shield, and it will be the case of a majority of power shield.

current direction detection block

In the case of Robotis shield case the problem is even more complex because the user have the possibility to plug the power into the robotis chain. In other word if we use the last picture as reference the Input power come from the “Container Load” and this circuit doesn’t work anymore, we have to detect something else.

To solve this problem we need to detect the current direction, from Vcontainer to load or from load to Vcontainer :
As you can see here diodes allow us to detect if the power come from Vcontainer or from the container load.

how to link all of this together to have an hybride container

Now we have a lot of different circuit for different situation how to put everything together to have a good hybride (provider+consumer) container.

here is a lit of block we have defined previously:

  • Provider Block
  • Consumer block (power converter or over/under voltage protection)
  • Mode detector (power source or current direction)

The P mosfet on this picture is used to bypass the provider block and switch into consumer mode. As you can see here we have a new block to link Conumer block and Detection block. To design this “Logic block” we have to make a truth table :

detection (1 = power from shield) consumer (1 = input not ok) Nmosfet (0 = blocked)
0 0 0
0 1 1
1 0 0
1 1 0

Now to have this result here is the logic block :

You have all blocks and possibilities now, you have to compose your own depending on the container purpose.

Pictures sources :


I am not sure to understand, here you mean we can either power the motor via plugging a power source on the shield (Vcontainer) or powering the bus via anywhere else on the bus (Container Load)? And sometime both are plugged at the same time?

Then what happens if Vcontainer == VLoad?

Could you reexplain what you mean by Container Load?

I will probably rewrite a big part of this post because we change a lot of things those days.

Yes we can have different power source on the network, for example if you have a xl320 chain (7v) and an AX one (12V) you can power both chain and the network will manage.
If you have 2x12V they will power the closest containers without compete with each other, so you can use multiple power source to dispatch current into your robot.

The container load is the part of the shield who consume the power. In case of the Robotis shield the container load are Robotis motors.

I will rewrite that to be clear, thanks.