Team 4201: Sensor Controls

Project Proposal & Preliminary Design Review

Minal Habash and Amy Hu Engineering Development & Design: Per. 3 December 9, 2013

Proprietary Information All information is the property of, and solely owned by the Designers.

Table of Contents
Introduction A. Presentation and Justification of the Problem B. Documentation and Analysis of Prior Solution Attempts C. Presentation and Justification of Solution Design Requirements D. Design Concept Generation, Analysis, and Selection E. Application of STEM Principles and Practices F. Consideration of Design Viability Conclusion 1 2 4 5 6 8 9 10

Proprietary Information All information is the property of, and solely owned by the Designers.

Introduction
FIRST Robotics Competition (FRC) is a STEM based program for high school students to get involved and exposed to engineering. Many students do not realize what engineering is mostly due to schools not having classes focused on those fields. Schools who do offer those classes give a student the option to take it against other classes that would seem more appealing to a teenager (Yoga, Art Studio, and Leadership). FRC tasks students to create a competitive robot in a 6 week building period and causes these students to separate themselves in sub-teams such as programming, build, and media outreach. Many veteran teams use their time starting the end of a robotics season in order to prepare for the next year.

Figure 1 Kick-Off Event held at Northrop

Grumman which allows teams to network with one another and gives an opportunity for teams to play the game through the use of their bodies as the robot.

In the year 2012, in Da Vincis 3rd year since its founding in 2009, Da Vinci founded its FRC team, the Vitruvian Bots. The team was primarily made up of the Class of 2013 with few from the Class of 2012, Class of 2014, and Class of 2015. As rookies for the 2012 competition, Rebound Rumble, the Vitruvian Bots were able to gain a lot of support from veteran teams such as Beach Cities. The day after kick-off, the Vitruvian Bots held a kit-bot Figure 2 The original kit-bot robot build through the kit of build day, where various teams gathered at Da Vinci parts given to teams at kick-off. Science to start building an operating kit-bot. From there, the kit-bot drive train had been the basis for the robots of the 2012 and 2013 year and one big goal is to break away from this set-up. Also, in those two years, programming had not been as big as an emphasis as the design and build, however is just as important. In this document, you will find our solution to improving the programming of our team and to make it as manageable as possible for the 2014 FRC season.

Proprietary Information All information is the property of, and solely owned by the Designers.

Project Proposal
Component 1 - Evaluation of Research Validation and Justification of Problem Selection Element A: Presentation and Justification of the Problem
Problem statement
In the year 2011 DaVinci founded a First Robotics Competition team which allows high school students to get involved with electronics such as utilizing closed loop systems for the 15 second autonomous period. However, in order for the robot to operate the robot will need good programming.

Problem background/statistics
Programming is an essential part in anything robotic, and is used in everyday activities. Programmers need to make sure their code functions to the task created in order to please the consumer. For example, a computer is used by many people in first-world countries. Without it functioning for the consumers best interest, it causes companies to lose sales. Also, there are instances where human interaction could not be used in order to work with a machine. This can be seen in satellites, where programming needs to be precise in order for it to do its intended task in space. Without human interaction, programming needs to be correct and accurate at the moment the satellite is deployed in space. In the 2012 competition, Rebound Rumble, the code was mostly scripted by Brian Vallelunga, the head programmer at the time. He had known the program Labview the most and was the primary programmer, however was not a person who liked collaborating with the rest of the team. In the 2013 competition, Ultimate Ascent, the code was scripted by a new team of programmers who had basic knowledge of Labview. These programmers were not able to reach the same level of understanding as Vallelunga, however were able to get a basic code that could run during competition. During this season however, the autonomous period was primarily focused on an open loop system which was not reliable and there were times the code during tele-op was dysfunctional.

Validation of problem
Experts who justify this problem is our mentors, which includes: Aaron Tostado, David Stuart, Caline Smith, Fazlul Zubair, Gerard Besina, Lenny Perez, and Michael McClendon. Each have identified that the movement of the robot during the autonomous code could be optimized through the use of more closed loop systems. Our mentors are engineers and teachers involved with Team 4201: The Vitruvian Bots.

