Control
Robot users want to have “control” over the devices they work with: the robot must act according to the commands it receives from the user. This somewhat vague “definition” of robot control is appropriate at the higher levels of the controller hierarchy. At the lowest levels, the meaning of control can be made much more explicit: the robot controller must make sure that the device follows the instantanteous motion (and/or force) setpoints generated by the interpolator, and measured by the sensors, and that it selects the appropriate (kinematics) models to link these sensor and interpolator data to the actuator signals.
This Chapter applies the general principles of systems and control to robotics devices, to control their motion (position, velocity, acceleration, …) and, when appropriate, their interaction (basically force, distance and vision) with the environment. Since more and more robotics systems consist of multiple devices and/or autonomous software components, multi-agent and component-based control becomes an increasingly important control topic. In addition, many controllers are also evolving towards “higher levels” of intelligence, which often results in the need to switch between control (or planning, or sensing) algorithms on line, i.e., the need for some form of hybrid event control.
The basic trade-offs in control are:
-
Stability vs. performance. A controller must be stable, in the sense that it should not input more energy into the robot system than “strictly needed” by the task. However, when the control developpers look at stability only, the resulting control will often lack performance, i.e., the speed and the quality with which the task is performed are lower than what would be physically possible.
Very often, performance can be increased when the control developpers make use of more detailed models of the robot and its interaction with the environment. But this inevitably introduces robustness worries: the resulting control can become incorrect and dangerous as soon as the detailed model used by the controller doesn't correspond anymore to the real physical interactions the robot is involved in.
-
Feedback vs. feedforward. The simplest controllers work with feedback only: they measure the current “state” of the robot system, compare it to the desired state, and steer their actuators based on a function of that “control error”. By definition, feedback control always comes “too late”: the controller only reacts after the control error has been realized.
This lateness can be avoided by using a model of the robot-environment interaction: if the model can predict what is going to happen, it gives the controller the opportunity (but not the guarantee!) “to look into the future” and hence to avoid control errors to occur. Of course, robustness can be compromised, as mentioned before.
These trade-offs in control are eminent in all robotics research, although most often only in a very implicit way. Most advances in robotics can be traced to the improvement of the quality of the robot-environment interaction models and estimators, such that the robot controller can better “interpret” its sensor signals, and, hence, can perform better. Ultimately, the lowest control loops are always some form of either PID control or reactive behaviour from a look-up table , i.e., the controller computes its actions from an “easy to calculate” or a “learned” input-output mapping. In addition, the feedback gains of the PID control are chosen in the context of a first-order or second-order state-space system, because only in those cases the influence of all control contributions are fully understood.