Mona: an Affordable Open-Source Mobile Robot for Education and Research

Mobile robots are playing a significant role in Higher Education science and engineering teaching, as they offer a flexible platform to explore and teach a wide-range of topics such as mechanics, electronics and software. Unfortunately the widespread adoption is limited by their high cost and the complexity of user interfaces and programming tools. To overcome these issues, a new affordable, adaptable and easy-to-use robotic platform is proposed. Mona is a low-cost, open-source and open-hardware mobile robot, which has been developed to be compatible with a number of standard programming environments. The robot has been successfully used for both education and research at The University of Manchester, UK.


Introduction
Robotic systems are an excellent demonstration technology for STEM (Science, Technology, Engineering and Mathematics) teaching due to their inherent multidisciplinary nature [1]. The basic concept of a robot is something that students of all ages and abilities can understand. The learning activities that can be undertaken span the full range of abilities, from entry-level primary school students [2,3] through to university undergraduates (UG) and postgraduates (PG) [4,5]. Robots are also being used for non-technical learning, especially in support of those with learning disabilities [6].
The field of robotic systems brings together electrical engineering, mechanical engineering (or combined mechatronic engineering) and computer science [7] and therefore covers a large number of underpinning topics, as shown in Fig. 1. Robots can be used to directly teach robotics [8], or indirectly as a platform to teach other topics, both technical and non-technical (soft skills) [9]. One of the biggest strengths of using robots for teaching is the practical nature of the work; it is very easy to physically demonstrate or experiment on hardware subsystems or on full robots. Farshad Arvin farshad.arvin@manchester.ac.uk 1 School of Electrical and Electronic Engineering, The University of Manchester, M13 9PL, Manchester, UK There have been several studies over the last few decades about how engineering students learn [10]. Whilst the studies showed that students have a range of learning styles, there is a notable preference towards active, sensing and visual learning [11]. Traditional university teaching methods, large-scale lectures with supporting laboratories, are designed for cost and time efficiency [12], but there is a growing demand from the latest generation of students to explore different learning approaches [13][14][15][16]. Mobile robots provide an excellent opportunity to explore these new methods of learning.
Unfortunately robots can be expensive and their use in teaching can be limited to a only a few laboratory sessions a year. Assuming a 50 week working year, with a 35 hour working week, mobile robots utilisation for teaching could be as low as 1%. This could be increased if the robots are used for project work, but in general teaching robots do not offer good value for money in terms of their use.
It is important therefore to try and use robots in teaching which can also be used for research. Not only does this improve the utilisation and value for money, but it also ensures that students are being taught using state-of-the-art technology.
This paper presents the design of the Mona robot, a low-cost, open-source platform which has been developed for both teaching and research. Details of the robot's application to research have been presented in [17]. The contribution of this paper is to its application to teaching.

