A BRIEF INTRODUCTION TO COMPUTER PROGRAMMING Scratch, LEGO MINDSTORMS, and Visual Basic. July 24, 2015

Transcription

1 A BRIEF INTRODUCTION TO COMPUTER PROGRAMMING Scratch, LEGO MINDSTORMS, and Visual Basic July 24, 2015

2 ABSTRACT This project was created to provide a better understanding of computer programs and their importance to society. As part of this project, we gained an understanding of programming through the use of the beginner programming languages Scratch, LEGO MINDSTORMS, and then Visual Basic. We then focused on specific languages and used those languages to create programs that accomplished predetermined goals. Our programs effectiveness was tested by users who completed performance surveys. INTRODUCTION In today s society, computers have permeated almost every aspect of our lives. Improvements in computer technology have greatly simplified everyday tasks. For example, in the past, information was kept in books, and the only way for an individual to find the information they needed was to sort through mass amounts of irrelevant material. With the advent of the internet and search engines such as Google, we are able to access all the information that pertains to our subject without having to sort through pointless data. Computers have also led to ever-increasing advancements in communication. Moving from letters, which were the only mode of long distance communication in the past, to cellphones, s, texts and social media, communicating with individuals hundreds to thousands of miles away has become easier. In addition, healthcare systems all over the world rely on computers for patient diagnosis as well as organizing and storing patient information. In schools, individuals are now able to take courses online and digitally access materials needed for class. Computers have also eliminated the easily rigged ballot boxes of the past, therefore, providing democratic systems with an element of credibility. These computers that are so ingrained in our everyday lives are composed of hardware and software. Hardware is the physical components that make up a computer (Farrell 2008). If a part of the computer can be touched, it is hardware. Some examples include the monitor, the keyboard, and the mouse. Software is the intangible aspect of a computer (Farrell 2008). It can be considered the logic that runs on top of the computer hardware. In comparison with the human body, hardware can be thought of as our tangible components, such as our brain. Software in this analogy would be our thoughts and emotions. They do not exist physically, but rather logically. Some examples of commonly used software are Microsoft Office, Microsoft Windows, and itunes. Software is also known as computer programs. A computer program is a set of instructions that a computer is able to follow in order to carry out a specific task (Farrell 2008). On its own, a computer is unable to perform any action; a program is needed even for simple tasks such as turning the computer on and off, saving a file, opening a file, or deleting a file (Farrell 2008). Computer programs must be written in precise ways called computer languages. A computer language is defined as symbols, words, numbers and letters that can be translated into instructions a computer is able to understand (Farrell 2008). Humans understand simple words, phrases, and sentences and can easily follow directions using these components. A computer, however, is unable to understand spoken or written language. 1

3 The only language a computer is able to understand is binary. This is a language composed of only zeroes and ones that represent open and closed electrical circuits (Farrell 2008). Binary is considered the lowest level computer language because it is the easiest for the computer to understand and the hardest for programmers to understand. Computer languages can be considered both high and low level. The lower the language level, the easier it is for a computer to understand because it requires less translation to get back to the zeros and ones of binary (Farrell 2008). However, high level languages are easier for programmers to understand due to increased readability. High level languages begin to incorporate words and phrases in order to create commands. Therefore, these languages undergo a series of translations to return to binary and tend to run slower than lower level languages. Similar to spoken languages, computer languages must follow a set of rules in order for the receiver to fully comprehend the message. These rules are referred to as syntax in computer languages and are specific to each language, meaning what is true in one language may not be applicable in another. For the computer to understand the programmer s instructions, proper punctuation, word placement, and word choice must be used. The different computer languages are like the different spoken languages (Farrell 2008). For example, in English, the simple question What is your name? is unrecognizable when translated to another language, such as French or German. In French, to ask an individual his/her name, the phrase used is Comment t appelles tu? This translates directly to What do you call yourself? In German, the phrase Wie heiβt du? is used. However, these expressions, whether in English, French, or German, mean the same thing. In computer programming, the same phrase will also look completely different depending on what language the programmer has decided to use. For example, in a programming language called Basic, a command would look like: if (x>5) print greater. However, the same command in another language such as Java would look like: if (x>5) System.out.printIn ( greater. ); (Farrell 2008) The purpose of our project was to understand and learn various computer programming languages. Using this knowledge, we aimed to successfully create a program using one of three programming languages, Scratch, LEGO MINDSTORMS, or Visual Basic. Scratch is a programming language and platform created by students at the Massachusetts Institute of Technology, MIT. Their goal was to provide a friendly programming environment for beginners (About Scratch). Scratch is a visual tool that provides users with instant feedback and the ability to see their program come to life. The platform can be used to create simple games and animations. Like most programming languages, Scratch programs are operated in sequence, meaning in order the way they are written. Sequences on Scratch are often activated by an event, which is a signal, such as a key press, that causes an action to happen. Another programming tool we used was LEGO MINDSTORMS. This programming platform was first released in 1998 by Lego Group (Valk 2008). Similar to Scratch, it was created as an educational tool for beginner programmers. The program creates visual and physical interactions with a robot that the user builds. 2