Consumers, users surveys, interviews

Interview with last years head programmer: Was the autonomous code reliable? Proprietary Information All information is the property of, and solely owned by the Designers.

No, it was not because of the fact that the hardware will never be perfectly the same every run. This was especially hard to figure out because the robot we practiced on and the one that we used in competition were not identical. By using accurate sensors the transition between the two robots would have been easier. In what ways could the autonomous code be improved? We could use sensors to help determine where the robot it is so it doesnt rely on time so much. The types of sensors we could use include vision, accelerometer, gyroscope, and others. We also seemed to have bad human to robot interactions, as well, last year that costed us time and points. What is some methods that we can use in order to make this easier for next year? We can use sensors to calibrate the robot to mimic the same stance each time it interacts with one of the team members. We could also incorporate a pneumatic system that would literally suck up the object in question. This would make the margin for error widen dramatically.

Brief summary of existing products and patents (more in Element B)

Currently there are many different types of sensors out there. This includes gyroscopes, light sensors, accelerometers, ultrasonic sensors, and vision tracking.

Works Cited
"Chief Delphi - Portal." Chief Delphi RSS. Chief Delphi, n.d. Web.

Figure 3 The 2012 Programming Team during the kit-bot build day (left). Figure 4 The 2013 Programming Team learning about different motors during the ice-breaker meeting (right).

Proprietary Information All information is the property of, and solely owned by the Designers.

Element B. Documentation and Analysis of Prior Solution Attempts

Although a lot of the information gathered is found through ChiefDephi forums, especially for the needs of FIRST robotics competition, a good chunk of the information also comes from firsthand experience. In previous experiences, programming has always had the least amount of time in testing with the actual competition robot. With less time to program the robot, there is less time for programmers to debug the code and to finalize it. Although there is time to test with a "stunt double" robot, there are many factors where the hardware doesn't match on both robots. This causes even greater confusion for the programmers as they will have to adjust to the hardware changes on the robot. One potential solution would be to use more sensors, as the programming can use close loop systems to be proportional to the coding itself. This can be seen through the use of the camera on the past two robots: Leo and Leo's Armie. On Leo, the coding on the robot was proportional to the camera and had an overlay on the screen that aided in the shooting mechanic of the robot. However, that same feature was not used on Leo's Armie. In the future, it has been discussed with our mentors Aaron Tostado and Fazlul that we will use more closed loop systems in order to compensate for inconsistencies in the hardware. Other teams address similar issues in the creation of their sub-teams in FRC. Many teams on their driver station upgrade from the default classmate as they gather funds. In doing that it allows teams to customize the types of controllers they use, such as the use of iPads. Although an upgrade would be nice, it is not an immediate need for Team 4201, especially with limited funds that have decreased from the lack of support from companies. Also, many other teams focus on training future team members year-round. The biggest issue found in all teams is the size of a team as a whole and the amount of people who constantly participate during build season. To compensate, each sub-team focuses on training team members they can count on in order to keep the future of the team alive. This can be seen in Team 4201's accelerated start on Team activities during September as the usual start the month before Kickoff. The con to this specifically is sorting out different jobs that the team is usually doing during build season itself. However, the time investment before build season allows that time to be strictly used for building and testing the program.

Figure 5 The 2013 season team; the robot on the right is the JAP, "Just a Prototype", which was used for
programmers after the competition robot on the right was bagged until the competition date.

Proprietary Information All information is the property of, and solely owned by the Designers.

Element C. Presentation and Justification of Solution Design Requirements