Robotics as a Teaching Platform Case Study
The School of Electrical and Electronic Engineering (EEE) at The University of Manchester, UK, uses robots in two ways; indirectly as an introduction to practical group project work for all UG students and directly in dedicated units as part of the B.Eng. and M.Eng. Mechatronic Engineering syllabi.
All second year UG students in the School take a compulsory unit entitled, Embedded Systems Project (ESP), which is a 20 credit unit run across both semesters of the academic year. Students are placed into teams of 5 or 6 and are given the task of building an autonomous white-line following robot buggy [18]. At the end of the year, a race day is held where the buggies compete against each other on a specially designed track.
The ESP is one of the flagship units in the School of EEE and provides students with an introduction to soft skills such as team working, project management and report writing as well as technical topics such as motor characterisation, embedded system programming, sensors, modelling and engineering drawing. The average Year 2 intake is approximately 280 students, split into 50 groups and the costs of running the unit are significant; the consumables budget is approximately £20k per year, in addition to 1200 hours of academic time commitment and 600 hours of support staff time. Whilst the ESP is highly successful and popular with both students and the School's Industrial Advisory Board, the operating model is not sustainable for more units in the syllabus.
Building on the ESP, third year Mechatronic Engineering students take a compulsory unit on Mobile Robots and Autonomous Systems (MRAS). This unit covers topics such as mobile robot kinematics (legged and wheeled), sensing & perception, planning & navigation and estimation & filtering. The average number of students on the course is between 40 and 50.
A key emphasis in the design of the MRAS unit was the use of real-world robotic systems. To achieve this, a new teaching style was utilised, which aimed to bridge the gap between the low-cost traditional lecture-based teaching with supporting labs, which provides limited opportunity for practical learning, and the high-cost problem-based learning (PBL) approach of ESP.
The teaching method employed is best described as practical lectures. All 12 lectures are given in a laboratory setting, where students have access to PCs (Fig. 2). This allows them to do simulation or experimental-based tutorial questions during the lecture, as well as being able to connect to robots to run simple experiments or exercises to observe the outcomes. In addition, there are two traditional laboratory exercises which build on the work done during the lectures.
Previous versions of the MRAS course have utilised practical lectures, but only using simulations (MATLABbased tutorial questions). This has been popular with the students, however it was felt that significant improvements could be made if the students had access to robots as well. The challenge lay in identifying a suitable small-scale, lowcost platform which could be easily used by the students. To meet these needs, a new platform has been developed: the Mona robot (Fig. 3), which is an open-hardware and open-source, low-cost platform. At The University of Manchester, it is important that the teaching is related to the world-leading research for two reasons. Firstly, it ensures  that the students are being taught with the latest technology and they can see how the material links into real-world challenges. Secondly, it provides an excellent pathway for those students who are interested in pursuing a research career. It was therefore a requirement that the Mona robot could be used for both teaching and research.
This paper presents the design of i) Mona's hardware and modules and ii) the software and programming of the robot. The rest of the paper is arranged as follows: Section 2 provides a review of existing educational robotic platforms. Section 3 presents the Mona hardware and Section 4 presents software and robot programming platforms. Section 5 provides examples of experiments conducted with the Mona robots. Section 6 presents the results from the experiments and Section 7 discusses the outcomes and presents conclusions.

Robotics in Education
There are a number of important considerations to make when selecting a robotic platform for teaching including cost, size, functionality and interface. Educational robot platforms can broadly be split into three categories; manipulators (used for industrial robotics) [19], legged mobile robots [20] and wheeled mobile robots [21]. For the MRAS unit discussed in Section 1.1, only mobile robots will be discussed here.
In terms of practical demonstrations or experiments, legged mobile robots are more expensive, larger and more complex. Platforms such as the Nao robot [22] cost approximately £6.5k per robot, which make them infeasible for class sizes of more than 10 or 20. Other legged robot platforms; humanoids, quadrupeds and hexapods, are available, however low-cost alternatives do not provide the functionality required [20].
The difference between wheeled and legged robots is the means of locomotion. Considering Fig. 1, actuation (and the associated kinematics and dynamics) are only one part of a robot system. All of the other subsystems can be made independent (for teaching purposes) of the locomotion method. Wheeled robots therefore offer a lowcost alternative for teaching.
Wheeled robots have been used as teaching aids for decades, but it has only been the last 10 years that small-scale, low-cost platforms have become widely available [23][24][25]. Platforms such as LEGO Mindstorms allow quick and easy access to robotics and their underpinning subjects across the education spectrum [26,27]. For more advanced users, the e-puck became one of the first commercial platforms to have an associated robotics syllabus with it [23].
The e-puck also became widely used for research into swarms and collective control as its small scale allowed for large numbers of robots to be used in experiments [28]. A major drawback of the e-puck is its cost, retailing at around £700 per vehicle. This is significantly cheaper than legged robots, however for a class of 50 students, it is unaffordable to provide one robot per student. Since its release, there have been a number of other robots developed as a low-cost alternative for both education and research. These range in complexity, cost and functionality, and a selection of them are shown in Table 1. Table 1 shows that whilst there have been a number of robots developed as low-cost platforms for education and research, very few of them have been successfully commercialised and are therefore not widely available. The majority of the robots are open-source in terms of hardware and software.