4 LEGO MINDSTORMS is considered a high level language. Using what we learned from Scratch, we were able to build more complex programs on LEGO MINDSTORMS. The final programming language we learned was Visual Basic. This language was released to the public in 1991 by professors at Dartmouth University (My. Resources Object). The language was created to make writing programs easier and is mainly applied in professional environments. It is used to create computer programs, as well as web sites and applications. Visual Basic was the most complex language we learned. Syntax played a large role in programming using this high level language. The skills we learned from Scratch and LEGO MINDSTORMS helped us gain an understanding of programming that could be applied to Visual Basic. ITEM RUSH: A SCRATCH PROJECT PROJECT DESIGN The goal of our project was to successfully create a two-player game in which users compete to get the most points by retrieving good items, while avoiding bad items that reduce points. We used Scratch because it is visual and user friendly, and also it is a better platform for making games and animations than Visual Basic. METHODS The first factor considered was choosing the Sprites (characters). Next, a neon tunnel was selected as the background and grey buttons were chosen as the barriers. Then, score boxes were placed on top of two of the grey barriers and labeled RED and BLUE. The letters that would appear on the screen to show the winner were then added. Our project was designed to accomplish eight goals: the game should be a competitive two player game, Sprites should appear within certain coordinates, the game should have an accurate way to keep score, players should be able to use W, A, S, D or arrow keys to move the competing characters, players should be able to collect good Sprites to add points, bad Sprites should subtract points, players should see no more than one good Sprite on the screen at any given time, and the game would end after all eleven good Sprites were collected. When the Sprites were coded to move, the keys W, A, S, and D, along with the original arrow keys were used. One player would use the WASD keys while the other could use the arrow keys. Different color ladybug Sprites were chosen as competing characters to reduce confusion. In order to make sure the players had to use strategy to move in, out, and around barriers, the Sprites were programmed so that when coming in contact with a barrier, the code would change the X or Y direction by 180 degrees. Multiple backdrops were added so that when an item was touching one of the Sprites, the backdrop would change, and a new item would appear. The items were coded to move around the game board by picking a random X coordinate for a specific Y coordinate and waiting one second between appearances. A checklist of all of the goals to be accomplished was made and the performance of the game was tested by users to see if all goals were met. 3

5 RESULTS All of the goals in our checklist were met. Each individual who tested our project agreed that it was a competitive two-player game, the items appeared in certain coordinates, there was only one good item on the screen at any given time, and the game ended after all good sprites were collected. Eight out of ten agreed that the game had an accurate way of keeping score. Seven out of ten agreed that they could use the correct keys to move their characters, they could collect good items to add points, and that the bad items subtracted points. CONCLUSIONS AND DISCUSSION To make a goal successful, six or more people out of ten needed to find no problem with it. Therefore, we considered our game a success. However, there are improvements that could be made, such as, adding multiple smaller barriers, more items, and levels that get increasingly difficult. These additions would make the game more challenging. Originally, our game used a cat Sprite. However, when testing the game, we realized we had coded the barriers so that when the Sprite is touching any barrier, it could not move past that barrier. With further investigation, we realized the cat Sprite would not move because the tail was still touching the barriers. Therefore, we changed it into a lady bug Sprite and took the wings off to avoid the same problem. One of the problems we ran into was that both Sprites were moving with the arrow keys. Knowing this, we changed the code, so one Sprite will use the WASD keys. We also realized that the Sprites could move freely through the barriers and collect items more easily. To solve this problem, we modified the code so that when the Sprite came in contact with a block, the Sprite s X or Y value would change. Another issue was getting a good item to appear after one was collected. The items were originally set on a timer to make Sprites appear every fifteen seconds. If the user collected an item before the fifteen seconds were up, they would have to wait for another item to show up. If the items were not collected in fifteen seconds, another item would appear, causing both of them to be on the screen. The fix for the problem was creating many backgrounds. When a Sprite was collected, the background would change, causing a new Sprite to appear. 4

