International Conference on Magnetics, Machines & Drives (AICERA-2014 iCMMD)

978-1-4799-5202-1/14/$31.00 ©2014 IEEE

Embedded Systems Project: Innovative Autonomous Line-following Buggy Design and Implementation

Daniel Matthews, Shuping Dang, Loucas Christodoulou, Han Chen, Yamen Hawit School of Electrical and Electronic Engineering

The University of Manchester UK

{ daniel.matthews-2, shuping.dang, loucas.christodoulou, han.chen-5, yamen.hawit}@student.manchester.ac.uk

Abstract— The Embedded Systems Project is at the core of the second-year electrical and electronic engineering course at the University of Manchester. The objective is to construct a working buggy based on microcontroller, which is able to autonomously detect a white line from a black surface then navigate around a track via the white line. It must be able to tackle obstacles, including slopes, different break points on the track and corners and reach the end of the track successfully. In addition, not only the operation, but also the speed of the buggy should be taken into consideration; the faster, the better.

Keywords—embedded system, line- following, microcontroller

I. INTRODUCTION The Embedded Systems Project (ESP) is at the core of the

second-year electrical and electronic engineering education at the University of Manchester. Through it, students learn more in this relatively short time compared to what they have in many years of accumulated education, including practical, theoretical, and other useful skills. Since they are competing with other teams, they also receive first-hand experience in dealing with time constraints and pressures whilst developing a working embedded system.

In terms of teamwork and project management, students apply management methods for the whole project, to work in cooperation with an appropriate and clear division of work. Thus each person in the group is responsible for his own part, which is beneficial and effective. However, this method also has some challenges, in ensuring that the interfaces between each part are compatible and suitable. Each project team specified how they were going to implement their buggy with respect to time via a Gantt chart, and also created a budget of the parts that required for this implementation. The modern management tools and methods that have been learnt are an essential part of the ‘UK Spec’ [3] education requirements for certification as a professional engineer in the UK.

The system design is comprehensive, requiring a systematic approach to the software and hardware, because the software is based on the hardware, and the hardware must provide suitable interfaces for the software; when the software is specified, it must allow for the constraints of the hardware and vice versa. Moreover the software algorithm and the implementation of the hardware must be consistent in order to achieve the high compatibility and efficiency. The most

significant achievement was to manage and complete a comprehensive and systematic project effectively.

In this paper, an overview of the design and implementation of the autonomous line-following buggy will be presented and evaluated, both technically and in terms of learning objectives. This paper includes a final system components summary, race analysis, and the innovation of the project design, along with a summary of specification. The overall outcome of our project was a successful one. Our buggy was completed ahead of schedule, and we completed all of the components of the final race. The key to our success was in the software, which will be described more in depth later on in this paper

II. OVERALL DESIGN AIMS The aim of this project was to construct a line-following

buggy, able to navigate around a track, up a slope, and come to a complete stop, all without human intervention and to complete the track with the fastest time of all groups. The track included line breaks of up to 50mm laterally and a slope. The white line stopped before the end of the track and the buggy was required to detect the end of line and stop automatically. The project also provided a practical introduction to the microcontroller-based implementation of embedded systems. These aims were never changed along the way the aim was always to construct the buggy and to win the race. Fig. 1 shows images of the final buggy. Standard-issue components included the motor driver board, breakout board, battery pack, wheels and motors. Additional components were selected within the constraints of the budget.

Fig. 1. Graphic of the buggy

International Conference on Magnetics, Machines & Drives (AICERA-2014 iCMMD)

III. FINAL SYSTEM COMPONENT SUMMARY

A. Mechanical Components Summary The mechanical design of the buggy required the team to

characterize the motor and estimate the load in order to specify a gear ratio. Mechanical tasks included gearbox design, selection of an appropriate chassis material and layout, production of CAD drawings and construction.

The mechanical section to the ESP buggy stayed virtually unchanged throughout the whole project. However when testing started, the buggy seemed to be unstable whilst navigating around the track. After observing the buggy it was quite apparent that the castor wheel that was supplied did not perform well enough, leading to unwanted oscillations when navigating the track as the wheel was offset from the centre of the radius thus giving it a “shopping cart” characteristic. This was overcome by installing a ball bearing castor in place of the castor wheel; it was bought-in so that as little fabrication as possible was needed for the installation. Upon installing the new castor the improvements were instantly apparent allowing smoother navigation, a shorter wheelbase and also adjustable height if needed for exceptional light conditions. The chassis and gearbox designs remained unchanged throughout the whole project, these designs were proven to be more than capable of handling the demands of the course.

B. Electronic Components Summary The main electronic components were the circuits to sense

