Robotics Challenge. Final Report Spring Semester Full report by Tyler Quintana Tyler Gus Josh Cogdill Raul Davila John Augustine

Transcription

1 Robotics Challenge Final Report Spring Semester Full report by Tyler Quintana Tyler Gus Josh Cogdill Raul Davila John Augustine Department of Electrical and Computer Engineering Colorado State University Fort Collins, Colorado Project advisors: Bill Eads and Megan Emmons Approved by: Megan Emmons

2 Abstract The Robotics Challenge is an annual engineering challenge sponsored by NASA through the Colorado Space Grant Consortium which culminates in a daylong event near Alamosa, Colorado in April. The challenge involves designing an autonomous robot to navigate through multiple courses at the Great Sand Dunes National Park. At the end of each course is a beacon which the robot will attempt to reach. In order to do so, the robot must detect obstacles in a manner that will allow it to analyze the best route to take. If the obstacle is small enough, the robot should proceed over it and if it is too large to overcome, the robot will navigate around the obstacle. The challenge was partially designed to simulate a Mars mission. Advancements made in the field of autonomous robotics offer a promising alternative for interplanetary exploration as demonstrated by the Curiosity rover on Mars. Rather than manned missions, which entail serious risks and prohibitive costs, robots offer a less expensive and much safer solution. However, space introduces long communication delays so to be effective, robots must successfully navigate without relying on human instructions. The NASA challenge allows young engineers to experience the framework of an engineering project and contribute to new ideas for interplanetary exploration by simulating a Martian-like environment and forcing fully autonomous navigation. Space exploration itself is not a new concept to the community of science and technology but robotics and autonomous motion are relatively novel tools. The purpose of the robotic missions is to help save on cost, time, and training. One of the current examples of robotic space exploration is the Mars Exploration Rover Mission. The robot s autonomous features allow it to navigate the terrain of Mars while collecting data for NASA with little to no human interaction. This is an efficient and less expensive approach to data collection. Unlike humans, the rover is able to explore and gather data round the clock with no need for food or shelter. NASA is able to direct the exploration with minimal contact and can leave the robot on Mars until it no longer works rather than conducting additional missions to return human explorers to Earth. This project does not only have relevance for space exploration, the technology used can also be imported into autonomous vehicles such as Tesla s self-driving car. The object detecting algorithms produced can be implemented into a system that can be used by an everyday user. This can help limit the number of accidents and accident-related deaths each year. The principal findings of the project have confirmed autonomous features are fairly inexpensive but extensive time is required to fully develop a robust product. With increased experience, the training time to learn about the system has decreased but testing individual features has continued challenges whether in software or hardware. Out-of-date processes make it difficult to make improvements on the project. Delays in any one portion of the project can have significant impact on other aspects of the project and make certain areas harder to test and improve. Nonetheless, a successful design was developed and demonstrated at the official Robotics Challenge event on April 16th. After extensive testing focusing on each portion of the project, portions could then be confidently integrated with other systems. In the end all systems were successfully integrated so overall system testing and refinement could occur the week before the official challenge.

3 Table of Contents Robotics Challenge Abstract Table of Contents Figures and Tables I. Introduction II Summary of Design II.I Controllers and Sensors II.II Signal/Beacon II.III Chassis III Details of Design III.I Controllers and Sensors III.II Signal/Beacon III.III Chassis IV Future Work and Conclusions IV.I Controllers and Sensors IV.II Signal/Beacon IV.III Chassis Conclusion References Appendix A Abbreviations Appendix B Budget Appendix C Project Plan Acknowledgements

4 Figures and Tables Figure 1: IR voltage as a function of distance [1] 8 Figure 2: XBee not visible in XTCU. 10 Figure 3: USB Device not recognized Figure 4: Final design test beacon. 12 Figure 5: 3D printed honeycomb pattern [2] Figure 6: Front of first prototype Figure 7: Interior of the first prototype body Figure 8: Rear of first prototype 14 Figure 9: First prototype printed and assembled Figure 10: Final design with rock crawler tires. 15 Figure 11: Paddle tires [3]. 16 Figure 12: Servo calibration circuit Figure 13: Final design.. 18

