Digital Twin of a Robot Dog

Short Introduction to Digital Twins

Digital twins are often defined as “Digital representation, sufficient to meet the requirements of a set of use cases” (Plattform Industrie 4.0). Integrating data about the asset (object which has a value to an organization and is therefore managed individually) from different life cycle phases, a digital machine twin can provide valuable structuring of data and insights; from asset development and configuration all the way to the asset’s end of life.

../_images/type_instance_intro.png

In the figure below, we can differentiate a type and an instance. All planning data creates the type of the asset. The type is used to implement the physical (real-world) instance of the asset. The planning activities are inclusive of all domains namely mechanical, electrical and software. A type becomes an instance when development and prototype production is completed, and the actual product is manufactured.

For example, the type of car includes CAD models, wiring diagrams, accessories which can be varied according to a desired use case. Thus, the type specifies which different car configuration are available in form of a 150% model. When the customer selects their individual configuration, for example in an online shop, a virtual 100% model is created. The 150% model as well as the 100% model are still part of the product type. As soon as the 100% model is manufactured, an individual instance is created. Thus, the customer gets a real-world touchable car with a unique serial number. Customers will use their car instances and create specific and individual lifecycles with respect to their usage.

When the product is delivered to the customer, this marks the beginning of a product’s lifetime or service time. During this, the product provides the service for which it was planned and manufactured. During service life, prescribed maintenance is suggested to avoid sudden breakdown of the product. Once the product’s service time ends or the product is no longer required, the product is decommissioned, and this marks as end of life. During the end of life, the product can be recycled, up cycled, or decomposed according to requirements.

The digital twin includes data from the type (analysis, specification, and design phases) as well as data from the instance (implementation, system test, operation, and maintenance phases). Also, end of life phases must be included. The collected data can be analyzed and a predictive model can be created. This way, objects which are, for example, subject to wear can be replaced at the right time.

Creating a Digital Twin for a Robotic Dog

In this course, you will learn to use a robot dog “Bittle” to develop your individual robodog instance. You will collect data from your instance of the robot dog and use it to build a digital twin. This course is designed to explain the concept of digital twin and its application with interactive ready to buy modules with plug and play interface. Bittle is a robot dog that can do simple tasks, such as walking or waving. However, it cannot perform complex tasks, such as object avoidance or line following, out of the box. This must be implemented by expanding the existing robodog hardware and by creating additinal program code.

An overview of the type and instance of robot dog with additional modules can be visualized in the image below.

../_images/overview_robodog_dt.png

When looking at the robot type, you will see that different robot configurations are possible, depending on your hardware selection. The hardware selection possibilities can be organized according to different hardware modules:

  • Control board: This is the main brain of the robot.

  • Locomotion hardware: Parts that help robot move in real world.

  • Peripheral devices: Sensors and Actuators used to interact with the real world.

  • Communication interface: Protocols used for sending and receiving information between control board and peripheral devices or locomotion hardware.

All hardware options as well as the base structure make up the 150% model of the robot. Thus, the 150% model describes all possible configuration variants of the robot dog creating the DT type.

Depending on your use case, you can create a specific robot configuration (100% model). As an example, the following configuration is selected:

  • Control Board -> ESP32

  • Locomotion hardware -> Bittle dog

  • Communication interface between control board and locomotion hardware -> UART

  • Peripheral devices -> Sharp GP2Y0A02YK0F (Distance measurement)

../_images/bittle_type.png

When the product described by the 100% model is manufactured, assembled, and given a unique article number, it becomes an instance. Different instances of the same robot type will perform differently due various factors, such as battery charge, position of the sensor, the code snippet used etc.

../_images/bittle_instance.png

Once the instance is ready, the data can be collected and stored. This data will help in analyzing the performance of that specific instance and can be used to compare with other instances or to improve the 150% model type. Thus forming a DT.