Design Specifications The controls branch of FRC will be split into two branches for this project. Our team will be working on the software side of controls while the other will be working on hardware. Because of this arrangement, we will not be designing anything per se; we will be designing the code. The framework of our code will be based on the SimpleRobot code on Windriver C++. We discuss our progress with our mentors and team 4201 once a week to make sure they are updated. We get feedback from our mentors through email, and we send them weekly updates every Friday. We make sure to also talk to our stakeholders, or team members, about our progress on our projects every Monday at the FRC meeting. These stakeholders are all considered equal to our project. The progress of this project will benefit from and help both the team members and mentors equally, for it is beneficial to the movement of the team as a whole. Originally, we believed we were going to use C++ for the FRC code this year however, we have come to the realization that it is not feasible in the short amount of time we have left. One reason for this is that RobotC, programming software commonly used in engineering classes throughout our school, was not similar enough to C++ to overcome the steep learning curve that such a program presents. The reason why C++ is so hard to learn is that it is written in a formal language meaning that it is (1) a new system of writing that must be learned as any new language does, (2) needs to be perfectly puncuated in order to be successful, and (3) it is hard to follow without using comments throughout the entire code. With most of our team having little to no background in C++, we have no choice but to revert back to LabView. LabView is a much simpler form of programming known as block code. It is a system of drag-and-drop functions that are very easily followed by looking at the color of the lines connecting different blocks. We have been using LabView for the past two years, so the heads of the programming team, Amy and Minal, have a good understanding of it and can teach incoming programmers the language. The only thing this switch changes about our plan is that the framework of our code would be the Sample Code provided in the LabView update earlier this year.

Proprietary Information All information is the property of, and solely owned by the Designers.

Preliminary Design Review

Component 2 - Evaluation of Design Validation and Justification of Proposed Solution Element D: Design Concept Generation, Analysis, and Selection
Techniques Used One technique that was used was examining our sample code in order to link back to our prior knowledge of programming in Labview. By doing this, it allows us to make connections back to the Labview code and can use the old code as a basic pseudocode in order to write in C++. Another task we are working on is looking at other FRC teams C++ code in order to settle on how to organize our code. We have also looked into project domains that would allow for multiple programmers to write their part of the code to incorporate to the teams code. In doing this, it creates a backed up online code that can be easily accessed and allows more assesibility to the code. Finally, at school there will be two designated desktops and a laptop that will be strictly for FRC usage. This allows us to rely on a on-site school storage system and allows programmers to have an offline code stored away. By doing this, this is making the programming more assessable as opposed to last year and gives each programmer more responsibility in their tasks. Also, by giving more access to the code earlier on, this gives more time for the programmers to work on writing the code and coordinating with the rest of the controls team. Collaboration will be a big part of this years success and that is the overall focus in teaching future team members. Best Solution One solution that will be beneficial would be creating a heavy duty guide book to C++ programming. Other teams who go by this approach are able to teach newer members aspects of the code that is important to learn for the specific competition of the year. However, without a guide, there would be holes in the learning curve that could be filled in with this guide and the team each year. This can also be furthered by the use of comments in actual code to make sure everyone on the controls team understands what is happening in the code, not just the programming team. Also, we will be writing a pseudo-code structure map that will be a way to see the programming as a whole. In doing this, it can easily help assign programmers to a task and helps map out what needs to be done. As previously stated in Element C, we will no longer be using C++; this does not mean that the approaches above are now made invalid. It is beneficial for the understanding of LabView to go through the connections between the blocks. The only thing that changes about our plan is the type of code will be changed from line to block.

Proprietary Information All information is the property of, and solely owned by the Designers.

Figure 6 This is the sub-program for the Tele-op sub program. Due to our difficulties in working with C++, we
decided to return to the use of Labview.

Example Pseudo-Code Map

In creating a Pseudo-code flowchart, it will allow us to organize our code and allow for a breakdown of what will need to be down. This will allow tasks to be separated out and organized in a fashion where everyone will be aware of what needs to be done. This will also allow for us to issue due dates to our team and allow us to make sure our code makes sense in earlier stages of writing the code.

Proprietary Information All information is the property of, and solely owned by the Designers.

Element E: Application of STEM Principles and Practices

