List of Abbreviations
- ROI – Return of investment
- DUT – Device under test
- URDF - Unified robot description format
- COLLADE - Collaborative design activity
- UI – User interface
- H/W – Hardware
Introduction
Device testing is one of the fundamental requirements to ensure product quality. Manual testing practices demand the operator to be attentive and execute the repetitive testing procedure. It makes the operator lose interest due to the monotonic nature of testing routines. A change in firmware and product upgradation also demands testing at the development stage. This degrades the testing quality and can severely affect the brand reputation of the company. Usage of these defective products in critical applications such as medicine, defense, and boiler, encounters a higher degree of risks and may result in catastrophic failures. Hence, it is vital to execute the testing procedure with the same level of precision all the time.
Robotic and computer vision systems can provide promising solutions to these problems associated with device testing. A robot arm connected with a finger-like end-effector can imitate the operator’s action to interact with the devices. The computer vision system can observe the visual outputs generated by the devices and evaluate the DUT functionalities. Being a précised machine, robots can operate and execute testing procedures at a consistent level of precision. However, the robot is electro-mechanical hardware whose efficiency can be evaluated only after deployment. Hence, the industries are reluctant to adapt to robot-based DUT testing. There must be a solution to estimate the ROI/ cost-benefit analysis even before the robot deployment.
Problem statement
Robot-based DUT testing automation has the following problems:
Longer onboarding time – The design of automated robot-based DUT testing is a series process where the software development starts after the robot installation. This increases the deployment process and other testing procedures. The robot and camera calibration required for coordinated transformation can only be performed after installations.
ROI estimation – Besides installation cost, the ROI depends on run-time parameters such as execution time, quality of testing, and movement space requirements. Assessment of the testing quality can be carried only after the deployment of such robotic solutions.
Choice of the robot – Any change of other robot deploymentincurs intense rework and installation cost. Analysis of the best suitable robot to operate the DUT and optimize the space requirement is highly demanding.
Transferability to other DUTs – Investigation on the use of the same robot for other DUT testing demands change of fixtures and mechanical elements. The minimal requirement to accommodate a variety of DUTs and to optimize the test setup is always better.
Testing visualization and robot collision – Visualization of the robot at work is always possible only after deployment. Robot self and environmental collision can be examined at this stage. A multi-robotic testing environment also demands collision studies before deployment. Any collision detected demands rework on the mechanical fixtures and environmental changes.
Solution
Robot simulators can provide promising solutions to the above-stated problems. It is a software package that captures the functionalities of a real-time robot and its interaction with environmental objects. The accurate robot dynamics can be simulated using the industry-provided robot configurations, and the use of physical engines simulates the object behavior based on its physical properties. Hence, a software architecture developed for robot simulators can be readily transferred to the real robot after deployment. For DUT testing services, automation scripts and robot control are the major software components, as shown in Figure 1. The automation scripts define the sequence of the testing procedure and its possible outcomes for validation. The robot control comprises robot inverse kinematic model and hardware interfaces to control joints of the robot arm.
Importing a robot arm into a simulated environment requires a detailed description of the robot configuration. This robot configuration describes the geometric layout of the robot arm, such as link lengths, number of joints, and the orientation of joints. It also describes the physical aspects such as weights and the type of material used to fabricate the robot, which helps in simulating the actual dynamics of the robot movement. The texture and color of the robot are also described in the form of meshes to bring the robot’s appearance closer to the real world. Standard robot configuration descriptions of file formats such as URDF, COLLADE, and xacro are widely used. A DUT is designed as an object in the simulated environment which reacts to the robot touch. A layout of the UI such as buttons, knops, and displays must be designed graphically in the simulated DUT. The functions and the change in displays in DUT are programmed in the simulator. Thus, the robot simulator facilitates choosing the appropriate robot arm for the DUT and examines the possibility of using the same robotic arm for several types of DUTs, as illustrated in Figure 2.
Benefits
Robot simulator can parallelize the software development and enable faster deployment
Robot simulator, being a software platform, provide the flexibility of changing the robot arm and DUT without any hardware requirements
Robot simulator also facilitates mechanical fixture design and accurate estimation of ROI. The real-time parameters, such as testing time, space requirement, and testing quality can also be estimated using the simulator.
Overheads
Thought simulation of robotics-based device testing can provide several benefits. But it requires some overheads as follows:
Creating virtual devices – DUT must be created in the simulated environment virtually. The structure of DUT can be designed graphically either by using the 3D scanner or the existing 3D models. The functions of the DUT can be captured using customized tools.
Simulation of non-standard robots – Non-standard/customized robots lack robot configuration files required to create virtual robots. However, several tools are available to create the robot configuration files from the 3D robot model.
Conclusion
The robot is electro-mechanical hardware, which can be controlled by a robot simulation software to achieve the desired motion/task. Deployment of such robotic hardware for DUT testing automation consumes a higher installation cost and demands accurate ROI estimation. Using a robot simulator can address the problem associated with the robotic solution development for automated DUT testing. A robot simulator tends to simulate the behavior of the robot, DUT, and other associated objects close to real-time. It allows the development of software architecture even without any robot hardware. A wide range of DUT versions often requires reworking on mechanical fixtures and automation scripts, which can be tested and validated on a robot simulator.
