Lab Report Robot Project - Grade: A+ PDF

Preview

Summary

This is a final lab report for Robot project. ENGR 10. San Jose State University . We got an A+...

Description

Robot Project San José State University, Charles W. Davidson College of Engineering, E10 Introduction to Engineering

Jerome Enriquez, Gaston Garrido, Dagan Johnson, Tram Phan, Jyoti Suri, Hoshea Valdez

E10 Section 08 - Group 3 Instructor: Dr. Ahmed Banafa

May 18, 2018

E10, Sec 08

Project Summary The purpose of this project was to design and create an autonomous, self-acting robot that could turn off a red infrared-emitting beacon and then move to, and later move a green beacon out of an arena, in the most time-efficient manner possible. Furthermore,the most efficient design would be a lightweight robot that contained accurate sensors and fine motor control. These tasks were orchestrated by the computer program, which ideally would allow the robot to perform efficiently. The robot contained two motors driving a total of four wheels, which were connected via multiple axles and a gear system. In order to complete the task, an arm was constructed, to turn off the first beacon. The arm was equipped with a scoop in the front and a plate on the bottom of it, allowing it to press the button of the first beacon and move the final beacon. Lastly, structural design of the robot included a box-shaped body, which surrounded the central electronic components such as the motor, IR Board ,and VEX Fig 1PS: The Group Prepares to test the robot controller. The body had a fork extending from it, stabilizing the beacon in place after grabbing the beacon. The IR Board allowed the robot to find the beacon, the ultrasonic detector in the back allowed the robot to detect obstacles, and the VEX controller contained the coding instructions, which instructed the robot to 1- Go to the red beacon, 2- lower the arm, 3-Find the Green Beacon, and 4-Drag the Green Beacon Out. Upon early tests, multiple problems were found, including mechanical design flaws and programming issues. Mechanical wise, the servo was unable to produce enough torque to lift the arm after the initial beacon was turned off. In coding, the robot initially turned away from the beacons instead of heading towards them. These were just a few of the problems faced as the group continued to refine the robots final design. In the moments before testing, the group made mechanical changes to the arm, including adding another motor and a counterweight. This allowed the robot to complete three of the four tasks: Finding the red beacon, turning it off, finding the green beacon, but not dragging it out of the arena. The three tasks were completed in 29 seconds, a relatively slow time, with a slightly high robot mass of 2.05 kg.

Table of Contents

E10, Sec 08

Project Summary…………………………………………………………………....i Table of Contents…………………………………………………………………...ii Introduction……………………………………………………………………...…1 Design and Assembly Description……………………………………………… 2-8 IR Board Description and Process ………………………………………………...……...2 Robot Description and Process (Mechanical Design) ……………………………..3-7 Software Description and Process…………………...……………………………….....8

Design Test and Performance…………………………………………………....…9 Conclusion…………………………………………………………………….…..10 Recommendations for Future Work…………………………………………...11-12 References……………………………………………………………………….13 Appendices…………………………………………………………………….14-17 Appendix A: Code flow Chart……..……………………………………………………14 Appendix B: Team Evaluation..……..…………………………………...15-17

E10, Sec 08

Introduction The project goals include finishing as many performance tasks as possible and minimizing the robot’s weight. The first task is to locate the red beacon and stop when the robot gets near the beacon. The second task is turning off said beacon by operating the arm successfully to press down on the switch located on top of the beacon. The third task is locating the green beacon. The final task is successfully moving the green beacon out of the arena (Fig.II). The robot was expected to finish as many tasks as fast as possible. Moreover, the ideal weight of the robot is looking for around 2.0 to 2.25 kg range or less. During the process of designing the robot, creativity and simplicity Fig.1I- The arena of the robot project as seen in were also encouraged. Robot Project Overview (Warecki et al, 2018) This project was divided into three parts: programming, mechanical, and electronic. We have six people in out team, therefore, we split the job to each pair based on our major relation to each part. We also set weekly milestones to make sure that we complete the project on time. For Programming team, the first two weeks job was to learn how to set up and navigate the environment of EasyCPro and easy C Cortex. Jyoti and Jerome were expected to learn how to write a program and study the program GOTO_BEACON which will take the robot towards the beacons. The Programming team’s mission the following week, was to develop a robot control program. For Electronics team, Dagan and Gaston constructed the Infrared Receiver (IR) Board for the first two weeks. To be able to construct the IR Board, they had to learn how to identify electronics components, how to solder, basic theory of operation of the board, and how to interface with the board . After finishing constructing the IR Board, they were expected to complete other relevant tasks. The Mechanical design team’s main goal was to build the body of the robot by using the provided VEX robotics kit. During the first week, Tram and Hoshea constructed the SquareBot following the instruction given in the VEX manual. The following weeks, the mechanical team worked on designing a mechanism for turning off the red beacon, and for moving the green beacon out of the arena.

