AUTONOMOUS SLAM ROBOT MECHENG 706. Group 4: Peter Sefont Tom Simson Xiting Sun Yinan Xu Date: 5 June 2016

Transcription

1 2016 AUTONOMOUS SLAM ROBOT MECHENG 706 Group 4: Peter Sefont Tom Simson Xiting Sun Yinan Xu Date: 5 June 2016

2 Executive Summary The aim of this project is to design and develop an Autonomous Simultaneous Localisation and Mapping (SLAM) Robot to perform the navigational functions of a robot vacuum cleaner. The robot had to have the have the ability to build a map of the environment and self-navigate through a route without collisions to cover the entire area in the shortest time possible. The robot communicates with a computer via Bluetooth in order to send the necessary data required for localisation and mapping. A LabVIEW program on the computer fuses the sensor data to plot the path of the robot and a map of the field. The robot outlined in this report was successful in the final run of its demonstration. It was able to cover a large area of the testing platform in a reasonable time without hitting any obstacles after its initialisation period. The robot was able to smoothly navigate its desired path, and able to fully navigate itself autonomously from the beginning to the end of the demonstration. i

3 Table of Contents Executive Summary... i Table of Contents... ii Table of Figures... iv 1.0 Introduction Project Specifications Project Description Project Requirements System Design and Integration Path Development Initialisation Path Development Avoid Obstacles Hardware Placement Mechanical Design Final Setup Sensor Calibration Voltage Regulation Infrared Sensors Sonar Motion Processing Unit Motion Control Speed Control Strafing Control Rotation Control Wall Alignment Control Finite State Machine States of Initialisation Path Planning Obstacle Avoiding Localisation and Mapping Localisation ii

4 3.7.2 Mapping Testing Final Results Discussion Hardware Limitations Future Improvements Conclusions References Appendices List of Parts Mechanism Drawings Arduino Codes iii

5 Table of Figures Figure 1: Initialisation Step Diagram... 2 Figure 2: Spiral Path Pattern... 3 Figure 3: Zig Zag Path Patterns... 3 Figure 4: Obstacle Avoiding... 4 Figure 5: Sensor Placement for the ZigZag Path... 6 Figure 6: Sensor Placement for the Spiral Path... 6 Figure 7: Electric circle for the Voltage Regulator L785CV... 7 Figure 8: Four Sensor Calibration Graphs (Relation between the voltage with the Distance). 7 Figure 9: The Block Diagram of the Fuzzy Logic Controller... 9 Figure 10: The Distance Membership Functions for Long Range Sensor (Left) and Short Range Sensor (Right)... 9 Figure 11: The Membership Function of the Output Speed Figure 12: Flow charts of the Finite Machine State (FSM) Figure 13: Flow Chart of the Path Planning Figure 14: Flow Chart of the Obstacle Avoiding Figure 15: Bluetooth Serial Input via NI-VISA Figure 16: Screenshot from the Video of the Rotational Velocity Testing Figure 17: Velocity and Displacement Calculations from Wheel Speeds Figure 18: Sensor data is rotated and plotted on the map Figure 19: To the left: The map produced in LabVIEW To the right: The actual path during the demonstration iv

