Investigation of the Use of Commercial Robotic Arms for Real-Time Hybrid Substructuring 109 P-controller in the robot’s task-space is used to further drive the tracking error to zero (not visualized in fig. 7). So the motion command for the robot is: zad = z +∆ILC +Kp,Kuka (z −z′meas). As robot we use a KUKA® KR16 with a KR C4 robot controller. To move the robot based on an external motion command, the software KUKA.RobotSensorInterface® (RSI) [24] is used. RSI runs on the KUKA® KR C4 controller and handles communication with external devices. In this work, we use UDP/IP communication via Ethernet. To send the motion command zad from the MicroLabBox to the KR C4 controller, we implemented a UPD server in Simulink®based on [25] and utilizing the RTI Ethernet Blockset [26] provided by dSpace®. The UDP server is compiled with the rest of the software and executed on the MicroLabBox. The RSI, which acts as the UDP client in our structure, initiates the communication by sending the current measured position of the robot’s end effector z′meas. As soon as the UPD server on the MicroLabBox receives a data packet, it processes it, calculates the current motion command zad and responds by sending this command back to the UPD client on the KR C4. The RSI processes the received data packet, forwards it to the internal KUKA® controller as the desired end-effector position and waits until the next communication cycle starts before sending the next data packet. Before using it in the RTHS setup, we validated the UDP communication in a simple benchmark test similar to [27]. In this test, a 3D sine trajectory in the robot’s task-space is commanded to the robot from the MicroLabBox via the UDP communication and recorded for 90 seconds. During this time, no packet loss was detected and we estimated the total delay to be 32ms. This delay includes delays for receiving and preprocessing the motion command, trajectory tracking errors, and delays for measuring, postprocessing, and transmitting the actual motion of the robot5. The actual motion of the KR16 robot z′ is transferred to the Experimental Substructure, which consists of a compression spring and a 3D-printed half-sphere attached to the robot’s end effector. A table is used as a ground to which the half-sphere intermittently makes contact. A SCHUNK® FTS 330/30 [28] is placed between the compression spring and the robot end effector to measure the interface force. The amplified force signal is fed to one of the analog inputs of the MicroLabBox where, after analog-to-digital conversion (ADC) and adaptation by the NPC, it is used as input for the numerical timeintegration in the Numerical Substructure. As shown, in fig. 7, different cycle rates are used in the experimental setup. The major reason is that the smallest possible cycle time of the RSI is 4ms. Thus, the time between two data packets sent by the UPD client is 4ms and consequently a motion command can only be sent with this cycle time. Therefore, we run the ILC and the UDP server on the MicroLabBox with a cycle rate of 250Hz, while the rest of the software on the MicroLabBox, namely the sampling of the force measurement, the NPC, and the numerical time-integration of the Numerical Substructure, is run with a cycle rate of 1kHz. So every fourth time step of the time-integration is used to generate the motion command for the robots. This procedure is done to be able to use a small time step for the numerical time-integration in order to obtain a stable and high fidelity numerical simulation. Note that the NPC requires the current measured velocity of the robot’s end effector ˙z′meas, which is only available at the rate of the UDP communication. To overcome this, ˙z′meas is held constant for three time steps until the next measurement is available. It is also assumed that the robot’s internal motion control operates at a much faster cycle rate than the RSI, which is indicated byfKUKA in fig. 7. In the following, we compare the results of a first RTHS experiment using the setup from fig. 7 with the performance of the setup from our previous work using the Stewart platform as actuator, which is described in detail in [18, 21]. To be able to compare the results, we also used the SCHUNK® FTS 330/30 for the measurements with the Stewart platform presented here. However, for the Stewart platform measurements, we used the ILC integrated in the joint controllers as described in [18] and not the version adapted for the commercial robots. It should be noted that in the setup for the Stewart platform also the low-level control is implemented on the MicroLabBox and a desired motor current is commanded to the current controlled joint motors via the analog outputs of the MicroLabBox. Therefore, in this setup no serial communication with additional hardware was required keeping all delays except trajectory tracking errors to a minimum. Table 2 summarizes the important parameters for the experimental investigations. An RTHS experiment using the KUKA® KR16 robot as actuator was successfully performed with the presented setup. In fig. 8 the results are shown without the ILC (Trial 1) and after 25 ILC trials. They are compared with the reference solution and with the results of an experiment using the Stewart platform as actuator. Although the interface quantities could be roughly replicated using the KUKA setup, the deviation from the reference solution is significantly larger compared to the Stewart platform setup. This is especially true for the period t ∈ [1.2s, 2s], where not only a delayed trajectory but also additional unwanted oscillations are visible for the measured interface displacement z′meas in fig. 8a. Such unwanted oscillations are typically observed when the RTHS experiment tends to become unstable due to an interface synchronization error. Since the NPC was in operation, the instability and further growth of unwanted oscillations was prevented. Note that the RTHS experiment could not be performed in the presented KUKA setup without the use of NPC due to stability problems, i.e., rapidly growing unwanted oscillations during the contact phase. Apart from that, it can be observed in fig. 8b 5We assume that delays due to processing on the MicroLabBox are well below1ms and thus do not affect the results
RkJQdWJsaXNoZXIy MTMzNzEzMQ==