Lab Report 2: Build a Line Following Robot
Introduction:
This document is a report on the design, building and testing of an arduino based robot that was produced to complete a line following and obstacle avoidance challenge. The robot was designed, built and programmed by Hugo Hall and myself over a three week period. In this document I will detail the task we were provided with and all the problems we faced during the design and construction of the robot. It will also explain the solutions we came up with and our reasons for choosing particular solutions. Finally there will be a section about the final performance of the robot and a summary of our findings.
The task:
The brief for this assignment was to build a robot from a Lego NXT set that uses Lego components but has an arduino microprocessor for control, instead of the standard NXT microprocessor provided in the kit. The robot had to undertake the following tasks:
· follow a line of white masking tape
· detect the end of the line
· avoid objects on the path
· calculate the path’s length
· map the area around the path as it follows it
to complete the task we were provided with :
· 1 arduino development board
· 1 NXT Lego Kit
· 2 NXT dc motors with built in encoders (360*)
· 1 sharp IR distance sensor (2Y0A21 F)
· l Ultrasound Sensor (SRF-05)
· 1 IR LED and IR Photo Diode
· 1 L293 dual h-bridge chip.
The test environment would be built on a micro mouse test surface with matt black floor and white reflective walls around the edge to be mapped. The performance would be evaluated on the accuracy of the measurement taken and the ability to map the surroundings.
The Design Process:
The first stage was to decide what our requirements for the robot were and what we wanted to include in the design.
The first decision we made was to use the smallest wheels available as this would increase the accuracy of the measurement of the line and would also make the robot slower and more controllable. With the Lego parts the smallest wheel that would fit on the motor had acircumference of 10cm which was useful as it is an easy number to work with later on when measuring distances. This meant that 360* rotation gave 10cm movement therefore each 36 encoder counts means the robot has moved 1cm.
The next decision that was made was to use an internal battery pack rather than power externally. This was because each NXT motor under load can pull 0.55 A at its recommended 9V operation level and even 0.6A at 4.5V as would be provided by USB (http://www.philohome.com/motors/motorcomp.htm). This is far greater than the maximum current of 500ma that can be provided safely by the USB cable. This would mean to power the robot externally you would have to hook it to a separate bench power supply and would need another set of cables running from the robot.
Extra cables could snag and would provide extra drag and wheel slippage leading to inaccuracies in the measurement. We chose to use a 9.6v 650mAh Ni-CD battery as it provided the required voltage and is a reasonable size to incorporate into the design.
After testing we found that the ultrasound and sharp IR sensor were both accurate however both were better in different circumstances. We found that the sharp IR sensor had a very focused field of view and worked best when perpendicular to the surface being measured. The ultrasound provided a much wider angle of view but was not very good taking accurate reading in corners as the sound reflected from closer points and caused inaccuracies. Because of this we decided to use the ultrasound on the front for detecting the obstacle and use the sharp IR on the side for the mapping or the surrounding area. Another thing that we found after reading the data sheet for the sharp IR is that it was most accurate if used upright when panning horizontally and if placed with the emitter end on top and receiver end on the bottom, it is not capable of receiving light past 90* so cannot get any interference or reflections from the floor.
The line sensor that we built worked well giving us readings between 400 on the line to 800 off the line but we decided that we wanted 2 sensors to get smoother line following so we purchased some of our own. Once built we set them the same distance apart as the edges of the masking tape that would be used for the line. This worked well and provided very accurate readings of position over the line. We also found that by angling the sensors we could eliminate most of the reflection from the black micro mouse surface and get reading from slightly in front of the actual robot.
After completing some testing we found that the most accurate way to read the encoders was to use an interrupt pin on the first encoder of the motor and a normal digital pin on the second encoder of the motor. As the interrupt was triggered by a change on the logic level of the first encoder, the second encoder was checked. If the values for both encoders were the same the counter was incremented, if different then the encoder was decremented. This meant that we could get a resolution of 360* per revolution from the motors and also check the direction of each movement.
The first full robot build was shaped like a cube with the wheels in the centre of each side and a servo to pan the front sensor. This design looked nice however we quickly found that it was not practical. There was not enough space on top for the breadboards and arduino to fit easily and making changes was very fiddly. We also found that this design was unstable and whilst accelerating backwards or coming to a quick stop the robot would lean forward and the rear caster would leave the ground. For this reason on the next design we decided to move the wheels further forward and try to reduce the centre of gravity. We also found that having a Wii Nunchuk connected to the robot as a controller was useful whilst testing. it was connected through I2C it gave us manual control of the robot. This meant we were able to easily simulate situations such as hard breaking or accelerating to see how the robot would react.
The second build of the robot was much wider and lower than the first to improve stability. We also decided not to use the servo to move the sensors and instead mount one on the front to avoid obstacles and one on the side for the mapping. This meant that we used 1 less pin on the arduino and had to send 1 less value back to the computer for the mapping. We also built this design with a specific space for the arduino and breadboard as they seemed like an afterthought on the last robot. This has made connecting up sensors and motor controllers a lot easier and more accessible. The only problem we found with this design was that the back of the robot was too low to fit a castor wheel underneath so instead we opted for a low friction skid pad as this worked just as well.
For the mapping we decided to use a program called processing as this was designed by the same group that designed the arduino IDE. It has many functions built in for communicating with arduino through a USB com port. The main benefit of processing is that It uses similar commands and functions as the arduino however can easily give visual representation of information. To produce the map we are recording where the robot moves and how far it is from a wall. This is similar to a dead reckoning system and uses the process of estimating its current position based on a previously determined position. The values for both wheel encoders and the distance recoded from the sharp IR are sent from the arduino through the USB to the com port, processing then reads this and uses the encoder values to calculate the distance travelled and angle of the robot. From this it then calculates the position of the centre, axel and wheels. With this information it updates the map with the new position of the robot and draws a wall at the given distance from the side. This process is repeated every 10ms gives 100 readings a second. It provides a very accurate map and is also capable of keeping count of the total distance travelled. The program also calculates the distance from start to finish “as the crow flies” so can accurately measure lines with obstacles on them.
The final problem that we found during testing was that the USB cable would often snag and cause the wheels to slip, this caused massive errors in the mapping and so we tried to find a solution. Eventually we found a set of radio transceivers called xbees that acted in place of the USB cable, this was ideal as we already had an internal battery to power the robot so didn’t need the power from USB. The xbee transmits the serial from the arduino directly so once they were set up they could be used with no modification to the robots code and could be swapped in and out as needed. This reduced the wheel slip a lot but presented another problem as there was a small amount of packet loss. This however was easily fixed by a quick change to how the robot sent the encoder values, this meant that if a single value was missed it would not affect the overall distance recorded on the map.
Performance:
We have been very pleased with the overall performance of the robot. In testing it has been able to follow lines smoothly and avoid obstacles well. it has also been able to produce very accurate scale maps of its surroundings. The accuracy of measuring was tested on a line exactly 1000mm long. When driven straight down the line the end to end distance was calculated to be 1009mm which is less than 1% off. When driven down the line and around an obstacle the end to end distance was calculated to be 1018mm. Although this is less accurate than the first reading it is still within 2% of the correct length. Considering the Lego wheels are soft and quite wide this could be giving the inaccuracies seen here however this is one of the constraints of using the Lego and could only be solved by changing to harder thinner tyres with more grip.
Test showing control on version 1 with the Wii Nunchuk
Conclusions:
Whilst completing this assignment I have learnt a lot about using distance sensors and what applications each type is useful for. I have also learnt about using interrupts to read the encoder values and how to send values through to another program to be processed.
If I was to complete this task again I think more time would be put in to the initial design as this would have meant that the first idea would of been of a higher quality and probably would not have needed re-building before we were happy with it. I would also like to implement some sort of PID speed control on the motors using the encoder values to calculate the error however time did not allow for this.
In summary we feel that the robot has performed well in our tests and we are confident that it will do well in its final assessment.
Qbotics 