6 1.0 Introduction Simultaneous localisation and mapping (SLAM) is the robotic process of tracking one s movement throughout an unknown environment whilst simultaneously creating a map of this unknown environment. Robotic vacuum cleaners are one typical application of this technology. This report details the system design process and the final design of one such fully autonomous robot. There are four main considerations in this project, which are the placement of sensors, the algorithm of navigation, the mapping, and the control systems. The systems thinking and integration are two key factors in this project. For the final design, two medium range infrared sensors were mounted on the side for wall tracking; while the sonar and two infrared sensors were faced to the front of the robot for obstacle detection. A motion processing unit (MPU) was used to detect the dynamic manoeuvres of the robot. Two PID controllers and a fuzzy controller were used to improve the accuracy and the stability of the movement. A finite state machine was used to control the execution sequence of the robot s path and motion. 2.0 Project Specifications 2.1 Project Description A breadth of knowledge and technologies across mechanical, electrical, and electronic engineering were applied to complete the Autonomous SLAM Robot design project. Computational technologies were used during the design of this robot, particularly in motion actuation, sensing and signal processing, programming and microcontroller sections. For the final result of this project, the robot should be able to cover entire area of the testing platform and without collisions. The platform for the final testing was a 1200 x 2000 mm table, with three cylindrical obstacles placed randomly on the platform. Assessment would be equally based on area coverage, the number of collisions, and the total time for a complete run. The robot was supplied with four individual servo motors and Mecanum wheels, four infrared (IR) sensors, one sonar sensor, and a 9 axis MPU-9150A. An Arduino Mega 2560 microprocessor was used as the computation centre of the robot. This microcontroller was programmed to read sensor data and then apply appropriate motor signals to control robot appropriate behaviours. 2.2 Project Requirements The final design had to achieve the following criteria in order to accomplish the project: To become fully autonomous and have the ability to self-navigate, without any human intervention once it gets started. Able to avoid objects placed randomly within the environment. Have the ability to build a map of the environment. A complete coverage of the assigned area in the shortest amount of time. 1

7 3.0 System Design and Integration 3.1 Path Development Design of the system began with considering the path of the robot. This was fundamental to the rest of the system as it determined the outcome of other stages of the design. The pathing algorithm is comprised of the following three components Initialisation Initialising the robot to a known location was identified as a necessity for a simplified robot path. By navigating to the corner of an area the robot is able to set a reference frame for its mapping and a start point for its desired path (shown in Figure 1.). To move to a corner, the robot first rotated a full 360 degrees to determine the nearest wall. It then moved to this wall, turned to be parallel with it and then travelled along it to a corner. During this initialising path, the robot was able to avoid anything in its path that it deemed to be an obstacle Path Development Figure 1: Initialisation Step Diagram With the assumption that the area in which the robot was to operate was a rectangle, two options for a desired path were identified, a spiral path or a zigzag path. The two patterns were compared against each other while concurrently considering simplicity, effectiveness, completion time, and sensor position. 2

8 Two sensors on the front of the robot and an MPU for rotation was thought to be the minimum sensor requirements for the spiral pattern. This option would give a full coverage of the area and also would navigate the perimeter of the area first which was seen to be useful for mapping purposes (shown in Figure 2.). This option was thought to be simple and fast as only a turn and straight function would be required. Figure 2: Spiral Path Pattern The operation of the robot during the zigzag pattern would be dependent on the position of the sensors. The two possibilities were to strafe from wall to wall or to drive forwards and perform a 180 degree turn at each wall (show in Figure 3.). The strafing option, although fast and simple, would require a minimum of two sensors on three sides of the car and given the hardware provided this was implausible. The option to turn 180 degrees at the wall was relatively complex and thought to be slower than the spiral pattern due to the number of operations required to turn 180 degrees and find the new path across the area. Conversely, the minimum sensor requirements were thought to be identical to that of the spiral pattern. Figure 3: Zig Zag Path Patterns 3

9 The spiral pattern was finally chosen as the best option to implement Avoid Obstacles The ability to navigate around an obstacle was considered after the desired path was chosen. As the robot's path is in a clockwise spiral, it was decided for the robot to avoid all obstacles by moving to the right regardless of the position of the obstacle relative to the robot s path (shown in Figure 4.). This eliminates the possibility of hitting a wall while avoiding an obstacle. Figure 4: Obstacle Avoiding Three concepts for obstacle avoidance were considered. These were: 1) Stopping in front of object, turning 90 degrees, moving forward until past object, turning back to straight, moving forward until clear of object, turning to face wall, moving to wall, then turning to be straight and continuing on desired path. 2) Stopping in front of object, strafing right until object was not in front of robot, moving forward until rear of robot was past object, strafing back and continuing on original path. 3) Detecting object from a large distance, beginning to strafe while moving towards object, once past object strafe back to wall while continuing straight. The second option was chosen because it covers more area than the third and requires less operations than the first. 3.2 Hardware Placement The hardware that was supplied along with the assembled Mecanum wheeled robot required mounting on the robot in useful positions. These components included four IR sensors, a sonar, a servo motor and an MPU. Careful placement of these sensors was dependant on the pathing and planned mapping method. 4