5 I. Introduction The Robotics Challenge is an annual engineering challenge sponsored by NASA through the Colorado Space Grant Consortium which culminates in a daylong event near Alamosa, Colorado in April. The challenge is designed to further robot development and generate new ideas from young engineering minds. For the official challenge, an autonomous robot is designed to navigate through multiple courses at the Great Sand Dunes National Park. At the end of each course is a beacon which the robot attempts to reach. In order to do so, the robot must detect obstacles in a manner that will allow it to determine a passable route. If the obstacle is small enough, the robot should proceed over it, and if it is too large to overcome, the robot should decide to go around the obstacle then reorient toward the central beacon. The challenge setup is designed to mimic interplanetary exploration missions which are more feasible than ever as a result of advancements in the field of autonomous robotics. Rather than manned missions, which entail serious risks and prohibitive costs, the evolving field of robotics promises a less expensive and much safer solution. Along with challenging terrain, space introduces the additional difficulty of long communication delays so to be efficient, robots must successfully navigate without relying on human instructions. Due to the project culminating in a nation-wide challenge, there are several rules and constraints to which the design must adhere. These design constraints are as follows: 1. The robot must be autonomous - no remote control signal of any kind is allowed. 2. Robots must remain on the ground - jumping, launching, or flying towards the beacon is not allowed. Robots must be propelled via direct contact with the ground such as through tracks, wheels, or other actuation. 3. Robots must fit into one of the two size categories: a. Less than 1.5 kg b. Less than 4.0 kg 4. The wheelbase may not be longer than 20 inches and the maximum height may not exceed 30 inches. 5. All hardware costs of the final design must be under $500 total. To place greater design emphasis on developing a robust navigation algorithm, the team chose to design a robot in the 1.5 kg weight class. The smaller platform limits the robot s ability to climb over obstacles so detection and avoidance becomes more critical for successful completion of the course. Ultimately, the final design measured 13 inches wide, 12 inches long, 8 inches tall, and weighed kg, successfully remaining well under all constraints. While this is the tenth year the Space Grant Robotics Challenge has been held, it marks the second year it has been an ECE senior design project at Colorado State. This gave the current group an opportunity to discuss the project with people that have firsthand experience with the challenge. The group has worked on learning from the previous team s experience while moving forward with our own designs. As discussed in Chapter 2, the group made a point of doing independent outside research rather than just building on last year s ideas. It was also advantageous to learn about design and specific event-related challenges from the previous team so we could avoid them and save significant time. Similar to last year s team, the current team is multidisciplinary - consisting of three computer engineers: Tyler Quintana, Tyler Gus, and Josh Cogdill, one electrical engineer: Raul Davila, and one mechanical engineer: John Augustine. This allowed the team to bring different skill sets and knowledge

6 in order to work through the challenges at hand. The team composition also allowed us to handle all facets of the project in an efficient and high quality manner. To further benefit from the multidisciplinary makeup, the group divided into three subgroups to maintain collaboration but focus on key tasks. Those three subgroups consisted of: Tyler Gus and Tyler Quintana working on the controls and sensors, Josh and Raul working on the signal and test beacon, and John designing the chassis. The remainder of the report details the final design of our autonomous robot. Chapter 2 contains a summary of the work done through the year, beginning with a review of previous work done primarily in the form of research at the beginning of the year. There were many aspects that were taken into consideration while completing this portion of the project. Previous groups provided useful information on what components they found worked well and what components did not work as expected once introduced into different environments. Here all the different options that were found are discussed in detail, weighing the pros and cons. Chapter 3 contains a detailed review of the work done, including controllers and sensors, the signal/beacon, and chassis. In this chapter the decisions made from the planning and research are detailed along with an evaluation of the performance at the challenge. In the first section, the implications of the hardware decisions regarding the controllers and sensors are reviewed. Primarily this is the methodology of conditioning sensor input to result in usable data. In the second section, the construction of the test beacon and testing the signal is detailed along with the many extensive troubles faced during the process. The third section discusses all the thoughts and considerations concerning the design of the chassis and wheels. Additionally, figures illustrate the progress regarding the design and printing of the first and second prototypes. Chapter 4 contains a look at the plans for possible continuation of the project regarding controllers and sensors, the signal/beacon, and chassis/wheel design. In the first section, future testing and integration of the controls and sensors is detailed. The second section discusses improving the test beacon in order to more accurately reproduce the beacon at the challenge. In the third section modifications and improvements of the chassis are detailed. II Summary of Design II.I Controllers and Sensors At the beginning of the year, each team member started by researching different available options for controls and sensors before looking at what other teams had done in the past. Initially the team thought it would be interesting to use some sort of camera, rather than a few basic sensors, for a more comprehensive vision system - much like humans. Additional research made the Kinect motion controller appealing as it would likely provide the most useful data for detecting obstacles. The main appeal of using a Kinect is that, in addition to an RGB camera for color information, it features an infrared (IR) depthfinding camera. This combination results in more data than an off-the-shelf webcam. After further research unfortunately, using a Kinect for the navigation challenge was deemed impractical. Even though the Kinect has a robust SDK and API, making full use of these features requires extensive work with computer vision software which does not fit well with the team s experience base. Further, the weight of the Kinect hardware alone would push the design toward the 1.5 kg weight limit, severely limiting the weight

