Academic Year 2015/2016

WARSAW UNIVERSITY OF TECHNOLOGY

FACULTY OF INFORMATION TECHNOLOGY AND ELECTRONICS

INSTITUTE OF AUTOMATION AND APPLIED INFORMATICS

DIPLOMA ENGINEERING WORK

Maciej Safarzyński

Overview of development environments for LEGO

Mindstorms EV3, with veri fi cation robot

depositing the Rubik's Cube

Supervisor:

dr. Tomasz Winiarski

Rating:. . . . . . . . . . . . . . . . . . . . . . . . . . . .

.........................................

Date and signature of the Chairman

Diploma Examination Commission

2
 summary

The aim of this study was different development environments for LEGO Mindstorms EV3. Review was a

practical one, because based on the creation of the robot built with LEGO Mindstorms. The robot had the task

of solving Rubik's cubes. This task is accomplished by writing three programs in environments ROBOTC,

ev3dev and Matlab. All three programs despite the implementation in different programming languages ​share

the same functionality.

Keywords: Mindstorms EV3 ROBOTC, Matlab, ev3dev, Rubik's Cube.

Abstract

title: Overview of programming environments for LEGO Mindstorms EV3, veri fi ed to the Rubik's Cube solving

robot.

The aim of this thesis was an overview of di ff erent environments for programming LEGO Mindstorms

EV3. The overview had a practical nature, because it was based on the creation of a program for the robot

built with LEGO Mindstorms. A robot built with LEGO had the task of solving Rubik's cube. This task was

accomplished by writing programs in three environments, ROBOTC, ev3dev and Matlab. All three programs

despite the implementation directory in di ff erent programming languages ​share the same functionality.

Keywords: Mindstorms EV3 ROBOTC, Matlab, ev3dev, Rubik's cube.

4
Table of Contents

1. Introduction 7

1.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Aim of the study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Structure of the work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Technologies used 13

2.1 The used equipment. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 LEGO Mindstorms Education EV3 Core Set. . . . . . . . . . 13

2.1.2 Rubik's Cube. . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 The algorithms. . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 The use of the software. . . . . . . . . . . . . . . . . . . . . 17

2.3.1 ROBOTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.2 Matlab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.3 ev3dev. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 System Design 23

3.1 The course of the job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Project assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Implementation 31

4.1 Implementation ROBOTC environment. . . . . . . . . . . . . . . . . 31

4.1.1 The main loop of the program - file "main". . . . . . . . . . . . . . 31

Module 4.1.2 global variables - file "globals". . . . . . . . . . 32

4.1.3 Module of manipulation - the file "manipulate". . . . . . . . . . . . . 32

4.1.4 Calibration Module - file "calibrate". . . . . . . . . . . . . . . . 33

4.1.5 Display Module - file "display". . . . . . . . . . . . . . . 33

4.1.6 Scanning Module - file "scan_cube." . . . . . . . . . . . . . 33

4.1.7 resolving module - file "solve". . . . . . . . . . . . . . . 33

4.1.8 Module scan and fix - file "scan_and_solve." . . . . . . . 34

5
6 TABLE OF CONTENTS

4.2 Attempting to implementation in Matlab. . . . . . . . . . . . . . . 34

4.3 Implementation of the system ev3dev. . . . . . . . . . . . . . . . . . . . 35

Module 4.3.1 global variables - file "globals". . . . . . . . . . 35

Manipulation Module 4.3.2 - Class "manipulate" . . . . . . . . . . . . 36

4.3.3 Calibration Module - Class "calibrate" . . . . . . . . . . . . . . . 36

4.3.4 Display Module - Class "display". . . . . . . . . . . . . . 36

4.3.5 Scanning Module - Class "scan_cube." . . . . . . . . . . . . 37

4.3.6 resolving module - Class "solver". . . . . . . . . . . . . . 37

4.3.7 Module scan and solve - Class "scan_and_solve." . . . . . . 37

5 Summary 39

5.1 The results of the comparative analysis . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.1 Characteristics of the projects for the environment ROBOTC. . . . . 41

5.2.2 Characteristics of the projects for the environment ev3dev. . . . . . . 41

5.2.3 Characteristics of the projects for the Matlab environment. . . . . . . 42

5.2.4 Overall conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . 42

And bibliographical 45
Chapter 1

Admission

This chapter contains the introduction to the work (Section 1.1), motivated the author to write the work

(Section 1.2), the purpose of the work (Section 1.3) and describes its structure (Section 1.4).

1.1 Introduction

This work is closely linked with the issue of robotics. In order to receive a proper work worth at the outset

to explain the meaning of the term "robotics", and the easiest way to do starting from the de fi nition of the

word "robot". According to the de fi nition introduced in 1979 by the Robotics Industries Association, "Robot"

is: "Programmable multifunctional manipulator designed to move material, parts, tools or specialized devices

through various programmed motions for the various tasks." [ 3] However, the wider term "robotics" Dr.

Wojciech Szynkiewicz explains: "Robotics has been designing, building, testing and use of robots." [ 11]

Robotics is one of the fastest growing technologies of today. The scope of its applications is growing, and

the number of areas in which specialized robots replace human is constantly expanding. Nevertheless,

robotics is a highly complex field of science. Primarily due to the fact that it is contained in a number of basic,

yet complex disciplines such as mechanics, electronics, mathematics, automation, computer science, or even

biology. Given such a multifaceted range of topics, the number of experts in this field is very limited. At the

same time at the present time significantly increasing demand for professionals just robotics.

To cope with this problem, and also to arouse interest in the subject among the widest on the market

appears more and more simplified

7
8 CHAPTER 1. INTRODUCTION

robotic platform. Simplification means first of all, that manufacturers have created or finished work in the

assembly uncomplicated, accessible to a wide audience including amateurs.

