Control loop model

[Antoine Rennuit]

Hi,

I am currently wondering about the architecture of my control loop. I am using a simulated robot (under vrep) for a robot which will be built in real in a few months. Obviously the control is performed using ros_control. I'd like to use the same control architecture (same loop) for my real and my simulated robots. Now I have looked around and found several architectures possible to link ros_control with a robot (simulated or real).

1. Synchronous model: at each simulation step the controller manager is updated and a command is generated and applied to the motors. This is the architecture used by gazebo_ros_control which is actually a gazebo plugin: the communication between the control and the simulator does not use ros communication as it uses gazebo's API, this makes the code rather simple but it cannot be extended to a real robot (as a real robot does not have periodic steps such as the simulation steps).

2. Pseudo-synchronous model: the simulator sends the joints state update at each step in a topic which the control loop subscribes to. The controller manager then updates, and the command is sent to the simulator via a topic which the simulator is subscribed to (and applies the command to the motors). The quality of the synchronization between the simulator and control depends on the speed of the spin (i.e. this model does not enforce to have exactely a ros_control step per simulator step). This architecture cannot be extended to a real robot.

3. Asynchronous model: setup a timer on the ros_control side which computes a command periodically and independently from the steps of the simulator - we should make sure the control loop runs much faster than the simulator (say 10x?). With this model there may be more control steps than simulation steps but if we use topics to send the commands, the latest command will overwrite the former ones and things should behave correctly. Control and ros communication run in separate threads. This is the architecture shown on the RosCon 2014 presentation and to my understanding it can be applied straightforwardly on both real and simulated robots.

Are there other relevant architectures possible which are not too far-fetched? Now my main question is related to getting a system as close as possible to the real setup. My gut feeling is that model 3. (asynchronous) is certainly closest to what I am going to use on the real robot (as there is no such thing as a synchronous mode on a real robot) and so it is what I should use for the simulator version as well, no?

Anyone having a recommendation or advise on the matter?

Thanks,

Antoine.

[Adolfo Rodríguez Tsouroukdissian]

On Sun, Oct 19, 2014 at 8:45 PM, Antoine Rennuit <antoine...@gmail.com> wrote:

Hi,

Antoine,
 

I am currently wondering about the architecture of my control loop. I am using a simulated robot (under vrep) for a robot which will be built in real in a few months. Obviously the control is performed using ros_control. I'd like to use the same control architecture (same loop) for my real and my simulated robots. Now I have looked around and found several architectures possible to link ros_control with a robot (simulated or real).

You can likely reuse some but not all of the code that makes up a robot backend.

The details of the hardware and simulation backends will likely differ in some ways. The most obvious one is the API for accessing hardware (real or virtual). Another one is how the periodic control loop is enforced. When you need to explicitly specify periodic timer events, you can use tools from ros::Rate for no real-time setups (the ROSCON talk example), to high-resolution RTOS primitives. In other circumstances you might embed ros_control into a higher level framework, which takes care of waking you up at a specified frequency. The Gazebo integration is an example of the latter, where you request the simulator to wake you up at a frequency lower or equal than that of the simulation.

Summing up, the controller_manager is designed to work with a periodic control loop, which either you set up or must be serviced by the embedding application.

(there is one inline comment below)

 

 

1. Synchronous model: at each simulation step the controller manager is updated and a command is generated and applied to the motors. This is the architecture used by gazebo_ros_control which is actually a gazebo plugin: the communication between the control and the simulator does not use ros communication as it uses gazebo's API, this makes the code rather simple but it cannot be extended to a real robot (as a real robot does not have periodic steps such as the simulation steps).

2. Pseudo-synchronous model: the simulator sends the joints state update at each step in a topic which the control loop subscribes to. The controller manager then updates, and the command is sent to the simulator via a topic which the simulator is subscribed to (and applies the command to the motors). The quality of the synchronization between the simulator and control depends on the speed of the spin (i.e. this model does not enforce to have exactely a ros_control step per simulator step). This architecture cannot be extended to a real robot.

3. Asynchronous model: setup a timer on the ros_control side which computes a command periodically and independently from the steps of the simulator - we should make sure the control loop runs much faster than the simulator (say 10x?).

There is no gain in running the control loop faster than the simulation loop because in between simulation updates state readings will not change and computed commands will not be executed. You'll just burn computational resources.

Adolfo.

 

With this model there may be more control steps than simulation steps but if we use topics to send the commands, the latest command will overwrite the former ones and things should behave correctly. Control and ros communication run in separate threads. This is the architecture shown on the RosCon 2014 presentation and to my understanding it can be applied straightforwardly on both real and simulated robots.