7 available for all other aspects. From looking into different sensors and previous challenge designs, it was found that IR and ultrasonic sensors are commonly used in obstacle-detection scenarios. The previous year s robot utilized an array of Sharp IR sensors (arranged to point forward and down at the ground ahead) and an ultrasonic sensor pointed straight ahead. A lot of valuable information was gained from discussing the performance of this configuration with the previous team. Primarily, they recommended heavily testing all sensors prior to assembly as an indoor lab environment is more stable than outdoors where performance can vary drastically due to uncontrollable environmental factors. They endorsed the Sharp IR sensors but emphasized the need to filter out noise in the system. The previous group did not recommend using an ultrasonic sensor because the data provided did not improve the overall obstacle detection. Because the sensor sends out a signal and then waits for the signal to return, good information was only received from the ultrasonic sensor when an obstacle was perpendicular to the sensor. They also emphasized that sensor noise became a much bigger challenge when the ultrasonic sensor was operated outside. As a result, we chose to avoid using ultrasonic sensors. One additional recommendation from the previous year s team was to include physical pushbuttons to tell when the robot has actually encountered an obstacle as a final failsafe for the IR sensors. The pushbutton failsafe would emerge in the second prototype and, while five IR sensors would be mounted on the front bumper, only the three forward pointing IR sensors would be operational for the final event. From looking at the previous year s robot, it was observed that they used two additional sensors: an MPU-6050 inertial measurement unit (IMU) to provide accelerometer and gyroscope measurements, and a HMC5883L three-axis magnetometer. With additional research, it was found that the MPU-9150 combines the abilities of the two units from last year but in one system in package (SIP). However, as the challenge approached, it was discovered that the MPU-9150 did not produce strong measurements from the magnetometer. Due to the reliance on magnetometer readings for robot heading, it was decided that the robot would need a better magnetometer in the form of an HMC5883L while still using the MPU-9150 for accelerometer and gyroscope measurements. Different options for microcontrollers to control the system were also researched. The most suitable single-board computers found were the BeagleBone Black and the Raspberry Pi. However, when considering how many input and output (I/O) pins (specifically analog) would be required for the number of sensors desired, it was found that neither processor would be satisfactory. The most common option that would provide enough I/O pins were Arduino microcontrollers. While the BeagleBone and the Pi have faster processors and more robust math capabilities, Arduinos have better real-time communication and analog capability, making them more suitable for use in the challenge. Arduinos are very prevalent in these types of applications so finding open-source code for interfacing with common sensors and hardware is quite simple and allows for faster development. Ultimately the Arduino platform proved to be a good choice as all the hardware used had extensive libraries available. II.II Signal/Beacon Although there were discussions with the previous team regarding beacon location, not much of the information provided was applicable to this year s challenge due to changes in the challenge signal. Past challenges required navigating toward a beacon with 433 MHz signal but this year the beacon was changed to a 2.4 GHz signal. On the day of the challenge last year, many of the teams had problems due to a high amount of signal noise from the beacon. From discussions, it was learned that the beacon rotated vertically which was not mentioned in the specifications of the challenge but significantly improved performance during testing. Overall, last year s team primarily recommended testing of the beacon system

8 in different environments for more accurate readings and knowledge of determining the beacon location. After extensive testing, the team was confident in the robot s ability to reliably find the beacon during the challenge. II.III Chassis At the beginning of the semester, the primary goal of the chassis system was conserving weight as much as possible to stay under the lower weight class. Various options for a chassis design were researched, focusing on previous years works from train-like designs to two-wheel designs, even tanklike robots. The robot ended up going through two iterations throughout the year. The first design was an eightwheeled robot with a single servo on either half of the robot using timing belts to power the left and right sides independently. The second and final design ended up being a four-servo, four-wheel design. This second iteration was possible as the first robot was far enough under the weight constraints that the additional servo motors did not put the robot over the weight constraint, while adding the benefit of reliability and additional power to drive the robot. III Details of Design III.I Controllers and Sensors After consulting the previous year s team, as well as doing independent research on sensors, a varied sensor array was chosen. Last year s team mentioned the effectiveness of IR sensors for obstacle detection but cautioned that signal noise must be taken into consideration. It was also discovered in testing that the analog voltage output from the Sharp IR sensors can vary wildly even during very basic stationary scenarios. It can be observed in Figure 1 that the output for the sensors ranges from 0.3 V (measuring distance of 40 cm) to 3.3 V (3 cm distance) but the relationship is nonlinear. As a result, the output of these sensors must be heavily conditioned. For the final design, conditioning was achieved by taking many sample readings, discarding erroneous values which were determined to fall outside +/- 10% of the previous reading, and then calculating the mean of the data read in during one time period. After this conditioning, the results are much more reliable. When testing the five IR sensors, it was useful to connect an LCD to the Figure 1: IR voltage as a function of distance [1] Arduino to properly test the data received from the sensors without being connected to the computer. If the value read in from the Arduino was less than zero or greater than forty, the LCD was programmed to