Robots give their creators a huge development prospects. Their versatility is based mainly on providing

users with tools that facilitate the programming of robots, while not limiting their multitude of uses. Thanks to

such a complex topic which is robotics becomes part available even for the layman, arouses interest, a desire

to explore issues, and thus increases the chances and opportunities for professional development of the

discipline.

Figure 1.1: LEGO MINDSTORMS Education EV3 Core Set.

One such platform is affordable LEGO Mindstorms. Developed since 1998 a series of sets, combining

LEGO blocks with electronic sensors, servos and computer central processing unit. The technology allows,

among others, the construction of robots and automation systems and their respective Programming the. The

latest product is a series of LEGO Mindstorms EV3 introduced to the market in 2013. The use of LEGO robots

as the main building material, and provide the user with intuitive tools for software development, meant that

this technology is audience even among children. It's a great way to introduce young people to the world of

robotics. At the same time the platform has enough Mindstorms unlimited use, it allows you to build a whole

spectrum much more complex and multi-functional robots for more advanced users. For them is developed a

range of professional environments, independent of the LEGO Group, fi RMY, wheel design, or individuals.

These organizations do not have

1.2. MOTIVATION 9

no commercial relationship with the business name producing Mindstorms, but their work is supported by the

LEGO Group and in the interests of creators Mindstorms platform. One of the Mindstorms product line is

shown in Figure 1.1.

1.2 Motivation

Nowadays, the use of robots is associated more closely with almost every field of science and life.

Robots are present in everyday life, during simple activities and games, but also in the most complex

activities such as surgery [1], study the ocean floor [2] or space exploration. [9] The process of creating and

construction robots dependent on the function they have to fulfill, in addition to technical design is based on

the development environment in which the robot is programmed. It is the environment determines the range

of possibilities and purpose of a robot. specifically "Is an application development environment or a set of

applications for creating, modi fi cation, testing and maintenance of software" [ 12], it is thus the place in which

is created a kind of "brain" is assigned to a specific device, "mind" which issues orders, defines the tasks and

controls the precision of the implementation.

Development environment and the associated programming language closely therefore affects directly to

ease the programming process. Environment together with the language of the programmer to provide tools

that determine whether a process robot software will run smoothly, comfortably and quickly, and that the

general assumptions in the program will be provided by technologies to realize the environment.

What is important is the environment differ from each other by providing developers with more or less

advanced libraries of programming languages. In connection with the completion of a robot functions may

require more or less time and lines of source code. In extreme cases, it may become impossible to perform

certain programs which in other environments would be feasible. In addition, the environment can provide a

range of tools to build a program, debugging, testing, transfer the program to the device, communication with

the robot, remote command execution, file or exploring robot. These tools can be more or less comfortable

depending on the quality of the environment. A set of tools available in the environment and their quality has a

decisive influence on the projects for which environmental data and determines a suitable comfort of work.

Therefore, it is important to choose the right programming environment for a specific project.
10 CHAPTER 1. INTRODUCTION

1.3 Purpose

The aim is to review the work of three different development environments for technology designed

LEGO Mindstorms EV3. LEGO Mindstorms robot is self-assembled, and then for it was written program in

turn in each of the three environments.

Figure 1.2: Rubik solver - stacker robot Rubik's Cube.

The subject of testing environments robot is "Rubik Solver", which arranges isolated Rubik's Cube. The

robot receives cube able mixed up, and then scans successive colors of fields, cubes, calculates the optimal

minimum amount of movement solving the cube and manipulates the end of the cube so that each of the

walls of cubes made up of elements of the same color. The design work is based on an existing project

"Mindcub3r" [8]. Be on the basis of this scheme was developed robot called for work "Rubik Solver", shown in

Figure 1.2.

The task was carried out, by writing three programs in environments ROBOTC, ev3dev and Matlab. All

three programs despite the implementation in different programming languages ​share the same functionality.

Rubik's Cube Robot-laying requires complicated software, using most of the features available in the library of

language environments, and environmental tools. Due to the complexity of the program, The respective

implementation in the environment resulted in a thorough knowledge of the system and use its many

capabilities.

The following work has been formulated conclusions summarizing the characteristics of each of the

environments, its positive features, as well as hindering aspects of the work.

1.4. STRUCTURE OF WORK 11

Based on the analyzed data have also been de fi ned types of projects that best fit your environment.

1.4 Structure of the work

This work consists of five chapters starting with this introduction 1. Chapter 2 presents the tools which

were used to build and robot software. Chapter 3 shows the course of the engineering tasks and formulates

design assumptions. Chapter 4 is devoted to the implementation of the implementation of programs in

development environments. The final chapter 5 is a summary of the results of work in the form of comparative

analysis and conclusions drawn.

12 CHAPTER 1. INTRODUCTION
Chapter 2

technologies used

The work equipment was used (section 2.1), algorithms (section 2.2) and programs (Section 2.3).

2.1 The used equipment

Equipment needed for the work was a set of LEGO MINDSTORMS Education EV3 core set (subsection

2.1.1) and the Rubik's Cube (subsection 2.1.2).

2.1.1 LEGO Mindstorms Education EV3 Core Set

The main equipment used in the work is a set of enabling robots to build LEGO Mindstorms Education

EV3 Core Set. This is the educational version of the product EV3 addressed mainly to students and pupils,

but also more professional users. The kit includes the mechanical means - LEGO Technic, and active - servo

motors, sensors and die EV3.

Mechanical Components used to build still part of the robot and do not have much significance in this

paper. But it is worth to devote some attention to the active elements, because they are about the possibilities

and potential of the robot. Active elements are shown in Figure 2.1.

13
14 CHAPTER 2. TECHNOLOGIES USED

Figure 2.1: servos, sensors and ankle EV3 - active external elements joint Mindstorms Education EV3 Core
Set

