The control architecture is open and accessible at different levels. A crucial feature is the usage of inexpensive miniaturized hardware for the superior level of control (eg. Embedded PC or notebooks).
In the bottom level of control, i.e. in the joints’ control, functions for the positioning and necessary parameters for the movement are stored. If required they are called by the middle control level which handles all data from force-torque, vision and other sensors and coordinates the joints’ movements. The top level control enables parameterization of the robot movement, process link-up and communication interface for human-robot-interaction like speech or teach-input.
The highest data throughput is achieved by using the CAN-BUS. Roughly, the following cycle times (CT) can be achieved by a CAN-Bus and a n-DOF configuration:
GIT = n×tA n: Number of Axes, tA: Response time per Axis
The response time tA implies the sending of a new position value (target position, target speed) and the response with the actual values (actual position/speed and status).
By using the CAN-BUS’ Multimaster abilities further optimization of the data exchange can be achieved. The following figure shows further reduction of the CT:
In this setup the superior control sends a broadcast with a synchronization signal (SYNC) to all bus subscribers simultaneously. The subscribers reply with their current values and status information (STAn). After reception of the current values the control sends the new target values (TARN), which get activated by the next SYNC message.
This control variant has another advantage. By using the SYNC-Broadcast the position controllers of all attached drives are synchronized. This avoids drifting of the local clock from the central target frequency and simultaneously improves the control performance of the overall system. The result is a higher precision of the trajectory control and minimal path deviation.
The integration of several subsystems in to one central control is an essential development task, when building service robots. From this point of view the manipulator is a subsystem, which needs to be combined with other subsystems. In most cases Mini PCs or Notebooks with standard OSes like Windows or Linux are used. They offer the possibility of timer based actuation although they have no hard real-time per se. Cycle times of below 10 ms with a deviation of 2ms are achievable.
With the help of SCHUK modular robotics it is possible to setup a robot control on PC basis without real time functionality. The synchronous SYNC-Broadcast is then triggered by a joint module. In this case the superior control is enabled to receive the SYNC signal and falls in line with the external clock generator. Obviously the control needs to be able to do the necessary calculation for the new target values within a certain time frame and to send the results out on to the BUS. To enable the control to synchronize with the external trigger a polling for the SYN signal (endless loop) or a Callback function can be implemented.
Control
Safety Issues
Generally when using robot systems hazards are unavoidable. The hazards are largely dependent on the automation process. Since countless applications can be implemented with “Modular Robotics” no specific safety and hazard guidelines can be given.
Generally, at the time of printing, ISO 10218-1 applies while prISO 10218-2 detailing installations
with cooperating robots will be published shortly.
Currently two main concepts are valid according to ISO 10218-1 which require further hardware or software:
If using separate workspaces:
Addition of separating safety devices
a. Mechanical (eg. fences)
b. Electrical (eg. laser scanners, safety light beams)
If sharing a workspace:
a. Securing a maximum speed of 250mm/s
b. Ensure either a maximum dynamic power of 80 W or a maximum static force of 150 N at the flange or TCP
More details can be found in the ISO 10218-1