Commercial Availability
Instead of impacting the commercial feasibility of the robots, anecdotal evidence is that end users are still likely to buy a complete unit for convenience. They are then able to modify the hardware or software (including adding extra functionality) to tailor the system to their needs. This approach provides the full range of black-box uses for education or basic research through to full customisation and the understanding of the fundamental systems. The Mona robot has been developed, in collaboration with a commercial partner, as a low-cost platform for robotic education and swarm/collaborative research. It currently retails at £100 per robot and is fully open-source (hardware and software). It has been successfully used for teaching on the undergraduate MRAS unit (Section 1.1) and MSc projects as well as being used for swarm research [17].

Teaching Resources
Most of the robots in Table 1 have aspirational plans for their use in a curriculum. Only the E-puck and Andruino-A1 robots have specific details of how they can be used in laboratories or as general teaching aids. The E-puck, being the first to be developed for teaching, is used in topics such as signal processing, automatic control, behaviourbased control, localisation and path planning and distributed intelligent systems. The Andruino-A1 is designed to be an introduction to mechatronic design and assembly and for embedded systems programming.
The Mona robot currently allows students to undertake practical experiments on system characterisation and motion planning. From a characterisation perspective (Section 5.1), students can do experiments on the sensors and actuation systems. For motion planning (Section 5.2), they can learn about open-and closed-loop control, obstacle detection and avoidance and more complex swarm algorithms.
A simulation environment is also being developed along with an add-on module to allow ROS control. This could enable low-cost practical ROS examples to be run. There are also plans to use the robots to for basic path planning (Wavefront, A*).

Research Capabilities
The primary research undertaken using the robots in Table 1 is focused on multi-agent systems or swarm robotics. The MarXbot has a specific focus on long-term autonomy [34] and the Colias, E-puck and Jasmine robots have a number of publications in the general field of swarm robotics.
The perpetual swarm interface designed for Mona in [17] allows for large-scale, long-term autonomy and swarm scenarios to be investigated. The Monas are also currently being used to explore fault tolerant control of multi-agent systems, pheromone communication based swarm behaviour and human-robot-interactions using mixed-reality interfaces

Mona Robot Hardware Specification
This section presents the robot's hardware systems. Mona was initially based on Colias [31], a low-cost and opensource robot, which has been used for swarm robotic research [37]. To allow flexibility for both teaching and research, a similar open-source and open-hardware approach was taken. Figure 4 shows the hardware architecture of the Mona robot.

Main Controller
Mona uses a low-cost ATmega 328 microcontroller (μC) as the main processor. The primary reason for utilising this μC was to develop the robot based on the Arduino Mini/Pro architecture and to be compatible with Arduino's open-source programming interface. Figure 5 shows the architecture of the main controller, the μC's internal modules, and external modules which are connected to the main controller.
The utilised μC has a low-power 8-bit AVR RISC 1 architecture with 131 instructions which are mostly executed with single clock cycle. It has several internal modules providing easy and reliable minimum system to develop the Mona robot. The μC has an internal 32 KB flash memory, 1 KB EEPROM, and 2 KB SRAM, which provide enough memory for programming and parameter allocation. The main clock source is an external 16 MHz crystal oscillator. An internal timer module is used to generate pulses for the motors' speed control and other function which requires an internal timer. Eight analogue to digital converter (ADC) channels are used to connect to the IR (infra red) sensors for obstacle range estimation and to monitor the battery level. The μC supports several serial communication methods such as RS232, I 2 C, and SPI, which are used for programming the flash memory or communication with external modules.
The μC directly controls the motors' driver and communicates with the PC using its USB driver. General purpose I/Os (input/output ports) are connected to LEDs and IR emitters. Moreover, there are two interrupt channels directly connected to the μC which are triggered by an external event. Mona uses these external interrupts for motors' encoders which will be discussed in Section 3.3.

