Reflections on Using Robots and Visual Programming Environments for Project-Based Teaching

1Abstract—Visual programming languages provide a more natural approach to specifying software/hardware systems with complex behaviour such as robots. They are especially important in education because they do not require formal knowledge of programming language syntax and are attractive to users. We present an analysis and comparison of two visual programming environments, Lego NXT-G and Microsoft Visual Programming Language, based on the cognitive and usability requirements, evaluate their application in roboticsbased Computer Science education, identify main problems and propose solutions for using visual programming languages in the Internet-of-Things domain.

Visual programming is a method to specify a program in a two (or more) dimensional fashion [4], whereas in a textual language a programmer writes and a compiler or interpreter processes a program as a one-dimensional stream of symbols.Visual programming language uses meaningful graphic representation and manipulates visual information or supports visual interaction [5] in the process of programming.Visual elements based on imagery thinking provide a more natural approach for specifying a program than textual languages and the 2D representation is more suitable for representing parallel behaviour of complex systems consisting of multiple components such as robots.Visual languages are especially important in education, because their do not require formal knowledge of programming language syntax, are visually appealing and attractive to their users, and can be combined with additional engagement-enhancing concepts such as gamification [6].
The Cognitive Dimensions introduced by Green and Petre [7] provide a framework for assessment of a programming system as follows: Closeness of mapping (closeness of programming structures to problem domain), Consistency (similar semantics are expressed in similar forms to allow inference), Error-proneness (possibility of making mistakes because of poor notational design), Hard mental operations (thought processes required to formulate an expression made difficult by the notation), Hidden Dependencies (important relationships between entities are not visible), Progressive evaluation (ability to execute the program partially, before all of it is put together), Role-expressiveness (purpose and role of each component is easily inferred), Secondary Other comparison criteria have been formulated by Howard [8]: Intended audience, Paradigm, Ease of use, Visual representation, Reusability, Data structures and types, Effective use of screen area, Effective use of colours, Clarity of graphical symbols, Interactive capabilities.
Next we analyse a subset of visual languages used in educational setting for teaching robot programming.

A. Microsoft Visual Programming Language
Microsoft Visual Programming Language (MVPL) is a part of Microsoft Robotics Developer Studio (MRDS).MVPL is a robotics-oriented data flow language that generates code to execute robotics programs with MRDS.In MRDS, every action is performed by a service, a basic building blocks that controls a particular software or hardware entity.Each service expresses an isolated behaviour that is defined independently and can interact with other services.MVPL provides 10 general-purpose building blocks, called basic activities (Fig. 1(a)) and many various application (or robot) specific blocks as well as blocks used to simulate hardware, called services (Fig. 1(b)).Some blocks have additional parameters that can be configured.The example program in Fig. 2 is written for the LEGO NXT robot to use ultrasonic sensor for collision avoidance while driving.The NxtUltrasonicSensor block sends the sonar data every time it gets a reading.The If block then activates one of three execution branches.The first branch is activated when the robot is really close to an obstacle; then, the Data block sends a defined rotation value to the NxtDrive block, which controls the robots driving motors.The robot is instructed to turn left 45 degrees.The second branch is activated when the obstacle is in mid-range.Two defined drive power values (0.3 left and 0.6 for right wheel) are joined to a named list by the Join block and sent to the NxtDrive block, forcing the robot to turn moderately left.The last branch is active when there is no obstacle detected, and the same drive power is applied to both wheels, forcing the robot to go ahead.Different types of control data can be sent to the same NxtDrive block.This is achieved by configuring the data connection.The NxtBrick block is not connected, but it is necessary in order to configure the NXT robot.
MVPL is simple enough even for a novice user to get started quickly, however, it has enough functionality to construct complex programs.Large number of additional services makes it possible to control many types of robots.
Modelling capabilities make it easy to experiment even without having a real robot.However, the dataflow concept can make it harder to move to the sequential languages (like C++ or Java), which are de facto standard for programming.

