A programming environment having three levels of complexity for mobile robotics

This paper presents a programming environment for supporting learning in STEM, particularly mobile robotic learning. It was designed to maintain progressive learning for people with and without previous knowledge of programming and/or robotics. The environment was multi-platform and built with open source tools. Perception, mobility, communication, navigation and collaborative behaviour functionalities can be programmed for different mobile robots. A learner is able to programme robots using different programming languages and editor interfaces: graphic programming interface (basic level), XML-based meta-language (intermediate level) or ANSI C language (advanced level). The environment supports programme translation transparently into different languages for learners or explicitly on learners’ demand. Learners can access proposed challenges and learning interfaces by examples. The environment was designed to allow characteristics such as extensibility, adaptive interfaces, persistence and low software/hardware coupling. Functionality tests were performed to prove programming environment specifications. UV-BOT mobile robots were used in


Introduction
Despite economic crisis, job demand related to science, technology, engineering and mathematics (STEM) has been growing.For instance, in Washington DC, USA, increase in such labour supply was 11% between 2001 and 2011 (Koebler, 2011).It has been estimated that there were eight million STEM-related jobs in the USA in 2011.The European Union has bonded STEM-related jobs to its strategic plan concerning education level and as a motor for competitiveness, productivity and environmental sustainability (European Center for the Development of Vocational Training -CEDEFOP, 2010).The South Korean research institute KIST has implemented an educational programme for assisting learners using mobile robots (Sang-Rok, 2011).However, America and Europe have been hit by educational crisis in STEM-related fields; science, technology, engineering and mathematics are considered boring and very demanding.Moreover, the number of students has decreased in these professional fields (Ulloa, 2008).Mobile robotics has thus emerged as a popular concept for engaging learners in STEM-related fields, due to the fact that it has been shown to be a tool producing tangible results regarding how learners acquire new knowledge about technology and related abilities (Brauner, Leonhardt, Ziefle and Schroeder, 2010).Robotic seedbed experience in Cali, Colombia (Jimenez Jojoa, Caicedo Bravo and Bacca-Cortes, 2010) has corroborated a large increase in learners' motivation and therefore their results when children and young people built, programmed and tested a mobile robot for accomplishing a specific task involving concepts regarding sensors, actuators, programming and mainly a lot of hands-on tasks.
Teaching STEM concepts nowadays requires a shift in educational thinking and appropriate learning tools, such as programming interfaces which adapt in terms of complexity depending on a particular learning purpose (entertainment, education and/or research).
Table 1 gives the characteristics of several programming interfaces for mobile robots: SR1 (INTPLUS, 2011), Robolab (the LEGO Group, 2011), Mindstorms (the LEGO Group, 2012), BrickOS (Noga, 2004), leJOS (Solorzano, 2012), BotStudio (K-Team Corporation, 2011), Cricket Logo (Handyboard, 2009), Webots (Cyberbotics Ltd., 2012), ARIA (Adept MobileRobots, 2012) and Pekeel (Wany Robotics, 2012).These programming interfaces were selected based on criteria such as programming language, supported operating systems, required level of user expertise in robotics and software license type.However, based on Universidad del Valle and Valle Departmental Library robotic seedbed experience, programming environments typically used in education have a very short life-cycle, suddenly ceasing to provide possibilities of more experiences for children or young people (Gobernación del Valle del Cauca & Universidad del Valle, 2006).By contrast, programming interfaces orientated towards research are more complicated to handle for someone lacking prior knowledge of robotics, and they are designed for audience prepared in robotics.Table 1 gives programming environments interacting with mobile robots teaching concepts related to mobile robotics and STEM (Kammer et al., 2011;Brauner et al., 2010;Eggert, 2009); however, some handle a single learner level (Kammer et al., 2011;Brauner et al., 2010).The programming environment life-cycle thus becomes shortened and prevents learners achieving more advanced knowledge and skills.This paper proposes a programming environment involving three levels of complexity.It offered learners the opportunity to gain experience through a growing range of knowledge; the programming environment life-cycle thus became extended.This work dealt with mobile robotics because they represent a multidisciplinary field, promote teamwork and are an attractive field for developing scientific and technological knowledge.The three proposed programming environment levels were basic (for users lacking experience in robotics), intermediate (for users having previous robotics experience) and advanced (for users with previous knowledge in robotics).UV-bot mobile robots were used for testing, specifications being detailed in Gómez, Muñoz, Florian-Gaviria, Giraldo and Bacca-Cortes (2008).The proposed programming environment was multi-platform, developed with free software tools, extensible, had adaptable interfaces (Oppermann, Rashev and Kinshuk, 1997), persistence management and low software-hardware coupling (robot).

