2018 First Year Project

Given my exposure to robotics in secondary school, creating a robot for my first year project was no daunting task as i had a wealth of experience in this area. The challenge of the first year EE198 robotic project was as follows, to design and build a functional robot that could travel around a white arena, the arena itself is 7ft by 7ft wide. In addition, the robots would need to pick up three red balls out of 9 balls in total. The remaining balls were three blue balls and three green balls. Each of these Red balls, and red balls alone must have been deposited in an end zone that is located at one of the corners of the arena. The robot should have be able to see the perimeter wall and turn accordingly, it should also be able to distinguish between each coloured ball, pick up each red ball in an effective and reliable way, and drop it in the end zone. This robot was also named 'Monty' as a homage to my first robot. All teams were given a Makeblock Ultimate 2.0 kit. Each kit contains about 50 beams that can be used to construct the robot. Along with about 100 screws and 50 Nuts. About 8 small and large wheels and three motors. Along with the kit, a Pixy cam was provided. The inputs that were included were, Bluetooth Module, Ultrasonic sensor, Line follower, Accelerometer along with a Robot gripper. The mother board was used to control the robot, the Board itself was is powered by 6 AA batteries. The pixy camera, distance sensor and all motors were connected to the board. Through the Arduino software, the robot could be programmed to function the way the team wanted it to.

The challenge we had to accomplish was to ultimately collect the correct balls and deposit them in the correct area. This challenge came with numerous problems. To successfully complete the challenge, we had to overcome the following problems.

• How were we supposed to pick up the ball?

• How were we supposed to decipher between the right golf ball, and wrong golf ball?

• How do we detect the wall and turn accordingly?

• How were we supposed to detect the end zone?

While doing researching and designing the robot, all these problems were considered. To pick up the ball should ‘Monty’, pick up the ball with a claw and deposit in the area ball by ball which is a tried and tested method. Or should the robot have more of an experimental collection method as shown via the track example. Which was the best possible option? No matter the collection method, the right balls need to identified so they could be collected by the robot. While a Pixy Cam was provided to identify the balls, it remained unknown how to code the camera, it took quite a while to figure out how the cam worked, this in turn took time from other aspects of the robot, as the end zone was coloured we used the pixy cam to detect the end long also.. Also, the robot had to detect the perimeter wall. In the set we are given a distance sensor, programming this to detect the wall was also difficult.

Approach

The Approach that the team followed was the Hyman model. Before starting the build and while researching design models, the Hyman model seemed the like the model that best suited the team. First, the task was given at the start of the semester. The problems of the task had to be identified, these problems are discussed and analysed in the above section. By researching past ideas and solutions that dealt with the task of picking and placing objects, or even robots that dealt with only certain elements of the task such as movement or collection methods we could plan the design of ‘Monty’. As all members of the team lived close by, the study rooms in the library was a frequent meeting stop to discuss ideas and address problems. By Evaluating the alternatives, all members decided what could work and what couldn’t. With all ideas discussed a preferred design was chosen. With the final idea decided, the team needed to communicate the design and make changes until everyone was completely satisfied with the finished design. With the design step done, the team focused on the build of the robot.

To construct the robot, the official approach was to work from the 3D models that we made for the robot. A 3D model of ‘Monty’ with all improvements and alterations was created, while building the robot, the team followed this 3D model as best as possible. Due to the limitations of kit that was provided, the 3D model could never be 100% replicated, so certain changes were required. If there were problems with the design that we overlooked while in mid-build, the team would decide what to do and solve the problem accordingly.

Similar to the build, the programming of the robot was experimental. As C++ and the Arduino software was new to the team, research was vital, as was trial and error (a lot of error). The robot would be programmed to function the way the team wanted it to, of course this didn’t always go to plan. While we followed the Hyman model in design, the building of the program contained an element of experiment. With each change being made to see what works and to see what doesn’t.

Final Design & Manufacture