Actuation
Two DC motors ( Fig. 6) with direct reduction gears are used as the main actuation method. The architecture shown in Fig. 4 shows that a symmetrical differential driven configuration was used to control the robot's motion. The robot's wheelbase is 80 mm and the diameter of the wheels is d w = 28 mm so the forward velocity of the robot is approximately 88 mm per revolution.
The rotational speed for each motor is controlled individually using pulse-width modulation (PWM). Each motor is controlled separately by an H-bridge DC motor driver, which requires approximately 74 mW to operate. As the motors are directly powered by the on-board battery, any voltage drop impacts the speed of the robot. Therefore, the battery's voltage must be considered in the robot's kinematic model.
The output voltage of the PWM (v m ) is a fraction of the maximum voltage of the source (E bat ) and the duty cycle of the PWM signal (p); v m = p · E bat . The maximum velocity of the shaft, N max , with a macroscopic model of the utilised motors [38], is shown in Eq. 1: where α m and β m are two coefficients dependent on the motor's characteristics and the robot's design. Suitable values of α m and β m were estimated through empirical experiments.
The kinematic model of the robot follows general differential-driven kinematics: showing the position estimation of the robot (ξ = [x y θ] T ) depends on the speed of the left and right wheels (ϕ l,r = The required torque at motor's shaft can be calculated by: τ m = τ noload + τ movement , and τ movement = τ wheel /n gear . Since the motors' gearbox ratio, n gear , is relatively high (250:1) and the robot is lightweight (45 g), the robot requires little torque to move (τ movement < 2 × 10 −7 N.m). As a result, the acceleration of the motors is similar to the no-load condition which means that the velocity rise-time is a few milliseconds. This means that acceleration can be considered instantaneous so the dynamics of the robot do not need to be modelled.

Motion Control
Precursor robots such as Colias [39] and AMiR [40] used encoderless position estimation [38], however this resulted in low precision and required additional feedback from the motors' current to operate.
Each of Mona's motors has a small-package magnetic encoder attached to the motors' shaft. Figure 6 shows the configuration of the utilised motors. Each encoder includes a 6-pole magnetic disc and two hall effect sensors which generates 12 pulses per shaft revolution (before the gearbox). Due to the limited number of IO pins on the μC, only the output of one of the sensors was used which reduces the resolution to 6 pulses per pre-gearbox shaft revolution.
The post-gearbox resolution is therefore 1500 pulses per wheel revolution (≈ 0.24 • /rev). The encoders' outputs are connected to the μC's external interrupt pins. Each pulse calls an interrupt routine in the main controller, which was used to increment an independent counter variable for each wheel.
The output of the encoders can be used as an input to a controller for closed-loop motion control.

Sensor Systems
Mona has been developed so that a range of sensors can be added through expansion boards, however there is a set of fixed short-range IR proximity sensors which are used for motion planning. Five sensors are mounted on the front half of the robot, with a 35 • spacing between them (see Fig. 4). These are connected to ADCs on the μC which allow the estimation of the distance to an obstacle to be made.
Obstacle detection and distance estimation use fundamental principles of electromagnetic radiation and its reflection. The reflected IR signal intensity measured by a sensor is mathematically modelled using (3) [41]: where s(x, θ) is the output value of sensor, x is the distance of obstacle, and θ is the angle of incidence with the surface. The model variable γ includes several parameters such as the reflectivity coefficient, output power of the emitted IR light and the sensitivity of sensor. κ is the offset value of the amplifier and ambient light effect. White body and black body surfaces reflect and absorb IR radiation with different ratios, which is a significant issue in selecting between an obstacle and a wall in robotic environments. The model parameters (γ and κ) were estimated empirically. Mona translates the received IR signal intensity to estimate the distance and bearing of the obstacle and neighbouring robots in the case of a swarm scenario. The distance is calculated from the amplitude of the received IR shown in (3). As Mona's IR sensors are placed symmetrically at a known angle, the relative angular position of the obstacle can be estimated using (4): where φ is the estimated angular position, ψ i is the angular distance between ith sensor and the 'top' of the robot (IR-1 in Fig. 4).ŝ i , i ∈ {1, 2, 3, 4, 5} is the translated IR intensity from sensor i. Since the proximity sensors have a narrow viewing angle (approximately 45 • ), there are blind spots between the sensors near the edge of the robot. However, those proximity sensors were deployed to act as the bumper for collision detection with walls and other robots, therefore to provide an accurate range & bearing function for the Mona, it needs an extension module covering 360 • around the robot with longer sensing radius (> 15 cm). This long-range sensing module is currently under development.
Mona's battery voltage is also monitored using an ADC from the μC and a voltage divider including two resistors. This value helps the robot to keep the voltage of battery in a safe range (> 3 V) and also monitors the charging process. This is very important as the motors' velocity is a function of the battery voltage as shown in the motor's model (1). It's also a key parameter in swarm scenarios which consider power management system e.g. perpetual swarm robotics [17].

Communication
As with the sensing systems, there are two sets of communication modules. The first is the on-board internal communications bus and the second is external communications add-on boards (such as Wi-Fi, RF or Bluetooth). -USART: used to send and receive data via USB (FTDI module). It is mainly for the Arduino programming link, but it can also be used to communicate with other add-on boards such as a Raspberry Pi or a bio-inspired vision system [42]. -I 2 C: is a general purpose communication link which can be used by external modules which support I 2 C protocol e.g. temperature sensor.
-SPI: is mainly used for RF communication module (e.g. NRF24L01 2.4 GHz). It is also used for programming of μC using the ISP method.
The IR proximity sensors can be used for face-toface inter-robot communication in case of multi-robot scenario [43], however they do not provide high quality or fast communication due to the distance limitation of the utilised modules (approximately 5 ± 1 cm). Therefore, Mona requires an external module to provide inter-robot communication, distance estimation, and bearing covering 360 • around the robot, similar to the module deployed by the e-puck robot [44].

Robot Modularity
To make Mona a low-cost versatile platform, it must be flexible enough to support other modules which have been developed for research and education. As illustrated in Fig. 7, the J2-SPI connector was considered to be a general purpose SPI connector, however the main reason was to attach a NRF24L01 module which is a widely used low-cost RF module with Arduino boards.
Due to the limited processing power of the main μC, Mona has been designed to interface with other more powerful processing modules such as Raspberry Pi Zero 2 to extend its applications.
A breakout board (Fig. 3b) has been developed which supports: i) Raspberry Pi Zero, ii) XBee module, and iii) NRF24L01. The board is mounted on top of the main platform and is able to communicate with the main platform using the internal communications buses.
To study the possibility of controlling Mona using ROS commands, a breakout board has been made that supports a Teensy 3.2 module. 3 [45].
An additional light sensor breakout board has also been developed for the Swarm Control laboratory discussed in Section 5.3.
Appendix presents list of developed extension modules for the Mona robot.