Are there other relevant architectures possible which are not too far-fetched? Now my main question is related to getting a system as close as possible to the real setup. My gut feeling is that model 3. (asynchronous) is certainly closest to what I am going to use on the real robot (as there is no such thing as a synchronous mode on a real robot) and so it is what I should use for the simulator version as well, no?

Anyone having a recommendation or advise on the matter?

Thanks,

Antoine.

--
You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo.r...@pal-robotics.com
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
Skype: adolfo.pal-robotics
Facebook - Twitter - PAL Robotics YouTube Channel

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.

[John Yamokoski]

I will share what we have done with ros_control. We embedded ros_control, inside an OROCOS component. This allowed us to tick ros_control with low latency and jitter on a RT-patched linux.

Second (this was somewhat specific to our hardware, but the same principle could apple), we communicate with our hardware through a kernel driver and that communication with the kernel driver is mediated by a share memory region. To switch between hardware and simulation, we simply wrote our own gazebo plugin that talked to the same memory addresses in shared memory that our hardware would. Therefore, except for some different gains used by the controller, there the controllers had no idea whether they were talking with simulation or hardware.

The drawback of our implementation is that we introduced jitter by using asynchronous loops in the controller and communication hardware. But we are working on a solution to that.

--

[Jonathan Bohren]

On Sun, Oct 19, 2014 at 2:45 PM, Antoine Rennuit <antoine...@gmail.com> wrote:

1. Synchronous model: at each simulation step the controller manager is updated and a command is generated and applied to the motors.

2. Pseudo-synchronous model: the simulator sends the joints state update at each step in a topic which the control loop subscribes to. 

 

3. Asynchronous model: setup a timer on the ros_control side which computes a command periodically and independently from the steps of the simulator - we should make sure the control loop runs much faster than the simulator (say 10x?). 

 

I'm having trouble understanding why you say the first two aren't applicable to both simulated and real hardware. Also, like Adolfo said, there's no sense in making a controller run faster than the information it's receiving. If anything, you want the simulator running at a higher rate than the controller. 

With our Barrett WAM arms [1], we use Orocos with a controller manager (ConMan [2]) that has a ROS API similar to that of ros-control, and enforces similar constraints between orocos control components. The entire real-time control infrastructure is completely independent of how we interact with the real or simulated low-level hardware. All of that is determined based on whether we load the WAM orocos component which talks over the CANBus or the WAM orocos component which uses the Gazebo APIs. 

On the real hardware, this WAM component spins up a dedicated thread for CANBus IO, and uses a pair of lock-free buffers to communicate with the single-threaded control loop managed by ConMan. The way this is implemented, it means that while the (bandwidth-limited) CANBus sending the last command and retrieving the latest state, our control command can be computed. When this is running, it synchronizes the two threads without blocking unless there is no recent state update from the hardware.

In simulation, we use the same model, except the scheduling of the whole system is controlled by the Gazebo clock. This simulated orocos clock is managed automatically by the rtt_gazebo [3] packages. This means that you can simulate a given (realistic) control update rate even if your computer can't simulate the world quickly enough. This has the downside, however, of slowing down the simulation because it executes orocos components and the gazebo simulation solver in series. Something I've been meaning to add to the rtt_gazebo packages is a way to parallelize the computation of the simulation step and the control step.

As an aside, what are your experiences using V-REP with ROS?

[1] https://github.com/jhu-lcsr/orocos_barrett

[2] https://github.com/jbohren/conman

[3] https://github.com/jhu-lcsr/rtt_gazebo

-j

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

[Antoine Rennuit]

@Aldolfo, my answer in the text below:

 

You can likely reuse some but not all of the code that makes up a robot backend.

The details of the hardware and simulation backends will likely differ in some ways. The most obvious one is the API for accessing hardware (real or virtual). Another one is how the periodic control loop is enforced. When you need to explicitly specify periodic timer events, you can use tools from ros::Rate for no real-time setups (the ROSCON talk example), to high-resolution RTOS primitives. In other circumstances you might embed ros_control into a higher level framework, which takes care of waking you up at a specified frequency. The Gazebo integration is an example of the latter, where you request the simulator to wake you up at a frequency lower or equal than that of the simulation.

Summing up, the controller_manager is designed to work with a periodic control loop, which either you set up or must be serviced by the embedding application.

Ok I have decided to use a vrep plugin which wakes my controller manager up periodically, this ensures synchronisation  with the simulation and simplicity of the communication (as I can use a plain API). I did not manage to get it working yet but I am on it ;) And thanks by the way as this was inspired by a former message of yours.

 