the white line and detect the slope. Initial characterization tests were used to select the line-following sensors. However, the sensors that were chosen as performing the best in the characterisation tests did not perform as well when it came to a practical test. The infra-red diode and phototransistor that was selected only showed a voltage level drop of 30 mV; in terms of being used with a comparator circuit this was not a sufficient change in order to determine which states the sensors where reading. The comparator circuit included a hysteresis loop to prevent chatter around the threshold level. A device that performed equally as well in the characterisation testing was chosen. This was a single package TCRT5000 which included both the sender and receiver devices meaning a circuit board change was needed. Upon completion of the new circuit board initial tests showed a dramatic improvement, the sensors worked as expected with increased voltage range and greater stability.

Two tilt sensors were used to to detect the up-slope and down-slope respectively. These were calibrated to act as complimentary pairs and switch on or off when the angle of the buggy increased from the horizontal 10° point or decreased from the horizontal -10° point. This enabled detection of the ascending slope to increase the torque supplied to the gearbox and for the descending slope to apply a breaking action by reversing the motor’s polarity for short periods, slowing down the speed. While the buggy was on the flat section of the track both of the sensors play no part in the navigation strategy. The circuit board was simple to implement, as it only required a simple pull up resistor circuit per tilt switch, each connecting to the microcontroller through a digital input. Tilt sensors

were chosen because they were more precise less sensitive to noise than using a motor current sensor to detect the slope.

The microcontroller that was supplied to the group was used throughout the project this was unchanged, this is because it was more than capable of handling the task set and was also a familiar set of hardware for all the group members..

C. Software Summary The software aspect of the project went under a

momentous amount of different revisions; this was due to the way in which the code was developed. As the group had a number of deliverables, the code was generated in order to meet the specification of specific tasks set in the deliverables. So functions that were used on the final race day were the collaboration of a number of tried and tested sub programs.

Even though many revision where made, the software still stayed true to the navigation strategy set in the project proposal; this was to use a “bang bang” style of strategy. The decision to use digital logic in the software kept aspects of a complex program simple and easy to troubleshoot, along with giving definitive functions that would not conflict with each other. Functions were made to move forward, right, left, stop and to conquer line breaks/shifts, the functions were called by the main program depending on the different binary combinations that the sensor array could output.

The direction of the motors was used to make turning faster and for braking to slow the buggy, this reversed the polarity of both of the motors resulting in a shorter stopping time and reversing either one of the motors to turn faster. The voltage applied to the motor was determined by a variable duty cycle, pulse width modulation (PWM) output from the microcontroller, with the H-bridge acting in bipolar mode. The direction of each motor was set by a logic output, where the two states indicated forwards or reverse.and a second logic enable signal.

D. Navigation Strategy The main motor control is from optical sensor outputs, as

shown in Fig. 2. If sensor 4 detects that the buggy is centered on the line, the response is to move forward. Both motors should be supplied with equal voltage.

Fig. 2. Sensor array

International Conference on Magnetics, Machines & Drives (AICERA-2014 iCMMD)

If sensor 5, 6 or 7 detects the line, the buggy is too far too the left, and in this situation the desired response is to move right. Motor A is supplied more voltage than motor B and in an extreme case, motor B will be reverse polarity. This is also the same situation if sensors 3, 2 or 1 detect the line however the motor with more voltage will be swapped to B. This happens until the buggy has again been navigated back so the white line is in the middle of the sensor array i.e. sensor 4. This simple strategy also covers a lateral break, where the line shifts 50 mm from left to right, as the right-most or left-most sensors will detect the line and then use this strategy to again navigate to the centre.

Fig. 3. Sensor array 2

As Fig 3, shows, for line breaks with curves, more than one sensor may be activated. When sensors 5 and 1 are detecting, (or on the other side sensors 7 and 3), then the motor corresponding to the sensors furthest from the centre must be given less voltage and the opposite motors be given more until the buggy is successfully navigated to the centre.

To deal with line breaks of up to 2 mm in the forward direction, a delay function is used to keep the motor going until the sensors detect the white line once again. This is also tied in with the complete stop function so that if no white line is detected for a longer time period all voltage to the motor will be stopped or even reversed in polarity and the buggy will come to a controlled stop.

The auxiliary motor control is from tilt sensors. The tilt sensors operate only when the gradient of the buggy increases above or below the horizontal line, they complement each other when working on a gradient and are obsolete when on the horizontal. The diagrams below slow firstly the sensors on an ascending gradient, on the flat horizontal then on a descending gradient.

Fig. 4. Tilt Sensors

From the above diagram it is clear to see that when the metal ball moves to the outer section of the sensor then the sensors output a logic zero, a logic one is only sent to the micro controller on two separate bits when ascending or descending. This allows control to increase the duty ratio of the PWM channel so that the buggy completes the harder hill