Power Management
The MRAS unit described in Section 1.1, comprise 2 h lectures and 3 h lab classes. During this time, it can be expected that a Mona robot will be used for between 1 and 2 h. This assumes that the robot is not continuously running allowing the students time to write programmes or analyse results. Table 2 shows the power consumption of the modules on the robot. Due to it's small form-factor, a 3.7 V, 250 mAh battery was used. This provides a continuous operation lifespan of between 1.2 h (maximum motors' There are a number of on-board battery management systems including: i) hardware for battery sampling, ii) hardware for battery recharging management, and iii) a function in software library to cheque the battery level occasionally.

Software and Robot Programming
This sections describes the software and programming of Mona robots. As outlined in Section 3.5, Mona has several communication methods, hence the user has flexibility in how to programme the robot.

Software Platform
Due to the open-source criterion of the robot, it needed be compatible with free and open-source programming platforms. Therefore, Arduino [46], one of the most successful open-source platforms, was used to programme Mona. The important reasons to use Arduino were: i) it is a relatively easy-to-use platform in comparison to other open-source platforms, ii) the rich set of online forums and available libraries with free access, and iii) variety of Arduino compatible programming environments especially for young age students (e.g. Ardublock, 5 Mblock, 6 and Scratch for Arduino 7 ).
It is worth mentioning that the robot can be programmed with any software platform that supports ISP, hence it is not only limited to Arduino.