6 SPACE CONVERSION CALCULATOR: A VISUAL BASIC PROJECT PROJECT DESIGN Our project purpose was to create a fully functioning Space Conversion Calculator for weight and age in Visual Basic. Our calculator would successfully convert a person s weight and age on Earth to each of the nine solar system planets (including Pluto), as well as the Sun and the Moon. METHODS The form of the Space Conversion Calculator was designed using labels, combo boxes, and text boxes. The two combo boxes were used to select the unit of conversion (kilograms, pounds, or Newtons) and the celestial body of choice (The Sun, the planets, or Pluto). With the user s selection of a planet from the Choose Planet combo box, the program was coded so a representative picture of that planet would appear. Labels were used for the titles and unit labels for the input and output values. Text boxes were used for the input of the values and the output of the converted values. Conversion formulas were coded into the program and the results were displayed in text boxes. RESULTS Through our tests of the program, ten out of the ten testers said our program operated under normal conditions, and five out of ten testers encountered an error situation. When all of the input text boxes were not completed before the Calculate button was pressed, the program crashed. CONCLUSIONS AND DISCUSSION Based off of our results, we determined our program was successful because our calculator executed more than 80% of tasks as expected. One bug found was if the user failed to enter a value for one of the inputs, but entered the other value and tried to calculate, the program sent an error message. This situation applied to both the entering in of Weight without Years old and entering Years old without Weight.. To fix the problem of leaving an input text box empty a line of code like this ( If TextBoxWeight1.Text = ( ) Then TextBoxWeight.Text = ( 0 )) was added to the Calculate button s functions to make the empty text box equal zero and the conversion for the completed input will take place. As of now, if the user does not select a unit or a celestial body, the program sends an error message. We can modify the code so if the user does not select those and attempts to calculate, the output results will be 0. Also, a line of code was added so if the user tried to type in the combo box, the combo box text would go back to the original selection prompt (either Choose Unit or Choose Planet ). Finally, code from a Visual Basic tutorial was used to prevent the user from inputting letters in the Weight or Age text boxes (Allow Numbers). Instead of excluding all letters it was decided to just allow the characters In future studies, we can determine if our calculator is helpful by releasing it to be tested on astronomy and physics students. We did not run into any limitations in Visual Basic, and we would consider reusing it for higher level language coding projects such as creating web sites, applications, or databases in the future. 5

7 RMSC EVENING ACTIVITIES FORM: A VISUAL BASIC PROJECT PROJECT DESIGN The purpose for this study was to create a new RMSC (Regional Math/Science Center) evening activity form, using Visual Basic, to improve the way students select their evening activities. METHODS The first task was creating a form with drop down lists containing the names of students, tutor counselors, as well as evening activities. The text file containing the student s names was read to input into the Student name drop down menu, and the same was done for activities and tutor counselors. To save the information, a Submit button was created. This button operated under a conditional statement, meaning, if the submit button was clicked, then the data would be stored. A problem we found was the form had no way of updating the information for each day and all of it was stored in the same file, so a calendar was added so the date could be added to the activity file name. Also errors happened if a field was left blank. A new conditional was then created, stating that if fields are left blank, then the message ERROR: Information is missing would appear. RESULTS All testers reported that the program worked fine under normal circumstances. 90% of people reported that the program was easy to use and understand and had a clear purpose. 50% of people reported that they could submit the same information more than once. 30% stated that they could change the data in the drop down menu, while 40% reported that they could type in the drop down menus, and that the program was confusing. CONCLUSIONS AND DISCUSSIONS Although the project worked successfully, many aspects could be improved. There were problems with editing information in the drop down menus, resubmitting the same thing more than once, changing the date, and not being able to find the collected information. The form could be modified so that the user can only submit the information for the same person once. A conditional statement could be created that states if the information is collected, then do not collect the information again. Also, the user should not be able to edit the information in the drop down menus. This could be done by creating another conditional statement that prevents writing in the text box whenever attempted. Finally, the date should not be changed in the calendar. This could be done by making the calendar read only. 6