9 display 999 meaning no object is detected. When receiving a reading of less than zero, it means an object is too close for the sensor to detect so a failsafe should be in place to prevent the robot from colliding with an obstacle. Such scenarios could be encountered if the IR sensors malfunction. For the robot design, the failsafe took the form of a leading front bumper with a pushbutton. When the pushbutton is depressed, the robot has physically encountered an obstacle and needs to navigate around the obstacle. This action was accomplished through polling the Arduino pin connected to the button to detect a change of state, indicating the robot has hit an obstacle. Ultimately the response for an object collision was backing away from the obstacle, then turning left or right a slight amount to give the IR sensors another opportunity to detect the obstacle. The next key portion of the robot is detecting direction and angle of travel both necessary for proper navigation toward the beacon. From the previous year s design, it was noticed they had two separate systems for the compass, gyroscope, and accelerometer. Each system is beneficial but added mass and complexity to the design. Additional research led to the MPU-9150 which contains a 9-axis gyroscope, compass, and accelerometer all in one chip. This option simplifies some circuitry and logic while reducing the weight with similar performance compared to the previous robot s sensors. When testing the MPU- 9150, the output from the gyroscope and accelerometer was found to be very accurate but required some conditioning to reduce the amount of information received and thus avoid jamming the system. Through testing, the best conditioning was found to be using the average of ten readings, thus smoothing out jitter. When testing the magnetometer readings on the MPU-9150, it was also found that the readings were extremely sensitive to any environmental electromagnetic noise. Calibration of the MPU-9150 was completed multiple times with very little benefit. Finally, because the magnetometer readings are needed to ascertain heading - a very important aspect, we would need to add a device with stronger and more accurate readings. Adding another chip to the board would increase the complexity of the wiring by occupying additional pins and would add to both our weight and budget but knowing the robot s heading is critical for navigation. Improved performance was found in the form of the HMC5883L, the same dedicated compass unit used on the test beacon. Switching to reading the magnetometer of the HMC5883L led to an immediate improvement in quantifying the robot heading and as a result traveling to the beacon became much more reliable. After doing extensive research to decide on a microcontroller, ultimately the Arduino microcontrollers were chosen due to their ease of use and suitability for the project. Initially, two Arduino Unos were purchased for the design but soon the six analog input pins on each microprocessor became insufficient for the number of sensors desired. Arduinos are capable of being configured in a master/slave situation so initially that was investigated and implemented with the two Unos. Due to the complexity and nature of the master/slave configuration, it was agreed to simply purchase an Arduino Mega 2560 which provides sixteen analog input pins and allowed for effort to be focused more on the sensors. Moving to the Mega 2560 proved to be quite beneficial as it accommodated additional hardware and wiring changes throughout the year. III.II Signal/Beacon The first semester primarily consisted of setting up a test beacon and simulating the beacon at the challenge. In doing so, many unforeseen challenges were encountered but eventually overcome so a

10 reliable test beacon was produced. The test beacon system was used to test the robot s navigation algorithm and proved extremely beneficial. The first task in developing the beacon system was to assemble all the necessary parts, namely: Two Arduino Fios One XBee receiver One XBee transmitter One patch antenna One digital compass Once the equipment was assembled, the XBees needed to be configured so they could communicate with each other using the Arduino IDE and the XCTU software. Configuring the XBees became the first unforeseen hurdle which was due to faulty code provided by the Robotics Challenge Beacon Setup website. After many hours of attempting to configure the XBees, with various group member attempts, it was found that the set baud rate in the provided code was incorrect. Once this baud rate was corrected, the computer was able to recognize each XBee and successful communication was established between the devices. Some examples of the error messages encountered during this phase can be observed in Figures 2-3: Figure 2: XBee not visible in XTCU

11 Figure 3: USB Device not recognized Initially the Arduino Fio could not find the XBee when configuring with XCTU software. Two different methods were discovered as potential fixes for this error: discovery and recovery. Troubleshooting began with method one, the discovery process which acts as the add device process except it tests for all possible choices. First all possible baud rates were chosen and then the other checkboxes were systematically selected. Unfortunately, this did not find the XBee so the second method, recovery process, was attempted. This method is typically used when the XBee itself appears bricked. Usually a device is bricked when due to some sort of corruption, in firmware or hardware, it is no longer functional and typically this is permanent. However, in the context of Fios and XBees it was found that they are quite problematic and their bricking is not usually permanent. After trying several times, the error message displayed in Figure 2 was continually encountered. It was next decided to upload the XBeeXCTU sketch to the Fio again because the Fio would not be able to read from the XBee if an incorrect sketch was installed. After several unsuccessful attempts, the final error message displayed in Figure 3 was received, leading to the conclusion that the Fio was not visible to the IDE. This happens when the Fio is bricked and frequently occurs mainly due to uploading code to it with an incorrectly set board. To solve the bricking problem, there is a basic procedure to follow that requires a reset to the bootloader and finally uploading the sketch within a very frustratingly tight time sequence. After following this procedure, the sketch uploaded properly. With all other avenues attempted, the challenge-provided sketch code was scrutinized. Here, it was discovered that the baud rate configured on the XBee was different than the baud rate set in the XBeeXCTU sketch meaning the Fio would not be able to communicate with the XBee at all, and hence, the XCTU could not communicate with the XBee. When the sketch was uploaded with a specific baud rate and then changed during configuration, the XBees were finally able to communicate with each other. With the XBees successfully communicating, the next task was to program the Fios to transmit and receive the beacon signal. Again, trouble was encountered and required several hours of troubleshooting due to the fact that the code provided on the website was wrong once again. Once the code was successfully debugged, a temporary solution was created to get the receiver to read in acceptable values from the transmitter. s were frequently exchanged with the author of the Beacon Setup tutorial in order to correct the code and generate this solution. In this extensive procedure of getting the beacon working correctly, various intermediate tests were implemented. The first value read in correctly corresponds to the signal strength. To confirm this and estimate the range of potential values, the beacon was placed at the end of a room and the different signal strengths were read in as the receiver was moved further away from the beacon periodically at one meter intervals. The second important value tested was the heading (direction of the beacon) read in by the