The final design was chosen after careful deliberation amongst the group. It was agreed that the best design was the conveyer design. There were many reasons for this decision, with a pick and place style, the programming would be quite difficult as it would have to have a high level of accuracy to be able to collect the balls. With the conveyor design, the program does not have to be as accurate due to the width of the conveyor and guides at the front. While the program still must be accurate, it was decided that the conveyor style would allow more room for errors than the pick and place style would. The main issue with the gantry style design was the number of motors needed was too great. There were three motors given in the kit and it was decided that at least four motors would be needed to implement this design effectively and even with four motors it would be difficult to implement. This meant that this design was discarded relatively quickly. Another problem with both the pick and place style and the gantry styles was where to store the balls after they had been collected. If the robot had to go to the end zone and drop a ball each time it picked a ball up, the robot would be inefficient as it would take a long time to complete the task of picking up all three balls. This also influenced the decision in the selection of the conveyor style robot.

After the style of robot had been chosen the design of it had to be decided. In the initial design the ball would be guided to the conveyor by the guides and then be pulled in by the spinning conveyor. The ball would be seen by the pixy cam and then robot would then travel to the ball. The ball was then supposed to be stored somewhere behind the conveyor, but this was changed as a solution to releasing the balls. The conveyor could now be reversed instead of trying to find a way to drop them out the back. This saved a lot of time as it was a big problem at the start when this was design was first finalised. The distance sensor was used to recognise the wall or any other obstacles that the robot might be faced with and then turn to avoid it.

Throughout the building of the robot there were a few small changes made to the design of the robot. The most significant change was the one that was made to the wheels. Four wheels were used at the start of the project but these wheels struggled to find traction while turning and this effect the robots’ efficiency. At first weights were added to the two drive wheels. This made some difference but the traction but not enough. As ‘Monty’ is neither preprogramed or operating on a completely smooth surface, the team knew it needed a new approach to get the robot to move correctly. An extra track was then borrowed off another group. With this extra track we could use tracks on both motors, instead of the previous wheels. This made a big difference, but in the only two places that the drive gears could be placed, the tracks were either too tight so the motor couldn’t drive or too loose where the gears were slipping in the track. A third tensioning wheel was added to tension the track, so the driver gear didn’t slip in it. This solved the problem, thus the robot’s movement problems were now addressed.

As the robot had to address the problem of noticing the wall, the distance sensor that was provided with the kit was ideal to combat this issue. Attached to the front of the robot, it was placed in such a position that it could notice the wall as quickly as possible to ensure a rotation away from the wall.

To drive the tracks, the robot contains three motors. One motor powers the left track and the other motor powers the right track. These two tracks allow the robot to move straight as well as turn. The third motor powers the third track that is used to guide the correct balls into the robot, and when in the end zone to guide the balls out of the robot. The two driving tracks are driven by two 185RPM motors. The conveyer track is driven by an 86RPM motor.

Programming

The robot is operated and controlled by an Arduino Mega Pi board. To begin, a simple algorithm was designed as follows.

Scan the area.

1. If the colour red is detected, turn the robot to centre the red, and drive towards it.

2. If there is no colour detected, move to a different position and scan again.

3. If there is a blue or green ball in the way, avoid it.

4. If all the balls are collected, drive to the end zone and deposit them there.

After constructing the algorithm, mBlock software was used to program the robot to move forward, activating all three encoder motors. A sample code online was used to begin coding the Pixy Cam, along with PixyMon to register the red, blue and green signatures.

Coding the robot to drive forward, backwards and turn displayed the difficulty of the task ahead. Using a code submitted by one of the students in the class, the encoder motors could be programmed as DC motors, making the code simpler and easy to read.

Along with the Pixy Cam and three motors, the robot needed to avoid the walls of the arena and turn if it gets too close. To do this, the Ultrasonic distance sensor was connected to the Arduino board, and coded to activate the turn function on the robot if it came within 30cm of an arena wall.