Active elements:

• Programmable ankle EV3 - a computer running the Linux-based ARM processor clocked at 300MHz

frequency. On the computer memory consists of 16 one hundred megabytes of flash memory was

expandable through microSD card port, and 64 MB of RAM. The cube has four input ports for

connection to the sensors, and 4 output intended for reactors, all based on standard RJ-12. To

communicate with an external computer are USB ports and Mini-USB, and Bluetooth wireless

standard and optional Wi-Fi via an additional adapter, sold separately. All this is crowned by a panel of

user interaction, which is 6 programmable buttons, colorful LED, speaker, and monochrome LCD with

a resolution of 178x128 pixels.

• Two large servo - drives high-power, a moment of force for the gear ratio of 0.2 newton meter. The

maximum angular speed is 160-170 rpm. Mechanisms are equipped with incremental encoders, or

rotation sensors with a resolution of 360 pulses per revolution. The axes of rotation of large servos are

arranged perpendicularly to the body component.

• Average servo - drive with overall dimensions less and less time for power transmission, 0.08 newton

meter. The expense of reducing the time it was possible to increase the maximum speed, which in the

case of the drive

2.1. USED ​EQUIPMENT 15

medium is 240-250 rpm. Servo also is equipped with a rotation sensor with a resolution of 360 pulses /

revolution. The drive axis of rotation is located along the longest dimension of the mechanism.

• Ultrasonic distance sensor - sonar, which indicates the distance to the nearest obstacle robot, works

on the principle of issuing and capture the reflected ultrasound waves from obstacles. By using this

advanced technology used, among others, air in the radar sensor has a high resolution of approx. 1

cm. Sonar is functioning correctly when the obstacle is at a distance of from 3 to 250 cm. In addition to

the function of distance measurement, the sensor can be switched to a passive state in which it acts

as a capture probe waves from external sources.

• Color sensor - it is more precisely the light sensor. Ledowy is equipped with a light emitter of the basic

colors: red, green, and blue color and white light beam. Emitted from the sensor light waves reflected

from the object tra fi AJA to the lens, collecting them again. Then examines the intensity of the sensor

of the reflected wave. Depending on what the sensor itself emits light, it can operate in three modes:

color recognition mode, the intensity of the reflected light mode, ambient light. Color sensor operates

with a sampling rate of 1kHz. To ensure correct reading of color, the object should be within 15-55mm

of the sensor.

• Two touch sensors - analog touch sensors detect the pressing or releasing a button positioned on the

front of the sensor. Button is specifically designed so as to be able to attach thereto a standard Lego

art. The depth at which the button can be pressed up to 4 mm. This sensor can be used in two ways:

by the robot to detect obstacles, and as an additional button for the user.

• Gyro sensor - digital gyro sensor measures the rotational movements of the robot, and changes in its

orientation. With it can improve the accuracy of the robot maneuvers, read the angle of inclination of

the robot relative to the substrate, which allows for balancing the construction robots. A gyroscope can

operate in two modes: the angle with an accuracy of approx. 3 degrees measured rotation angle

sensor; mode gyro measures the angular velocity where the maximum
16 CHAPTER 2. TECHNOLOGIES USED

measurable speed is 440 degrees per second. Sampling rate gyro is 1kHz.

2.1.2 Rubik's Cube

In 1974, the Hungarian sculptor and architect Ernő Rubik constructed a logical puzzle, which quickly

became one of the most recognizable toys in the world. In honor of the creator he has been called "Rubik's

Cube". Solving the cube is laying on such colored squares to each of the walls had all the squares of the

same color.

Figure 2.2: Rubik's Cube

Construction of cubes: Block 26 is composed of cubes, and articulation which enables the outer layers of

the ankle about an axis of rotation center of the ankle, which is perpendicular to the plane of the layer.

Commercial cube visible from the outside are painted six colors: red, green, blue, yellow, orange and white.

The following figure shows the Rubik fi RMY Rubik's 2.2.

Figure 2.3: Wall and wall Rubik's Cube

To facilitate the description of the cube, we introduce speci fi Total terminology for it, so the concept of

walls and walls visible on rysunku2.3.

• Wall cubes - refers to the entire wall Rubik cube, which is the single color embodiment.

• Cube wall - wall 26 of one of the small cubes visible on the outside having one of the six colors.
2.2. USED ​ALGORITHMS 17

2.2 The algorithms

The work was used algorithm stacking Rubik's Cube. There are many techniques for stacking cubes. The

problem of finding the optimum algorithms, is difficult because of the enormous number of combinations of

different poses block that is more than 43 tryliardy (43 252 003 274 489 856 000). In 2010, a group of

mathematicians, thanks to the computing power of computer servers proved that freely mingled cubes can be

arranged to take up to 20 "movement."

Designing a new algorithm stacking Rubik's Cube, is an extremely complex and demanding process.

Because it is not related to the theme of work, it was used an existing algorithm. It is part of the project

Mindcub3r, developed by David Gilday'a, passionate about creating robots with LEGO recognizable figure in

the online world of LEGO. [8] The same algorithm little is known as it is available only in the form of a binary

code and can be run from a separate program. It is not known the source code of the program, called later in

the work "solver". It is known, however, that there was implemented an algorithm that fi potra lay an average

of the Rubik's Cube in 24 moves. Communication with the robot program solver is done using shared read

and write files.

2.3 Use of Software

Software used in the work programs include engineering, ROBOTC (subsection 2.3.1), ev3dev

(subsection 2.3.3) and Matlab (subsection 2.3.2).

2.3.1 ROBOTC

ROBOTC is a cross-platform development environment for popular robotic systems, such as the VEX IQ,

VEX EDR VEX PIC tetrix, Arduino UNO Arduino MEGA products and Lego RCX, NXT, and the latest EV3.