3. Asynchronous model: setup a timer on the ros_control side which computes a command periodically and independently from the steps of the simulator - we should make sure the control loop runs much faster than the simulator (say 10x?).

There is no gain in running the control loop faster than the simulation loop because in between simulation updates state readings will not change and computed commands will not be executed. You'll just burn computational resources.

 

So what I understand from what you wrote above and from reading this post on another message is that:

• there is no need to have control running faster than simulation (this makes sense)
• if communication and control are asynchronous, control should be an order of magnitude faster than communication (to account for varying delays in transport)
  

Right?

[Antoine Rennuit]

@John: this is a very clean approach, especially when you eventually solve the jitter problem. Any idea on how time consuming this was to develop? I guess this depends on the skills of the team in systems programming...

Also, I guess with this architecture, the control update is called at the same rate whether in simulation or in real mode, no? But also the shared memory (I guess containing the system state and command) must be updated much faster with a real robot than with a simulation, no? That does not cause control glitches?

[Antoine Rennuit]

@Jonathan: my answer below:

Le lundi 20 octobre 2014 18:00:15 UTC+2, Jonathan Bohren a écrit :

On Sun, Oct 19, 2014 at 2:45 PM, Antoine Rennuit <antoine...@gmail.com> wrote:

1. Synchronous model: at each simulation step the controller manager is updated and a command is generated and applied to the motors.

2. Pseudo-synchronous model: the simulator sends the joints state update at each step in a topic which the control loop subscribes to. 

 

3. Asynchronous model: setup a timer on the ros_control side which computes a command periodically and independently from the steps of the simulator - we should make sure the control loop runs much faster than the simulator (say 10x?). 

 

I'm having trouble understanding why you say the first two aren't applicable to both simulated and real hardware. Also, like Adolfo said, there's no sense in making a controller run faster than the information it's receiving. If anything, you want the simulator running at a higher rate than the controller. 

In the simulation case you can synchronize the control loop against the simulation step events, but I am not sure I understand which event you can use in the real robot case, to synchronize your control loop against... This cannot be encoders (or robot state) updates, can it?

 

With our Barrett WAM arms [1], we use Orocos with a controller manager (ConMan [2]) that has a ROS API similar to that of ros-control, and enforces similar constraints between orocos control components. The entire real-time control infrastructure is completely independent of how we interact with the real or simulated low-level hardware. All of that is determined based on whether we load the WAM orocos component which talks over the CANBus or the WAM orocos component which uses the Gazebo APIs. 

On the real hardware, this WAM component spins up a dedicated thread for CANBus IO, and uses a pair of lock-free buffers to communicate with the single-threaded control loop managed by ConMan. The way this is implemented, it means that while the (bandwidth-limited) CANBus sending the last command and retrieving the latest state, our control command can be computed. When this is running, it synchronizes the two threads without blocking unless there is no recent state update from the hardware.

In simulation, we use the same model, except the scheduling of the whole system is controlled by the Gazebo clock. This simulated orocos clock is managed automatically by the rtt_gazebo [3] packages. This means that you can simulate a given (realistic) control update rate even if your computer can't simulate the world quickly enough. This has the downside, however, of slowing down the simulation because it executes orocos components and the gazebo simulation solver in series. Something I've been meaning to add to the rtt_gazebo packages is a way to parallelize the computation of the simulation step and the control step.

Very clean! This is far from being the out-of-the-box (or low time-intensive) solution I am aiming at. I keep it in mind for the record (and because it may inspire me in the future). Unfortunately at the time being I cannot invest all the time needed to develop such a clean solution...

 

As an aside, what are your experiences using V-REP with ROS?

So far my feeling with vrep is that it rocks! It just works... It is easy to use from the very beginning and scales well to more complex setups. The basic integration with ros is clean, comprehensive and open (the default vrep-ros plugin is easy to modify). I still have my hands dirty on the integration with ros_control. So more on this in the coming days when I struggle a bit less on the matter...

 

[Adolfo Rodríguez Tsouroukdissian]

 

So what I understand from what you wrote above and from reading this post on another message is that:

• there is no need to have control running faster than simulation (this makes sense)
• if communication and control are asynchronous, control should be an order of magnitude faster than communication (to account for varying delays in transport)
  

This last point is not implied in the referenced post. What I meant was that if you have two independent threads that:
- share common data,
- update at the same periodic frequency,

- but have no mechanism to notify each other when data becomes available,

then the shared data you read might be up to one period old.

Having the control loop running faster than your backend, be it simulation or hardware, is a waste of computational resources. If you want to reduce your control cycle delay, there are other alternatives.

HTH,

Adolfo.

Right?

