learning to program in k12 using a remote controlled robot: roboblock · fig. 2. ardublock . fig....

adfa, p. 1, 2011.

© Springer-Verlag Berlin Heidelberg 2011

Learning to program in K12 using a remote controlled

robot: RoboBlock

Javier García-Zubía*, Ignacio Angulo*, Gabriel Martínez-Pieper, Pablo Orduña, Luis

Rodríguez-Gil, Unai Hernandez-Jayo

University of Deusto, Department of Industrial Technologies

Avenida de las Universidades 24, 48007, Bilbao- Spain

{zubia, ignacio.angulo, gabi.martinez, pablo.orduna,

luis.rodriguezgil, unai.hernandez}@deusto.es

Abstract. Programming is part of the curricula in different subjects and coun-

tries. To face this challenge, schools are using visual programming (e.g.,

Scratch, Blockly) and/or educational robots. Some combinations of these two

tools are very popular, such as the Lego Mindstorm robots. This work presents

a remote controlled robot called RoboBlock, and its main characteristic is that it

can be programmed and controlled via Internet. RoboBlock is developed under

the WebLab-Deusto Remote Laboratory Management System.

Keywords: Remote experimentation, educational robotics, K12 education

1 Introduction

The promotion of STEM among the young people is one of the objectives of different

countries and institutions like EU. To increase the interest of the young people to

science, engineering and technology the schools are including subjects that combine

programming and robotics [1, 2]. The main effect of these initiatives is in K12.

In general, the teachers in the classrooms have to deal with different problems.

Firstly, they need financial resources to buy several robots. Secondly, they have to

maintain them in perfect conditions (even after being used by students). These two

issues reduce the time that they have to teach the students how to program. It is excit-

ing for the students to program and control real robots, but at the same time it is frus-

trating for the students to see that their robot is not running properly but the robot of

other group is running well, with the same program!! At the same time the teacher has

to manage this situation, and he could also be frustrated or he could be very busy

reviewing the boards, the sensors, etc. This problem is especially remarkable at the

beginning of the learning process because the students have more problems with the

equipment and with the programming language. The learning curve is in Fig. 1.

REV2017 – 14th International Conference on Remote Engineering and Virtual Instrumentation15-17 March 2017, Columbia University, New York, USA

Page 264

Fig. 1. Typical learning curve

At the same time, and at least in Spain, robotics use to be taught in the Technology

subject and the associated teacher does not use to be a computer or electronics engi-

neer. The common situation is that the Science teacher must to teach program-

ming/robotics because he needs to fill his timetable. Currently it is not common to

have a specific teacher for technology and programming.

To solve this situation or at least to help teachers and institutions to manage this

situation a robot can be designed and used as a remote experiment. RoboBlock will

help the community to solve these problems using a web tool to complete all the

teaching process. There are several remote laboratories offering robots around the

world but not with the same characteristics that RoboBlock [3, 4].

2 RoboBlock general characteristics

A remote laboratory allows the user/student to experiment using the Internet as his

eyes and hands. Instead of using the hands to manipulate the equipment and instead of

using the eyes to see the evolution of the experiment, the user will use the Internet. To

make an experiment the user only needs an Internet connection, so he can experiment

everywhere and every time he has an Internet connection.

To deploy a remote laboratory into a K12 classroom there are some requirements

[5]:

Universality: the remote laboratory can be accessed using any OS and any web

browser.

Device: the remote laboratory can be accessed using any kind of device, including

tablets and smartphones [6].

Security: the remote laboratory cannot affect the IT security of the school, so it is

based only in standard ports (80, …) and without problems with firewalls.

LMS: the remote laboratory can be connected to the LMS of the school.

Queue: the remote laboratory manages the users’ queue.


65

If the previous requirements are not fulfilled by the remote laboratory, then it could

not be implemented successfully in the classroom. RoboBlock fulfills these technical

requirements. But there are also some functional requirements.

The typical scenario with a robot in a remote laboratory is [7]:

Phase 1. The student writes the code in his computer/tablet, he compiles it (maybe

he simulates the code now)

Phase 2. The student accesses the remote lab with his user/pass, maybe he has to

wait in a queue.

