I am quite new to ROS, I've browsed through the wiki, and I am
starting to write some code (toy problems). So far so good. In
preparation of later work, I have some questions related to real time
issues and design of the software architecture.


Let say I have a fast sensor that I use to control an actuator. For
instance an encoder and a DC motor. The controller loop has to be
quite fast in order to ensure proper control. I read that ROS design
philosophy is "divide and conquer", i.e. small processes collaborating
toward a goal. So here are 2 solutions:

1) One process to read the encoder value and post the current position
/ speed on a topic. One process that reads voltage on a topic and pass
it to the motor. One process to run the PID controller using both
topics and one more to accept velocity / position commands.

2) One single process that will do all of it in a tight loop, publish
joint's position / velocity, and read position / velocity commands.

Of course, which solution to choose might depend on the hardware. For
instance, if both the encoder and the motor are connected to the same
DAQ card it make sense to have a single process to handle all the
hardware on that card and do the PID control as well. In that case, it
might be a rather complex process, depending on the number of IOs on
the card.

But otherwise, assuming that the encoder and the motor are on
independent hardware, which solution would be recommended? And how
fast can a ROS process run?

The problem get slightly more complex when several actuators are used
at the same time, i.e. when doing inverse kinematics on a 12 DOF
robotic arm. How would you suggest to design such a piece of hardware?
36 nodes (3 per DOF: encoder, motor and PID), and one more for the
inverse kinematics? Or one big node only that would accept different
types of commands (direct joint control, control the end effector,
etc. and publish the joint positions).



Other related scenario: on a robot, we have the odometer (updated
every 10ms) and a gyro (updated every 5ms). I want to combine them
both to obtain a more precise estimation of the robot's position. Here
again there are 2 solutions, one with 3 processes (gyro, odo, and
odoGyroPosSystem) and one with only one process that combines
everything.

In the second case, everything is neatly coupled in one process.
Typically one thread to read from the gyro, one to read from the
odometer, and the main thread to combine the information.

With the first solution, I am curious to know what would happen. The
gyro node would publish a new data every 5 ms? or packets would be
aggregated and a listener would get several packets at once (jamming)?


I will be grateful for all comments
Brice