climb at a competitive speed and also slow the buggy down on the decent. This is done by reading the two pins of the sensors and incorporating this into an IF statement within the code, if this statement is deemed to be true by the micro controller then it will take the necessary action to the switch combination sent to the port being read.

IV. RACE PREPARATION In this part, the race preparation based on performance

analysis and testing will be presented. The specific challenges for the buggy in the race can be summarized as:

1) How to control the buggy’s velocity and direction effectively according to the condition of the white line track.

2) How to go through the three different kinds of break points.

3) How to detect the slope and increase/decrease the velocity respectively.

4) How to maintain the high velocity while keeping appropriate stability.

5) How to detect the end of the line and stop running immediately.

To solve these problems, a series of models of the track were built to test the behaviour of our buggy, and to figure out all the solutions to these challenges mentioned above. The analysis will be elaborated later on. In addition, all of the testing and analysis are based on the dimensions of the sensor board as shown in Fig. 5.

Fig. 5. Graph of the sensor board with relevant parameters

A. Control of Velocity and Direction For the velocity control, PWM control was used to output

variable duty cycles to the driving board, to control the velocities of both motors. Because of the mechanical mismatch between the two motors, even the same PWM could produce a different velocity. Therefore, keeping the two motors at the same speed became crucial and the first major problem. After a large number of tests, the relationship between the left and right motors at the same value of PWM was found experimentally as

0.9859right leftv v= (1)

For the direction, control, after a series of experiments, the decision was made that a normal corner (turning angle 45≤ ° , where the track can be detected by sensors 2, 3, 5, 6), the speed difference between the motors would be used to change

International Conference on Magnetics, Machines & Drives (AICERA-2014 iCMMD)

its direction. However, for sudden sharp corner (turning angle 45> ° , where the track can be detected by sensor 1,7), the the rotation direction of one of the motor, would be changed to output a negative velocity in order to make the buggy turn as fast as possible.

B. Break Points There are three kinds of break points. For the 2 mm break

point, a delay function was used to maintain the velocity of the buggy for 0.1s. If it could re-detect the white line, normal control could be resumed.. The reason why 0.1 s was chosen is that tests showed that the buggy could go through further than the 2 mm break point in this time, while not going too far.

For the two-direction shifted break, the mark of the presence of this break is that the two sensors at the two sides on the sensor board detect the white line concurrently, but one of them is closer to the outboard of the sensor array. Therefore, this phenomenon provides the buggy with basic evidence to find out the real direction it should turn to. The algorithm can determine if sensor 7 and any other sensor detect the white line simultaneously, then the buggy should turn right; if sensor 1 and any other sensor detect the white line simultaneously, then the buggy should turn left.

Testing showed that the one-direction shifted break, could be regarded as the normal corner and the buggy could execute the turn right or left without any special setting.

C. Slope Testing the buggy on the slope showed that it was capable

of completing the climb, however the time it took to do this was significant. Detection of the slope using the tilt sensors outlined in Section III allowed an increase in the duty ratio to the motor controller, to increase the torque supplied to the gearbox, making it capable of tackling the hill climb in a shorter time period.

D. Stability The problem of stability is that with a higher velocity of

the buggy, the accuracy of line-following decreases, and the buggy may fail to detect the track and turn round effectively. To solve this problem, an innovative method called the While-Loop-Retrieve (WLR) algorithm was created to guarantee that the buggy would never miss the white line track. This method is described in Section V.

In addition, other factors that improved the stability, such as mechanical lubrication, and reduced computation delays, have also been taken into consideration.

E. Ending of The White Line When the sensor array failed to detect any white line track

for 0.1 s, it was programmed to signal that the final destination had been reached. However, there was only 200 mm between the destination and the end wall, and because of the inertia, the buggy maintained its fast velocity even after the voltage for two motors was set to zero. To solve this problem, the logic signals setting the direction on the driving board were inverted causing both of motors to run in reverse for 0.5 s in order to

brake the buggy. After testing, this method stopped the buggy within 0.3 s and with a 2.5 mm brake distance from the end wall.

V. INNOVATIONS This section identifies the innovative features that contributed to the success of the buggy

A. Tilt sensors By using tilt sensors, the buggy’s speed on the slope could

be controlled more precisely. This also allowed the stability of the line-following algorithm on the flat to be improved. Hence, there were three modes for the whole track: flat mode, up-slope mode and down-slope mode.

B. Ball bearing castor Before replacing the castor wheel, each time the buggy

finished a turn, the buggy could not revert to its original direction before turning immediately, which would cause severe oscillations. This phenomenon was eliminated after using the ball bearing castor because of its ball structure.

C. While-Loop-Retrieve Due to the high speed of the buggy, it was possible that all