Phase 3. The student downloads the software in written in phase 1 into the robot.

Phase 4. The robot starts to execute the downloaded program: it follows the line, it

avoids the obstacles, it fights against another robot, etc.

Phase 5. The student sees the evolution of the robot to decide if the program is

correct or not. If it is not, the student must go back to phase 1.

The code can be written in C, python, scratch, Blockly, etc. The language depends

on the teacher and in the level of the students. For K12 students it seems to be clear

that it is better to use graphical software like scratch or Blockly. The first two phases

are placed in the student’s computer/tablet, and the last three phases are placed in the

remote laboratory.

So to program the robot, the student needs to have his own computer with the pro-

gramming environment, IDE, installed (like SDK, KEIL, EV3, etc.), and because of

this to perform a task, the student needs his computer or a computer with the same

software installed. This is not a problem when the student is performing his tasks in

the school, but maybe is a problem when the student is at home.

The purposed solution by RoboBlock is to integrate the robot, the programming

environment and the remote laboratory in a unique web. Under the RoboBlock ap-

proach, the student to perform the experience only needs a computer/tablet (any com-

puter) connected to Internet. This characteristic promotes the use of the remote exper-

iment everywhere and every time. RoboBlock portal has two parts:

ArduBlock. In this part of the portal, the student draws/writes the program using

blocks, or even he can write the code directly in C. When the student obtains the

program using Blockly, at the same time he can automatically see the correspond-

ing code in C.

Zumoline. In this part of the portal, the student downloads the code written in Ar-

duBlock to the see the evolution of the robot in real time.


Page 266

Fig. 2. ArduBlock

Fig. 3. ArduLab

3 Functional description of RoboBlock

In the previous section, RoboBlock has been described in general terms, and this

section is devoted to describe what can be done with RoboBlock and how it can be

done.

Universality, security, etc. are key factors of any IT learning tool in the school, but

they are not important for the teacher if the tool is not powerful enough. RoboBlock

can be explained using the programming blocks and to the programs themselves.


Page 267

3.1 Programming blocks of RoboBlock

RoboBlock programming tool is based in Blockly (developed by Google as part of

Google for Education) and the blocks are divided in four main groups:

Logic. It contains logic, mathematics and loops.

Data. It contains variables and functions.

Input/Output. It contains sensors, leds, motors, etc.

Miscellaneous. It contains time functions, communications, etc.

Fig. 4. Main functions of ArduBlock

In a first group (see Fig. 5), in Loops the student can select blocks to implement:

loop, while, count and break. In the Logic area the available blocks are: if, numerical

comparison, logical comparison and other blocks. In the Mathematics area we can

find: arithmetical operations (basic and advanced), constants, and other functions.

There is a block for timing functions: wait, measure, etc. There are other blocks for

text, communications, etc.

For programming RoboBlock, it is important to have powerful blocks for sensor-

ing. It is important to read from sensors the current situation of the robot, and it is

important to write in the actuators to modify the situation of the robot, everything in

real time. There are three proximity sensors placed in the center of the robot, in the

right side and in the left side, but also every sensor has two parts: left and right; by

this way the control of RoboBlock can be very accurate. The same situation occurs

with line detector sensor: there is one sensor in the center of RoboBlock but it reads

five signals. RoboBlock has also three buttons to perform different tasks, in this case

the programmer can scan the buttons to read pulses and levels.

The student can also control RoboBlock using the actuators of the two motors, left

and right. Each motor has an associated speed from 0 to 100.


Page 268

This is the current state of RoboBlock, but additional sensors or actuators can be

added to it, and in this case new programming blocks should be added. The design of

web programming tool, ArdulabBlockly, is intended to allow its modification easily

to promote the adaptation of RoboBlock to each scenario in different schools and

events.

Fig. 5. Sensors, buttons and motors in RoboBlock

Fig. 6. Blocks for programming of RoboBlock: loops, time, and numerical and logical func-

tions,


Page 269

3.2 Programming RoboBlock

To write the program, the student should drag and drop some specific blocks to

combine them in a graphical structure. This structure is the algorithm that will be

downloaded in RoboBlock. Fig. 7 shows in the center the graphical algorithm that

moves RoboBlock during 2 seconds (2000 milliseconds), and in the right side, the