12 receiver. In doing this, the receiver was rotated as if the robot were facing different directions. It was soon realized that the beacon needs to be spun because essentially the robot needs to navigate toward the direction the beacon is facing. This discovery took a few tries, but after modifying some code on the transmitting system, a solid connection was made between the reading and the different positions of the beacon. This was then tested with the code, reading in new desired directions of the robot. Due to delays in the construction of the chassis, the navigation system was not tested on the actual robot until fairly late in the timeline but it was simulated prior with promising results. Eventually with the second prototype, the chassis was tested with the navigation extensively and as a result at the conclusion of our project, the test beacon design was working better than ever. The hardware design consisted of the following: Wooden Base Mounted Motor PVC pipe Tupperware container Patch Antenna Arduino Fio V3 Xbee Transmitter HMC5883L Magnetometer The final design of the test beacon can be seen in Figure 4. Although the beacon would read somewhat inconsistently inside, it would produce great readings when away from any wireless networks which can interfere with the readings. A few places that were found to work well were large parking lots, large grass fields, large dirt plots, and the Great Sand Dunes National Park. On the receiving end, the code reads in from the transmitter, and proceeds to alter these values in order to produce an accurate beacon heading. The first step was to average five read in headings. In order to filter out bad values, the code checked to see if the difference between the maximum and minimum value of the averaged five values was larger than a given number. If this was the case, then robot simply reads from the beacon again. Figure 4: Final design test beacon Additionally, the code had to adjust for wrap around values (switching from 0 to 360 degrees) when dealing with the averaged value. Once the code had a dependable average to work with, it determined which direction the robot should turn toward the beacon by reading the robot s compass heading and comparing it to the averaged beacon heading value. Obviously there are many more details to this complex algorithm, but these are the main functions of it. One point learned from observing the code of the previous team was to watch out for when the compass is tilted as it will get quite inaccurate readings. From testing it was found that the compass should be within roughly ten degrees of level. The current algorithm implemented a system using the gyroscope to continue moving towards the desired heading until the compass is level before reading from the compass.

13 From our extensive testing this beacon detection algorithm worked great. This test beacon was only to replicate the official Robotics Challenge beacon, and the team s code actually produced even more accurate readings from the official beacon. Each time during the challenge the robot attempted to find the beacon, it would find the correct heading within five to ten degrees. This was very satisfying for the team because significant time was spent working on the beacon detection algorithm. III.III Chassis After consideration and evaluation of previous designs, an eight-wheel design was selected for the first prototype, followed by the final four wheel four motor design. This eight-wheel design could be significantly lighter than previous years, while maintaining stability over the various surfaces and terrains potentially encountered. An RC car was initially bought to use as a test platform while the main chassis was being developed. After stripping down the RC car, the suspension design was found to be wellsuited for the actual robotics challenge. This discovery led to the robot being designed to use the RC car s preexisting suspension system. The suspension consisted of three rigid bars per side used in conjunction with two spring shocks on each side. This suspension Figure 5: 3D printed honeycomb pattern [2] system allows for maximum maneuverability of the robot while maintaining a stable body for the sensors. To be able to implement this with the chassis design, the suspension had to be slightly modified. Originally the suspension was mounted in the front and back of the RC car. For the desired robot, the suspension had to be adapted to fit on the left and right hand sides of the robot to allow on-point turning with only two motors. To achieve on-point turning with the use of only two motors as opposed to the four motor system employed by last year s team, a track system was developed to provide power to the full left side with only one motor and the full right side with the second motor, this would later be resolved into a four motor four-wheel design similar to last year s design. Staying in line with the tight budget and trying to minimize weight, it was decided to use a plastic wheel and rubber band system for the belt drive system. This system was both light and inexpensive, however after installation it clearly will not work reliably enough for our final design. Upon initial assembly and testing it was found that the rubber bands would not stay in place so a more permanent solution had to be found. The rubber bands were replaced by timing belts and gears. Though this solution of timing belts and pulleys was more rugged than the previous rubber band design, it was further refined to eliminate four of the wheels and add two more motors to have each wheel independently driven. This was possible due to the initial prototype being far under the weight constraints, allowing the addition of motors while remaining under the weight constraint.