sensors could lose the white line when the buggy turned a sharp bend, which could mislead the buggy into ‘thinking’ that the destination had been reached. In order to avoid such a situation, a while loop in the code was used, to help the buggy retrieve the white line. Specifically, when the rightmost sensor detected the white line, which means the buggy could miss the line later, a while loop was applied which continued the turn right until the middle sensor detected the line. A similar turn-left while loop was also used for the leftmost sensor case. The while-loop-retrieve innovation ensured the buggy could re-locate the line. This allowed the speed to be increased without considering the situation of missing line at the turn.

D. Bipolar PWM Bipolar PWM was used to control the direction and speed

of the wheels. After taking the speed and the stability into consideration, bipolar rather than unipolar was chosen. By using bipolar, dynamic braking could be implemented easily, which reduced the time of turning significantly and also allow the buggy to navigate more easily.

E. Controlled stop at high speed When the buggy is moving at high-speed, it is hard to fulfil

a controlled stop at the destination. The reversal of direction of both wheels for 0.3s, or until the sensors detected the line again, ensured that the buggy could stop in the required distance.

VI. CONCLUSIONS The buggy was completed early, demonstrating good

teamwork and planning. Before race day, the buggy worked fine, using the tilt sensors to adjust the speed properly and following the line smoothly. Two software “modes” were

International Conference on Magnetics, Machines & Drives (AICERA-2014 iCMMD)

implemented: a slow mode and a fast mode. On race day, the buggy was tested on the practice track before the race and adjustments were made to the tilt sensors. Another problem identified before our race was the repeatability of the controlled stop. The buggy stopped most of the time, but if it was too fast on the straight section of track before the end, it bumped into the wall. This was fixed by adjusting the timing in software. The buggy was tested again in fast mode, and ran perfectly including a controlled stop, so it was decided to run the buggy in fast mode on the first attempt of the actual timed trial.

In the first time trial, the buggy didn’t go up the slope. This was diagnosed as due the angle of the tilt sensor for the up slope being too steep; as the buggy was placed on the track before the race, the sensor was moved slightly, which effectively turned the sensor off. The up-slope tilt sensor was adjusted to a shallower (and hence sensitive) angle and the down-slope sensor was turned off. The buggy was tested again to check that everything was running smoothly for the next run; it finished the track, with a controlled stop in 6.8 s. In the second time trial, the buggy finished in 7.5 s but unfortunately bumped into the wall at the end. It was a good lesson, and it just goes to show that problems always arise last minute.

Overall, looking back, the buggy was designed well, and was simple yet efficient. The only design flaws were the original choice of sensors and castor wheel, but these were necessary lessons. The final cost of all the components of the buggy was £23.92 out of a total budget was £50, so less than half of the budget was used, which was cost-efficient overall. In the end, we are all proud of our work and will never forget what we learned and what we gained designing and building a white-line-following robot buggy. The experience was invaluable.

ACKNOWLEDGEMENT We take this opportunity to express our profound gratitude

and deep regards to our tutor, Dr. Judith Apsley for her exemplary guidance, monitoring and constant encouragement throughout the project. The blessing, help and guidance given by our university time to time shall carry us a long way in the journey of life on which we are about to embark.

REFERENCES [1] Vishay Semiconductors, Relective Optical Sensor with Transistor

Output, http://www.vishay.com/docs/83760/tcrt5000.pdf. [2] ‘UK standard for professional engineering competence’ (UK-SPEC),

Engineering Council, 2003, last updated 2013. Available at http://www.engc.org.uk/ukspec.aspx (Accessed 15/02/2013). http://www.engc.org.uk/ukspec.aspx

[3] http://www3.imperial.ac.uk/ugprospectus/facultiesanddepartments/electricalengineering/eleceng http://www3.imperial.ac.uk/ugprospectus/facultiesanddepartments/electricalengineering/eleceng

[4] http://www.strath.ac.uk/eee/undergraduatecourses/eeeug/ [5] Baharuddin, M. Z., Abidin, I. Z., Mohideen, S. S. K., Siah, Y. K., &

Chuan, J. T. T. (2005). Analysis of Line Sensor Configuration for the Advanced Line Follower Robot. In Proc. of Student Conference on Research and Development (SCOReD), Bangi, Selangor, Malaysia.

[6] http://luis.lboro.ac.uk/epublic/WP5015.module_spec?select_mod=12ELB0131.

[7] Sangiovanni-Vincentelli, Alberto, and Marco Di Natale. "Embedded system design for automotive applications." IEEE Computer 40.10 (2007): 42-51.

[8] Malinowski, A., & Yu, H. (2011). Comparison of embedded system design for industrial applications. Industrial Informatics, IEEE Transactions on, 7(2), 244-254.

[9] http://www.nasa.gov/centers/marshall/news/news/releases/2013/M13-053.html#.U51_t3a0TAk