Design requirements
The programming environment proposed in this work was designed and implemented to offer users a continuous learning framework ranging from basic to advanced level and keeping software engineering complementary requirements in mind.The following sub-sections describe the firmware and programming environment requirements around eight cornerstones: mobility, perception, communications, programming and hands-on challenges (mobile robot) and usability, adaptability and data persistence (graphic user interface).

Basic complexity level
Mobility, perception, communications and programming functionalities include simple tasks at this level.However, they are focused on offering users overall knowledge of a robotic perception system and its actions regarding the environment.

Medium complexity level
Medium complexity includes basic level perception and mobility and allows users to deal with other concepts, such as 2D robot movement, distance-based and angle-based movements, communicating with other robots using IR modules and using arithmetic operations.

Advance complexity level
Basic and medium level requirements are used to build robot control architecture in the advanced complexity level, based on behaviour programming (Brooks, 1986).Sensor data are fed into perceptual schemas (Arkin, 1987); seven basic behaviours can be used individually or cooperatively in this work.A cooperative

Examples
Basic programmes for finding light or dark places, following objects and avoiding obstacles

GUI usability and adaptability
Showing programming blocks sorted by type XML schema to adapt the tool palette Zoom controls in the graphical programming editor (*) Editing many programmes simultaneously (*) Showing user challenges and programming examples with their corresponding explanation (*) Once an example is selected, its corresponding main programme is shown coordinator was used to coordinate behaviour response (Arkin, 1987).Actuator schemas were used to modify the robot's wheel speed, robot IR modules and buzzer.Table 4 shows this level's additional requirements.

Architecture
Programming environment architecture was based on the modelview-controller (MVC) design pattern.This pattern separated logic and data, user interface and control actions into three units (Crawford & Kaplan, 2003).Figure 1 shows the component diagram for the programming environment where grey modules were part of the model, dark grey modules were part of the view and blank modules were part of the controller.The design was modular and extensible; it involved a combination of code written in Java and XML languages.The final programme had to be written ANSI C to be compiled and downloaded to the robot.The environment was responsible for making a transparent translation of programmes when a learner used the graphical programming and XML programming modules.If a learner wished to view his/her programmes' translation code, the environment made it possible for beginners to the highest learning level.Successive actions regarding translation, compiling and programme download to the robot were performed, respectively by translation module, compiler module and communication with robot module.The persistence management module handled access to and creation and modification of stored data regarding configuration route, user data, programmes and challenges.The robot & interface configuration module provided views for selecting language and organising the tool palette according to the custom robot in use.XML schemes describe the structure and restrictions of XML documents having a high abstraction level, going beyond XML language syntactical norms (Fawcett, Ayers and Quin, 2012).XML schemes were joined to the environment architecture to support extension, adaptability, persistence and low coupling hardware / software regarding the programming environment.This programming environment had four XML schemes as its cornerstones.
Scheme for robot description (environment.xsd)This scheme represented the robot's initial configuration for basic level programming.It defined available variables and functions and the robot's mechanical description (number and type of sensors, engine number, power, etc.).A library of functions was extensible because multiple robot descriptions could be created and the objective of low coupling software / hardware was achieved.The interface configuration presented adapted forms of functions and graphical appearance of the blocks from the data types described for function parameters.Table 5 presents the characterisation of this scheme's elements, subelements and attributes.These elements defined the library of available functions in the graphical tool palette.Each function had attributes such as name, parameters, parameter data type and predefined parameter value These elements led to establishing a direct relation between input parameters and their graphical configuration

Graphic tool palette scheme (blocks.xsd)
This described all available functions on the graphic tool palette within the graphic programme environment.The user interface presented functions as graphic blocks.These blocks had the drag and drop interaction mechanism in the programming space.This scheme allowed personalising graphic elements by creating functional groups and setting colour, structure and input parameters.The tool palette was thus extensible.Table 6 presents the characterisation of this scheme's elements, sub-elements and attributes.These elements described each block group on the graphic tool palette.Blocks were separated according to functionality.Each block had attributes such as background colour, block type, name of represented function, Boolean attribute to identify whether the block was a conditional one, and block icon