Using the scan method from the sample PixyMon code above, and several methods using the motors to turn, drive and reverse, the robot could aim itself towards the red golf ball, and away from the green and blue.

Implementing while loops and break statements, the robot could gather the red balls and travel around the arena semi reliably. The robot could definitely detect the different coloured balls. However it had problems driving towards them, and got confused to where the end zone was.

Testing

Throughout the project the robot was continually tested. Each individual component needed was tested separately and then tested together. Testing each component separately ensured that each component worked, and this ensured that they would work together. This meant that while testing the robot any problem encountered was not due to an individual component not working.

When the pixy cam was first connected to the laptop it could not be recognised by the laptop. At first it seemed that human error was to blame but as more testing was done it was found that the pixy cam was not working, and the team was given a new pixy cam. The new pixy cam was tested individually by setting signature 1 to red and holding the red ball in front of it. Using PixyMon it could be seen that the signature was detected. The ball was then moved further and further away until it was 2.5 meters away. The pixy cam could still detect the ball at this distance. This showed that the pixy cam worked. It also showed that the ball could be recognised anywhere in the arena as the arena is two meters by two meters.

The ultrasonic (distance) sensor was tested by using a simple code. A code was written which created a variable called dis. The code then said if dis was less than 10 a message saying “wall” would print to the screen. The distance was set to centimetres. The message printed correctly each time, this showed that the ultrasonic sensor worked correctly.

The motors were tested at the start by building one of the designs given in the booklet. This design used all three motors and showed that all three motors were in perfect working order.

After the robot was built the coding was started. After each piece of new code was written the robot was test thoroughly. Often certain components failed to work but that was due to the code and not the component.

While testing the robot a few problems were encountered. The first was that the robot continued driving towards the wall even after the wall should have been detected. The robot would hit the wall and then reverse and turn. The distance was increased so the robot would get a signal to turn quicker. This solved the problem, so it seemed that the time it took for the wheels to get the signal was the cause of this problem.

The turning of the robot was another issue found while testing. As discussed in the design stage of this report the wheels were used at first, but the wheels were slipping so weights were added. This made some difference but not enough, so the tracks were used but the tracks were loose, so the drive gear was slipping in the track. A third gear was added to tighten the track, and this solved the problem.

The testing also showed how the robot struggled to pick up the balls when it saw two balls close together. If two red balls were close together it didn’t know which one to go to and if it saw another colour close to a red, it turned away as its programmed to avoid the other colour. These two problems are very difficult to solve and tin the end they couldn't be solved due to time constants.

There were also many other small issues found by testing the robot such as nuts loosening by spinning parts and simple solutions were found for these problems such as using a lock nut.

Conclusion

In Conclusion, the team was tasked to create a robot that could collect balls within a perimeter and release them in a specific area. To design and create the robot, the team had to look back at robots that came before it, not only notable relevant achievements in robotics, but also past solutions to a similar challenge. With the design picked and progressively refined, ‘Monty’ was build as close to the 3D model as possible, with certain design alterations required due to problems overlooked in design stage. While the build did pose certain challenge that required creative solutions, the programming was the most challenging aspect of the robot. Due to the challenging nature of the programming, it always felt like one step forward and two steps back. One day it would work, and another day wouldn’t. While the team did get the robot collecting the right balls semi-consistently, it could not identify the end zone to drop the balls in. While there were many aspects that were a success such as detecting the wall and the different coloured balls, problems with multiple balls in view confusing the robot, and problems detecting the end-zone meant that the robot could not perform its task. Even with experience in design, manufacture and programming, under real world time constraints there are no guarantees a product will work. Given that this was my first time programming an Arduino, and partaking in a university project, I am happy at the progress we had made and believe given more time we could have got it functioning correctly. Taking into account, all the reports and vlogs, for the project I got 51% overall. This section was heavily influenced by the teams report, which is listed below to provide more information.