8 SNATCH3R: A LEGO MINDSTORMS PROJECT PROJECT DESIGN The original design for our project was for the robot to sort objects by their color and place them in their respective bins, but due to implementation issues, the program design was changed. To accomplish the updated design of our project we programmed our robot to do specific actions as it moved through a series of blocks. METHODS The SNATCH3R model was chosen because it had a claw to pick up items. However, modifications specific to our project were needed. The color sensor was moved to the back of the robot resulting in the claw and color sensor being on opposite sides. An infrared sensor was placed within the claw, and the color sensor was removed. To prevent the robot from getting stuck while attempting to lift a block, the rotation numbers for all of the medium motors were decreased. The robot was also designed to go around the third wall. When the distance between the two blocks was decreased, the robot would hit the block, so the sensitivity of the infrared sensor was raised from fifteen to twenty inches. The robot was programmed to approach a block, sense it, and perform the action. The power of the wheels was decreased and the robot went at a slower pace, allowing more time to detect the object. Our robot was tested by users who completed a performance survey. RESULTS Data showed that our robot only performed one out of the six goals it was programmed to accomplish, which was detecting objects in its way. Two out of ten people said the robot hit the LEGO blocks and three out of ten said that the robot did not go straight. All of the actions that involve the robot turning did not work and the robot did hit some of the blocks. Lastly two out of ten people said that they did not think the robot had a specific goal. CONCLUSIONS & DISCUSSION Overall our robot was unsuccessful because it only performed 27% of the initial tasks correctly. The robot had no problem detecting objects in its path. The robot was unable to move straight, because it would move 90 degrees to the right or left depending on the task, but never turned exactly 90 degrees back. Thus, we had the users place the blocks and determine their own course. However, if the block was too close to the robot, it would not have enough time to sense the object. In the future, a color sensor could be added so that the robot could do different actions depending on the color sensed. Also more detail could be included in the instructions stating how far the block should be placed in front of the robot. 7

9 SNATCH3R 2.0: A LEGO MINDSTORMS PROJECT ROJECT DESIGN The purpose of our LEGO MINDSTORMS project was to successfully program our robot to sort out colored balls and place them in different locations depending on their color. We used a robot that could recognize the colors red, green, and yellow. METHODS The robot was designed to complete seven main tasks. The first task the robot was designed to perform was to search for a colored block every two feet. The next task was if red was sensed, the robot was designed to pick up the block, turn left 90 degrees, go forward and then drop that block. The robot was then designed to return to its original spot by backing up and then turning right 90 degrees. If green was sensed, the robot s fourth task was to pick up the block, turn right 90 degrees, go forward, and then drop the block. The fifth task the robot needed to complete was to return to its original position after detecting the green block by backing up and then turning left 90 degrees. The sixth task the robot was programmed to accomplish was detecting the color yellow, picking up the block, turning 180 degrees, and then moving forward before dropping the block. Finally, the robot needed to be able to return to its original position after picking up the yellow block by turning 180 degrees and moving forward. The robot was built using a modified version of the EV3 SNATCH3R model (Valk 2014) which had its infrared sensor in the claw replaced with a color sensor. The robot had trouble recognizing colors before it was extremely close to an item, and would often push away or knock it over before the color was identified. This problem was fixed by decreasing the power on all the motors, causing the robot to move much slower. The portion of the program that made the robot move forward two feet and try to detect an item was placed in a forever loop, meaning that if a color was not detected, the robot would continue moving forward indefinitely, thus creating a searching mechanism. After programming, the robot was given to ten people who tested it and identified any problems or bugs with the robot and program implementation. RESULTS The robot successfully completed the first task, which was to search for a block every two feet, each time it was tested. The second task, which was sensing and moving the red block, was completed successfully over 90% of the time. The robot was able to complete the third task and return to its original position each time tested. The robot was successfully able to sense and move the green block over 50% of times tested. The fifth task the robot needed to complete was to return to its original position after detecting the green block. The robot had trouble turning exactly 90 degrees and was unsuccessful in completing this task. The detection of the color yellow proved to be a problem with the majority of testers. The robot was unsuccessful in this task 60% of times it was tested. However, the four times out of ten that the robot did detect the yellow block, it was successful in its final task, which was returning to its position after moving the yellow block. 8