Data persistence scheme (persistence.xsd)
This scheme represented programming environment persistent data.It described demographic user information.It also defined challenges and examples available in the programming environment.Furthermore, it stated a learners' performance regarding challenges and examples.Table 7 presents the characterisation of this scheme's elements, sub-elements and attributes.
Scheme for BOT-XML meta-language (meta-language.xsd)This scheme represented a programming meta-language called BOT-XML.Its meta-language was built for the programming environment middle level.BOT-XML was based on o: XML (Klang, 2007).BOT-XML had some simplifications for evaluating expressions calculating variable values.BOT-XML supported a greater number of data types than o:XML, such as int, distance, angle, direction, sensor, light, motor, speed, angular_speed, state, song, time, sensor_number.These elements defined challenges.Each challenge had a name, a unique identification, a short description, a long description, some hints for supporting learners during solution, a video showing the desired solution and a questionnaire for learners who finished a challenge <examples> <example> </ example > </ examples > These elements explained examples (a collection of selected pairs of programmes).Each example had a name, a summary, a complete description of the solution programme and the path of the programme file to be displayed in the programming environment <config> <config-path> </config-path> </config> These elements held environment commands and configuration file paths.Each command had identification, a name, a type and a text field with the path file Based on this scheme, learners' programming files were validated; programming files were thus saved in XML format.Translation took place at the end the programme to be downloaded to the mobile robot.
This scheme made it possible to build middle languages for each robot a user might want to use with the programming environment (i.e. the mechanism allowing extensibility and low coupling software/hardware).It also allowed the persistence definition for learner programmes.Table 8 presents this scheme's elements, sub-elements and attributes.

Results
Figure 2a shows basic GUI level programming and Figure 2b explains the challenge, involving the following tools: programming control flow blocks, graphical programming editor, zooming GUI controls, editor navigation GUI controls and programme editing tools (delete, add and programming block properties).
Figure 3a shows XML programming GUI where a XML editor was used.Using this XML programming GUI, the mobile robot could be programmed using BOT-XML metalanguage.The XML editor included a console for syntax error log and another console for compiling results and showing programme download status.
The ANSI C programming GUI is shown in Figure 3b.An ANSI C editor was used in this GUI and included the most common ANSI C editor tools, a console where the compiling results and download status were shown.It started with a code template in which users had to add the C main programme and enable or disable sensor events.
Users could start programming at any level (basic, medium, advanced), but medium and advanced levels had important advantages: deeper access to mobile robot functionalities (robot behaviour, sensor events and perception schemas) and being able to add custom utilities.
The tests were divided into two main parts.Translation between three programming languages was tested writing a programme using the graphical GUI; it was then transformed to its BOT-XML equivalent and translated to its ANSI C equivalent, downloaded and run on the mobile robot.A behaviour-based program was coded (available for the advanced level) to use and test all inherited functionalities from the basic and medium levels.was used to test translation between the three programming languages (this task is crucial in mobile robotics).Figure 4 shows the graphical code written using the basic level and its corresponding translation to BOT-XML language.The obstacle avoidance algorithm was pretty simple; it modified the left and right motor speed according to right or left contact sensor activation.

An obstacle avoidance application
Figure 4a shows three columns; the first is the main programme and the other show each sensor thread modifying the main programme's behaviour.
Considering the XML code shown in Figure 4b (basic programming level GUI) and the translation file called xml2c.xslt,defining translation instructions to ANSI C, Figure 5 shows examples of translation from BOT-XML to ANSI C for different programming tags.The <for> tag and its properties (from, step and to) are shown in Figure 5a; the corresponding translation from the <if> tag to the ANSI C if control flow sentence is shown in Figure 5b; Figure 5c shows all the sensor functionalities translated to conditional sentences within an ANSI C function controlling sensor events.Figure 5d shows the ultimate ANSI C code resulting from such translation.
The obstacle avoidance programme was then downloaded into the robot memory and the resulting robot path along the experiment is shown in Figure 6.This robot path was extracted off-line using a digital image processing tool specifically developed for this project.Two obstacle configurations were tested: a mazebased environment and a corridor.The second batch of tests was focused on using and testing all inherited functionalities from basic and medium levels achieved by programming the mobile robot in advanced level, particularly using the behaviour-based application.Homing is a typical behaviour in mobile robotics whose main goal is orientating the mobile robot towards a region of interest.This behaviours can be combined with other behaviours such as obstacle avoidance and emergent behaviours thus becomes more complex (Arkin, 1989).
In our case, the region of interest was defined using a metric position in 2D (x, y) or using an environm kinds of behaviour.iour, changing the criteria used to define the region of interest to sense light intensity.It is worth noting that the mobile robot did not know the stimulus position in advance, nor the obstacles' distribution around the environment.The perceptual schema obtained high light intensity orientation using an array of photocells.It was assumed that the mobile robot had a line of sight towards the light source.The resulting robot path is shown in Figure 7c.