14 For material selection of physical construction, the pros and cons of various materials were debated and ultimately it was decided to 3D print the body using PLA plastic. 3D printing allows for the design of a wide range of easily manufactured complex shapes, while remaining incredibly light. 3D printing also allows these shapes to be strong and light by printing hollow honeycomb patterns inside of materials rather than them being solid. The use of this honeycomb pattern allowed the design to achieve the same physical strength properties of a solid material, while being only roughly a third of the weight it would be if using traditional materials as observed in Figure 5. The first prototype body designed this year was made to fit an Arduino Uno, the MPU axis sensor, the XBee receiver, and batteries with IR sensors Figure 6: Front of first prototype mounted on the front bumper. We later upgraded to using an Arduino Mega which still fit into the existing body, though the final revision had a larger top cap for ease of wiring and maintenance. The board layout was designed to be as compact as possible to maintain low weight which can be observed in Figure 6. The encasement of the interior board can be previewed in Figure 7 and Figure 8. After 3D printing the prototype component Figure 9 shows the chassis fully assembled. The main goals of this design were to reduce weight as much as possible and to enable on-point turning. The first design, shown above, was such that the robot would be able to do on-point zero degree turns while keeping optimal contact with the ground, the final design implemented the same type of suspension. To better ensure optimal contact, the extra set of wheels was added on the inner side of the leg in the initial design to prevent undesirable motion such as external rotation of the belt housing, later being removed when the four motor solution was used. Figure 7 Interior of the first prototype body One major aspect of the iterative design process that took place was the need for ease of service and stability of the axle assembly. Through the prototype iterations these areas became much more robust while remaining under the weight restriction. Figure 8: Rear of first prototype

15 Towards the end of the first semester research into different wheel options was conducted while considering their great importance. The primary goal of the wheels was to have a large surface area, good angle of contact in the various terrains, and to not dig themselves into a hole. The first option pursued was that of rubber paddle tires for remote control cars. While these tires provide great traction in sand, the paddles are shaped so extremely that they could likely result in digging into the sand instead of forwards motion if proper care were not taken to drive them at the proper speed. These tires are also relatively heavy for their size compared to other options. Another option pursued was 3D printing the wheels. Figure 9: First prototype printed and assembled While typically lightweight, the nature of infill combined with a large wheel diameter can lead to heavy parts. The final option considered at the end of the first semester was the use of foam-core. Foam-core is rigid while maintaining some elasticity relative to the surface it is in contact with, potentially increasing grip. It is lightweight and its issues in durability are overshadowed by its benefits seen in other properties. The initial wheel designs for the first prototype were 3D printed and with a standard RC wheel diameter and a basic 12 lobed flower profile seen in Figure 9. While considering the different material options for wheels and tires it was pointed out that any material can be rubberized, increasing grip. Ultimately the conclusion at the end of the first semester was that foam-core was the best material considered to produce our own wheels. Additionally, the profile chosen would then dictate the proper method of driving wheels regarding speed and torque while maintaining traction and control. Around the middle of the second semester the different wheel options were again revisited. After considering the weight restrictions and final design budget limit it was found that we were well under both constraints, leaving a large allowance for tires if needed. After some research it was found that RC car tires could easily slip over the existing 3D printed wheels from the first prototype. This option was ultimately chosen due to how quickly it would allow testing movement and climbing obstacles. Research showed that the most versatile option available was RC rock crawler wheels as observed in Figure 10. These were specialized for climbing over obstacles. An additional set of sand paddle tires was also purchased to replace the rear set of tires if Figure 10: Final design with rock crawler tires more traction in the sand is needed Figure 11. From extensive testing it was decided that the rock crawler tires were quite good on most surfaces and provided great grip allowing the robot to slowly scale large