10 CONCLUSIONS AND DISCUSSIONS Out of the seven tasks the robot was designed to complete, it could successfully complete five of them, earning the robot a performance grade of 71.43%. The searching mechanism we designed for the robot was effective during testing; however, the robot was programmed so that it would only move forward in a straight path when seeking a block. The robot s range could be improved by randomizing the directions in which the robot traveled. This would increase the detection field of the color sensor and allow the robot to perceive items on its peripheral rather than just blocks directly in front of it. The robot could be made more efficient if it were programmed to continue searching for blocks as it returned to its original position. The portion of the program used to search for blocks could be copied and reused in the section of programming that the robot uses to return to its original position. Therefore, if the robot senses a color on its way back, it will perform the task specific to that color, and if no colored object is sensed, the robot will continue its return. During testing, the robot was frequently unable to detect the yellow block. This was due to limitations in the materials we had available to us and the sensitivity of the LEGO MINDSTORMS color sensor. The blocks we used were constructed from sheets of paper taped together and wrapped in reflective duct tape, so often a side of one of a block would cave in. The EV3 color sensor must be extremely close to the item whose color it is detecting. If the side of the block facing the color sensor was even slightly caved in, the sensor would not be close enough, and the robot would react as if there were nothing in its path. The yellow block was more fragile than the red and green blocks; therefore, more of its sides were likely to have been pushed in and rendered undetectable by the robot. This problem could be fixed by either creating or purchasing more stable blocks. The other problem the robot had during testing was returning to its original location after it had completed its assignment with the green block. The robot would sense the green block and perform the necessary action; however, it could not return. Consequently, the program s entire path for the remaining blocks would be thrown off if the robot was unable to return to its intended location after completing a task. This problem was most likely a result of the motors controlling the wheels not being set to the right amount of rotations, power, or degrees. 9

11 TRACK3R: A LEGO MINDSTORMS PROJECT PROJECT DESIGN We designed our robot to distinguish between colored LEGO walls and carry out tasks based on the color it sees. For blue, it will hammer the wall, for yellow, it will trample the wall, and for red, it will avoid the wall. Our robot will also be able to move tires from one specified spot to another by exact programming. METHODS The robot TRACK3R was built with a few modifications to fit our project. For example, an outward facing color sensor was used instead of the original design s infrared sensor. Basic actions such as the forward propelling motion and the swinging down of the hammer were programmed before the robot was built. After these were tested, a conditional statement was created that would have the robot say the name of the colors it sensed. This conditional was put inside an infinite loop, which allowed it to reevaluate itself. The rest of the actions were programmed, and they were added to a color sensor conditional allowing the robot to complete a certain task based on the color it senses. For the color sensor task, the forward motion was in slow pulses, but those would sometimes put the sensor too close to the wall for a proper reaction. The code was changed back to the original continuous, smooth motion. However, the power was decreased. A color conditional was set up for red, yellow, and blue, and the robot could then sense any of the three colors, in any order. For the red wall, the robot was programmed to say detected as soon as it sensed red. A code block was placed that stops the motor before the sound to prevent the robot from sensing red and moving forward while saying detected. For the tire task, exact measurements for the tire spacing were needed, so a test track with set measurements was created. Instructions for the two courses were created. Testers used those to operate our robot and give feedback based on the outcome of the program. Scores were used to determine the performance of the robot. RESULTS Ten out of ten people completed the wall obstacle successfully, and there were no issues reported. The robot correctly sensed colors for each wall and executed the correct action for each color. The robot also moved forward, as intended, when it did not sense a color. The tire obstacle was unsuccessful as four out of the ten testers found problems with it. Three out of those four testers reported that the robot ran over the tires and got stuck. One tester said the robot pushed the tires to the right side and returned to the starting point, but the robot did not use the claw to do so. CONCLUSIONS AND DISCUSSION ` Based on the users feedback, we concluded that the colored wall obstacle was 100% successful, but the tire obstacle was only 60% successful. When we were still debugging our robot, we detected no problems with the coding on the tire obstacle. Every time we tested the robot on the test track, the sequence was successful. This led us to believe that the tire obstacle was unsuccessful because of non-code related reasons. Towards the end of the 10

12 trial, our robot started to get low on batteries. Two of the four users who reported issues with this obstacle were testing when the battery was low. This could possibly have affected our results. In the future, we would make testing more standardized and supervised. We were present while some of the users were testing and not there while others were testing. We would also have the programmers watch while the users were testing, so we could see exactly what caused our issues. There were also a very limited amount of testers. GENERAL CONCLUSION Overall, this project helped us to gain a better understanding of the programs used in the computers we encounter every day. Scratch provided an easy to use overview of programming that served as a vital knowledge base. LEGO MINDSTORMS was an exceptionally useful tool which we, as individuals with little to no previous background in programming, could use. Visual Basic was a necessary introduction into complex coding that gave insight on universal programming concepts such as syntax. 11

13 REFERENCES CITED About Scratch. (n.d.) Retrieved from Allow Numbers only in a Textbox Visual Basic.NET. (2015). Retrieved from Farrell, M. (2008). Computer Programming for Teens. Boston, Massachusetts: Course Technology, Cengage Leaning. My. Resources Object. (2015). Retrieved from Valk, L. (2014). The LEGO MINDSTORMS EV3 Discovery Book. San Francisco, CA: No Starch Press Inc. 12