Conclusions and future research work
This work has shown a programming environment having three complexity levels to enable users to experiment with mobile robotics using differing degrees of knowledge.Compared to other mobile robot learning tools considering only one user profile, this work had the advantage of extending the lifetime of the programming environment and the hardware platform.Not only concept-based mobile robotics can be learnt, but also hands-on STEM-based concepts.
The programming environment proposed in this work, which was implemented using the MVC pattern, provided a set of important properties such as a training module for inexperienced users, exercises at different levels of complexity (basic, medium and advanced), basic level programming GUI orientated towards users lacking previous experience in robotics, medium level XML-based GUI programming and advanced level programming GUI based on ANSI C, extensibility, interface adaptability, data persistence, and low software/hardware coupling due to BOT-XML language.This work was able to translate programmes at three complexity levels using XSLT translations.
Considering robotic seedbed experience (Jimenez Jojoa et al., 2010) and current academic and governmental efforts to develop novel educational strategies (European Center for the Development of Vocational Training -CEDEFOP, 2010), the work presented here represents an interesting option for stimulating children and young people's science, technology, engineering and maths learning.
A challenge management module should be developed to evaluate user learning.Simulating mobile robot behaviour is an important tool prior to downloading the application into a mobile robot.Adding remote mobile robot operation and programming environment represents an interesting direction for future work in this field.
To register, modify and delete users User authentication Data persistence (*) Open, save and close user programmes (*) XML-based schema for describing and storing user programmes (*) XML-based schema for describing and storing user data (*) Requirement available for all levels of complexity Table 3. Medium complexity level requirements Mobility  Distance-based and angle-based robot movement  Robot displacements and turns based on sensor state Perception  To obtain the XY robot position, orientation and current speed Communications  Transmitting and receiving ID codes using the robot IR modules Programming  XML-based programming  Maths, shift and logical operations support Building XSLT files to translate from the graphical programming interface to XML-based programming  Explicit switching to ANSI C programming (advanced level user) Examples  Programme to move the mobile robot to a fixed XY coordinate GUI usability and adaptability  Embedded XML editor including XML syntax highlighter, XML syntax corrector, and debugger Table 4. Advanced complexity level requirements Mobility  Modifying the robot wheels' speed and the corresponding speed controller parameters Perception  Vector-based representation for IR and contact sensors  Obtaining a free-obstacle angle sector around the robot with more or less illumination  Obtaining a vector orientated towards a desired region of interest on the XY frame Programming  ANSI C programming structures and variables definition  Building XSLT files to translate from the XML-based programming interface to ANSI C-based programming Examples  Behaviour-based programming examples such as obstacle avoidance, noise adding, light-based homing, pose-based homing, wall following and escape  Cooperative coordinator based on a weighted sum of priorities to fuse behaviour responses GUI usability and adaptability  Embedded ANSI C editor including C syntax highlighter, C syntax corrector, and debugger Mobility  Modifying the robot wheels' speed and the corresponding speed controller parameters

Figure 1 .
Figure 1.Diagram of programming environment components

Figure 2
Figure 2. a) Basic level programming GUI showing a built-in exercise.b) Challenge explanation window

Figure 7 .
Figure 7. Position-based and light-based homing behaviour and obstacle avoidance.a) Mobile robot behaviour stack.b) Robot path for positionbased homing.c) Robot light-based homing path.Position-basedhoming and obstacle avoidance (Figure7a) shows the behaviour stack where homing and obstacle avoidance were only enabled.Homing behaviour aimed at an XY position (100cm, 0cm) in the overall framework.The mobile robot was stopped at the point when it approached a 5cm region.Figure7bshows the robot path using a digital image processing tool developed for this project.Light-basedhoming and obstacle avoidance.The only behaviours changed in the behaviours stack was homing behav-

Figure 5 .
Figure 5. BOT-XML to ANSI C translation.a) <for> tag translation, b) <if> tag translation.c) Sensor event translation.d) ANSI C result

Table 2 .
Basic complexity level requirements The controller module received a learner's requests; it then sent queries to the data model and decided what action to execute to build an appropriate view for a learner.When the programming environment was opened, the first view was the learner management module validating a learner through his/her access key and created new users.Once a learner had been validated, an adaptable interface was displayed; the graphical programming module was displayed for beginners, the XML programming module for intermediate learners and the ANSI C programming module for advanced learners.The graphical programming module had two complements displayed as pop-up windows: challenges and examples.

Table 5 .
Characterising the XML scheme environment.xsd