corresponding program in C can be seen.

Fig. 7. ArduLab-Blockly programming environment.

The student, after writing/drawing the code, can validate his code clicking on Vali-

date (Validar) to see if there is any problem with his program. After doing this, the

student will open the Zumoline environment to download his program in RoboBlock.

Zumoline knows what is the last program validated by the user (called blocks), and

this program will be downloaded in RoboBlock. The student can also access and test

to a variety of running examples.

RoboBlock is designed to develop the basic programming skills using a robot. The

student can create programs combining basic blocks like loop, if-then-else, assigna-

tion, read, write, etc. It is up to the teacher to decide the complexity level of the pro-

grams focusing to the curricula of the subject.


Page 270

Fig. 8. Zumoline environment

For example, the program in Fig. 9 controls the robot increasing its speed one by

one from 0 to 50 every 10 milliseconds. In this case the student practice the for struc-

ture using the robot to see the effect of it.

Fig. 9. Example of RoboBlock program

In Fig. 10 the algorithm shows the student how to use the if structure. RoboBlock

will go faster (one by one, from 0 to 50 every 10 milliseconds) until detecting a line in

the floor using the sensor.


Page 271

Fig. 10. Example of RoboBlock program

As final project the teacher can purpose the students a competition like “Win in a

Formula one circuit”. The circuit made with plastic in Fig. 11 is a copy of the Mont-

melo Circuit in Spain, and the students should write the best program to obtain the

lowest time to tour the circuit.

Fig. 11. Montmelo Circuit with RoboBlock


Page 272

Every time the student writes a new program, he can test it in the remote laborato-

ry, in RoboBlock. At this moment to download the code it is needed to open a new tab

in the web browser, the Zumoline environment. When a student accesses to Zumoline

he has 5 minutes (it can be increased) to select his program, download it in RoboB-

lock and see the evolution of the robot. After this, maybe he can modify the program

to be just a bit faster in the competition. In Fig. 12 there is a simple program to win in

Momtmelo that the student can improve adding a better control.

Fig. 12. Montmelo Circuit program

3.3 Technical description of RoboBlock

The development of the laboratory can be divided into three stages. Firstly, a Python

module performs remotely the compilation of source files to generate the binary files

to be loaded into the program memory of the microcontroller. Secondly, a program-

ming environment has been developed to capture algorithms with Blocky. Finally, a

system has been developed that allows the programming of the mobile robot and the

interaction with its inputs, so that these can be accessed remotely.

3.3.1 Cloud compiler

Main objective of this laboratory is to provide the students a full development studio

without installing requiring any specific software, farther the Internet browser. To this

end, the back-end provides all required tools to compile the project source files and

store the binary files, that will be accessed later.

Developed module has been developed in Python and makes use of the "InoTools"

tools [8]. This toolkit allows you to compile Arduino projects from the command line

so it can be easily integrated into any third-party development environment such as

those presented in this project.


Page 273

The developed module performs the cloud compilation service and manages com-

pilation queues. Using this system only one simultaneous compilation can be per-

formed. Since the compilation of a project is performed in a matter of seconds, the

"Celery" software tool [9] has been used to add a queue system to the compiler and

ensure that the compilations are sequentially.

3.3.2 Development environment

The development environment is based on the Ardublockly tool [10]. Ardublockly is

a bifurcation of Google's Blockly project, a set of tools that allow you to generate

source code in various programming languages from interlocking block strings. It has

natively generators of code for Javascript, Python, PHP and Dart. It also includes

basic blocks like loops, conditionals, arithmetic operations, operations on strings, etc.

Blockly has tools for developers to implement new blocks and code generators. In this

way, Ardublockly extends Blockly by adding a code generator for Arduino and blocks

for the control of digital inputs / outputs, serial communications or timers.

For the development of this remote laboratory, Ardublockly has been extended to add

the necessary blocks to carry out the reading of the sensors and the control of the

actuators of the robotic platform.

This development environment eliminates the possibility of compile errors. Panels

have not been added to show the results of the compilation. Instead, the validate but-

ton changes color when the compilation is complete.In this case, when the validation

control is pressed, the code generated by Ardublockly is downloaded and a file is