Robot Programming
Mona has been developed based on an AVR RISC microcontroller (ATmega328P). The architecture of the robot allows its connection to Arduino-based platforms via a USB cable. However, it is possible to use any programming language which was developed for AVR μCs including C, C++, Java, Pascal, Basic, and Assembly.
Due to the Arduino platform's popularity amongst undergraduate and graduate students and the open-source nature of the Arduino project, lab activities were therefore conduced with C programming. Students are given an Arduino Sketch file which can contain as much or as little of the underpinning code as is required (Arduino sketch is available at: https://github.com/MonaRobot/Mona-Arduino).
For example, the sketch could contain all of the functions to access the peripherals and actuation systems and the students only have to write the main loop, calling these prewritten functions. Alternatively students could be asked to write the functions themselves.
The purpose behind using the sketch was to give students the experience of programming the robots at a relatively low level, in the manner used by the researchers. The aim is also to use readily available and supported interfaces. All of the underlying code will be accessible on Git-Hub. A custom GUI is being considered, however there are challenges with regards long-term support of such an interface should new versions of the robot be developed.
The use of Arduino sketches has been successfully implemented in a number of lab sessions in the MRAS course using not only Mona, but also just an Arduino with an IMU.

Simulation Software
Mona has been modelled in Stage [47] for the study of bioinspired aggregation scenarios [48]. Stage is an open-source software platform that simulates a group of mobile robots in a 2D environment.

Experiments
The robot was evaluated for its suitability for teaching and research in two phases. The first phase considered the core functionality of the robot with regards to the characterisation of the motors and sensors. The second phase evaluated the suitability for a range of motion planning algorithms, including traditional open-and closedloop controls and modern swarm control techniques.

System Characterisation
The quantitative experiments were performed to evaluate the performance of the hardware design and focused on two areas: -An analysis of the actuation method and the characterisation of the utilised motors by extracting the macroscopic model's (1) parameters (α m and β m ). -An evaluation of the sensor system for obstacle detection and the estimation of the model's (3) parameters (α and β). Additionally, the accuracy of the relative angular position presented by Eq. 4 was evaluated.
These experiments characterise the performance of the robot and can also act as an excellent introductory lab for students. This could be either as stand-alone exercises on actuation or sensing, or as part of a robotics systems performance lab.

Motion Planning
In this set of experiments, a constant speed for both left and right motors was selected. The error, e(t), is the differences between the current (P V l,r ) and desired (set point, SP l,r ) rotational speed of the motors. The error term is caused by two aspects of the design: i) the motors heterogeneity and ii) physical asymmetry.
Experiments were conducted in for open-and closedloop control at different motors' speeds of N l,r ∈ {60, 70, 80} rpm. In the case of open-loop control, the left and right motors' set points were assigned to the PWM pulse generators and the error was observed using the feedback from wheels' encoders, P V l,r .
In the closed-loop control experiment, a proportional controller was selected as the robot does not have rapid changes in its trajectory. The goal was therefore to identify, compare and compensate the motion error due to motors' manufacturing heterogeneity and physical error parameter at different forward speeds of N l,r ∈ {60, 70, 80} rpm. The proportional controller calculates a proportional output, P out , over a period of δ t using the following equation: where K p ∈ {0.05, 0.15, 0.25} is the proportional gain, e(t) is the error of the system, e(t) = SP − P V , over period of δ t = 200 ms and P 0 is the output of controller when there is no error, which is the PWM value. It is worth mentioning that the Eq. 5 controls the left and right motors independently using the separate feedback values from the motor encoders. The preliminary experiments showed that the effect of different time frames (δ t ) was