--
You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adolfo Rodríguez Tsouroukdissian]

On Tue, Oct 21, 2014 at 9:16 AM, Antoine Rennuit <antoine...@gmail.com> wrote:

@Jonathan: my answer below:

Le lundi 20 octobre 2014 18:00:15 UTC+2, Jonathan Bohren a écrit :

On Sun, Oct 19, 2014 at 2:45 PM, Antoine Rennuit <antoine...@gmail.com> wrote:

1. Synchronous model: at each simulation step the controller manager is updated and a command is generated and applied to the motors.

2. Pseudo-synchronous model: the simulator sends the joints state update at each step in a topic which the control loop subscribes to. 

 

3. Asynchronous model: setup a timer on the ros_control side which computes a command periodically and independently from the steps of the simulator - we should make sure the control loop runs much faster than the simulator (say 10x?). 

 

I'm having trouble understanding why you say the first two aren't applicable to both simulated and real hardware. Also, like Adolfo said, there's no sense in making a controller run faster than the information it's receiving. If anything, you want the simulator running at a higher rate than the controller. 

In the simulation case you can synchronize the control loop against the simulation step events, but I am not sure I understand which event you can use in the real robot case, to synchronize your control loop against... This cannot be encoders (or robot state) updates, can it?

It depends on your setup. If you have a meaningful source of time events that you can synchronize against, you can use that; otherwise you should create that source yourself (like the ros::Rate instance in the basic examples). In Gazebo there exists the simulation loop, which takes care of waking up the ros_control plugin periodically. Some robot hardware backends also have some governing structure that takes care of stepping the control loop.

 

With our Barrett WAM arms [1], we use Orocos with a controller manager (ConMan [2]) that has a ROS API similar to that of ros-control, and enforces similar constraints between orocos control components. The entire real-time control infrastructure is completely independent of how we interact with the real or simulated low-level hardware. All of that is determined based on whether we load the WAM orocos component which talks over the CANBus or the WAM orocos component which uses the Gazebo APIs. 

On the real hardware, this WAM component spins up a dedicated thread for CANBus IO, and uses a pair of lock-free buffers to communicate with the single-threaded control loop managed by ConMan. The way this is implemented, it means that while the (bandwidth-limited) CANBus sending the last command and retrieving the latest state, our control command can be computed. When this is running, it synchronizes the two threads without blocking unless there is no recent state update from the hardware.

In simulation, we use the same model, except the scheduling of the whole system is controlled by the Gazebo clock. This simulated orocos clock is managed automatically by the rtt_gazebo [3] packages. This means that you can simulate a given (realistic) control update rate even if your computer can't simulate the world quickly enough. This has the downside, however, of slowing down the simulation because it executes orocos components and the gazebo simulation solver in series. Something I've been meaning to add to the rtt_gazebo packages is a way to parallelize the computation of the simulation step and the control step.

Very clean! This is far from being the out-of-the-box (or low time-intensive) solution I am aiming at. I keep it in mind for the record (and because it may inspire me in the future). Unfortunately at the time being I cannot invest all the time needed to develop such a clean solution...

 

As an aside, what are your experiences using V-REP with ROS?

So far my feeling with vrep is that it rocks! It just works... It is easy to use from the very beginning and scales well to more complex setups. The basic integration with ros is clean, comprehensive and open (the default vrep-ros plugin is easy to modify). I still have my hands dirty on the integration with ros_control. So more on this in the coming days when I struggle a bit less on the matter...

Sounds good. Let us know if at some point in the future you'd be interested in contributing a robot agnostic v-rep backend.

Best,

Adolfo.

[Antoine Rennuit]

This last point is not implied in the referenced post. What I meant was that if you have two independent threads that:
- share common data,
- update at the same periodic frequency,

- but have no mechanism to notify each other when data becomes available,

then the shared data you read might be up to one period old.

Having the control loop running faster than your backend, be it simulation or hardware, is a waste of computational resources. If you want to reduce your control cycle delay, there are other alternatives.

Okey dok, this point is now clear.
 

It depends on your setup. If you have a meaningful source of time events that you can synchronize against, you can use that; otherwise you should create that source yourself (like the ros::Rate instance in the basic examples). In Gazebo there exists the simulation loop, which takes care of waking up the ros_control plugin periodically. Some robot hardware backends also have some governing structure that takes care of stepping the control loop.

I did not think such a thing as a governing structure on the hardware could exist, but in such a case than that makes sense.
 

Sounds good. Let us know if at some point in the future you'd be interested in contributing a robot agnostic v-rep backend.

I will be happy to contribute with an example of a simplified working setup + code, but I am not there yet.

Cheers,

Antoine.