Design

and

Assembly

IR Board Description and Process (Electronic Task)

Description

E10, Sec 08

IR Board: Our IR board consisted of a combination of Resistors, Capacitors, Infrared Detectors, Transistors, LEDs and Integrated Circuits. The Resistors’ function is to limit the amount of current that can pass through the entirety of the circuit. The Capacitors store energy for later usage. The Infrared Detectors detect light and the direction its coming from. The Transistors are used for signal switching and signal amplification. The LEDs restrict current flow to one direction and light up when enough current is passing through.Of these components it was critical that the, Integrated circuits, LEDs, and infrared detectors were soldered in the correct orientation, otherwise current would not pass through correctly through the circuit. The first week of IR board fabrication revolved around practicing soldering, which for many of us, myself included, was our first time soldering. In order to gauge proficiency, the electrical team needed to correctly solder 10 practice resistors and present them to the instructor for approval. The following week all teams received the components and blank boards. We decided it would be most time efficient to connect the smaller pieces, such as resistors first. The next week the board was completed and unceremoniously mounted onto the front of the robot, carefully placed so as to not be connected to anything possibly conductive (Fig.IR1).

Fig.IR1-The IR board.

Robot Description and Process (Mechanical Design) In order to meet the goals of the project, the mechanical design of the robot had to be lightweight, as well as capable of completing the tasks of the project, which were to locate beacons, turn the first one off, and drag the second one out of the arena. Thus, the responsibilities of the mechanical team were to create a lightweight body, an arm to perform the beacon functions, and generally have mechanisms and components set in place as to have the robot perform appropriate mechanical actions. Body

E10, Sec 08