B. Lego Mindstorms NXT
NXT-G is a visual programming language and environment developed by Lego for Lego Mindstorms NXT robotics kit.The language is aimed at children as well as adults with no programming background.The language is block-based: each physical Lego block contains hidden digital implementation, and can be chained together to perform a sequence of behaviours.Sensor blocks receive inputs from outside world and send data to other blocks [9].
NXT-G blocks (Fig. 3) are of six categories: a) Commonaction Move and other commonly used blocks from other groups; b) Action -general robot control actions such as Motor control, Sound or Display; c) Sensor -blocks that allow to control and get data from the sensors; d) Flowflow control blocks such as Wait or Loop; e) Data -blocks that allow to define variables and perform mathematical or logical operations with them; f) Advanced -additional action blocks like File access.Each block can be additionally configured using a simple Configuration menu (see Fig. 4).  Figure 5 shows a program which implements the same robot control algorithm using a supersonic sensor as in Fig. 2 The main difference from MVPL is that all blocks in the diagram are invoked sequentially and there are flow control blocks such as Loop (similar to looping statement in textual languages).The program in Fig. 5 has one infinite Loop block which contains the remaining functionality.
Inside the Loop block, there is a Switch block, which can be tied to a selected sensor (supersonic sensor in this example), reads and compares the data from that sensor to a defined value, selects one of two branches according to the result.As the Switch block only allows one comparison, two nested blocks are required in order to define three branches similar to Fig. 2. The Move blocks control the drive powers of two motors for steering the two-wheeled robot.As NXT-G is aimed specifically at programming the Lego NXT robot, most of the blocks have a clearly defined functionality which directly translates to concrete actions of the robot which can be visually observed.This makes programming straight-forward as compared to more abstract MVPL, and more suited to novice users.The sequential execution and flow control of NXT-G is closer to traditional text programming languages than MVPL and could make it easier to move to mainstream programming.
The disadvantage of NXT-G is its overtly iconographic representation: NXT-G displays the numerical or logical values of the blocks by icons or hides them altogether.To see concrete values one has to click each block and open the configuration window.While this might be more visually appealing to intended users, it is harder to make sense of larger programs with many defined values.Other disadvantages are the representation of the FOR loop and poor usability of some block icons.

C. Evaluation
The evaluation of MVPL and NXT-G is summarized in Table I.Qualitative criteria are evaluated using the 4-level measurement scale (none, weak, fair, strong).

III. VISUAL PROGRAMMING IN ROBOTICS PROJECTS
The use of visual programming languages was explored during laboratory works of "Robot Programming Technologies", a course delivered at KTU Faculty of Informatics to 4th year bachelor students.
The course was attended by 34 students.Course aims to teach students of the basic principles of robot control and robot programming.The main concepts to learn are state (property of the robot), action/reaction (change of the state of the robot due to external or internal factors), behaviour (specific sequence of actions aimed to achieve a pre-set objective), decision (ability to undertake a specific sequence of actions from a set of alternatives), autonomity (ability to independently), communication (ability to send/receive messages from external devices).Fair.Symbols are simple and easy to understand.Basic functions of blocks are indicated by text.

Closeness of mapping
Strong.Most language blocks map directly to concrete capabilities of the NXT robot.
Fair.Many services map directly to concrete capabilities of different robots, however, basic activities are abstract.

Consistency
Strong.Blocks from the same group are used consistently Weak.Similar services for different robots can be used very differently.

Error-proneness
Strong.The simplicity of the language doesn't allow for many slips.
Fair.Mostly textual data and parameters representation can cause typos.

Hard mental operations
Fair.Programing is mostly straight forward; however, more complex programs can be a challenge.
Fair.Although there are more abstract blocks, it can make programing complex operations easier.

Hidden Dependencies
Strong.Dependencies in lower levels are made obvious by icons in the highest level.
Weak.The functionality and inner dependencies of most of the services is not immediately obvious.

Progressive evaluation
Fair.Created programs can be encapsulated in special block and reused later.
Fair.Created programs can be encapsulated in special block and reused later.

Role-expressiveness
Strong.Roles of most of the blocks are obvious.
Fair.Basic activities are abstract.Many services express concrete roles.