16 obstacles. The sand tires were also tested and it was thought that they could be useful if the sand at the sand dunes proved to be very thin. During the first semester motor calibration was done for the servos. This was thought to be necessary due to the variation of the individual servos center point. In order to move high speed continuous rotation (HSCR) servos a number is written to the servo. The further this number differs from the center number the faster it rotates in either direction with a range of +/- 90 (resulting in a range of 0-180). This center point number is found to be the number that results in no movement. The calibration was done by attaching them to a potentiometer circuit and minimizing their offset speeds. The circuit used was based off the circuit shown in Figure 12. This was done by mapping the range of the potentiometer to the range of each HSCR servo. Any difference in the speeds and center points of the servos was calibrated out through the shifting of a servo s range. For these servos, their mapped directions must be opposite so that when mounted on the robot they spin in similar directions, meaning one servo was mapped from the potentiometers to and the other The actual calibration of ranges was done in matching the center points of each motor. This can be a valid method of calibration as the servos used are HSCR, meaning that a value given to them does not correspond to angular position, but to rotational velocity. Through the calibration process with the potentiometer circuit it was found that the motors had an offset of 12. For the mapped ranges this means that one is from to and the other from to Since the ranges the potentiometer is mapped to are similar in magnitude, no change in speed will need to be accounted for. During the second semester the HSCR servo use was revisited and their operation was found to be quite simple. Through basic testing with the servos connected directly to the Arduino it was found that the center variation was actually quite small from servo to servo and could be found easily. After finding the proper center point different speed offsets could be written to the servos and the resulting rotation speed of each servo would match. Matching the rotation speeds of each servo was required in Figure 12: Servo calibration circuit Figure 11: Paddle tires [3] order to enable zero turning radius and turn a consistent and predictable amount every time. At the challenge the chassis proved to be a weak point in the design, primarily because it was not well suited to the unexpected wind-swept snow that covered the sand dunes. From testing it was found that the RC car tires provided a lot of grip and this caused problems when all four tires were on a surface that would not move like concrete. However, when

17 the wheels were on sand or gravel, which was expected to be the predominant surface at the challenge, this was not a problem. But because the snow at the challenge was wind-swept and packed down the servos did not have enough torque to push it out of the way so everything would just bind up. If the servos were larger and provided more torque this could potentially been less of an issue however it might have pushed our weight restriction. Another possible solution would be to use different wheels, a design closer to the wheels on the Mars Curiosity Rover would have been well suited to the snow. There the basic design is a simple hollow cylinder with cleats. However, this design would have been difficult to produce and properly test with only a few days notice. IV Future Work and Conclusions If the Robotics Challenge is to continue at CSU next year there are certain aspects in which the team should improve on. As with the previous year they excelled mechanically and this year the objective was to have better obstacle avoidance as well as navigation to the beacon. The current team achieved that goal and would like to see next year s robot improve on the sensing and navigating algorithms as well as improve on the mechanical design. It would be optimal to increase the weight so they can use better motors that will operate better in different environments. Also they should consider what the weather might be like at the challenge and be proactive in weatherproofing the design (i.e. waterproof for rain and snow). IV.I Controllers and Sensors To improve the sensors from the current situation it would be best to work with the gyroscope to integrate the readings so that it can detect holes when going over objects. This was a problem faced toward the end of the testing phase and there was not enough time to integrate it into the system. Another issue faced was the power consumption of the IR sensors that can easily be avoided. Initially the Arduino was powered by a single 9-volt battery and it would have issues detecting obstacles. However, when it was plugged into a computer the IR sensor readings were much better. This led to the conclusion that the Arduino needs to be powered from an external power supply to the USB port. This provides more current to the IR sensors and results in better readings. These problems were found a week before the challenge and a solution was found in the form of a cell phone charging battery pack. IV.II Signal/Beacon Although the final outcome was successful, many wrong turns were taken along the way of creating a robust beacon detection algorithm. In retrospect one thing the team should have done differently was to ensure the robotics challenge beacon code was finalized before beginning work on the test beacon code. This was an issue because the official website had changed the beacon code three times through the year, and each time the new code was uploaded to the team test beacon and it would not work. This was frustrating to the team because after putting many hours into getting the beacon to read in accurate values, the website would update the code, and work on the receiving code would have to start over, essentially wasting significant time. Similarly, one persistent issue was testing the beacon inside where wireless networks were present. As a result, there was a constant problem with noise and interference that caused the team to spend endless hours trying to figure out why the beacon readings were inaccurate. Once the beacon was tested away from any possible interference, the readings were found to be accurate, and likely had been the whole time. From how well the current system read from the challenge beacon the current algorithm used was effective but not optimally efficient. It would be good to take less readings from the beacon for sake of saving time as with the official beacon it was much more accurate at retrieving data. Also through configuration of the test beacon it was found that there are many tricks when trying to