ROBOTC, it is also the name of a programming language, which he uses in this system. ROBOTC your

language syntax is based on the well-known C language and is thus similar to his twin. The operating system

is required by ROBOTC Windows, but it is possible to run the program through a virtual machine. Below in

Figure 2.4 ROBOTC window.

18 CHAPTER 2. TECHNOLOGIES USED

Figure 2.4: Window ROBOTC

The program is a complex environment, the so-called Integrated Development Environment (ang. Integrated

Development Environment, IDE). This means that it provides tools for writing and editing code, and can

compile the code and send a binary file to the device, all in one program.

In addition to the above, the program tools are available such as:

• Debugger

• Browser library functions

• Con fi gurator communication with the robot

• File Explorer robot

• Con fi gurator drives and sensors

• Kernel update utility robot

• Automatic formatting and code completion

In addition, the environment is related to virtual simulator robot and its workspace Robot Virtual Worlds. It

is a separate, surcharge program that allows you to simulate the behavior of the robot in the game fi cznym

virtual world. Robot Virtual Worlds is great for learning robotics, even without
2.3. SOFTWARE USED 19

Figure 2.5: Window Robot Virtual Worlds

the need for a fi-lingual job. There is a straightforward tutorial and a series dealing with the challenges of

development. Window Robot Virtual Worlds can be seen in Figure 2.5. On this platform are organized

numerous robotic competitions, having odnajdywać young talents in the field of robotics, one example of such

competitions is the "Mini Urban Challenge". [6]

2.3.2 Matlab

Figure 2.6: Window of Matlab with the addition of the LEGO Mindstorms EV3 Support Package
20 CHAPTER 2. TECHNOLOGIES USED

Matlab is a powerful computer program designed to perform scientific calculations and creating computer

simulations. Paid program creates fi rma MathWorks. It is available on Windows operating systems, OS X,

and Linux and Unix. The program is well known by students of engineering studies, it is widely used at

universities. It operates here in Matlab based on the C language Matlab window shown in Figure 2.6.

For the program are numerous additional libraries (called. toolbox) which increase the ability of Matlab

with additional functions. One such additive is "LEGO Mindstorms EV3 Support Package". [5] This addition

allows you to write programs to work in the technology Mindstorms EV3.

Operation of Matlab is different from other development environments for robots. The difference is that

Matlab acts as a remote controller for a robot. The program here is not transmitted to the device is performed

on a computer only when the robot has to perform some instructions are sent to him orders.

2.3.3 ev3dev

Figure 2.7: Window SSH session with a robot running on ev3dev

One way of programming robots series EV3 is ev3dev environment. In contrast to the previously

described programs ev3dev there is an integrated development environment. Ev3dev is developed by Ralph

Hempel
2.3. SOFTWARE USED 21

and David Lechner operating system based on Debian Linux distribution. Since the cube EV3 runs on Linux,

simply upload the disk image of another Linux distribution on a memory card affixed to the robot pocket.

Then, the robot starts when you turn the system on the memory card instead of the non-volatile memory. In

this way, it possible to change the robot system. Ev3dev system has low-level drivers to enable the use of

sensors, motors and EV3 same ankle. Figure 2.7 is a window SSH client combined with a robot that works is

running ev3dev.

The basic premise of the system is the openness and accessibility. As a result, developers around the

world to help in the development of the project. The effect of global cooperation is the existence of libraries

cooperating with the robot LEGO, written in a very wide range of programming languages. The user wishing

to work on the robot system ev3dev can choose according to taste one of the available languages: C ++,

Node.js, Python, Google him, C, Clojure, Lua, Perl.

The process of software development through a system of robotic ev3dev as follows:

1. Writing program source code in any text editor

2. Compiling code on a computer (using a compiler for ARM processor)

3. The message of the compiled binary file to the robot via a link (SSH called.

Secure Shell [ 4])

4. Starting the program remotely via SSH or directly on the robot

Presented above steps are the only representation of the process framework, it is possible modi fi

cations. For example, a compilation can be performed on the device, it saves upload executable file from your

computer, however, due to limited processor compilation of the robot takes a long time. There are also

additional tools for example. Debug the program in an SSH session.

22 CHAPTER 2. TECHNOLOGIES USED
Chapter 3

system design

This chapter describes the successive stages of the task (section 3.1) and characterized design

assumptions (Section 3.2).

3.1 Mileage tasks

The following work has been distinguished individual stages of work on the LEGO robot. The main task

was to review several development environments and their testing and comparison from the perspective of

programming a robot.

Step 1: Create a lingual fi robot model

The first stage consisted in selecting the appropriate robot. Appropriateness was based on the possibility

of a fair and efficient test development environments. These assumptions are met stacker robot Rubik's

Cube.

Advantages of testing environments on the robot solves Rubik's Cube:

• Complexity - this is a complex project that uses a large number of sensors and actuators. The project

implementation requires a large amount of source code, using a wide range of library functions of a

programming language. Thanks to this environment can be thoroughly tested by the use of only one

device.

• Repeatability - the robot will behave consistently received the same input data. This means that every

time when the robot gets the same mingled ankle places it by the same movement sequence. This is

a feature that greatly facilitates the process of testing the robot, in contrast to the unique robot, where

it is difficult to objectively compare the behavior of the robot subsequent startups.

23
24 CHAPTER 3. DESIGN SYSTEM

• Independence from the environment - the robot solves the Rubik's Cube is less dependent on external

factors. Only the illumination can affect the light sensor, however, can diminish the effect of using a

suitable initial calibration. Thanks to the influence of external factors compact robot becomes

dependent only on the input data. This translates into a robot repeatability and allows you to skip the

state of the environment surrounding the robot every time it starts. It is a factor in the ease of testing

and work environments.