10 3.2.1 Mechanical Design The sensors were placed strategically to ensure the dead zones of the sensors were within the volume of the robot. This meant all of the sensors would be able to detect obstacles right next to the robot. It was also made sure that the path of the associated physical phenomena was clear. The sensors were first placed in a CAD model at their desired location in free space and then mounts were designed to assemble them to the robot. A mixture of additive manufacturing and metal fabrication was used to mount the sensors as accurately as possible in a narrow time frame to allow for testing and debugging. The mounts were iterated as problems evolved. In example, the first concept did not have the front facing short range sensor over the front wheel, but further inboard. This limited the possibilities in obstacle avoidance as this design does not rely on timing for avoidance. The MPU was originally insulated and installed close to the Arduino however we found it was prone to magnetic interference of the chassis and motors so we created a mount tall enough to limit the amount of interference. The design utilised a simple slot for the MPU to sit in and it was bolted to the left chassis rail Final Setup With the path pattern finalised and a couple of weeks of testing experience, a final setup was decided upon. Figures 5 and 6 display the differences between our first testing set up and the final set up ready for proper runs. The two medium range sensors facing the wall were utilised to provide spot-on wall following which meant the robot was always moving in a straight line and made a perfect outline of the walls on the mapping program. The combination of three front facing sensors were key to the success in avoiding obstacles that the robot came across, while the placement above the wheel of the short range sensor meant the robot was able to know when it was safe to move past an obstacle without any finicky timing. It was decided that the sonar would be best utilised in a static position and that the mapping would occur in real-time as the robot moved about its path without the need for a sweeping sensor. 5

11 Figure 5: Sensor Placement for the ZigZag Path 3.3 Sensor Calibration Figure 6: Sensor Placement for the Spiral Path Precise calibration of all of the sensors was required so that the voltage readings from the sensors gave an accurate measurement relative to the actual position of the sensors Voltage Regulation The sensor supply voltages were originally sourced from the 5V pins on the digital I/O. However, after a week of running the robot it was found that there were large variations occurring day-to-day between the sensor readings. Upon further investigation it was realised that this was due to two reasons: Introducing new loads to the system such as another sensor or servo, and the battery supply voltage decreasing over time. In order to rectify this a voltage 6

12 regulator circuit was constructed on stripboard. The supply for the voltage regulator was the battery voltage pins on the Arduino which were typically around 8V. The L785CV voltage regulator utilised can handle up to 18V making it perfectly suitable. Three-pin male headers were put on the stripboard in order to make installation quick and easy (shown in Figure 7.) Infrared Sensors Figure 7: Electric circle for the Voltage Regulator L785CV The IR sensors work by sending out a signal from a light emitting diode, this signal will reflect off from objects and can then be detected by a photodiode. Based on the intensity of the signal, which is determined by object reflectivity and distance, the sensor outputs a voltage. Calibration was required to find the relationship between the output of the sensor and the actual distance from the sensor to the object, or the wall, in the platform. Figures 8 below show the relationships of all four sensors. Figure 8: Four Sensor Calibration Graphs (Relation between the voltage with the Distance) 7