generated in the basic project with the downloaded content. At the end of the compila-

tion, the binary is stored in a directory associated with the author of the program.

3.3.3 Robot interaction

To perform the communications between the robot and the client, the Open Source

Socketio tool has been used. Socketio is a library that allows bidirectional communi-

cations and low latencies. This library uses a protocol that allows to switch between

Websockets and longpolling based on the compatibility with these technologies of the

client browser [11].

When the client has a browser compatible with the WebSockets technology, makes

use of this technology, so that the communications are realized bidirectional and in

real time. In contrast, if the user accesses with an unsupported browser, the client

performs longpolling simulating bidirectional communication. This feature provides

universality to the laboratory since, in this way, the application works on all devices

without the need to install plugins or perform communications through specific ports.

To perform this task, the official socket.io library was used in the web client and

the Flask-Socketio library on the robot.


Page 274

3.4 The robotic platform

The robotic platform consists on the Zumo 32u4 Pololu robot and a low-cost em-

bedded system that allows remote programming the microcontroller and interact with

the inputs and outputs of the Pololu platform.

The main element of the experimentation platform is Pololu Zumo robot 32u4.

This robot is based on the microcontroller compatible with Arduino Atmega32u4. It

includes the following electronic and mechanical components.

Electronic components:

4 wide-angle infrared sensors

2 DC motors

2 encoders

5 line sensors matrix

3-axis Gyroscope

3-Axis Accelerometer

Magnetometer

Buzzer

Bootloader

Chassis:

4 sprockets

2 tires for crawler type wheels

Main Chassis

Metal shovel

Raspberry Pi embedded platform has been used to develop the controller. This de-

vice connects to the robotic platform performing the following functions:

Bootloader activation

Programming the robot

Access to serial communication port

Activation of buttons remotely

Reading the status of the outputs

The Zumo robot 32u4 includes several expansion ports that allow to replace the

sensors and actuators of which it has natively by others. In this case, this expansion

port has been used to connect certain outputs of the Raspberry Pi in it. Since the con-

nections are made directly, it has not been necessary to develop an extra electronic

circuit.

At the software level, an object has been implemented that contains the methods

necessary to perform the actions listed above. These methods have been developed in

Python language and are invoked directly from the web application. The methods

included in the driver are as follows:


Page 275

ledChecker (): This routine continually checks the status of the microcon-

troller outputs that activate/deactivate the robot LEDs.

startLedChecker (): Method to start the status check routine of the LEDs.

stopLedChecker (): Method to finalize the status check routine of the

LEDs.

startSerial (): Method to initialize the serial port.

connectSerial (): Opens the serial port and starts the serialTask () routine.

serialTask (): This routine checks if data has been received by the serial

port and transmits it to the connected client.

sendSerial (message): This method is invoked when the client sends data

through the serial port to the robot.

enableBootloader (): This method is used to activate the bootloader and

load a program.

eraseMemory (): This method erases the entire program memory of the

microcontroller.

loadBinary (path): This method is used to load a binary on the robot. It is

necessary to mark the path of the binary as a parameter.

buttonOn (button): This method activates any physical button on the ro-

bot remotely.

buttonOff (button): This method disables any physical button on the robot

remotely.

4 RoboBlock in WebLab-Deusto and Labsland

RoboBLock is included in the WebLab-Deusto RLMS (Remote Management La-

boratory System) to take the advantages of using this powerful tool:

Groups and Access. If a school wants to use RoboBlock, WebLab-Deusto will

create a group and the students will access to the robot using the same credentials

that they are using at their school, so no new user/pass are needed for the students.

Also RoboBlock can be accessed through Moodle, Google Classroom, etc. Even, if

the school is interested, WebLab-Deusto can create a personalized web portal for it

(see Fig. 13 to see the WebLab-Deusto portal for the Urdaneta School in Bilbao,

Spain).

Queues. At this moment there is only one copy of RoboBlock, so if a student wants

to access the RoboBlock but it is being used by other student, the first student must

be in a queue until RoboBlock is released. If there are several schools using Ro-

boBlock more situations like this can happen. WebLab-Deusto manages the queue

and can assign different priorities to each school or student, or maybe the teacher