MRAS Lab Activity: Swarm Control
One of the benefits of using the Mona robots for teaching and research is that multi-agent systems can be investigated. The work presented in [17] showed how their capabilities for research, however it is important that this functionality can be translated into the teaching domain.
A lab exercise was developed based on the bio-inspired BEECLUST aggregation algorithm [49] and experimental setup presented in [48]. The BEECLUST, a state-of-theart swarm aggregation algorithm, was chosen due to its simplicity in implementation and programming. To perform the swarm aggregation, all the robots follow a similar control mechanism which is shown in Fig. 8. A light source (cue) was provided by the desk lamp as a gradient cue that placed in one side of the arena. The robots followed the aggregation mechanism to find the optimal part of the arena (local optimum).
In the lab session, groups of students were given an individual Mona and required to programme it to search for a light source. They had to do some limited robot characterisation (ambient light intensity and open-loop motor characterisation) before running a basic motion planning algorithm. An Arduino sketch was provided with the basic interface functions pre-written.
Once the students completed the individual robot exercise, they had to modify their code to implement the BEECLUST algorithm. Multiple groups were then combined so that five robots were placed in an arena at the same time. The behaviour of the robots was then recorded.
The deliverables expected from each group were: i) adjust the waiting time and find appropriate values for the parameters, ii) record the aggregation time when 4 robots are aggregated within the cue zone, iii) repeat experiments 10 times and calculate median and standard error rate, iv) submit a short video showing an aggregation of 5 robots, v) report any issues and unexpected outcomes.

Motor Characterisation
The model's (1) parameters were extracted from an experiment using an adjustable power supply. Figure 9a shows the rotational speed, N, of the motors as a function of its motors' voltage. Motors showed a linear relationship as voltages varied from 0.5 to 5 V. Results on 40 motors showed that all motors followed the macroscopic model with similar α m = 28.07 ± 2 and β m = −6.2 ± 0.5.
In the second step, the reactions of the robot's motors in different PWM and motion directions were evaluated. Figure 9b shows a linear relationship between speed of motors and the PWM values in both forward and reverse directions.  Sensor readings from IR short-range proximity sensor reflected from a 20 mm wide and b 10 mm wide obstacles with different colours (white, red, and black) which was faced towards the sensors. The lower sensor reading shows a higher amount of IR Figure 10 illustrates the recorded values from the IR proximity sensors which were reflected from two different sizes of obstacles with 10 mm and 20 mm widths. The effects of obstacles' colours have also been studied.

Sensor Characterisation
The results showed that an increase in size of the obstacle improves the distance estimation function by increasing the amount of reflected IR from the surface. However, this reflection was not similar for experiments with different colours. As shown in the results, the white colour obstacle reflected higher amount of IR than the darker obstacles. Table 3 shows the extracted model parameter (γ and κ, Eq. 3) for the individual IR sensors. As discussed previously, γ relies on several parameters including the reflectivity coefficient for the obstacle, output power of the emitters, and sensitivity of the receiver. The results revealed that the obstacles' widths and colours directly impacted the γ value of the model (3) in every configuration. Similar results have been reported in [41]; white white colour obstacle had the highest reflection and black colour obstacle had the lowest reflectivity.
On the other hand, κ, which that relies on the emitters' power and ambient light, was not affected by the different experimental configurations. Since the experiments were conducted at the same time under similar conditions (lighting and IR emitter power source), the results had approximately similar κ value of 3.
In the next step, we tested the neighbouring robots detection which is an important issue in collaborative robotic systems. The neighbour robot was placed at three different angles {−45 • , 0 • , 45 • } from the centre of the observed robot and the model (4) in different distances (5.6 to 11.3 cm) from the centre of the observed robot was tested (Fig. 11). Since the utilised sensors are very short range and narrow angle, the readings for longer distances did not fit the bearing model with a high precision. Therefore, to increase the bearing accuracy using a low-cost solution, weights (gain) for each sensor were added to the Eq. 4:    The proportional control that was used to compensate motion error demonstrated a significant improvement in motion planning. The results revealed that an increase in proportional gain, K p , increases the performance of the system in all configurations. However, it contained fluctuation in error rate with lower speed (60 rpm) than with faster rotational speed. Therefore, with δt = 100 ms, the proportional gain of K p = 0.25 demonstrated precise error compensation with median error rate of {1.15%, 0.94%, 0.8%} at N ∈ {60, 70, 80} rpm, respectively. We must mention that the closed-loop motion control could be more optimised by using a different time frame or applying a PI or a PID controller, which is beyond the scope of this paper.