When the robot concept was determined, the next task was to find and choose the appropriate, finished

the project work. The best project was Mindcub3r [8], created by David Gilday'a. The selection criterion

subject, reliable design and the ability to build a robot using only the active elements of a set of Core

Education EV3 Set. The design of the robot "Rubik solver" is different from project Mincub3r'a, because the

second also uses a set of LEGO bricks "EV3 Education Expansion Set", which have been replaced by other

elements from other LEGO sets. [10] In addition there was no need to use a distance sensor for detecting the

ankle, such as in the design Mindcub3r. Figure 3.1 are visible both robots.

Figure 3.1: Project work "Mindcub3r" (left) and the robot "Rubik solver" (the great- input)

Robot "Rubik solver" potra fi scanned and manipulated by moving a die to systems constructed of the

actuators, the color sensor and Lego LEGO Technic.

3.1. COURSE OBJECTIVES 25

Mobile systems have been named:

Figure 3.2: Spinner

• "Spinner" - a rotating platform that holds the ankle. "Spinner", shown in Figure 3.2, has two functions,

the cube is rotated about a vertical axis, and rotates the lower layer of cubes when it is held from the

top of "flipper". For rotating the platform corresponds to a large servo positioned beneath it. Servo

drive platform moves through two gears: lower

- 12 teeth, the larger - 36 teeth, which results in a geometric ratio equal to 3.

Figure 3.3: Camera

• "Camera" - a movable arm at the end of which sensor is arranged in color. "Camera", shown in Figure

3.3 makes it possible to scan consecutive walls of the cube. Scanning is done through a rip in the time

of two motions: motion platform and sliding movement of the boom. In this way, the colors are

recognized edge walls of one of the walls of the cube. The color of the middle wall is recognized at the

nieobracającej platform. Between the average servomotor located vertically below the boom, and the

boom are three gears, the first placed with the axis
26 CHAPTER 3. DESIGN SYSTEM

rotation vertically facing teeth 12, the second horizontal axis of rotation 12 of the toothed wheel with

the most recent horizontal axis by 36 teeth. This setting changes the gear axis of rotation of the input

vertical to horizontal, and increases the precision of movement.

Figure 3.4: Flipper

• "Flipper" - moving robot arm performing two functions. The first function is to rotate the cube on the

platform in the horizontal axis, through the "stretch" cubes on the platform railing. "Flipper", shown in

Figure 3.4, is constructed in such a way that by pushing in the opposite direction to the rotating

movement of the ankle, shoulder ankle does not rotate in the opposite direction, so that it is possible

to return the arm to its original position after the turning maneuver. The second function is to hold the

arm of the ankle at the time when the platform rotates, to rotate the lower layer of cubes. Execution of

arm movements is a large servo motor located at the axis of rotation of the arm. Motor is connected to

the arm by an articulation in the form of a broken curve. Thanks to this joint shape of the frame moves

sliding, rod-like movement of the steam locomotive. Connecting rod locomotives for imaging is shown

in Figure 3.5.

Figure 3.5: Diagram of a steam locomotive chassis, it is visible in the connecting rod, whose movement
resembles move "Flipper"
3.2. PROJECT ASSUMPTIONS 27

Step 2: Writing robot software environment ROBOTC

When the robot was already solidly constructed next stage was to create software in the first of

environments. It has been selected as the first ROBOTC environment, as the author of it had the most

experience. Writing the first program is the most time-consuming task, so choose the environment that knows

best seems to be the right solution, because it speeds up the process, which has a positive effect on the

development work.

Step 3: Rewriting program Matlab

When the program work properly and satisfactorily, it is time to rewrite it to another environment, which

was Matlab. Here, there have been some complications about which you can learn more in Chapter 4.

Step 4: Rewriting the system ev3dev

The last test was ev3dev environment. Just as in previous environments at this stage of the work was to

write a program in this environment.

Step 5: Comparison of convenience of implementation code in these environments,

After fi nalizowaniu all the steps related to the implementation time has come to draw conclusions about

the work in each of the environments. Compare them with each other, the statement of the most important

attributes of these programs in the comparative table. Determination of what types of projects are best suited

to each of the environments.

3.2 Project assumptions

An important phase, which took place before the start of the design work was to formulate assumptions

which robot programs and the work must meet. With the assumptions route to the destination is simpler.

Assumptions prevent unnecessary actions that delay fi nalizowanie project.

Objectives of the project are:

• Robust design a robot - a robot must be placed on a stable platform. The design should not change

during operation, it should

28 CHAPTER 3. DESIGN SYSTEM

be able to withstand a minimum of 10 consecutive starts of the program, without the need for repairs.

The robot should be immune to damage handling and transport.

• Robot made possible using a minimum of parts - "The simpler the better." "Less is more." The motto

was accompanied by a robot design. In addition, the limited number of available parts forced the

minimalist design.

• Use of at least two programming environments - zakładanymminimum was to test two potentially the

best available to the robot programming environments.

• Programs potra fi robot-binding solve the Rubik's Cube in less than 2 minutes - top-down robot to

reduce the time needed to complete a task, forced to obtain an efficient job. The time is counted from

the start of the scan until the cube is fully aligned. As a result, the average time is much shorter than

the established limit, thus testing the robot goes very smoothly.

• Programs capable of overcoming the fatal errors - there is no one ideal program meets a feature,

developers often dissatisfied with the results, the program undergo continuous improvements.

Developing software for financial potra it last much longer than the acceptable minimum, and in many

cases, the programs are almost never completed. The requirement that the program is considered

completed when work and its effects, proven through tests is not interrupted by programming errors

clearly states when you finish upgrading the code. As a result, the overall process of creating a work

of engineering is reduced, and the time saved can be spent on more important elements of the

project.

• Programs from different backgrounds having similar effects possible - robot software from different