will have a higher priority than the students to grant him to access the robot in a

short time.

Learning analytics. WebLab-Deusto tracks all the activity of the student, so the

teacher can see for every student how many times and when he entered the plat-

form. Even more WebLab-Deusto records the files that the student downloaded


Page 276

during the semester. An additional tool allows the teacher to see if there are files

copied among the students.

Scalability and load balance. If there was different copies of the RoboBlock, Web-

Lab-Deusto would manage the situation sharing the effort among the different cop-

ies of the robot.

Federation. A school can implement a copy of RoboBlock in its building, and in

this case it can be federated in WebLab-Deusto. In this situation, instead of having

only one copy of RoboBlock, we will have two copies. The federation mechanism

implemented in WebLab-Deusto allows the school to fix the conditionsof use of its

own RoboBlock, and even the school can earn some money from this federation.

Fig. 13. WebLab-Deusto Urdaneta School.

5 Conclusions and future work

RoboBlock is designed and implemented to help the schools and teachers to teach

programming and robotics to K12 students. This tool will help to promote STEM

among young students.

RoboBlock is a remote experiment and it can be controlled remotely in ZumoLine

by the student using the algorithm written by him in ArduBlocks using a graphical

tool based in Blockly. All the tasks are performed in the web, so if the student has an

Internet connection he can complete his practical activity using any computer in any

place at every time. RoboBlock is a novelty in the K12 scope.

The design of RoboBlock has been recently finished and it has been deeply tested,

and it is time to implement it in several schools in a pilot. The results of the pilot will

help the designers to improve the original design of RoboBlock.


Page 277

6 Bibliography

[1] Roscoe, J. F., Fearn, S., y Posey, E. (2014) Teaching Computational Thinking

by Playing Games and Building Robots, Int. Conf. Interactive Technologies and

Games (iTAG), pp. 9-12.

[2] Merrill, M. D. (2002) First principles of instruction. Educational Technology

Research and Development, Vol. 50 (3), pp. 43–59.

[3] Islamgozhayev, T. U. et al. (2015) IICT-bot: Educational robotic platform us-

ing omni-directional wheels with open source code and architecture, Int. Siberian

Conf. Control and Communications (SIBCON), pp. 1-3.

[4] Antonio, C. P. et al. (2015) Remote experiments and 3D virtual world in educa-

tion. 3rd Experiment@, Int. Conf., exp’at 2015, pp. 65-70.

[5] García-Zubía, J.; Orduña, P.; López-de-Ipiña, D.; Alves G. (2009) Addressing

Software Impact in the Design of Better Remote Labs. IEEE Transactions on Indus-

trial Electronics, VOL 56, Nº12 4757-4767.

[6] García-Zubía, J.; López-de-Ipiña, D.; Orduña, P. (2008) Mobile devices and

remote labs in engineering education. 8th IEEE International Conference on Ad-

vanced Learning Technologies, Proc. ICALT 2008, pp:620-622.

[7] Guimaraes, E.;Cardozo, E.; Moraes, D.; and Coelho, P. (2011). Design and Im-

plementation Issues for Modern Remote Laboratories. IEEE Trans. On Learning

Technologies Vol. 4, No. 2, pp:149-161.

[8] J. Sarik and I. Kymissis. (2010) Lab kits using the Arduino prototyping plat-

form, 2010 IEEE Frontiers in Education Conference, FIE 2010, Washington, DC,

2010, pp. T3C-1-T3C-5.

[9] I. Woodring and M. El-Said. (2014) An Economical Cluster Based System for

Detecting Data Leakage from BYOD, 2014 11th International Conference on Infor-

mation Technology: New Generations, Las Vegas, NV, 2014, pp. 610-611.

[10] C. Perate, Ardublockly. (2016) https://github.com/carlosperate/ardublockly

[11] V. Pimentel and B. G. Nickerson. (2012) Communicating and Displaying Re-

al-Time Data with WebSocket, in IEEE Internet Computing, vol. 16, no. 4, pp. 45-53,

July-Aug. 2012.


Page 278

https://github.com/carlosperate/ardublockly

learning to program in k12 using a remote controlled robot: roboblock · fig. 2. ardublock . fig....

Documents