MRAS Lab Activity: Swarm Control
The MRAS Swarm Control lab session was run for 3 h with 30 students. The first phase of the lab focused on characterising Mona's functions and hands-on programming and was successfully completed during the allocated 45 min.
The groups were able to measure and draw the light map of the arena and the observed results showed that the light intensity reading was between 800 to 1000 (dimensionless, 10 bits ADC). Therefore, ambient light (assumed 800) was subtracted from the future calculations.
In the second phase of the lab, groups were expected to run the BEECLUST algorithm. The students were able to understand that the ambient light (the offset) must be subtracted from the light reading to avoid unexpectedly long waiting times. As expected, the groups observed variance in their aggregation times, primarily due to their arena position and light interference caused by the room lighting. The median of aggregation time was 200 s with ± 50s tolerance, which is normal for experiments with low population size as reported in [37,50]. A future extension of the lab could be to run the scenario with different population sizes to observe the effect on the aggregation time.
It is worth noting that there were two issues during the experiments. The first was that the light sources (desk lamps) contained some IR, despite using cold white colour lamps. This led to the robots performing unexpected turns due to received IR from light that was mistaken as an obstacle.
The second issue which was that several collisions happened when a robot reached the other robot from back side. In this case, the robot couldn't receive any reflected IR using its front proximity sensors. To solve the issue, future robots will have a white colour case that reflect the IR, hence it is considered as an obstacle.

Conclusion
This paper has presented an open-source and low-cost mobile robot platform that has been developed for education and research purposes. An affordable mobile robot, Mona, can be programmed using off-the-shelf open-source programming platforms (e.g. Arduino). The robot's hardware functionality including: sensory systems, actuation, communication, and power management has been assessed and characterised. Control systems for single and swarm robotic scenarios have been implemented to show the abilities for both teaching and research. Mona is currently being used for two different tasks: i) teaching resource for autonomous system and robotics as an educational platform and ii) study on long-term evolutionary algorithms as a platform for research.
The next stage of development for the Mona robot is the design of a series of add-on modules which will allow additional functionality. As shown in the Appendix, a number of these modules are already being developed, including one which allows the robots to be controlled using ROS. It is hoped that this unique capability (for a robot of this size) will make the robots more attractive for both teaching and research. The open-source repository of hardware and software will be improved as well as all the systems being available commercially.
From a research perspective, the Monas are currently being used to explore fault tolerant control of multiagent systems, pheromone communication based swarm behaviour and human-robot-interactions using mixedreality interfaces. the module which was developed to read RGB colours with Mona robot. The module communicate using I2C ports. It has two APDS-9960 RGB and Gesture sensors, which was developed for use with Arduino boards. The next module which is shown in Fig. 13f is a communication module which has been developed for inter-robot shortrange communication. His current research is focused on the robotic deployment of scientific instruments for inspection of hazardous environments, such as those found in the nuclear industry. He has expertise in instrument design and data analysis, with a background in experimental plasma physics.
Simon Watson is a Lecturer in Robotic Systems at the School of Electrical and Electronic Engineering at the University of Manchester. He obtained his MEng in Mechatronic Engineering in 2008 and his PhD in 2012, both from the University of Manchester. His research focus is on mobile robots for the exploration and characterisation of hazardous and extreme environments and active areas of research include novel platform design, communications and localisation, sensing and navigation and multi-level control. His current research portfolio includes developing robots for the nuclear industry (for the Sellafield and Fukushima sites) and power generation (offshore wind).
Barry Lennox is Professor of Applied Control and Nuclear Engineering Decommissioning in the School of Electrical and Electronic Engineering at The University of Manchester and is the Research Director of the Dalton Cumbrian Facility. He is an expert in applied control systems and their use in process operations and robotics and has considerable experience in transferring leading edge technology in to industry.