13 Sensors were calibrated by fitting multiple linear equations into the raw data relationships. A moving average filter was used to remove the noise from the sensor readings. A window length of 40 samples was used and the output was the average of the 40 readings. This filter caused slight delay of the output, however the improvement to the accuracy of the data outweighed this drawback Sonar The HC-SR04 sonar provides a range of 2cm-400cm with an accuracy of 0.03cm. In this this system, the pulse width output from the sonar was used to detect the distance at the front of the robot. The distance of the object or wall from the sonar was calculated by noting how long sound waves take to leave and come back to the sonar sensor. The speed that sound travels is 344m/s. By multiplying the duration taken to travel by the sound wave by the speed of sound we get the total distance travelled by the wave. Because the signal takes the same time to send and receive, this value must be halved to get the distance of the obstacle from the sensor. An effectual angle of less than 15 degrees was required for the sonar to give a proper reading. Any reading less than 2cm or higher than 400cm would be not recorded for the ease of mapping. Reliability of the sonar when detecting obstacles was a problem due to their curved surface. For this reason, the sonar reading was compared with the front IR sensor readings for obstacle detection. 3.4 Motion Processing Unit The MPU-9150 consists of a 3-axis accelerometer, a 3-axis gyroscope and a 3-axis magnetometer. An external library which contains several functions to set up, calibrate and read the data from these sensors was used as a base on which to build on. The main reading of interest from the MPU was the instantaneous rotational speed in the Z- axis. A yaw value was calculated by taking the sum of each sample multiplied by the time interval since the previous sample. This method proved to be accurate at measuring the angle at which the robot turned through, however, after these turns the gyroscope started to drift. An attempt was made to use the Digital Motion Processor (DMP) integrated within the MPU. Although this improved the accuracy and minimized the drift of the yaw reading, the length of time that the reading took to initially settle was far too long for practical use and so this idea was no longer pursued. The problem involving the drift of the gyroscope was resolved by resetting the MPU at each corner so that the gyroscope did not have enough time to build up enough drift to make its readings invalid. An attempt was made to determine the location of the robot through using the acceleration values in the X and Y axis and integrating them twice with respect to time. This method however, generated large amounts of drift due which resulted in unusable values of position. 3.5 Motion Control The motion of the robot was controlled through several different controllers. Fuzzy logic was implemented for speed control whereas PID controllers were used for the remainder of the operations. 8

14 3.5.1 Speed Control A fuzzy logic controller was used for the automatic speed control to allow the robot to have increased reaction time. The fuzzy logic was the control of simple loops instead of PID controllers, and it can also handle a nonlinear plant behaviour. A block diagram of fuzzy logic controller is in Figure 9. Figure 9: The Block Diagram of the Fuzzy Logic Controller For this project, the reading data of the two front sensors were the input of the fuzzy logic. Therefore, two different membership functions were required since those sensors had different range of measurements, and those functions were used for converting the distance measured into a fuzzy value between zero and one (shown in Figure 10.). For example, if the distance reading of the short range sensor was less than 2cm, the output of the near case would be 1, and the far case would be 0. And for any distance that was greater than 32cm, the output of the near case would be 0, the far case would be 1. Figure 10: The Distance Membership Functions for Long Range Sensor (Left) and Short Range Sensor (Right) The only required output of this fuzzy logic control was the speed of the robot. The membership functions of the speed could be divided into three parts: slow, medium and fast (shown in Figure 11.). Because the actual range of the speed value for the robot was from 75 to 200, the fuzzy value for slow was multiplied by 75, the medium fuzzy value by 100 and the fast fuzzy value by 200. The final output of the speed value was the sum of those three values. 9

15 3.5.2 Strafing Control Figure 11: The Membership Function of the Output Speed The primary function of the strafe state was to ensure that the robot was the correct distance from the wall. In order to move to this specified distance, a strafe PID controller takes side sensor reading comparing with desired distance to the wall to do strafe. This controller would strafe the robot towards the desired distance from the wall based on the readings from the side sensors. Once the robot was within a specified range from the wall, it would stop and move into the next state. The problem with this controller was that due to the systems response time, the band of acceptable distance from the wall was not able to be very small otherwise the robot would continuously overshoot the limits and oscillate about the desired value. A PID controller was developed as a solution to this problem. The controller took the error (e(k)) between the current distance reading of the side IR sensors and the desired distance from the wall as the input. Using Equation [1], with manually tuned values for the gains (Kp, Ki and Kd), the controller set the speed value (U(k)) to a value from 75 to 200 as this was the operating range of the motors. U[k] = u[k 1] + e[k] (Kp + Ki + Kd) + e[k 1] ( Kp 2Kd) Rotation Control +e[k 2] (Kd) [1] The initial controller for rotation of the robot was a simple limit controller. The robot would turn until it reached the set value of rotation based on the reading from the gyroscope. Similarly to the initial strafing controller however, the response time of the system caused a large amount of overshoot with this method and so it was decided that a PID controller was to be implemented. This was done by using the same equation as the strafing control (Equation [1] above) with the difference between the desired rotation and the actual rotation value as the error input. The gains of the rotational PID controller were tuned so that it gave a slightly overdamped response. This type of response was preferred over an underdamped controller due to the speed requirement of the run. 10