backgrounds should be written in a similar way as possible, so that the robot behavior was

indistinguishable.

• Running programs can not destroy the robot construction and its components - programs must be

selected so the value of the power and speed of moving parts, so they can not destroy the robot

construction.
3.2. PROJECT ASSUMPTIONS 29

• The behavior of the program modules division between the communities - robot software consists of

modules responsible for specific functions. The requirement is that programs in different environments

were divided into the same modules.

• The robot has three approaches to digitizing the correct cubes - in a situation when the robot

encounters a problem while scanning cubes failed attempts are counted. After the third attempt, the

robot interrupts the execution of the program. This avoids a situation in which the robot takes endless

failed attempts to scan the cube.

• Dice manipulation by the robot must pass flawlessly - coefficients of motion manipulators should be

chosen in such a way that no errors were committed in moving Kostka. For example, the situation is

unacceptable, in which the robot had to turn Cube, Cube choke and as a result did not change their

orientation.

• The robot after laying the cubes must be ready for the next stacking - the state of the robot after the

successful stacking cubes must be exactly the same as the state of work before laying the cubes. This

ensures smooth operation of the robot in subsequent startups. Faster and easier testing of the robot.
thirty CHAPTER 3. DESIGN SYSTEM
Chapter 4

Implementation

This chapter describes the implementation of the program the robot in environments: ROBOTC (Section 4.1),

ev3dev (section 4.3) and Matlab (section 4.2).

4.1 Implementation in an ROBOTC

ROBOTC environment allows you to write programs in ROBOTC that uses the syntax of C. In that

language is written in a robot program. The program is divided into modules. The modules reflect the specific

function for which the code is responsible. UML 4.1 diagram shows the distribution of the files corresponding

to the separate program modules. In the following subsections describes all program modules.

4.1.1 The main loop of the program - file "main"

The main loop has a very simple construction. Dispatched in it are three functions in sequence. With the

launch of the program is called the "calibrate ()" of the calibration module, which sets the correct position

servo robot. After calibration function is invoked "displayPatternSelection ()" from the display unit, which

displays the appropriate message and waits for pressing the starting scanning. When the button is pressed,

the function is called "scanAndSolve ()" from the scan module and solve, which deals with the scanning, and

the laying of solving Rubik's Cube.

31
32 CHAPTER 4. IMPLEMENTATION

Figure 4.1: UML sequence diagram of the structure of a program written in ROBOTC

Module 4.1.2 global variables - file "globals"

This module de fi ned variables are shared by other modules. De fi ned here are tables poses ankle fl ag

program, motor control, etc. factors.

4.1.3 Module of manipulation - the file "manipulate"

The module of manipulation is the most important part of the program. De fi ned here are features that

with high accuracy change position and the position of the wall at the ankle. Here are used features available

in rich library provided by ROBOTC environment. Library functions make it possible, among other things:

motor traffic by a certain angle with a predetermined power, motor traffic by a certain angle with the set speed

using PID algorithm, stopping the thread until the end of the movement. Providing high-level functions that

operate motors enables smooth writing program and does not require constructing your own functions. With

the manipulation module is utilized by all other modules in addition to solving module.
4.1. IMPLEMENTATION OF ENVIRONMENTAL ROBOTC 33

4.1.4 Calibration Module - file "calibrate"

Calibration module provides methods needed for setting the moving part of the robot in the respective

starting positions. It also includes a function that checks whether running an external program is responsible

for finding the optimal sequence of solving the cube. This module is mainly called upon startup and after the

operation of the robot to return to the original state.

4.1.5 Display Module - file "display"

This module is responsible for displaying messages on the screen, the robot and the control buttons

located on the front of the ankle EV3. To display messages include: name of the currently performed

operation (calibration, scanning, calculation, solving), display errors, the possible selection formula used at a

Cube or the number of remaining moves needed to solve the cube.

4.1.6 Scanning Module - file "scan_cube"

File "scan_cube.c" is responsible for all operations associated with the next scan color wall cubes. There

are functions, such as scan central wall cubes, scan edge wall, a wall corner scan, scan the entire wall of

cubes and connecting all the previous ones, the function of scanning the whole cube. This module uses the

multithreading capabilities of the program, creating separate threads that regardless of the performance of the

main causes movement of the camera ". This allows you to synchronize the rotation of cubes with the

movement of the color sensor, so as to efficiently and correctly retrieve the next cube wall colors.

4.1.7 resolving module - file "solve"

Resolving module deals with communication with an external program that calculates the optimal solution

Kostka. Communication between the two programs is done using two text files in the memory robot. The first

file is called mc3cmd.rtf and serves to transmit the next command. The file mc3dat.rtf are placed by the

program read color values ​robot walls. In the same file is saved as a response by the solver information:

number of troubleshooting steps, and a series of numbers representing the sequence of stacking cubes.
34 CHAPTER 4. IMPLEMENTATION

The communication process is carried out in order:

1. resolving module first writes to a file mc3cmd.rtf message started.

2. The "solver" replied that he understood the command response in saving the file mc3cmd.rtf

3. After scanning Kostka program saves the file mc3dat.rtf color values ​of successive walls of the cube.

4. After calculating the optimal solution "solver" saves the file mc3dat.rtf number of solution steps and

sequences of movements laying paving

5. At the end of "solver" in the file mc3out.rtf report puts the program "solver"

4.1.8 Module scan and fix - file "scan_and_solve"

This module contains only one function. This function is used to start the sequence of all the methods

needed to properly scan to calculate movements and lay the Rubik's Cube. If three failed attempts Cube

orientation module ceases to execute further attempts, displays an appropriate error message and sets the

robot position.

4.2 Attempting to implementation in Matlab

Before starting the implementation in Matlab, a review of this environment. The aim of this review was to