18 program the XBees and Fios which are not in the tutorials or set up guides. Future teams should be sure to ask many questions of the challenge coordinators when running into issues that could take one to two hours or more to troubleshoot. Many times it was found that it was not something that was being done wrong but some step in a tutorial was overlooked. IV.III Chassis Figure 13: Final design The chassis design worked very well for us. It provided a lot of vision for the IR sensors and was also useful for traversing the terrain. Some aspects to be improved on with this design is to have a longer wheelbase so that it is easier to go over obstacles. Another caution is to buy quality motors as the current team learned the hard way at the challenge when the servos did not operate in the cold snowy environment. Also using a four motor design greatly simplifies use compared to a two motor design such as on the first prototype. A significant portion of time was spent working on this initial design with little to no results. A four motor system would be best to save time and get things moving. Another item that has room for improvement is the suspension of the current system. The first prototype had a good idea but had a common issue was the legs splaying outwards when moving. To fix this two bolts were run through both legs to stabilize it as observed in Figure 13. This worked very effectively but at the cost of quite a bit of flex and some clearance so some more research should be done in the suspension of the chassis. Conclusion Ultimately, each stage of the design was extensively tested and the result was a robust system capable of reliably detecting the challenge beacon with high accuracy. The final design was able to consistently avoid obstacles and reorient towards the beacon. Dozens of successful test runs were conducted in challenging outdoor environments prior to the April 16th challenge date. As a result, the team was able to approach the NASA challenge with confidence. Unfortunately, the serious change in weather and short notice significantly impacted the performance of the current robot. The team did not anticipate snowy conditions but rather focused on sandy terrain along with all other challenge participants. Weather issues aside, if the project is continued at CSU there are still many areas upon which the final robot design could be improved.

19 References [1] SHARP Opto-Electronic Device Division. Sparkfun.com. SHARP, Web. 1 March Oct < [2] "MakerWare More Features." MakerBot. MakerBot, 26 June Web. 5 Oct < [3] Pro-Line Sand Paw 2.8 (Traxxas Style Bead) Sand Truck Tires Pro-Lineracing. Pro-Lineracing, n.d. Web. 25 Apr <

20 Appendix A Abbreviations API: Application Program Interface HSCR: High Speed Continuous Rotation I/O: Input/Output IDE: Integrated Development Environment IMU: Inertial Measurement Unit IR: Infrared LCD: Liquid Crystal Display PLA: Polylactic Acid RGB: Red Green Blue SDK: Software Development Kit SIP: System in Package

21 Appendix B Budget Our team was provided a budget of $1,200 from the ECE department along with a generous donation of $530 from Keysight to utilize over the entire year. Product Description Cost Signal/Beacon Beacon Hardware $ Patch antenna for Beacon $50.90 Beacon Compass (HMC5883L) x4 $72.04 Fio V3 $44.50 XBee Explorer $11.95 Mechanical/Motors Servos x4 $90.84 Cog Kit $13.98 Servo Hubs x6 $28.44 Tires x6 $90.14 Sensors MPU-9150 $36.59 IR Sensors x5 (repurposed from old $40.00 project, only included in final design cost) Team Arduino Uno x2 $42.80 Arduino Mega $43.81 USB A to B Cable $4.24 Batteries $75.66 RC Car prototype $32.19 Robot Kit $65.00 Miscellaneous Hardware $ Team Shirts $ Travel Mileage $ Hotel $ TOTAL $

22 Appendix C Project Plan Phases Assignment/Deliverables Beginning Timeline Post Test Plan Timeline Current Timeline Phase 0 Preliminary Project Plan 9/16/2015 9/16/2015 9/16/2015 Website 9/16/2015 9/16/2015 9/16/2015 Notebook check 1 9/23/2015 9/23/2015 9/23/2015 Revised Project Plan 9/29/2015 9/29/2015 9/29/2015 Order critical components 10/1/ /1/ /1/2015 Phase 1 Meeting with industry 10/21/ /21/ /21/2015 Test signal completed 10/5/ /28/ /31/2015 Notebook check 2 11/3-6/ /3-6/ /3-6/2015 Have Prototype printed and integrate motors 10/20/ /4/ /31/2015 Project Test Plan(DTVC) 11/6/ /6/ /6/2015 Have directional control with motors Testing sensors with test platform N/A 11/10/ /31/ /2/ /18/ /31/2015 Phase 2 Signal recognition from receiver 10/20/ /3/ /29/2015 DTVC review 11/11/ /11/ /11/2015 Integrate motors with sensors 11/2/ /18/ /31/2015 Integrate motors with signal receiver 11/16/ /26/ /31/2015

23 Phase 3 Oral presentations 12/9-10/ /9-10/ /9-10/2015 Notebook check 3 12/14-18/ /14-18/ /14-18/2015 Integrate all moving components and code 12/31/ /31/2015 1/10/2016 Phase 4 Testing platform in loose sand 3/15/2016 1/29/2016 1/29/2016 Testing platform in loose sandy incline 3/15/2016 2/29/2016 2/29/2016 Testing platform on rocks 3/15/2016 3/16/2016 3/16/2016 Complete testing Platform in different environments Test completed project and have all bugs fixed 4/8/2016 4/8/2016 4/8/2016 4/8/2016 4/8/2016 4/8/2016 Final Phase Participate in The Robotics Challenge 4/16/2016 4/16/2016 4/16/2016 E-Days 4/15/2016 4/15/2016 4/15/2016