16 3.5.4 Wall Alignment Control The robot was able to self-align itself with a wall using either the two front sensors or the two side sensors and the states square_f and square_s respectively. The robot aligned itself at two different stages throughout the state transitions. The square_f state was only used when the robot first detected a wall so that it initially aligned itself before turning to be parallel with the wall. The square_s state was used after each strafe state, to realign itself if the turn or strafe operation caused the robot to become misaligned. These states employ a simple proportional controller which directly changed the speed value being sent to the motors based on the difference between the readings of the two sensors being used. If the absolute difference between the sensor readings was less than 1 cm for square_f and less than 0.25 cm for square_s, then the robot was deemed to be aligned with the wall and proceeded to the next state. 3.6 Finite State Machine The number of states was dependant on several elements such as the path algorithm and the placements of sensors. Over-complication of the finite state machine (FSM) would be an easy mistake as the task of the robot is not simple. However, careful analysis of the tasks and a comprehensive design of the FSM allowed the amount of states to be kept at a minimum. There were only three initial behaviours required for this robot to achieve the spiral pathing and obstacle avoidance. 1) If the robot could not move forward due to an obstacle, it would strafe right first to prevent collisions then strafe left to its original path of movement. 2) If the robot could not move forward due to a wall, it would turn 90 degrees clockwise. 3) Otherwise the robot would always move straight forward in its designated path. For the final design of this robot, three main states were used to achieve those three behaviour rules stated above. These were the state of the initialisation, the state of path and the state of avoidance. Under these three main states, there were 11 small states to specifically control different movements of the robot (show in Figure 12.). Sensor readings were used as the input of the finite state machine, and the motion control was the output from those states. 11

17 3.6.1 States of Initialisation Figure 12: Flow charts of the Finite Machine State (FSM) When the power was turned on, the MPU and the battery were checked in the initialising state. If the MPU was not connected properly or if the battery level was too low for moving, the state would directly change to the stop state. After status checking, those four servo motors would be running at a stationary condition and wait for commands. There was an extra state called the start state. It initiated IR sensors and the sonar, when the power was turned on as those sensors need a warm up time to allow the readings to calibrate 12

18 from 0 to its true value, due to the filter size being 40 samples. When the sensor reading was greater than a specific set value, the FSM would move into the states of path Path Planning There were four states inside of the path state, that allowed the robot to move along walls and move in a spiral pathing (shown in Figure 13.). The strafe state was operated after the straight state to ensure the robot was moving in a specific side distance to the side wall and was facing the front. This state basically depended on the two side sensors to measure the distance between the robot and the side walls. The robot would keep strafing left or right with a low speed in the strafe state. It would move into the straight state when the average reading value of those two side sensors were equal to a specific side distance. A PID controller was used for the strafe state to allow the actual side distance to be as close as possible to the set side distance. The square_s state was required after the strafe state to ensure the robot was parallel to the wall. This state allowed the MPU reset in order to clear the stored data in the registers and eliminate any drift that might have occurred. While the robot was moving straight, it would have encounter situations in which a wall or obstacle blocked the path of movement at the front of the robot. When the front distance was set below 37cm, the change of state would be dependent on two front sensors. Once the front distance was set above 37 cm, the short range sensor would be out of its range, therefore the change of state would be depended on the sonar. If the reading values of two front sensors or the sonar were smaller than a specific front distance the robot deducted that it had met a wall and the next movement was to turn 90 degrees. Otherwise if the difference of the reading data between those front sensors and the sonar was greater than 15cm but smaller than 19cm, then the robot would deduct that an obstacle was in its way and move into the states of avoiding. Figure 13: Flow Chart of the Path Planning 13