After discussion with the members in the group, the mechanical group decided to follow the design outline given by the Carnegie Mellon Robotics Academy, which was named Squarebot. (http://www.education.rec.ri.cmu.edu /content/vex/building/media/squarebot4.pdf). We decided to use four small wheels for our robot in order to minimize the overall weight as much as possible. As given by the VEX Squarebot guidelines, the robot’s body consisted of a metal chassis which surrounded the drive system. The drive system, in turn consisted of a motor, which was connected to an axle, connected to a large gear. This gear, subsequently, provided connection from the motor to two smaller other gears in the front and back of the large gear. These smaller gears were connected to axles, which turned smooth wheels. This system was symmetrically mirrored on the left and right side of the body. These motor systems enabled the robot to move over smooth ground, which was crucial to completing the tasks (http://www.education.rec.ri.cmu.edu /content/vex/building/media/squarebot4.pdf) (Fig.1B). The squarebot design had many desirable characteristics that the group found to be beneficial to completing the goals of the project. First of all, the robot had a center of mass that was in an ideal location. According to Dr. Beyersdorf, a professor of physics at San Jose State University, objects tend to rotate around their center of mass (Beyersdorf, 2018). Therefore, if the robot had a center of mass that was located at its geographic center, in will rotate and turn much more easily. The controller and the battery were also placed around this ideal location. This location also helped with connecting the cables from motors, rotors, IR board, sensors, to the control board easier. The robot also had a ultrasonic sensor that was attached on the back. A limit switch on the front to the right side (Fig.2B). Components were strategically placed in order to maximize capabilities and to ensure the robot could perform the tasks effectively (Fig.3B). The Infrared board (IR board) was placed on the front, under the arm, and separated from the metal frame by foam (Fig.4B). Another foam piece was placed on the arm right above of the IR board to help protect from damage caused by the arm moved up and down many times during the tests. The purpose of the IR diodes were to act as eyes of the robot to detect the frequencies of the beacons; therefore, the robot could locate the beacons correctly. In order to make sure the IR board would work correctly, the electrical team placed it parallel to the frame, pointing it directly to the front (Fig. 5B). During the first tests, we recognized a need for some extra components to help the arm placing on the beacon more accurately. In front of the robot, under the IR board, we attached two long piece metals placed together to create a “V-shape” barrier. The purpose of these pieces was to help “trap” the beacons in place in order to help the arm turn off the beacons easier. In addition, the combination of the arm and these pieces also helped to drag the green beacon out of the arena. Also, as said as above, the limit switch was attached on the right of the “V-shape” barrier since there is no stable place in the front middle of the robot. We also worried if it could block the IR board eyes if we put the limit switch in the middle. However, this location of the limit switch led to another issue when the robot came closer to the beacons. When the beacons were in the capture zone, they could not reach the limit switch. Therefore, the limit switch wasn’t turned off and the robot kept moving. To overcome this issue, we attached another extra small stick on the left side of the “V-shape” in order to create a smoother path for leading the beacon to touch the limit switch (Fig.2B).

E10, Sec 08

Fig.1B-Vex robotics Kit

Fig.4B-IR board with a foam Arm

Fig.2B- Limit switch

Fig.3B-Robot’s component protector on the arm

E10, Sec 08

The arm of the robot was the hardest part of the whole design, as it consumed the most time of the process and continuously needed adjusting and modifying. Thus, multiple versions were created sequentially, each fixing the problems faced by the previous. During the first few weeks of the project, the mechanical team created a basic arm design. This first design was simple: it contained a servo that was connected directly to an axle. This axle, in turn was connected to an arm which contained an “hand”, a rigid barrier that surrounded the beacon, as well as a plate that pressed the buttons of the beacons. However, this first design faced a number of a huge issue. This issue is defined by Dr. Beyersdorf of San Jose State University Fig. 1Arm, Tram works on the first ,who defines torque as tangential force times distance version of the arm to pivot point (Beyersdorf, 2018). The arm’s issue in particular was that it had a large downward force a considerable distance away from the pivot point, creating a huge torque downwards. The servo, being weak and small, could not produce a torque to lift the arm at all. This was fixed by the second version of the arm. This second version added a counterweight at the opposite end of the arm, away from the “hand” of the arm. This counterweight contained about the same amount of mass as the other end, thus creating a torque that equalized when combined with the torque of the front. All of this meant that the servo then was able to to lift the arm, although sometimes having an insecure grip on the axle, producing an inconsistent lift. This worked similar to a crane, as described by Nancy Bruton in her 2017 article “How do Tower Cranes Work?”. A crane works by having a long arm, called a “jib” in the front, which carries the load, while having a smaller jib in the back which carries a counterweight that prevents the tower from falling over (Bruton, 2017). In addition to the second change, on the third week of this project, our team faced a Fig. 2Arm, the team works on creating the second problem, the “hand” of the arm was Version of the arm disappeared when we returned to the lab. problem, the “hand” of the arm was disappeared when we returned to the lab. This unfortunate event led to a completely new design for the arm, resulting an intermediate version between the second and third. On the positive side, the new design of the arm was more complete, and stable. During the first couple performance tests, the team realized that the arm needed to be raised up more at the beginning; the new arm implemented a stronger servo that generated more torque. The battery was placed next to the rotor system of the arm and

E10, Sec 08

was secured by zip ties. The nice thing about securing the battery by zip tie, is it is easier to take out for charging. Moreover, many parts of the robot were secured and connected by zip tie, and this helped reducing the overall weight dramatically. Although the aforementioned changes helped in the arm’s ability, the inconsistent lift of the arm led to the team’s decision to create a better version. In the third version, the servo was connected by an axle, but instead of being directly connected to the arm, the axle was connected to a 12-tooth small gear. This gear was in turn connected to a larger 60 tooth gear, which was connected to an axle that turned the arm. Ultimately, this caused a major breakthrough in the function of the arm. The arm design followed Dr. Peter Beyersdorf’s explanation of power, which is described as work over time (Beyersdorf, 2018). The gears allowed the servo to lift the arm over a larger period of time, ultimately reducing the required power of the servo. Although this solution solved a couple of problems, it ultimately created a new one. Due to the gears that was used, there was a ⅕ ratio between the gears. This meant that for every 5 degrees the servo moved, the arm would only move 1. Ultimately, this meant that, while the servo could move to a maximum 120 degrees, the arm would only move 120/5 degrees, or 24 degrees. This was a huge issue, as the arm needed to be raised to not only reach over the beacons, but be out of the way for the infrared board. The need for a fix led to a final design, the fourth version. In order to fix the angle issue, a motor was used. This motor allowed the robot to freely move the arm, without being hindered by the servor’s angle limitation. In addition, a counterweight was once again added to arm end opposite of the beacon- retrieving front. This once again reduced the torque the motor had to fight against, effectively freeing it from the burden of the torque of the front. The counterweight also made sure the the arm did not tip over to the back of the robot, opposite to the beacon it was supposed to interact with. However, there were still downsides of the design process such as many pieces of the frame being bent, broken, and not uniform. Therefore, when connecting together, some parts of the frame were very difficult to screw perfectly and tied enough. During the testing, some of the screws were falling out. Fig 3Arm, the team takes a look at the third version of the arm Moreover, the overuse of zip ties made the overall look of the robot less professional. Even though the team had tried to minimize the weight of the robot, the total weight was still over 2.0 kg. This could be because of the new arm design required many heavy

E10, Sec 08

weight materials to help balancing, especially for use as counterweights.

E10, Sec 08

Software Description and Process (Programing) In the lab, the programming language we used to program the robot was EasyC Vortex and the Integrated Development Environment we used was the EasyC Environment. We obtained the code from the E10 website. We mainly edited the Main Method and Move Method. In the move method, we changed the motor numbers; we assigned the left motor to be number 1, and the right motor to be number 4. We assigned the motor module for the arm on port 3. The forward speed value was decreased because the robot was too fast when travelling forward to the beacons. Our final forward speed value was 35. We implemented multiple while loops as states for the robot to accomplish specific tasks. For finding the red beacon, we changed some parts of the move method. Another problem we’ve encountered during testing was making the robot stop when it approached the red beacon. We initially tweaked the values of the stop_level to change the robot’s sensitivity of finding the beacon, but the robot didn’t reliably stop. Our team then decided to add a limit switch which made our job comparatively easy, as we didn’t need to rely on the stop_level to stop the beacon. To use the limit switch, we assigned the limit switch on port 2, then created an integer value called lim and set it equal to 1. In the program we changed the value of limit to that of the Digital Input from port 2. We created an if loop for the limit switch with the condition if “lim == 0” then the switch is pressed, and the robot should stop in front of the beacon and bring the arm down to switch it off. If the limit switch has been pushed, the limit will be set to 0, stopping the robot from moving. After it found the red beacon, we assigned the Motor Module to have an angle of -127 to hit and turn off the red beacon. Then, we changed the angle of the Motor Module back to 127 to bring the arm back up. We made the robot go reverse, then made the robot find the green beacon. To find the green beacon, we changed the freq value to 1. Unfortunately, we were only able to code the robot to stop at the green beacon. We were hoping on using an ultrasonic sensor and coding it to bring back our robot out of the arena but we had to deal with more important issues such as the robot finding the red beacon, stopping at the red beacon, and the arm turning off the red beacon. We also copied the same code for the green beacon and just changed the freq variable value to 1 so that the same tasks are performed for the green beacon. This was a last minute edit on behalf of the software team so we didn't have time to edit the move method for the green beacon. This is the reason for our failure to capture the green beacon, and the robot coming out of the arena with its arm up.

E10, Sec 08

Desig...