Especially looking into the framework of the programming, programmers would need to understand some math concepts in order to understand what is happening in the coding. This can be seen especially when researching PID control systems. By looking at PID controls, a lot of math needs to go into the work behind the programming in order to figure out the proportioning of the programming language. Also with programming, it's important to plan out how a code will look before blindly programming. With Labview, alterations to the code are a lot easier due to the use of visual blocks. However, with C++ it's crucial to plan out what the overall code will look like and the sub-programs. In planning the pseudo code before the creation of the actual program, it allows programmers to plan out and map any changes to their code. In these early stages of programming, it gives the programmer breathing room to see if everything is together. Decision Matrix of what Program to Use Feasible Time Experience Flexibility 1 1 2 4

Total Windriver 8 C++ Labview 3 3 4 1 11 In planning this, the use of Windriver Workbench will be utilized with some reference to Labview. By looking at Labview and how the visual block code works, it can help guide a programmer on what type of loops or case structures to use. The practices needed for a successful code is definitely planning everything out and documenting daily in an engineering notebook. By taking notes, it allows a programmer to check their own progress and allows them to check if they are upholding to their time management restraints. With the use of Labview, we will be focused on improving our code from last year by spending more time to organize what needs to be done in a Gantt chart. We will also be logging our information and what we will be doing in a daily log in our engineering notebooks.

Proprietary Information All information is the property of, and solely owned by the Designers.

Element F: Consideration of Design Viability

Market Analysis Because we are an FRC team, we compete with other teams every year. In a sense we are selling how well our robot works in order to gain additional support from sponsors. Last year, our product was not as good as the other teams robots in some cases. If we are able to become more reliable on the programming aspect, then we will be able to get farther this year. By having a reliable robot, then more sponsors will be willing to invest in our team and our future success. In working to gain support, we have started a team piggybackr that allows community members to donate to our cause. This has helped raise money for additional raw materials and for our tea to register in two competitions this year. We will also be fundraising throughout the entire year through the selling of laser engraved water bottles and little trinkets made with our laser cutter and 3D printers. This has worked for many teams in the past to gain extra funds towards team necessitates such as food.

Proprietary Information All information is the property of, and solely owned by the Designers.

Conclusion
Importance of Market Analysis Although looking at the percentage of the population who believes the problem is important to solve is beneficial in some aspects, it isn't as important in discovering who would actually buy the product in the market. By looking at the available market, it allows producers to determine if the product they are making will be of interest to the consumer. Also, the people who believe a problem is important to solve, might not be committed to buying the product especially due to conditions such as quality, price, and need. Reassessment Although it's likely that each part of this document will be reviewed, the parts most likely to change would be parts C, E, and F. The reason being is that these parts aren't set in stone as further research in this problem will cause the initial ideas to change. These parts will become reassessed at least once every two weeks, however these checks will increase as time gets closer to the start of a new season.We believed we were going to use C++ for the FRC code this year, but we realized that it is not feasible in the short amount of time we have left. One reason for this is that RobotC was not similar enough to C++ to overcome the steep learning curve that such a program presents. The reason why C++ is so hard to learn is that it is written in a formal language meaning that it is (1) a new system of writing that must be learned as any new language does, (2) needs to be perfectly puncuated in order to be successful, and (3) it is hard to follow without using comments throughout the entire code. With most of our team having little to no background in C++, we have no choice but to revert back to LabView. LabView is a much simpler form of programming known as block code. It is a system of drag-and-drop functions that are very easily followed by looking at the color of the lines connecting different blocks. We have been using LabView for the past two years, so the heads of the programming team, Amy and Minal, have a good understanding of it and can teach incoming programmers the language. The only thing this switch changes about our plan is that the framework of our code would be the Sample Code provided in the LabView update earlier this year. In conclusion, we still have a lot left to learn about in order to program it in our 2014 final code. The issue we ran into with C++ was a huge setback that took a lot of our time. We really wanted to be able to program in C++ because (1) it is similar to RobotC, a programming language taught throughout the school, (2) it is used extensively in the engineering world, and (3) once you know the language it has a wide variety of capabilities.

Proprietary Information All information is the property of, and solely owned by the Designers.

10