19 3.6.3 Obstacle Avoiding The avoiding movement was divided into five states (shown in Figure 14.). Every time when the robot thought there was an obstacle in the front, the first state would be to check if was an actual obstacle or if it had come at an acute angle to a wall. If there was an obstacle in the front, then the robot would strafe right immediately until the short range sensor detected the obstacle, otherwise the robot would return to straight state. Then the second state of avoiding allowed the robot to keep strafe right until the reading of the short range sensor was greater than 15cm then it would move into the third state. The third state was aiming to have the robot to move straight forward until the reading of the medium range sensor at the rear of the robot was lower than 15cm. In the fourth state of the avoiding, the robot would keep moving forward until the reading of that medium range sensor was greater than 15cm, which means the robot have passed the obstacle. At the end, the robot would strafe left to its original path of movements. Figure 14: Flow Chart of the Obstacle Avoiding 14

20 3.7 Localisation and Mapping Data was received over a serial Bluetooth link by the LabVIEW program using the National Instruments Virtual Instrument Software Architecture (NI-VISA). A simple pattern match and string-to-number conversion method was used to gather the data necessary for calculations. As shown below in Figure Localisation Localisation of the robot was achieved by using odometer. The speed of the robot at various pulse width inputs to the servos was experimentally obtained in order to produce a mapping of pulse width (input) to speed (output). As there was no direct way of measuring an individual wheel s velocity it was assumed for the purposes of localization that all of the motors rotated with the same rotational velocity given the same input, even though in reality this wasn t true and the robot would veer one way. Figure 15: Bluetooth Serial Input via NI-VISA Figure 16: Screenshot from the Video of the Rotational Velocity Testing However, it was decided this was an entirely reasonable assumption to make as the rotation and line following control was very good. After finding the velocity of each Mecanum wheel, equations [2] and [3] were used to determine the X and Y velocity vectors of the robot. Given that the coordinate system is: Vx = (ω1 + ω2 + ω3 + ω4) r 4 [2] 15

21 Vy = ( ω1 + ω2 + ω3 ω4) r The LabVIEW program integrated this at 10ms intervals to find the displacement. Before adding the current displacement to the previous displacement the MPU reading is then used to rotate the newly found coordinates into the current frame orientation. This code continues to iterate and plots a reasonable path of the robot. 4 [3] Figure 17: Velocity and Displacement Calculations from Wheel Speeds Mapping Figure 18: Sensor data is rotated and plotted on the map Mapping was achieved by taking the IR and sonar sensor outputs, offsetting the sensor from the centre of the virtual robot, adding the values in the correction direction, rotating the coordinates to the current robot's frame, and then adding the value to the current position, and plotting it. This method worked well, using the existing moving average filters aforementioned on the Arduino. This method does however rely heavily on the odometer for the robot path being accurate and so there was some error. The resulting map was proportional and could clearly show where the robot had travelled and where the obstacles were relative to the walls in real-time. 16

22 Figure 19: To the left: The map produced in LabVIEW To the right: The actual path during the demonstration 4.0 Testing Thorough testing was necessary for the design and functionality of the SLAM robot and was performed for all aspects of the robot. Initial testing was primarily for hardware performance and involved testing the range of sensors after calibration as well as testing for any inherent differences in the servo motors. From these test it was discovered that the long range IR sensor was only capable of reliably reading up to 80cm rather than the 150cm specified on the data sheet. Testing of the servo motors revealed that they required calibration to ensure equal performance. Later testing of the robot was primarily used to validate the functionality of the code. Newly written portions of code, such as a new state or function, were first tested individually to ensure they performed as desired and then tested as an integrated part of the system. In order to debug the any problems that were encountered, outputs of sensor readings and the current state were sent over Bluetooth to a computer so that a written output of what the robot was doing could be seen. Flags were also set and output at stages which were thought to be the source of the bugs. Problems such as response time of the robot and insufficient voltage being sent to the wheels were discovered during this stage of testing. The results of these tests also helped to alter and improve the design such as repositioning the sensors or tuning the controllers that were implemented. 5.0 Final Results The demonstration run was successful. The robot had a small issue with an obstacle during initialisation but once it began its path it avoided all obstacles and covered the entire map. Rotation control and line following were executed very well. The labview mapping program provided a proportional representation of the robot's path, walls, and obstacles. The robot finished the run in 2 minutes and 45 seconds. 17

