Degree Thesis
HALMSTAD
UNIVERSITY
Mechatronics Engineering, 180 credits
Digital twin of crane robot
Degree Project in Mechatronics, 15 credits
Halmstad 2021-06-06
Andreas Stadin, Oskar de la Vaux
I
Acknowledgements
We would like to thank our supervisor and client Björn Åstrand for all the great knowledge, support, and ideas throughout the project.
A special thanks to Tommy Salmonsson with his expertise with the hardware and software for the project.
We would also like to thank Oliver Olsson and Erik Svensson for
participating in our test and making sure our tutorial worked as intended.
II
Abstract
The creation of digital twins has been on a rise in the last years, and digital twins are becoming an essential part in today's industries. To be able to keep up, the engineering students at Högskolan i Halmstad need to follow and explore the current development. The goal with this project is to introduce digital twins to the students and give them a wider knowledge about the future of
manufacturing.
In this project a digital twin was developed from a physical crane. The digital twin was made from a CAD model and was imported into a simulator to replicate the physical robot and its parts. The digital twin had virtual sensors installed and may be considered a cyber-physical system.
Sammanfattning
På senare år har skapandet och användandet av digitala tvillingar ökat drastiskt och de håller på att implementeras i dagens industrier. För att ingenjör
studenterna på Högskolan i Halmstad skall hänga med i utvecklingen av dagens tekniska samhälle, behöver de vara med och utforska de tekniska nyheter som finns. Målet med detta projekt är att introducera digitala tvillingar till ingenjör studenterna, för att ge dem en bredare grundkunskap inom framtidens
industrier.
I detta projekt har en digital tvilling utvecklats utifrån att efterlikna en fysisk kran. Utvecklingen av den digitala tvillingen har designats som en CAD-modell och importerats in i en simulator för att efterlikna den fysiska kranen och dess delar. På den digitala tvillingen har även virtuella sensorer installerats och systemet kan anses vara ett cyber-physical system.
III
Table of contents
Acknowledgements ... I Abstract ... II Sammanfattning ... II Acronyms ... VI
1. Introduction ... 1
1.1 Purpose ... 2
1.2 Requirements ... 2
1.3 Goals ... 2
1.4 Delimitations ... 3
2. Background ... 5
2.1 Simulators ... 5
2.2 Communication framework ... 6
2.3 CAD-programs ... 7
2.4 Tree-structure and robot modeling ... 7
2.5 Programs used to control the physical crane ... 10
2.6 Controlling the physical crane ... 11
2.6.1 Velocity profile... 11
2.6.2 Position profile ... 12
2.7 Related work ... 12
3. Method ... 15
3.1 Scrum ... 15
3.2 Product design process ... 15
3.3 Design of digital twin ... 16
3.3.1 Simulator ... 16
3.3.2 Programming ... 17
3.3.3 Simulink ... 18
3.4 Level of integrations in a digital twin ... 18
3.4.1 Digital model ... 19
3.4.2 Digital shadow ... 19
3.4.3 Digital twin... 19
3.5 Result analysis ... 19
IV
3.5.1 Importing a 3D-model ... 19
3.5.2 Easy adjustable parameters of the digital twin ... 20
3.5.3 Easy to setup ... 20
3.5.4 Visual analysis of the lag ... 20
3.5.5 Accuracy of the digital twin ... 20
3.5.6 Students importing their unique 3D-model ... 20
4. Implementation of the digital twin ... 21
4.1 Conversion from physical robot to digital twin ... 21
4.1.1 Load elevation (z-axis) ... 21
4.1.2 Crane rotation around z-axis ... 22
4.1.3 Crane slider along x-axis ... 22
4.2 Virtual sensor and obstacle ... 23
4.3 Programming ... 24
4.4 Tree-structured robot ... 25
5. Results ... 27
5.1 Final system overview ... 27
5.2 Simple design ... 27
5.3 Advanced design ... 28
5.4 Analysis of digital twin performance ... 29
5.5 Virtual sensor and obstacle ... 31
5.6 Delay between the digital twin and the physical crane ... 33
5.7 Test students setting up the digital twin ... 34
5.8 Student task ... 34
6. Discussion ... 35
6.1 Sustainable development ... 37
7. Conclusion ... 39
7.1 Further improvements ... 40
8. References ... 43
Appendix ... 47
Appendix A: Conversion from physical crane to digital twin ... 47
Appendix B: Matlab code ... 49
Appendix C: Scrum sprints ... 51
V
Appendix D: Video analysis ... 53
Appendix E: Measured position data ... 55
Appendix F: Measured delay data ... 57
Appendix G: Tutorial ... 59
VI
Acronyms
API Application Programming Interface CAD Computer-Aided Design
CPS Cyber-Physical System DT Digital twin
FEA Finite Element Analysis GPU Graphics Processing Unit IoT Internet of Things
LCM Lightweight Communications and Marshalling ROS Robot Operating System
UDP User Datagram Protocol
URDF Unified Robot Description Format
V-REP Virtual Robot Experimentation Platform XML Extensible Markup Language
1
1. Introduction
Throughout history, humans have always strived for better tools and standards of living. Starting with the first industrial revolution [1] in the 1700s, a new method was learned, how to use steam to power machines making
manufacturing much easier. The second industrial revolution began in the late 1800s with the discovery of electricity and the innovation of the assembly line further improving manufacturing efficiency. The third industrial revolution began in the 1970s with partial automation and programmable computers.
In today's society, technical development is reaching heights never seen before.
With this rapid improvement in technology the industry is adapting to the changes and moving forward. This has had big implications on development processes and the industry has entered the phase known as industry 4.0 [2].
Industry 4.0 is a combination of automatization, digitalization, and robotization.
With this development the need for digital twins has surfaced. Increasingly physical devices are being connected to the Internet and data is becoming a very important asset of human society. The connected devices collect data and
transmit it through IoT. With all the data that is required to process, a new era has come, this is being called Big Data [3] and includes a large amount of
structured, semi-structured and unstructured data.
A digital twin is a virtual prototype of a real product, process, service, or system [2]. Digital twins are being used more lately because they create the opportunity to improve the efficiency of the system, lower energy consumption, increase reliability and decrease production times. It improves the overall company's profits [2].
In the course Design of a Mechatronics System, 15 hp [4] at Halmstad University, the project was to create a physical crane that could move an object between different positions (see Figure 1).
Figure 1. The left picture shows the real crane robot and the picture to the right shows the one from the simulator that will be controlled at the same time.
2 By making a digital twin of the crane, the students would be given the
opportunities to explore the simulation and compare reality to the virtual model.
Making the crane run in real-time would give the students a better overview of the different parts that need to be produced. For example, the students will easily see if their gear ratios are good enough, they will also see which positions their crane can reach with their current setup. This tool will make it easier to optimize the crane’s speed, precision, and accuracy.
1.1 Purpose
The purpose of this project is to allow the students to explore a digital twin that works in real-time together with their crane. With an easy setup of the virtual model, it would give the students a better understanding of their crane and they will easily see how they can improve their crane's capability to operate. The students will save a lot of time by testing a new setup in their virtual model without having to produce, install and test the 3D printed parts. Importing an assembly of their crane from a 3D-modeling software and transferring it directly into the simulator would give each student a unique setup to work with.
Another project [5] that was done using a real robot and creating a digital twin was used as a comparison for this project.
1.2 Requirements
● Create a 3D-model of a crane that can be used by the students.
● Import a custom 3D-model from a CAD-tool (using .stl format) into the simulator. The model must be controlled using Matlab.
● Define and control the motions of the 3D-model in the simulator.
● Creation of an easy-to-use guide/tutorial.
● Easily adjustable parameters of the imported 3D-model (motion parameters and length/angle of the crane arm).
● Must be able to be run on standard computers (without external GPU).
● The entire project must be simple to use (students should be able to set it up within 2 hours).
● The destination of the simulated load must be within ± 3% of the expected position.
1.3 Goals
The goal is to have a digital twin that can run in real-time with a maximum lag of 0.5 seconds to the physical crane robot. It should be easy to maintain the digital twin and a task involving the twin should be created for the students.
Another goal is to incorporate virtual sensors into the digital twin, this would
3 allow for the crane to avoid virtual objects in the simulator. Without the virtual sensors, this project would only be seen as a digital shadow [39]. Students should be able to incorporate their crane design into the simulator and be able to adjust the simulation parameters to suit their crane.
1.4 Delimitations
The 3D-model that is created for this project, will not have a crane arm. This is due to every student's unique crane arm having different angles and lengths.
The design of the housing has been provided from the course “Design of Mechatronics system” [4]. All the other required parts will be created in this project.
4
5
2. Background
This is the model that was used during the project (see figure 2). Matlab, Simulink, and the physical crane are prerequisites for control of the robot and will therefore be used to communicate with the simulation as well.
Figure 2: An overview of the desired system.
In this part the programs that were considered when choosing the approach to solve the problem is looked upon. There are two ways of approaching the virtual robot to move, by using an external framework or by using libraries of each of the simulators. Using the API of the simulators keeps the entire project easier to maintain because it is less complex, which is the goal. Different simulators are good at different things, the simulator must be able to import a 3D-model from an .stl file and have a lot of documentation on how it works. The simulator must also work well with Matlab and Simulink that are being used in the course [4] as communication to the physical crane.
2.1 Simulators
In this part, the different simulators that were considered when deciding what program should be used for the digital twin.
CoppeliaSim [6] is formerly known as V-REP. This is a software used for 3D robot simulation. CoppeliaSim allows the user to design, program, and simulate everything from a single sensor to an entire environment with sensors and robots. To analyse the simulation, CoppeliaSim supports four physics engines (ODE, Bullet, Vortex Studio, and Newton Dynamics), which allows the user to quickly build a prototype and check the system for possible errors.
Gazebo [7] is a robot simulation toolbox. Gazebo makes it possible to design and test robots in the simulator, this allows for rapid development of new robots.
Gazebo uses the ODE physics engine and OpenGL rendering which makes it a powerful tool when creating virtual robots. Gazebo can be used together with ROS (see chapter 2.2) making it possible to connect the virtual robots to real
6 ones, this also allows for real robots and their digital twin to run at the same time.
RoboDK [8] is a software that allows the user to create a virtual environment to simulate virtual models. RoboDK uses offline programming which allows the user to program the robot outside of the production environment. The software allows the user to import industrial robots from a library with well-known manufacturers such as ABB, Fanuc, KUKA, Motoman, Hwashi Robots, and Universal Robots. There is an Add-in that allows the user to import 3D-models from Solidworks [9]. The simulation in RoboDK can also be controlled by
Simulink [10].
Simscape Multibody [11] is a toolbox within Matlab that allows the user to create a virtual environment to simulate mechanical systems such as a robot.
The multibody system becomes blocks that represent bodies, joints, constraints, force elements, and sensors. The blocks can be used in Simulink. Simscape Multibody can use the simulation of SimWise 4D to simulate the robots.
In conclusion, looking at the different options, all the simulators except Gazebo have an interface to work with Matlab without using ROS (see chapter 2.2). ROS would make this project more complex. A disadvantage with RoboDK is that it is the only simulator that requires a paid licence for students. Simscape Multibody has the advantage that it does not require any external software other than Matlab to be run but lacks documentation on how to actually use it.
CoppeliaSim has a built-in API that works well with Matlab, which allows the velocity profiles or the position profiles (see chapter 2.5) to be run in the
simulator. CoppeliaSim does not require to be run together with ROS and has good documentation (code examples, Matlab API, videos and forums) which make it user-friendly. CoppeliaSim works well on standard computers that are either using Linux or Windows.
2.2 Communication framework
This part goes through two different communication frameworks that can be used for robots and their digital twins. These frameworks were selected because of their good documentation, and they are well established and commonly used by companies, professionals and enthusiasts [12] [13].
LCM [14] is a collection of libraries and tools that uses message passing and data marshalling. LCM focuses on real-time robotics where low-latency is mandatory. To get low-latency, LCM uses UDP multicast [15] which is fast but an unreliable transport. The messages-passing uses a publish/subscribe system
7 that allows the correct component to decode and display the correct message, which has no impact on the overall system performance.
ROS [16] is a communication framework that has a wide collection of tools and libraries to simplify the creation of robots. ROS uses nodes to communicate with robots and digital twins, making it possible to run them both in real-time. ROS is Linux compatible but is missing some features on Windows.
2.3 CAD-programs
To simulate a model of the physical crane, a 3D-model needs to be created and fully assembled. The 3D-model needs to be exported using the file format STL.
The saved files will then be imported into the simulator. These are the CAD- programs that were considered. These programs were considered because of their ease of use, and Solidworks were already available for use so there were no extra costs.
Solidworks [17] is a software that allows the user to design CAD models [18].
By combining many CAD models into one assembly makes it possible to visualize the entire project. Solidworks contains toolbox-libraries with standardized
mechanical components. Solidworks allows the user to test a product before it is produced by using features like Finite Element Analysis (FEA), motion analysis, and many more.
SimWise 4D [19] is a software that allows the user to design CAD models.
Creating assemblies using many CAD models is possible and with this software, it is possible to simulate all the mechanical parts. SimWise 4D is a combination of a simulation in motion (kinematics and dynamics) and FEA. SimWise 4D offers the ability to check the performance of a prototype before producing the product.
2.4 Tree-structure and robot modeling
A known robot modelling format, URDF, can create kinematic models of robots.
This format is very popular with the users of ROS, this is because ROS offers standard support for URDF models [20]. The format implementation reminds of an XML like structure that uses XML elements. An example of XML elements can be seen in Figure 3, these elements are <robot>, <link> and <joint>. Within XML, terms such as parent and child are being used. The parent in this tree is
<robot>, and the children of this group are <link> and <joint>. Elements can have attributes and, in this example, (see Figure 3), the parent and the children
8 need to have a name attribute as strings, these names would be used to identify each part of the entire system.
Figure 3. The parent in this example is <robot> and the childrens are <link> and <joint>.
A joint is the connection between two links on a robot. The joints can be used to control the robot's movements. A link is an object that can be moved using the joint to create a movement (see Figure 4).
Figure 4. A visualization of the XML tree shown as a robot.
The children, <link> and <joint>, can have their own children (see Figure 5).
Figure 5. The parent in this example is <robot> and the children are <link> and <joint>. Both
<link> and <joint> are parents themselves to some children, these children are <inertial>,
<visual>, <collision>, <origin>, <parent> and <child>.
9 The element <link> could have children such as the elements <inertial>,
<visual> and <collision> which can be seen in Figure 6 [21].
➢ Inertial contains all the information about the link’s inertial properties for example origin, mass, and inertia.
➢ Visual contains all the properties of the visualization, for example the shape of the object. It contains information about the origin, geometry, and material of the object.
➢ Collision contains all the information about the object’s collision properties, this could be different from the visual properties and are therefore mostly used for reducing the computing time of the simulator.
Figure 6. An example of all the link properties used to build the XML tree for the robot.
The element <joint> could have children such as the elements <origin>,
<parent>, <child>, <axis>, <calibration>, <dynamics>, <limit>, <mimic> and
<safety_controller> which can be seen in Figure 7 [22].
➢ Origin is the bond from the parent link to the child link. The joint’s origin will be located at the origin of the child.
➢ Parent contains the name of the parent link and must use the datatype, string, and this attribute is mandatory for the structure.
➢ Child contains the name of the child link and must use the datatype, string, and this attribute is also mandatory for the structure.
➢ Axis contains information about how the joint should be used. For
example, a joint is either of the type revolute, prismatic or spherical. The revolute joint is used for rotation and the prismatic joint is used for linear sliding movement. The spherical joint is used for rotational movements with 3 degrees of freedom.
➢ Calibration is used as a reference point for the joint.
➢ Dynamics contain all the physical properties of the joint.
10
➢ Limit is only used for two of the joint types, prismatic and revolute, and contains the lower and upper limit that the link should be able to move.
For the prismatic type, the limit is in meters and for the revolute type is in radians. Limit also contains the maximum joint velocity that can be used.
➢ Mimic can be used whenever there is more than one joint. This element will allow the one joint to mimic another one, in addition, an offset and a multiplier can be added to the mimic.
➢ Safety_controller is being used to secure the model. It contains properties about soft lower limit, soft upper limit, k_position and
k_velocity. The soft lower and upper limit is an attribute that specifies the joint boundaries. The k_position is an attribute that is being used for specifying the relation between position and velocity limits. The k_velocity is an attribute that is being used for specifying the relation between effort and velocity limits.
Figure 7. An example of all the joint properties used to build the XML tree for the robot.
When all the parts from the robot have been added to the URDF file, it can be imported to the simulator and will be represented exactly how all the properties are set. There is an add-in within Solidworks (SW2URDF) that allows the user to convert the 3D-model into a URDF by defining joints and links within
Solidworks [23]. This add-in will be creating the URDF file that represents the entire robot, with all the set properties.
2.5 Programs used to control the physical crane
This part goes through what programs are used to control the physical crane, these programs are prerequisites for controlling the physical crane and are therefore required to complete the project.
Matlab [24] is a programming platform that is based on matrix programming.
Matlab is mainly used for analysing data, developing algorithms, and creating models and applications.
Simulink [25] is a toolbox within Matlab that uses model-based programming.
Simulink provides a graphical user interface for the user to design and simulate the system with blocks and makes it easy to analyse and visualize the data in Matlab. Libraries with commonly used blocks are included and they are customizable.
11
2.6 Controlling the physical crane
The physical crane can be controlled using different profiles. The physical crane uses 3 motors and each of the motors needs a profile to be able to perform its movement. The profiles are calculated in Matlab for each of the motors. By using the calculated profiles in the Simulink model, the physical crane will rotate and move accordingly.
Using the same profiles on both the physical crane and the digital twin will give the same movement. The profiles that will be used to control the digital twin will be created by the users themselves.
2.6.1 Velocity profile
The purpose of using velocity profiles to control the physical crane is to have constant acceleration until the system reaches the maximum speed. When the system reaches maximum speed, the speed remains constant until the system reaches the point where it is time to start the retardation. The retardation
remains constant until the velocity reaches zero. The aim is to have a soft motion on the physical crane that prevents the load from swinging at a high speed. The soft motion could increase the lifespan of the physical product due to the less wear of the material from the 3D printed parts. The shape of this velocity profile is named “trapezoid” (see Figure 8) [26].
Figure 8. An example of a trapezoidal velocity profile on the slider.
The first profile that was introduced in the course [4] was the velocity profile. A velocity profile is the integration of an acceleration profile. Using velocity profiles (see Figure 8) gave the opportunity to start controlling the physical crane. A Simulink model was given from the course that works with velocity profiles, this
12 model will send the desirable speed for each of the motors at a given time and updates every sample time (0.02s).
For the digital twin, a function was created, and the velocity is first integrated into positions (see Appendix B) because CoppeliaSim gets less errors using positions rather than velocities.
2.6.2 Position profile
The second profile that was introduced in the course [4] was the position profile.
A position profile is the integration of a velocity profile. Using position profiles (see Figure 9) will result in the physical crane to get higher precision and
accuracy. The shape of this position profile is named “sigmoid” (see Figure 9). To use position profiles on the physical crane, the Simulink model needs to be changed. This change includes a P-regulator with feedback. The velocity also needs to be integrated into positions.
For the digital twin, a function was created (see Appendix B) and by using position profiles the data will be sent to CoppeliaSim from Matlab.
Figure 9. An example of a position profile on the slider.
2.7 Related work
A related project [5] was done using a real robot and creating a digital twin. The related project is relevant to this project due to the remote API usage, path- planning, obstacle, and collision detection. Both projects have the same major challenges and the same approach of using the remote API. Both projects share the same goals, but the related project’s results are not measured. Both projects also managed to set up a digital twin using the same simulator.
13 Another related project [27], made a digital twin from an overhead crane [28].
This crane was installed and accepted for use in 2016, in Aalto University in Finland. The crane contains several smart features such as sway control, snag prevention, adaptive speed range, target positioning, assisted load turning, hook centring and many more [29]. The related project is relevant to this project, because the crane is targeted for university education purposes. The students are working on a crane that uses a lot of up-to-date hardware and software to be more prepared for their future in the industry. The university is building course assignments around the crane and the students are usually working in groups in these assignments. In the related project, the digital twin utilizes and enhances the universal connectivity of the crane and other devices. It also maintains a small database of the crane’s position and relay information to the Mixed Reality that controls the overhead crane, using Microsoft HoloLens. The digital twin sends control signals from the Mixed Reality device to the crane. The students are also learning about Industry 4.0, CPS and IoT. This related project also brings up another interesting thing about CPS. The CPS can be described as different physical devices, objects and equipment that can interact with a virtual model through a communication network [30]. Currently, the physical part can be defined easily but the cyber part is not as easily defined. As a conclusion in their project, the actual digital twin is being explained as the cyber part [29].
A review [31] of 240 studies containing digital twins analysed what a digital twin is and what level of integration there needs to be between a physical and digital system to be considered a digital twin. Part of the study compares the differences between a digital shadow and a digital twin, and concludes that a system needs a bi-directional interaction between both the physical system and the digital
system to be considered a digital twin.
14
15
3. Method
This project has been combining multiple methods to move forward. One method is Scrum (see chapter 3.1). Scrum is used to plan each task into a specific time frame. Another method is a product design process (see chapter 3.2) making it possible to test all the base functions to see if it is possible to make everything work. The main method used in this project is the product design process and has been combined with the tasks from the sprints in Scrum. The group members have been meeting up with the supervisor every week to go through what has been done and what is going to be done during the week.
3.1 Scrum
Scrum [32] is a method used by a lot of companies in the professional circuit [33].
A backlog is created and divided into different sprints (see Appendix C). The backlog is a list of prioritized tasks that need to be completed. Each backlog item is completed with a sprint, a sprint is a period of time in which a certain task is focused on. After a sprint, the team demonstrates what has been achieved during the sprint. Each sprint will not be finished therefore it is important to show the scrum master what has been done during that time. A backlog of items that need to be completed has been created. These items have been planned for in the time plan. The time plan is divided into different sprints and after each sprint, a short sprint review is held to demonstrate the progress that has been made in the sprint.
3.2 Product design process
The chosen method to design the digital twin uses three steps to make it easier and more efficient. The same method [34] has been proposed since early 2017.
Conceptual design is the first and the most important step of the entire
process. In this step the main functions are created and tested to make sure that the idea would work. In this project this will be the communications between the simulator and Matlab and sending commands to the simulator from the main function. The main function is a Matlab script that sends movement data to a basic model in the simulator that has been imported from Solidworks.
Detailed design is the next step, this step is to complete the design of the prototype, with all the parts that should be included. In this project the main function works with all the moving parts and requires a lot of testing to ensure that it is working as intended. Testing contains the three different motors in the
16 simulator and that they are fully converted correctly from the physical crane to the digital twin (see chapter 4.1).
Virtual verification is the last step, this step is to verify that the design performs as intended. To improve the design from any possible issues,
redesigning and implementing will be fast and convenient. This step is to make sure that everything moves as intended and that the visualization in the
simulator moves as the physical robot. In this project the verification is to control that the load of the physical crane is within the limits compared to the load of the digital twin (see chapter 1.2 Requirements). Testing this will consist of only using the slider (x-axis), only using rotation (y-axis) and a combination of both slider and rotation (x and y-axis). Testing the z-axis will be to visually control that the velocity profile or position profile is working as intended.
3.3 Design of digital twin
In the design of the digital twin, all parts have the work together. The simulator needs to be able to communicate with Matlab where all the programming is done. Matlab is being used to control the physical crane using Simulink.
3.3.1 Simulator
There are many different simulators that can simulate a moving robot. In this project, four simulators were analysed and compared to each other (see chapter 2.1). These four simulators were CoppeliaSim, Gazebo, RoboDK and Simscape Multibody. The comparison was about the amount of documentation, user- friendly, install process, free to use or required a paid licence, and if they were able to run on standard computers. In this table (see Table 1), points are given from 1 to 10, where a high number means better or easier. The simulator with the highest number of points is the simulator chosen for this project.
Table 1: Shows a comparison of vital features of the different simulators.
Points given from 1-10.
The more points, the better.
Ease of use/
Ease of installation
Documentation / free of charge (in educational purpose)
Platform availability (Windows/
Linux)
Total points
CoppeliaSim 8 10 10 28
Gazebo 2 10 6 18
RoboDK 10 1 10 21
Simscape
Multibody 6 6 10 22
17 For the first column (ease of use/ease of installation) is taking into consideration the installation process (max 5 points) and how easy it is to use (max 5 points).
The total is then written in the row for each of the simulators.
Gazebo would make the project more complex due to the usage of ROS. The installation process is also long and very complicated. Both RoboDK and
Simscape Multibody have a very easy installation process but are more complex to use, whereas CoppeliaSim is easy-to-use but has a longer installation process when it comes to using the remote API to Matlab.
For the second column (documentation/free of charge), both CoppeliaSim and Gazebo are free to use, and both have very good documentation. RoboDK
requires a paid licence and lacks documentation on how to use it with the remote API. Simscape Multibody is free to use due to Halmstad University already having paid licenses to Matlab but lacks good documentation on how to set up a digital twin.
For the third column (platform availability), CoppeliaSim, RoboDK and
Simscape Multibody can run easily on both Windows and Linux. Gazebo is the only simulator that lacks some functionality on Windows but runs well on Linux.
A comparison [35] of different simulators shows that V-REP (CoppeliaSim is formerly known as V-REP) has more features, good API documentation, and many code examples. A disadvantage with V-REP is that it requires more resources from the computer compared to Gazebo, but both can be run on the standard computers (see chapter 1.2 Requirements). A library of tutorials on how to connect CoppeliaSim with Matlab and create virtual obstacles and sensors [36] which will be done in this project.
The simulator that was used in this project was CoppeliaSim due to it being a free to use program with a lot of documentation. The installation process is also very simple and has a built-in API [37] for communication with Matlab.
CoppeliaSim can also be run on standard computers and was able to easily import the general 3D-model from Solidworks.
3.3.2 Programming
All the programming is done using Matlab scripts due to Matlab being used to control the physical crane robot. The main function that communicates with CoppeliaSim can be run in three ways. These three ways can be chosen by the user to run the digital twin.
18 1. Reads position data from the physical crane and sends the position data
every 0.1 second to each of the movable parts (slider, rotation, and spool) to the simulator.
2. Calculate three velocity profiles (for slider, rotation, and spool) in Matlab (see chapter 2.6.1), integrate the profiles to get the position data and then send it directly to the simulator and update each value every 0.02s.
3. Calculate three position profiles (for slider, rotation, and spool) in Matlab (see chapter 2.6.2) and send it directly to the simulator and update each value every 0.02s.
The advantage of using Matlab scripts is that it uses Simulink to control the physical crane and the communication to CoppeliaSim is running in real-time.
3.3.3 Simulink
When both the digital twin and physical crane are used at the same time, Simulink is used to control the physical crane. The Simulink model is uploaded to the Raspberry Pi on the physical crane. By using the calculated velocity or position profiles in the Simulink model, the physical crane will move accordingly.
The motors on the physical crane use encoders, the motors are connected to a motor shield on an Arduino Due. The motor shield contains these encoder values.
These encoder values are being read by a scope within Simulink in real-time using Matlab. These values can be sent to CoppeliaSim, using the Matlab API to move the digital twin. This can be regarded as a CPS [38]. A CPS is the
integration between a physical and a computation process. The CPS contains many sensors that are working together to achieve an intelligence device, with all the sensor data that are being processed this enters the new era, Big Data [3].
The goal of using CPS is to have a physical system that is intelligent, resilient and self-adapting to be able to transform today’s industry into Industry 4.0 [38].
There are many different uses of CPS, but one example of how this project could become a full CPS would be if it contains sensor data to create an autonomous collision avoidance system on the crane. In this project, it cannot be seen as a full CPS, due to the lack of external sensors and algorithms using the sensor data.
3.4 Level of integrations in a digital twin
There is a level of integration when developing a digital twin. There are three levels towards building a digital twin, with the different levels are digital model, digital shadow, and digital twin [39].
19
3.4.1 Digital model
Digital model is the lowest level, and it represents a physical product and does not have any kind of automated communication between the two objects. The model can interact with the physical product using manual data exchange. For example, in this project, a rotational movement on the physical crane would not in any way affect the digital representation to do the same movement or vice versa.
3.4.2 Digital shadow
Digital shadow is the middle level, and it uses a one-way automated
communication system between the digital representation and the physical product. With this level, it is possible to send data from the physical product to the digital representation but not vice versa. For example, in this project, using a rotational movement on the physical crane would allow the digital
representation to do the same movement.
3.4.3 Digital twin
Digital twin consists of a two-way communication system and allows the digital twin and the physical product to send data to each other. For example, in this project, using a rotational movement on the physical crane would allow the digital representation to do the same movement. Together with a virtual sensor on the digital twin, data can be read and sent to the physical crane. This would allow the physical crane to stop the load from ever lowering the load on top of a virtual obstacle.
3.5 Result analysis
For each task there is a specific solution (see Appendix C) that will be used to control that it is working. Each task will be dealt with during its specific sprint.
The requirements and goals use different methods, these methods will be explained in the upcoming section.
3.5.1 Importing a 3D-model
To import a general 3D-model from Solidworks into CoppeliaSim is a critical part of this entire project, this will be verified in an early stage of the project. The verification will be done visually. To make it easier to use, all the dimensions in the simulator must be the same as the physical crane.
20
3.5.2 Easy adjustable parameters of the digital twin
Making it easy to change the parameters of the robot in the simulator requires a tutorial (see Appendix G) with text together with pictures showing where to click and insert the parameters. This will also be verified from the speed of setting everything up (see chapter 1.2 Requirements).
3.5.3 Easy to setup
The requirement that will test the speed of setting up everything will be tested by students from the course Design of Mechatronics System [4] using the produced tutorial (see Appendix G).
3.5.4 Visual analysis of the lag
To test the lag a visual analysis will be done, the analysis will consist of a camera filming both the digital twin and physical crane at the same time. The test will be done by analysing the film and looking at how many frames it takes for the digital twin to move after the physical crane has started to move. Since the time between each frame is known, a frame-by-frame analysis will be done to calculate the lag. This test will be performed at least 15 times. The results will be put into a measurement series and the results will be used to calculate the minimum, maximum, variance and average lag. An example of the calculations can be seen in Appendix D.
3.5.5 Accuracy of the digital twin
Testing the accuracy of the system will be done by measuring the expected location of the load from the physical crane, this will be measured with a ruler.
Then measuring the simulated position of the load from the digital twin. The data will then be analysed and the difference for each run will be calculated.
Through a series of measurements an error will be calculated. An example of the calculations can be seen in Appendix D.
3.5.6 Students importing their unique 3D-model
For the students to import their 3D-models could cause issues. The 3D-models will be imported using both Windows and Linux to check for any issues during the installation of the guide that needs to be within the tutorial for fewer issues in the end. The same students from the course will be testing this feature as well, using the produced tutorial.
21
4. Implementation of the digital twin
This part goes through the mathematical conversion from the physical crane to the digital twin, how the product process design is being used during the
implementation of the digital twin. Also, how the digital twin works with
implementing a virtual sensor and obstacles and how the programming behind it was made. An explanation will be given on how the digital twin was
implemented using a tree-structured robot model.
4.1 Conversion from physical robot to digital twin
This part goes through the mathematical formulas and calculations needed to convert the movement of the physical crane into movement of the digital twin.
The physical crane uses a DC-motor that is connected to a spool. The spool (see Figure 10) that can elevate (z-axis) the load when it rotates. Another DC-motor is being used to rotate the crane around the z-axis, this makes it possible to reach different x and y-coordinates. A stepper motor moves the crane along the x-axis on a slider. The following chapters describe how these were implemented using the product design process method.
Figure 10. Shows a spool that is mounted on top of a cog. The spool has a wire that is connected in the middle, and it is used to elevate the load when it rotates.
4.1.1 Load elevation (z-axis)
The formula to translate encoder values into a distance in the simulator is done by the following steps. The total distance the load can move, from being on the minimum position to maximum position is 219 mm (Simulation max distance).
Total required encoder values of 219 000 (Max encoder values) to move the load from its minimum position to its top position (see Appendix A). Converting the distance required for the load to reach top position in the simulator are done by the formula (1):
𝑍𝑝𝑜𝑠 = 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝑒𝑛𝑐𝑜𝑑𝑒𝑟 𝑣𝑎𝑙𝑢𝑒
𝑀𝑎𝑥 𝑒𝑛𝑐𝑜𝑑𝑒𝑟 𝑣𝑎𝑙𝑢𝑒𝑠 × 𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑖𝑜𝑛 𝑚𝑎𝑥 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 (1)
22 Each student’s unique crane arm will not always be pointing straight out from the crane house, which means the required distance is going to increase when the crane arm is pointing upwards.
The total amount of cogs in the system will determine if the system is going to rotate in the same direction as the motor or in reverse. If the system has an even number of cogs (see Figure 11), the direction is going to go reverse from the motor. With an odd number of cogs (see Figure 12) the direction is the same as the motor. This applies for both the gear of the spool as well as the gear for rotation. This is done in the coding part and will allow the user to enter the total amount of cogs in the system to determine the correct directions.
Figure 11. Showing that the even number of
cogs will give reverse rotation as the motor. Figure 12. Showing that the odd number of cogs will give the same rotation as the motor.
4.1.2 Crane rotation around z-axis
Converting the encoder values from the motor into degrees is done by taking the total amount of encoder values required for an entire revolution and dividing it by the total amount of degrees on a circle. A gear ratio must be added into the system, and it is done by multiplying the inverse of the current gear ratio. The start angle of the crane needs to be added to the equation to get the correct position. To move the digital twin using the communication API, this needs to be converted into radians. To calculate the rotation, see the final formula (2):
𝜃 = 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝑒𝑛𝑐𝑜𝑑𝑒𝑟 𝑣𝑎𝑙𝑢𝑒 𝐸𝑛𝑐𝑜𝑑𝑒𝑟 𝑝𝑒𝑟 𝑟𝑒𝑣𝑜𝑙𝑢𝑡𝑖𝑜𝑛
360
× 1
𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝑔𝑒𝑎𝑟 𝑟𝑎𝑡𝑖𝑜× 𝜋
180+ 𝑆𝑡𝑎𝑟𝑡 𝜃 (2)
4.1.3 Crane slider along x-axis
The workspace of the physical crane is 600 by 500 mm, but the crane cannot move the full 600 mm and has been programmed to move between 150-480 mm to avoid problems with the slider. These positions have been represented by a coordinate system that goes from 0 to 600 and the possible coordinates for the crane house attachment point lie between 150-480.
Now that the minimum and maximum position is defined (see Figure 13) the difference between maximum and minimum is easily calculated by taking the maximum position and subtracting the minimum position. This gives the
23 possible travel distance for the digital twin (480 - 150 = 330 mm, which is the Simulation max distance). Total number of steps for the motor from minimum to maximum is 28460 (Max steps).
Figure 13. Shows the physical crane and the simulation in the minimum position (top two pictures) and the maximum position (bottom two pictures).
With information on how many steps the physical crane takes to go from minimum to maximum, a conversion from physical steps to digital twin movement can now be created by the formula (3):
𝑋𝑝𝑜𝑠 =𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝑠𝑡𝑒𝑝
𝑀𝑎𝑥 𝑠𝑡𝑒𝑝𝑠 × 𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑖𝑜𝑛 𝑚𝑎𝑥 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 (3)
4.2 Virtual sensor and obstacle
A virtual proximity sensor was implemented (see Figure 14) according to the created tutorial in Appendix G. The sensor was combined with an obstacle and together with the Matlab API, data can be sent from the digital twin to Matlab.
This is implemented to make the digital twin more resemblant of a CPS and teach the students that will be using the system about Industry 4 and how it can be used to make improvements to a design without physically building it. The data from this system can be used for one of the student tasks created (see Appendix G).
24
Figure 14. Shows a virtual sensor that has been triggered because there is an obstacle at the load's end position.
Without this function, this entire project would be a digital shadow and not a digital twin [39]. The sensor data can be sent to Matlab and send the stop signal to the physical crane.
A test was programmed to verify that the sensor works as intended. The sensor was only allowed to detect the specific obstacles and was designed with that in mind.
4.3 Programming
All the coding to control the digital twin was done using Matlab scripts. The Matlab API gave the opportunity to set positions to each of the motors using velocity/position profiles that were calculated in Matlab. If the user is using a velocity profile, there is a function that integrates the velocity profile into a position profile (see Appendix B) before sending it to the simulator.
Using the API, there are two different modes used to send data, blocking and non-blocking. The blocking mode sends a request from Matlab to CoppeliaSim and waits for a response before continuing. This must be used when setting up which joints to control from Matlab. The other mode, non-blocking, sends a request but does not wait for a response hence the program continues. This is used when sending data from Matlab that does not need any responses such as speed values for the motors/joints. The reason a response is not needed when sending velocity/position values to the digital twin is because the response is sent when the digital twin has reached the set velocity/position, this would slow the
25 system down because of the time it takes for the digital twin to reach the set velocity/position.
Another function was created to control the digital twin using encoder values instead of velocity/position profiles. The function reads the encoder values from the motors on the physical crane. By sending these values to the digital twin, it makes the digital twin move whenever the physical crane moves.
In addition, all the functions above have a built-in stop function that stops both the digital twin and the physical crane if there is an obstacle at the end position.
The stop function was created to check if the velocity of the load on the digital twin is zero and there is an obstacle underneath. If both are true, the stop signal is sent.
4.4 Tree-structured robot
To be able to control a robot in CoppeliaSim, the robot uses a scene hierarchy structure [40]. The scene hierarchy displays a tree of this hierarchy. A complete tree-structure (see Figure 15) has been made from the simple design (see Figure 18). In this model, almost all the joints have names that end with “_motor”. This structure is using a part (for example an stl-file) that is connected to a joint, except for the first part that is in this project mounted on the base.
Figure 15. Tree-structure of the simple design.
A joint is the connection between two parts on a robot (see Figure 16). These joints are either of the type revolute or prismatic. The revolute joint is used for rotation and the prismatic joint is used for linear sliding movement.
26
Figure 16. Showing how the joints are connected to the parts.
Joint 1 (see Figure 16) is of the type prismatic, where the crane must be able to move along the x-axis. Joint 2 is of the type revolute, the crane house must be able to rotate around the z-axis. Joint 3 is of the type prismatic, this takes care of the movement of the load in the z-axis. By controlling these joints using the Matlab API, the movement of the digital twin can be controlled.
Using a tree-structure gives an easy overview of the entire system. If there is an issue with the model, it is easy to know what part of the tree that has the issue.
Whenever a joint is being used, the rest of the tree-structured components that are connected to that part of the tree will be affected by the motion. This is a very effective way to control the robot, but it requires good understanding on how the robot can move.
27
5. Results
In this section are the results of the implementation and tests of the digital twin.
The results are compared with the requirements and goals (see chapter 1.2 Requirements and 1.3 Goals). During the project, both Windows and Linux have been used while working on the digital twin.
5.1 Final system overview
The final system (see Figure 17) contains the CAD-software Solidworks. This was chosen because the school already has licences for the program, and it was the program that was used in the design of the physical crane. The parts were imported from Solidworks into the chosen simulator, CoppeliaSim, as stl-files.
This simulator was chosen because it has an API which allows it to communicate with Matlab natively, this makes the work less complex since an external
communication framework is not needed.
Figure 17. An overview of the programs and products that were used to complete the system. All of these things except Solidworks are needed to run the crane in real time.
In this system, both the physical crane and the digital twin can send data to Matlab and use this data to control each other. The physical crane’s encoder data can easily be read by Matlab, and Matlab can use that data to control how the digital twin should move. The digital twin can implement virtual sensors and Matlab can read the data from those sensors and use the data to control the physical crane.
5.2 Simple design
In the simple design are only the mandatory parts added to the digital twin that are being used when moving the crane from a start position to an end position (see Figure 18). This design contains a workspace, slider, crane housing, crane arm, load, and a sensor. The entire simple design is a kinematic model that uses mathematical formulas to represent each movement. The movement consists of sliding the crane house (x-axis), rotating the crane house (around z-axis) and moving the load (z-axis).
28
Figure 18. The simple design only has the mandatory parts to test the functionality.
This model can be run using either velocity/position profiles or by using the function that reads encoder values from the physical crane. The model that the students will be given is this model, except for the crane arm. Even though this model is simple, it can detect obstacles with the sensor (see Figure 14) and send a stop signal to the physical crane.
5.3 Advanced design
In the advanced design are all the parts from the physical crane integrated into the digital twin (see Figure 19), with a small exception of cables and the
hardware like the Arduino and Raspberry Pi. This design contains a workspace, slider, gearbox for crane rotation (around z-axis), gearbox holder, motor holders, crane housing, gearbox for the load (z-axis), crane arm, load and a sensor. The entire advanced design is a kinematic model that uses mathematical formulas to represent how each of the cogs are moving while rotating and elevating the load.
The yellow and the green cogs on top of the crane house (see Figure 19) rotates when the load is being raised up or lowered down. The yellow, light blue and orange cogs on the back and under the crane house are moving when the crane rotates around the z-axis.
29
Figure 19. The advanced design contains the same parts as the physical crane.
This model can be run using either velocity/position profiles or by using the function that reads encoder values from the physical crane. This model can also detect obstacles with the sensor and send a stop signal to the physical crane.
5.4 Analysis of digital twin performance
The measured results show that the digital twin works similarly to the physical crane (see Figure 20). The results also show that the digital twin has a high accuracy and works very well together with the physical crane. By applying the virtual verification method, the results verifies that the model works as
intended. To analyse this the method described in chapter 3.5.5 was used.
30
Figure 20. This plot is showing how far off the digital twin was compared to the physical crane, where a 0,0 value would be the same position as in the given coordinate system. The red dots show the spread when the digital twin is moving counterclockwise, and the orange dots are showing the data when it is moving clockwise. The data can be found in Appendix E.
The variance and mean were also calculated for both the x-axis and y-axis.
The calculated variance for the x-axis is: 6.59 mm.
The calculated variance for the y-axis is: 7.77 mm.
The calculated mean for the x-axis is: -0.4 mm.
The calculated mean for the y-axis is: 1.23 mm.
The calculated covariance as a 2x2 matrix: [ 6.5931 −3.9724
−3.9724 7.7713 ]
The covariance and the error between the digital twin and the physical crane can be seen in Figure 21.
31
Figure 21. Shows the covariance together with the error between the digital twin and the physical crane. The red dots show the spread when the digital twin is moving counterclockwise, and the blue dots are showing the data when it is moving clockwise. The data can be found in Appendix E.
5.5 Virtual sensor and obstacle
Without the sensor on the digital twin, the only interaction between the digital twin and the physical crane would be when the Matlab reads the encoder values of the physical motors and uses them as control signals to move the digital twin.
A one-way communication would not be explained as a digital twin, but rather a digital shadow [39]. By adding a proximity sensor on the digital twin (see Figure 22), Matlab can easily read the sensor data from CoppeliaSim to send a stop signal to the physical crane. With the virtual sensor, the system becomes more versatile. With the implemented sensor, this 3D-model can be called a digital twin (see chapter 3.4.3).
32
Figure 22. Left picture shows the digital twin without the sensor being triggered. Right picture shows what it looks like when the sensor has been triggered.
The proximity sensor has two detection states, when it senses an obstacle the sensor value is 1 and when there is no obstacle, the sensor value is 0. The stop signal that is being sent to the physical crane is only sent if the detection state is 1 and the velocity of the load is 0. If the obstacle is not at the end position of the load (velocity of the load is 0), the stop signal will not be sent. This will prevent the physical crane from ever bringing down the load on top of the obstacle. The movement to lift the load over the obstacle will still be available.
33
5.6 Delay between the digital twin and the physical crane
The measured results (see Figure 23) shows that the digital twin is within the 0.5 second time requirement, The digital twin that was used when testing this was the simple design. To analyse this, the method described in chapter 3.5.4 was used.
Figure 23. This histogram is showing the time difference between the digital twin and the physical crane when running a real time simulation. The acceptable lag was below 0.5 seconds, and all the measured data is below 0.5 seconds. The data can be found in Appendix F.
The variance and mean were also calculated for the time data (lag between digital twin and physical crane).
The calculated variance for the lag is: 0.012 s.
The calculated mean for the lag is: 0.305 s.
34
5.7 Test students setting up the digital twin
A requirement for this project was to create a tutorial that was easy-to-use, this has been measured by how long it takes two students to set up their own digital twin. Both students have completed the course [4] and have good knowledge about Matlab, Simulink and the physical crane, and how it operates using either velocity or position profiles. The two students were given all the documents and files to complete this task within two hours. Neither of the test students have been working with CoppeliaSim before this test, they were working together to make one digital twin using Windows. Groups of two are being used in the course [4] to make the physical crane work.
The total amount of time to set up a digital twin using the produced tutorial (see Appendix G) for the test students was 1h 6m. Within this time, the test students also implemented a virtual sensor and obstacle to the environment in the
simulator.
5.8 Student task
One of the goals for this project was to create at least one task for the students, using the digital twin. The task that has been created is the implementation of a virtual sensor and adding obstacles on the students own digital twin. Within the created tutorial (see Appendix G), there is a section on how to implement virtual sensors and objects. The test students were able to implement one sensor and one obstacle and test if the digital twin would drop the load on top of the obstacle or not. The digital twin stopped and did not drop the load on top of the obstacle and the test was successful.
35
6. Discussion
Using CoppeliaSim as a simulator was a good choice. Using CoppeliaSim, Matlab and Simulink at the same time worked well on a standard computer without an external GPU which was one of the requirements. In an early stage of the
project, the simple design model was converted into an URDF-format in
Solidworks. Trying to import this URDF to CoppeliaSim was unsuccessful due to an error explaining that the URDF did not consist of a robot. A workaround was found, using the stl-files of the entire simple design. Instead of Solidworks building the tree-structure (URDF), it had to be done manually. Using guides and videos made this possible and gave good knowledge on how things are used within CoppeliaSim. Another good thing with CoppeliaSim was how easy it was to use and the communication with Matlab also works very well. Whenever a new function was made, it was always easy to use the Matlab API. Testing the function was fast and gave a virtual verification if it was working as intended or not.
Using the product design process worked very well. By making a simple design as a very basic prototype of the physical crane, that only includes the mandatory parts and then testing movement gave good knowledge of how to control the digital twin. In early stages of the project, testing the Matlab script to move only the slider was made and to see that the conversion from the physical crane was the same as the digital twin. After the Matlab script to move the slider was successful, another test was made, to test rotation and to move the load up and down. This simple design (without the crane arm) will be the model that the students will be given which is one of the requirements.
The advanced design is fully equipped with all the parts as the physical crane.
By using the same mathematical conversions that were done in the conceptual design for the movements worked well. To make the advanced design took a lot of time due to many parts needed to be combined into one part in Solidworks.
This was not mandatory but to get an easier to use tree-structure to work with, within the simulator. The advanced design is using 5 rotating cogs, by making a function to make them rotate with the correct speed and when they are supposed to rotate requires good knowledge of how the system should work.
With the accuracy analysis of the digital twin, it can be concluded that the digital twin has a high accuracy and does what it is expected to do. The model that was used in this test was the simple design. What the test also told was that the digital twin had a maximum error of 6 mms, of which is within the expected limits. This was while the digital twin was running in real-time with the
physical crane.
36 One of the goals was to implement some sensor that would avoid the load from ever colliding into any virtual objects. The stop function that was made stops both the digital twin and the physical crane. Although calculating a new
velocity/position profile and using it to get back to “home position” never worked.
This is due to the Simulink model that was stopped and Matlab then calculating a new profile for the robot. When the new profile was created and the Simulink model was supposed to upload the new profile, the old one was always being used and the movement of the physical crane was not working as intended.
When comparing this project to one of the related projects [5], both projects have had the same approach and major challenges. Both projects have investigated different simulators and communication frameworks before a decision has been made. The related project concluded that V-REP (CoppeliaSim is formerly known as V-REP) was the better choice for a simulator. Since both projects use the same simulator and have the same goals, these projects are closely related. The goal for both projects is to have a robot that can avoid objects and be run in real-time with each other. Although the related project uses Python and C++ programming where this project uses Matlab and Simulink to calculate the path and trajectory planning and both projects use two different API. The results from the related project have not been measuring the delay between the digital twin and the physical robot, nor the position difference. Both projects managed to create a digital twin that was able to avoid objects and be run in real-time.
The related project on the overhead crane at Aalto University [27], in the “Use Case 4: Product design course”, states that they are teaching an undergraduate course every year using the crane platform as a learning environment. The students are learning about the engineering design challenges. The product design course also includes a series of exercises that have been targeted towards real-life design tasks which can be related to the course [4] at Halmstad
University. This related project uses control signals from the digital twin to the crane which is the same that was used in this project. Although the related project has more sensors on the physical product compared to the physical crane used in this project, both projects managed to create a digital twin using two-way communication [39].
Comparing the produced digital twin in this project with the review study [31]
and what they consider a digital twin. The produced digital twin in this project can be seen as a digital twin because it has a two-way communication between the digital twin and the physical product using the implemented virtual sensor.
37
6.1 Sustainable development
In this section, different social aspects about this project are being analysed.
Economical
All the hardware and software that was used in this project has either been provided by Halmstad University or been free to use for students. The
development of the digital twin is a long process and requires a lot of time spent on it. The students developing this digital twin worked for free and therefore saved the school a lot of money.
For companies that are about to produce a new robot, the company can create a design and use simulation to detect any issues with the design before producing it. This leads to a profit to the company because of less complaints from the customers that will use the product.
Environmental
By creating a digital twin to improve the physical product, it is easy to change components properties without having to design, produce and implement them.
The result will be fast and shown visually instead of a long installation process on the physical product. Saving material from not producing extra components is good for environmental development.
Safety
The only moving part in this project is the physical crane which may imply a risk to the user if they are within the workspace of the robot. By only using the
digital twin, this risk is eliminated [41]. This is an advantage when developing any robot since the robot can be tested and the risk of the robot making any sporadic movements can be eliminated.
Integrity
Either the digital twin or the physical crane that was used in this project does not save any kind of collected data. The sensor data that are being used are not of any use after the robot’s movement has been made.
38
