Week 15 Wildcard Week wuuu

Engraving operation with router and Kuka

In the field of robotics, the virtualization of work cells has become an essential component for planning and optimizing industrial processes. In this context, programs like RoboDK allow us to perform this task accurately and as faithfully as possible to the real process. RoboDK is a powerful tool for robot simulation and programming that provides the capability to model and simulate complete robotic systems, in this case using a robot from the Kuka family, model KR 16-2. This software enables the creation of virtual environments where we can design and test operations without the need to interact directly with the real hardware. Its functionality is based on advanced robotic kinematics and dynamics algorithms, allowing for an accurate representation of the movements and capabilities of our robots.

The relevance of RoboDK lies in its ability to reduce costs and time in the development of robotic systems. By allowing us to simulate and validate processes before their implementation in the real world, it minimizes the risks associated with programming errors or misunderstandings in the interaction between the robot and its work environment. A critical aspect of work cell virtualization is the correct definition of the robot's operating space and the precise configuration of the Tool Center Point (TCP). This is essential to ensure that the robot performs tasks effectively and safely. Errors at this stage can result in collisions or inefficient movements, which could have significant consequences for the system's operability

Once the work environment is virtualized, the next crucial step is trajectory planning. This involves generating precise movement sequences that enable the robot to perform complex tasks efficiently. RoboDK provides advanced tools for this phase, allowing for route optimization and ensuring that the robot carries out its tasks smoothly and accurately.

1. Virtualization of the Work Cell

As the first part of the practice, relevant measurements of the work cell to be virtualized were taken, including distances, heights, thicknesses, and the locations of objects in the space. Once these measurements were obtained as accurately as possible, they were modeled in the SolidWorks program to be imported into RoboDK.

The Kuka KR 16-2 robot is mounted on base plates with a thickness of 3.3 cm, as shown in the figure.

To mount the tool, the robot is equipped with an aluminum coupling, as shown in the figure.

Finally, the work table was designed with dimensions of 60 x 68.5 cm and a height of 45 cm. On this table, the complex trajectory was plotted, which was also positioned at a fixed distance of 50 cm from the robot, as shown in the figure.

2. Definition of Tool and Work Frame in Software from Real Data

Once the elements were designed, they were imported into RoboDK. The tool was defined as the marker, as used in previous practices, utilizing data provided by the team members responsible for calibrating the TCP earlier. The following data was defined:

Figure 2: TCP coordinates of the marker, extracted from real data provided by team members.

As shown in the object tree in Figure 2.1, the green icon over Plumón_Solo indicates that this is our TCP with the coordinates from Figure 2.

Figure 2.1: Assembled and positioned components in RoboDK.

Next, the work table and base plate were placed in their positions and distances as they are in the physical work cell, as shown in Figure 2.2.

Figure 2.2: Base plate and table positioned relative to the work cell.

Once the elements were correctly imported and positioned, the reference frame of the work table was placed at one of the corners, as shown in Figure 2.3.

Figure 2.3: Frame on the work table.

3. Assigning a Design with Complex Trajectories

The trajectory to be executed was a logo exported in DXF format. It was then imported and positioned at the center of the work table.

Figure 3: Assignment of the design with complex trajectories.

HOME trajectory

After importing all the elements, the program configuration process began. The first step was to generate the program and define the tool and reference plane, in this case, the work table, as shown in Figure 4.

Figure 4: Tool and reference frame assignment in the HOME program.

With this, the HOME position was defined using a MoveJ, as shown in Figure 4.1.

Figure 4.1: HOME trajectory.

The next trajectory was an approach movement to the work area, also a MoveJ, as shown in Figure 4.2.

Figure 4.2: Approach trajectory.

The next step was to configure the trajectory of the imported logo. The robot, reference, tool, and figure (logo) were selected. Speeds were configured, and in the "More Options" button, a menu appeared allowing curve selection. All the logo curves were selected.

Figure 4.3: Path configuration.

Figure 4.4: Curve selection.

Figure 4.5: Simulation in progress.

Finally, a subprogram was generated to execute both programs in a complete sequence, as shown in Figure 4.6.

Figure 4.6: Complete routine.

To export the program for the physical robot, the Post-Processor was selected, enerating the following programs ready to be tested on the robot, as shown in Figure 4.7.

Figure 4.7: Post-Processor and exported programs in .src format.

5. Simulation, Adjustment, and Application on Physical Robot

After generating the programs, access was granted to the work cell to replace the marker, as the previous one was bent. The new marker was installed, and the HOME program was executed.

Figure 5: HOME program executed in the work cell.

Once the HOME program was correctly executed, the trajectory program was loaded to verify if the Z coordinate was correctly defined, as shown in Figure 5.1.

Figure 5.1: Correction of the Z axis in the work cell.

The marker was 3 cm above the surface, so the Z origin coordinate was adjusted to allow drawing on the work surface, as shown in Figure 5.2. With this, the marker was nearly on the surface.

Figure 5.2: Correction of the Z coordinate for trajectory tracing.

With these corrected parameters, the program could be executed on the work area. As shown in Figure 5.3, the work table was quite uneven, preventing proper drawing on the surface. However, the simulation result was achieved, requiring only an adjustment of the work table.

Figure 5.3: Trajectory execution showing uneven work surface.

Final results

And here is a video of the router with the kuka 🙂


What i learned?

The work cell was successfully virtualized by accurately measuring distances and thicknesses, which were then correctly implemented in RoboDK. This software enables interaction with realistic scenarios without the need for the physical robot. The Home and approach positions toward the work table were accurately calculated, along with defining the reference frame on the table. A complex trajectory was created using a DXF file.

During adjustments on the physical robot, the Z coordinate required modification, as it was not aligned with the work table. A 3 cm displacement was corrected, allowing the full execution of the HOME program and trajectory. Despite the irregular surface of the work table, the final result was achieved.

This marked a successful first step in using RoboDK and understanding the complete process of generating simulations, along with recognizing the advantages and limitations of such software.