23 6.0 Discussion 6.1 Hardware Limitations There were 3 main limitations of the hardware provided which hindered: the effectiveness of wall following, wheel speed feedback, and mapping. One of the main issues found was with the Sharp IR sensors. It was found that with long range sensors after about 85cm the voltage output started to invert which meant that a particular voltage could have meant 2 different measurements. This type of 2-to-1 mapping was inherently flawed and not useful without other logical inputs. What this meant was that we could not see multiple points of at least 2 walls at all times to allow for ideal orientation control. This lead to relying on the MPU for long periods of time without any sensor fusion. The Sharp IR sensors were very susceptible to light interference from multiple sources. For example, in the afternoon while the sun was setting and light came through the window and cast shadows and caused areas of large reflections which skewed some of the IR sensor readings. Even casting a shadow or small nudges with your hand caused disproportional variations in the output. Due to the number and quality of sensors the classic issue of localisation and mapping was amplified with the robot not being able to accurately know its position from a fixed origin at all times nor could it accurately interpret the map features surrounding it at all times. 6.2 Future Improvements Rotary encoders on each axle could have given a closed loop control system of both the velocity and pose of the robot with high accuracy. The robot had to rely on IR and Sonar sensor inputs from map landmarks in order to plan its path. The mapping and obstacle avoidance could have been well served with a 180 degree LIDAR sensor. These sensors have incredible refresh rates and great accuracy that along with some rotary encoders on the wheels could have plotted an excellent map and kept track of obstacles with ease. 7.0 Conclusions The SLAM robot performance was up to the standard laid out by the brief. Even though there was a slight fault at the very beginning of the demonstration the robot performed very well amongst its peers. The following conclusions can be made from the project: The robot completed the runs entirely autonomously The robot avoided all obstacles after its initialisation stage There are a few areas, namely the rotation and initialisation, where the time could have been reduced further. The time taken was 2 minutes and 45 seconds. Coverage was incredibly efficient with little overlap of paths taken. The LabVIEW mapping program produced a path and obstacle map with a strong resemblance to the real path. 18

24 8.0 References Arduino. (2016). Arduino MEGA 2560 Schematics. Retrieved from ELEC Freaks. (n.d.). Ultrasonic Ranging Module HC - SR04. Retrieved from InvenSense. (2011). MPU-9150 Register Map and Descriptions Revision 3.0. Retrieved from SHARP. (2016). GP2D120XJ00F. Retrieved from SHARP. (2016). GP2Y0A02YK. Retrieved from SHARP. (2016). GP2Y0A21YK0F. Retrieved from 19

25 9.0 Appendices 9.1 List of Parts Quantity Part 1 Arduino Mega Sensor Shield Arduino bluetooth module 1 2S Turnigy LiPo Battery 2 Sharp GP2Y0A02YK Medium Range IR Sensor 1 Sharp GP2D120XJ00F Short Range IR Sensor 1 Sharp GP2Y0A02 Long Range Sensor 1 HC-SR04 Ultrasonic sensor 4 Bearings 2 Vex Chassis Rails 1 Plastic Cover w/ Switch 4 Mecanum Wheel 4 VEX Servo Motor 1 MPU holder 1 Rear dual sensor mount 1 Front sensor mount 1 Side sensor mount 4 Vex 3" Shaft 1 Vex 5x15 Plate MPU 1 L785CV Voltage Regulator 1 80mmx50mm veroboard 4 3-pin male headers 1 2-pin male header 1 330nF capacitor 1 100nF capacitor NOTE: All wire and small components omitted 20

26 9.2 Mechanism Drawings Front Sensor Mount Rear Dual Sensor Mount 21

27 Side Sensor Mount 22

28 9.3 Arduino Codes Sonar Calibration 23

29 PID Controllers 24

30 25

31 Sensors Calibration 26