# Revision history [back]

This is a comment, but I can't do formatting in a comment.

We know handling plugins is a significant load. Right now you have one thread doing

simulate-one-step / handle-plugins / simulate-one-step / handle-plugins / ...


One way to get more simulation per unit of real time is to split this into two threads.

thread 1: simulate-step 1  / simulate-step 2  / simulate-step 3  / ...
thread 2: handle-plugins 0 / handle-plugins 1 / handle-plugins 2 / ...


These threads are synchronized through a shared memory flag.

It is true that with this scheme, the controller at best can use information from step i to affect step i+2. 1) This matches reality, and the way we actually control our existing humanoid robot. It takes time to move data, and with individual joint controllers it takes a lot of UDP packets to do it. 2) If the simulation time step is smaller (say 0.5msec) than the control interval (say 1msec), this effect is reduced.

Plugins that happen less often but take more computation (vision) can be handled in a different thread that is only triggered every N simulation steps, but otherwise is idle (avoid creating and destroying threads for each plugin invocation to reduce overhead):

thread 1: simulate-step 1  / simulate-step 2  / simulate-step 3  / ...
thread 2: joint-plugins 0  / joint-plugins 1  / joint-plugins 2  / ...
thread 3: idle             / vision-plugin 1 ********* / idle                      ...


In fact, to process the plugins as fast as possible, they should each run in a separate thread once the relevant simulation information is available from the simulation step.

I hope this clarifies what I am trying to say about threading the simulator more effectively.

Thanks,

Chris

This is a comment, but I can't do formatting in a comment.

We know handling plugins is a significant load. Right now you have one thread doing

simulate-one-step / handle-plugins / simulate-one-step / handle-plugins / ...


One way to get more simulation per unit of real time is to split this into two threads.

thread 1: simulate-step 1  / simulate-step 2  / simulate-step 3  / ...
thread 2: handle-plugins 0 / handle-plugins 1 / handle-plugins 2 / ...


These threads are synchronized through a shared memory flag.

It is true that with this scheme, the controller at best can use information from step i to affect step i+2. 1) This matches reality, and the way we actually control our existing humanoid robot. It takes time to move data, and with individual joint controllers it takes a lot of UDP packets to do it. Moving a camera image from the imaging chip through some USB/Firewire/ethernet interface into computer memory takes time (usually 10s of msec) and happens in parallel with the robot physically moving. 2) If the simulation time step is smaller (say 0.5msec) than the control interval (say 1msec), this effect is reduced.

Plugins that happen less often but take more computation (vision) can be handled in a different thread that is only triggered every N simulation steps, but otherwise is idle (avoid creating and destroying threads for each plugin invocation to reduce overhead):

thread 1: simulate-step 1  / simulate-step 2  / simulate-step 3  / ...
thread 2: joint-plugins 0  / joint-plugins 1  / joint-plugins 2  / ...
thread 3: idle             / vision-plugin 1 ********* / idle                      ...


In fact, to process the plugins as fast as possible, they should each run in a separate thread once the relevant simulation information is available from the simulation step.

I hope this clarifies what I am trying to say about threading the simulator more effectively.

Thanks,

Chris

This is a comment, but I can't do formatting in a comment.

We know handling plugins is a significant load. Right now you have one thread doing

simulate-one-step collision-and-physics (CP) / handle-plugins / simulate-one-step / handle-plugins / (PL) / CP / PL / CP / PL ...


One way to get more simulation per unit of real time is to split this into two threads.

thread 1: simulate-step CP step 1  / simulate-step CP step 2  / simulate-step CP step 3  / CP step 4 / ...
thread 2: handle-plugins PL from 0 / handle-plugins  / PL from 1 / handle-plugins  / PL from 2  / PL from 3 / ...


These threads are synchronized through a shared memory flag.

It is true that with this scheme, the controller at best can use information from step i to affect step i+2. 1) This matches reality, and the way we actually control our existing humanoid robot. It takes time to move data, and with individual joint controllers it takes a lot of UDP packets to do it. Moving a camera image from the imaging chip through some USB/Firewire/ethernet interface into computer memory takes time (usually 10s of msec) and happens in parallel with the robot physically moving. 2) If the simulation time step is smaller (say 0.5msec) than the control interval (say 1msec), this effect is reduced.

Plugins that happen less often but take more computation (vision) can be handled in a different thread that is only triggered every N simulation steps, but otherwise is idle (avoid creating and destroying threads for each plugin invocation to reduce overhead):

thread 1: simulate-step CP step 1  / simulate-step  / CP step 2  / simulate-step  / CP step 3   / CP step 4  / ...
thread 2: joint-plugins joint PL 0  / joint-plugins joint PL 1  / joint-plugins joint PL 2  / joint PL 3 / ...
thread 3: idle         / vision-plugin using data from step 1 ********* / idle                      ...


In fact, to process the plugins as fast as possible, they should each run in a separate thread once the relevant simulation information is available from the simulation step.

I hope this clarifies what I am trying to say about threading the simulator more effectively.

Thanks,

Chris