Secondary notation
Fair.Variables can be named; much of extra information is represented by icons.Comments can be written in program window.
Fair.Expressed mostly in text; however, this can make complex programs more understandable than in NXT-G.
The robot hardware used during lab works included two LEGO NXT robots with NXT Intelligent Brick, a brickshaped computer (32-bit ARM7, 256 KB flash memory, 64 KB RAM, and secondary 8-bit AVR with 4 KB flash memory, 512 B RAM) with 100 × 64 pixel monochrome LCD display and 4 buttons to navigate a user interface.The Brick can control up to three motors and input from four sensors (light, sound, ultrasonic, touch) via RJ12 cables.The Brick also has built-in Bluetooth for transfer of programs and data.
The Arduino 4WD Mobile Platform provides a 4 wheel drive system with ATmega328 microcontroller board and 4 DC Motors.The platform can be connected to a computer with a USB cable or powered using the AC-to-DC adapter or battery.Control is implemented using the SSC-32 protocol.
The Lynxmotion 5LA Robotic Arm robotic arm has a rotational base joint, a vertical shoulder joint, a vertical elbow joint, a vertical wrist joint, a rotational wrist joint, and a two-fingered end-effector (gripper).The base can rotate 360° horizontally, while other joints can rotate 180°v ertically.The grip can do holding and putting action.The control is also implemented using the SSC-32 protocol.
The course takes a project-based approach to teaching robotics.The approach involves giving students a robot to assemble, adding sensors, and providing increasingly complex challenges.Students are left to work on their lab assignments in teams.Learning typically follows the following scenario: 1) A group of students are presented with a problem and learning materials required for solving it.
2) The students study learning materials and select/adopt appropriate solutions under the guidance of the teacher.3) The students construct, model and deploy a robot to empirically validate the solution.4) The students present their solution to other students and the teacher at workshop.For the final project of the course, the students had to arrange into groups of at least three persons and complete a project with a selected robot.The use of visual programming language was not enforced but highly recommended; groups could choose any language to program their robot.Projects completed in the course are summarised in Table II.The analysis of students' choice of language for their projects shows that 44 % of students have selected Lego NXT-G as compared to 26 % of students that have selected MVPL, and 30 % of students -the text-based language (Arduino C).

IV. CONCLUSIONS
Three main problems of visual programming languages were identified: scalability, readability and speed of input.
The scalability problem arises as with increasing program size, visual languages become less usable and face the socalled Deutsch Limit [10], which states that 'you can't have more than 50 visual primitives on the screen at the same time'.The solution of this problem requires more effective methods of using screen area (e.g., automatic layout) and going beyond the 2D representation to achieve more effective representation of program's structure without introducing unnecessary over-complexity.
The readability problem arises due to inherent parallelism in the robotics domain and complexity of input/output relations between blocks which lead to difficulties in under-standing a program.Many students found visual languages harder to read and understand than textual ones, especially for larger programs.However, this is not sufficient to conclude that visual languages are inherently harder to read than textual.The already formed habits of the students could have made them biased.The problem can be addressed by using colours and other graphical effects (e.g., animation) more effectively beyond simple separation between groups of blocks to represent different views of a program.
The speed of input for visual programming languages still remains below that of textual languages using the keyboard, which may be a reason why professional programmers prefer text-based languages.The problem could be addressed by introducing more design automation and raising the level of abstraction above simple structures of structural programming (such as loops) to the idiom or pattern level.
The graphical representation of building blocks in MVPL and NXT-G is different.MVPL has minimalist design, with plain blocks and textual configuration parameters.NTX-G is colourful and represents almost all additional parameters by icons.This presents problems for both: MVPL is less visually appealing and friendly to novice users, while NXT-G might be considered both too difficult to understand and too childish to someone with programming experience.The NXT-G programs proved to be very large in real projects.Overall, students found programming with NXT-G more cumbersome than with textual programming languages (all students had previous programming experience).
Both MVPL and NXT-G examined in this paper lack identification and interaction capabilities which are needed to integrate a robot into the Internet of Things (IoT).They are aimed at controlling a single robot from a computer.To make these languages suitable for the IoT applications, other services providing robot identification, data exchange, interaction, and data sending to web services are needed.

TABLE I .
EVALUATION OF MVPL AND NXT-G LANGUAGES.
Effective use of screen areaWeak.Blocks can only be stacked horizontally and there are no scrollbars, so larger programs spread beyond the screen bounds Fair.Most of screen area can be used to build a program, blocks can be freely arranged and easily placed anywhere in the programming window Effective use of colours Fair.Colours are used to indicate blocks belonging to the same category.Fair.Colours are used to indicate blocks of similar or close functionality.Closeness of mapping Strong.A robot specific language.Fair.A multi-purpose language Clarity of graphical symbols Weak.Heavy use of icons makes it harder to immediately understand function of used blocks.

TABLE II .
SUMMARY OF ROBOTICS PROJECTS.