investigate the possibilities of what this program offers. The review came to light as a limited functionality

represents the Matlab environment in this application. In particular, the most important limitations are:

• Inability to transfer the program to the device - programMatlab only allows work in the form of a

remote control robot. The program is executed on a computer that only means of communication with

the robot sends him on a date subsequent instructions to be executed. This means that it is

impossible to separate the operation of the robot.

• A limited number of library functions - the nature of the remote controller Matlab causes very limited

predefined library functions. Developer receives only the most basic set of features
4.3. SYSTEM IMPLEMENTATION EV3DEV 35

such as power transmission to the engine, whether the read value of the raw sensor color brightness.

No more complex functions, eg. Servo rotation with maintaining a given speed, thanks to the PID

algorithm, hampers and slows down the writing complicated programs.

• No read and write files on the device - in Matlab it is impossible to perform operations on files in the

memory of the robot. Through this communication it is not possible with an external program "solver",

which communicates with the robot's software through the exchange of data in the files of the device.

• Lack of multithreaded programming - Matlab program does not allow concurrent programming

Mindstorms robots. This is a severe limitation. In many cases, the software can convert the

single-threaded concurrent, but this can be time consuming and changing the behavior of the robot.

The other two multithreading environments was used.

All these factors contributed to the decision that the Matlab environment is not suitable for

implementation of the program on the robot "Rubik solver." So after the initial hearing with the

environment, it was concluded that the robot will be programmed in environments ROBOTC and

ev3dev, and Matlab will be excluded because it is not suitable for projects of this type.

4.3 Implementation of the system ev3dev

To implement another copy of the program was used ev3dev system. The program was written in C ++.

C ++ is object-oriented language, so the program was divided into classes corresponding modules of the

program. The main functions are created through all the main classes of objects modules. Objects need

methods classes are transmitted to them by the arguments of the method call. For this purpose, de fi ned

methods are templates. Figure 4.2 class diagram is shown in a program written in the system ev3dev. In the

following subsections describes all program modules.

Module 4.3.1 global variables - file "globals"

As in the case of ROBOTC program is used for a number of global variables. It is almost identical set of

variables, constants and tables as in the case file "globals" program written in ROBOTC.
36 CHAPTER 4. IMPLEMENTATION

Figure 4.2: Class diagram of the program written in the environment ev3dev

Manipulation Module 4.3.2 - Class "manipulate"

In the classroom manipulate functions are responsible for the manipulation of Rubik's Cube. Ev3dev

Library provides a little poorer feature set associated with servonapędami. However this does not in creating

their own high-level functions. In the classroom have been implemented manipulate features designed on the

model of the environment ROBOTC, this facilitated the rewriting of the first environment. In addition, thanks to

programs maintain a consistent design, which was one of the objectives of the project.

4.3.3 Calibration Module - Class "calibrate"

Exactly as in the case file "calibrate" the ROBOTC in this class are methods of positioning robot in

position to solve the cube.

4.3.4 Display Module - Class "display"

Class is responsible for providing an interface for communication with the user. Messages are displayed

indicating the status of the robot, the next phases of action

4.3. SYSTEM IMPLEMENTATION EV3DEV 37

program, or any errors. For simplicity messages are formatted and are simply inscribed successive lines of

text on the screen, as in the case of a PC command line.

4.3.5 Scanning Module - Class "scan_cube"

Module "scan_cube" is the class de fi excep- tion methods that deal with exact scanning all the colored

cubes wall. These functions use the color sensor operating in RGB - feeding components czerownego, green,

and blue color panel. The information collected in these tables scan_red, scan_green, scan_blue are then

sent to an external program.

4.3.6 resolving module - Class "solver"

This class provides methods whose task is to communicate with an external program "solver".

Communication takes place in exactly the same way as ROBOTC in the environment because it uses exactly

the same external program solving.

4.3.7 Module scan and solve - Class "scan_and_solve"

This class is, it starts the following methods of all classes, so that as a result of the scrambled cube after

calling scanAndSolve get solved cube. As in the case of the ROBOTC they are made three attempts

arrangement Kostka, and in case of failure is communicated error and set the robot in the starting position.
38 CHAPTER 4. IMPLEMENTATION
Chapter 5

Summary

In the last chapter the results of an analysis of the development environments (section 5.1) and the

lessons learned during the execution of the analysis (section 5.2).

5.1 The results of the comparative analysis

Figure 5.1: Comparison of programming environments. * Depending on the selected editor, the possibility of
installing this module **

39
40 CHAPTER 5. CONCLUSION

Comparative analysis went smoothly, thanks to the environment that have been learned from the side of the

implement. We managed to get the results characterizing each of the environments. The results of the

comparison are presented in the table in Figure 5.1.

The main differences between the environments:

• ROBOTC environments Matlab and you do not have con fi gurować before the start of the first

projects. In contrast, only ev3dev environment allows the number of modules to extend functionality of

the program.

• ROBOTC Matlab and have integrated editors, which are known from standard integrated development

environment features, such as syntax coloring code, and automatic replenishment expressions. In

addition, a very useful advantage is the browser of all library functions, which is available only in the

ROBOTC. Ev3dev does not have a dedicated editor. While you can use any editor that supports the

languages ​used by ev3dev. Picking your own editor requires self-con fi guration, install compilers and

skrośnych doinstalowywania needed extensions. Despite the effort required by the con fi guration, the

effect can match ROBOTC editors and Matlab environments. Another advantage is distinctive ev3dev

open the source code of the project.

• In the case of testing and debugging environment ROBOTC and offer built-in Matlab, all the standard

tools needed for these processes. Ev3dev while the standard does not have such tools, however, it is

possible to install additional tools that you can find on the net.

• Integrated compiler can boast ROBOTC and Matlab but in the case of the second binary code is never

