Rename CanBusControlBoard to CanBusBroker

docs/tutorial/motor.md

@@ -53,8 +53,8 @@ The preferred approach, using the APIs provided by YARP within our programs and
     - [roboticslab::YarpOpenraveControlBoard](https://robots.uc3m.es/openrave-yarp-plugins/classroboticslab_1_1YarpOpenraveControlBoard.html)
     - [openrave-yarp-plugins/libraries/YarpPlugins/YarpOpenraveControlBoard](https://github.com/roboticslab-uc3m/openrave-yarp-plugins/tree/master/libraries/YarpPlugins/YarpOpenraveControlBoard)
   - Implementation in real robot
-    - [roboticslab::CanBusControlBoard](https://robots.uc3m.es/yarp-devices/classroboticslab_1_1CanBusControlBoard.html)
-    - [yarp-devices/libraries/YarpPlugins/CanBusControlBoard](https://github.com/roboticslab-uc3m/yarp-devices/tree/master/libraries/YarpPlugins/CanBusControlBoard)
+    - [roboticslab::CanBusBroker](https://robots.uc3m.es/yarp-devices/classroboticslab_1_1CanBusBroker.html)
+    - [yarp-devices/libraries/YarpPlugins/CanBusBroker](https://github.com/roboticslab-uc3m/yarp-devices/tree/master/libraries/YarpPlugins/CanBusBroker)
 - Examples (in the `remote` line, switch to `/teoSim/leftArm` or the limb of your selection)
   - C++
     - [yarp-devices/examples/cpp/exampleRemoteControlBoard](https://github.com/roboticslab-uc3m/yarp-devices/tree/master/examples/cpp/exampleRemoteControlBoard)

docs/tutorial/trajectories.md

@@ -40,13 +40,13 @@ The current default is **"online remote push"**, which is often the correct choi
 The [`TechnosoftIpos`](https://github.com/roboticslab-uc3m/yarp-devices/tree/master/libraries/YarpPlugins/TechnosoftIpos) device encapsulates a collection of CANopen instructions that enable communication with the robot's iPOS drivers.
 We have implemented `yarp::dev::IPositionDirect` in a twofold manner:
 
-- Cyclic synchronous position (CSP): this low-level iPOS mode assumes position commands are sent in a periodic manner - in our case, defined by the `syncPeriod` option to [`CanBusControlBoard`](https://github.com/roboticslab-uc3m/yarp-devices/tree/master/libraries/YarpPlugins/CanBusControlBoard) (configurable; current default at time of writing is 0.02 seconds). If you choose a CSP-compliant method, an internal interpolator will adjust incoming values to avoid gaps as much as possible (thus achieving a smooth behavior) unless the command period used in your application matches said synchronization period, in which case values will be processed exactly as they are. Provided examples show how to avoid detrimental clock drifts.
+- Cyclic synchronous position (CSP): this low-level iPOS mode assumes position commands are sent in a periodic manner - in our case, defined by the `syncPeriod` option to [`CanBusBroker`](https://github.com/roboticslab-uc3m/yarp-devices/tree/master/libraries/YarpPlugins/CanBusBroker) (configurable; current default at time of writing is 0.02 seconds). If you choose a CSP-compliant method, an internal interpolator will adjust incoming values to avoid gaps as much as possible (thus achieving a smooth behavior) unless the command period used in your application matches said synchronization period, in which case values will be processed exactly as they are. Provided examples show how to avoid detrimental clock drifts.
 - Interpolated position (ip): involves an internal setpoint buffer which depletes at a constant (**synchronous**) or variable (**asynchronous**) period. Because of said buffer and the delays it would introduce, *ip* is not suitable for online trajectories. Users can select one of two submodes: *pt* (linear interpolation) or *pvt* (cubic interpolation). Note that *ip* is considered legacy per the latest CANopen standards.
 
 On the above premises, implemented methods can be described as follows:
 
 - Online remote push: CSP trajectory execution, best suited for online targets generated on the fly (but also good if loading saved setpoints from a file), can be tested on the simulator. In this case, the client application manages a timer or anything of that sort to "push" setpoints on a precise schedule. Said application is usually not executed aboard the robot (i.e. remote).
 - Online remote pull: largely the same as above except that it is designed to connect to a remote synchronization port and send position commands in a callback fashion. The port streams current system clock at the same rate CSP expects a new setpoint. On the real robot, look for a `/<prefix>/sync:o` port. You can also mimick this behavior in simulation, check the footnotes for the previous table.
-- Online local pull: also callback-based in the same vein, but it depends on passing a semaphore handle to `CanBusControlBoard`, therefore it is only suitable for applications that run on the robot board and instantiate `CanBusControlBoard` along with the full robot configuration. The handle you need to pass is an instance of [`StateObserver`](https://robots.uc3m.es/yarp-devices/classroboticslab_1_1StateObserver.html).
-- Offline synchronous: depends on [`yarp::dev::IRemoteVariables`](http://www.yarp.it/git-master/classyarp_1_1dev_1_1IRemoteVariables.html) to correctly configure `TechnosoftIpos` for compliance with the *ip* mode ([docs](https://robots.uc3m.es/yarp-devices/md_libraries_YarpPlugins_CanBusControlBoard_README.html)). Solely for use in offline trajectories (e.g. loaded from file) in which all targets are expected to be reached on a fixed period (i.e. synchronously). For efficiency, you should send all those points at once, as opposed to using a timer or a `for`-loop with delays.
+- Online local pull: also callback-based in the same vein, but it depends on passing a semaphore handle to `CanBusBroker`, therefore it is only suitable for applications that run on the robot board and instantiate `CanBusBroker` along with the full robot configuration. The handle you need to pass is an instance of [`StateObserver`](https://robots.uc3m.es/yarp-devices/classroboticslab_1_1StateObserver.html).
+- Offline synchronous: depends on [`yarp::dev::IRemoteVariables`](http://www.yarp.it/git-master/classyarp_1_1dev_1_1IRemoteVariables.html) to correctly configure `TechnosoftIpos` for compliance with the *ip* mode ([docs](https://robots.uc3m.es/yarp-devices/md_libraries_YarpPlugins_CanBusBroker_README.html)). Solely for use in offline trajectories (e.g. loaded from file) in which all targets are expected to be reached on a fixed period (i.e. synchronously). For efficiency, you should send all those points at once, as opposed to using a timer or a `for`-loop with delays.
 - Offline asynchronous: same as above, but points are sent gradually instead of in a single batch. It is allowed to have a varying period between points. Therefore, commands would be usually issued in a `for`-loop with a variable delay (i.e. asynchronously).