entirely sent to the robot, which stems from the work environment in the form of a remote controller.

ROBOTC ev3dev and also allow operation mode remote control as standard, however, the compiled

program is sent to the device. Another advantage ev3dev environment is the ability to build a program

directly on the robot. This allows you to carry out the whole process of implementation of the program,

by means of a device enabling remote access to the robot without using a computer. This mode is

convenient only for very small programs.

5.2. CONCLUSIONS 41

• All environment for stable communication with a USB cable, and wireless standards using Bluetooth

and Wi-Fi. However, in an environment ev3dev it requires manual con fi guration such a connection,

while other programs have a convenient integrated communication modules.

• Distinguishing features of each environment are: Opportunities analysis and presentation of data in

Matlab. It is also possible to create a virtual model of the robot and testing program, cooperating with

Simulink [7]. ROBOTC ev3dev support and connection to the robot NIEO fi cial components. In

ev3dev it is possible to write your own drivers, which opens the way to connect the components of

copyright. Ev3dev distinctive advantage of the system is the ability to choose from a variety of

programming languages.

5.2 Conclusions

Applications are to form the characteristics of the most suitable projects for specific environments. In the

following subsections are requests for environments ROBOTC (subsection 5.2.1), ev3dev (subsection 5.2.2)

and Matlab (subsection 5.2.3). At the end there is a general request (subsection 5.2.4).

5.2.1 Characteristics of the projects for the environment ROBOTC

ROBOTC environment is the most versatile among the analyzed programs. Features such as automatic

con fi guration, gathering all the necessary tools in one program, integrated compiler, debugger and a

communication module, included with the browser function library and documentation, testify to the fact that

the environment is ideal for both small and very large projects. The disadvantages of the environment are

closed source code, and the lack of choice of programming languages. The most recommended for young

people, in particular school and university classes.

5.2.2 Characteristics of the projects for the environment ev3dev

Ev3dev is a system whose major advantages are a broad spectrum of available programming languages,

and unlimited opportunities to develop the program.

42 CHAPTER 5. CONCLUSION

Open source code allows you to attach your own extensions system, using any NIEO fi cial components, and

adjusting the project exactly to your needs. One major advantage is the ability to write programs from virtually

any platform, including mobile operating systems. Biggest flaw of the system - the lack of an integrated editor,

is also a great advantage. The disadvantage is the lack of need for an independent editor and complicated

con fi guration of the system, which in the case of a multi-user platforms Lego Ev3, especially the youngest

may be an insurmountable barrier. However, for demanding developers expecting the lack of imposed

restrictions is a huge advantage. That's why it experienced developers, this system is the most

recommended, for small and large projects.

5.2.3 Characteristics of the projects for Matlab

Matlab environment in terms of the creation of software robots is the most limited. The biggest

advantages of the program is to present data and results in the form of charts, creating mathematical models,

using complex mathematical operations, simulate and program the robot in Simulink. Matlab is recommended

for projects, some of which robotics is limited to a minimum, while the main focus is to collect data and

analyze the behavior of the robot. In simpler words the best designs are made with a very simple function with

few active elements, where the issue is examined precision robot optimality algorithms, robot behavior and

compliance with its virtual model.

5.2.4 Overall conclusion

As part of the work robot it was built of solid construction, whose task is to lay Rubik's Cube. For this

work written two programs were written in two different development environments. It has also attempted to

write a program in Matlab, but the limited extension of the technology Lego Mindstorms decided to exclude

from the Matlab implementation phase. Both programs written in environments ROBOTC ev3dev and meet all

the assumptions set out in section 3.2. Robot test in most cases when you start any of the two
5.2. CONCLUSIONS 43

programs properly arranged mingled Kostka. Failed attempts result only from the impact of external lighting,

which causes the error when scanning the colors red and yellow. At any other stage of the robot out of phase

scanning without problems. Creating a robot, however, it was only part of this paper. An important issue was

to test environments. This analysis was successful, they have been formulated positive and negative

characteristics of each of the environments. They were juxtaposed in a comparative table, and in the end

were presented pro fi le projects that best fit each environment. Therefore it can be concluded that the work

proceeded according to plan, and the results are satisfactory.

44 CHAPTER 5. CONCLUSION
And bibliographical

[1] da Vinci surgical robot - article. http://www.asimo.pl/modele/

davinci.php.

[2] Robotics underwater - article. http://yadda.icm.edu.pl/yadda/element/

bwmeta1.element.baztech-article-BSW1-0109-0006 / c / Gieldzinski.pdf.

[3] Robotyka.com: Theory robotics. http://www.robotyka.com/teoria.php/

teoria.4.

[4] Secure Shell - wikipedia English.

[5] Home addition LEGO Mindstorms EV3 Support Package. http:

//www.mathworks.com/hardware-support/lego-mindstorms-ev3-matlab. html.

[6] Home Mini Urban Challenge competition. http: // www.

robotvirtualworlds.com/mini-urban-challenge/?_ga=1.160675512.

469,940,421.1427281178.

[7] Home Simulink product. http://www.mathworks.com/products/

Simulink /.

[8] Home Mindcub3r project. http://mindcuber.com/index.html.

[9] Home project of NASA Curiosity Rover. https://www.nasa.gov/

mission_pages / msl / index.html.

[10] Board Internet product LEGO Mindstorms EV3 Education Expansion Set.

https://education.lego.com/en-us/products/

Lego-mindstorms-education-ev3-expansion-set / 45560.

[11] Introduction to Robotics - Lecture 1. http://elka.pw/obieralne/wr/wyk/WR_cz1.

pdf.

45
46 BIBLIOGRAPHY

[12] The integrated development environment - Definition of de wikipedia. https: // en.

wikipedia.org/wiki/Zintegrowane_środowisko_programistyczne.