2015 Programming
Between last season, and this season, we switched between NXT and EV3. Our coach didn't know how to use EV3 software, so our programmers were out on their own to brave the depths of EV3's switches and loops. Most of the programmers' time at the beginning of the season was spent recreating the utility code we had amassed from our NXT days.
In Our Programs We...
Use Myblocks
Use a Master Program
For EV3, when you download to the robot, it downloads the whole project in no particular order. It's very time consuming to click through to all the programs find the particular program you want. Therefore, we created a master program which has the missions we want to run in order we want to run them. In our master program, we give a number to all of our programs and have a counter that's an endless loop, so if we have five missions, the counter won't go out of range to six, but instead back to mission one. All we need to do is click on the right and left arrows keys to go back and forth between the desired missions, meaning that we can skip over missions and go back quickly, when we are running during the competition. It saves a lot of time and makes thing more organized.
Use Utility Code
Some crucial utility code that we use, but not to directly get points on the mat include Check Counter Range and Mission Number to Program Name, which are both a huge part of the master program (see above).
Use Error Correction
To ensure our position around the field, we use error correction, which corrects the robot if it goes too far or misses a line. It uses the motor sensor to calculate how far the robot has gone. In our programs, when the robot is expecting to find a particular colored line on the field, we know approximately the distance the robot should have to go to find that line. If the robot goes too far (the rotation sensor reading is greater than the expected distance), then it backs up, turns slightly, and goes forward again to find the colored line. It's nice to have this as a back up in case our robot doesn't make it to a crucial spot in our mission. It ensures that the mission run more effectively and accurately.
Use Data Wires and Variables
For building majority of our Myblocks, we use variables and data wires. Data wires are embedded in the myblock and connects the variable block to the function which we want to be a variable in our Myblock. Variable blocks allow us to plug in different amounts as we reuse the same basic functions. For example, for MyMoveInInches (see above), we connected a data wire from a variable block to the power slot of a motor steering block, which as a myblock, enables us to plug in a different percentage of power each time.
Documentation and Organization
To keep track of so many programs and myblocks, we have created new folders, commented all our programs, kept track with change logs in each program, a programming notebook, and created a master program.
Pseudo Coding
Before we program missions, we pseudo code it! Pseudo coding is the process of writing/documenting every movement of the robot during the mission, so it's clear and carefully planned out. This process catches a lot of errors that would come up in programming without any pre-planning, and saves the time that would take to fix those mistakes. It's easy to comprehend and may seem time consuming, but pays off in the long run.
Use Myblocks
- MyBlocks are pieces of reusable code. You use MyBlocks when you have code that you use over and over in multiple programs, like a right or left turn. You can make MyBlocks that have constants, like the direction the motor turns, or your MyBlocks can have variables like power and duration. Those are the only values you have to put in. Some benefits of using MyBlocks are: You can name the blocks exactly what they are and that makes your program more readable. MyBlocks save time, because you don't have to recreate code, they streamline programs, and they save space on the brick because each MyBlock is only downloaded once to the brick, and then called by each program that uses it. We also keep naming standards for all of our MyBlocks.
- This year, we use five main MyBlocks to move our robot around the mat.
- MyMoveInInches: MyMoveInInches is our main piece of utility code. It is a MyBlock that allows us to move our robot backwards and forwards in inches rather than the software presets (rotations of the wheel/ degrees of rotation on the wheel). Within the MyBlock itself, we convert the number of degrees of wheel rotation it takes for our robot to move an inch into a variable using a math block. This allows us to break out a measuring tape, find out how many inches we want to go, pass that parameter into our MyBlock, and quickly and accurately program missions.
- MyGyroTurn: This year, being that we switched to EV3, we had the opportunity to use the gyro sensor. This sensor allows us to make our turns more accurate. At the beginning, we reset the gyro sensor to "calibrate" it, so the sensor doesn't add on to the last count. In our MyGyroTurn MyBlock, we tell our robot the power for each of our drive wheels, and, using our gyro sensor, how far we want our robot to turn. This MyBlock allows us make right and left turns consistently.
- MyLineFollower: On the mat, there are a number of red, green, and black lines. Some of our programs use these lines in order to guarantee our robot's position on the mat while we are running missions. Our main MyBlock to serve this purpose is MyLineFollower. This MyBlock, utilizes our two, front-mounted color sensors to track lines on the mat. The code itself is made up of one main switch, and two nested switches.
- MyAArm: The MyAArm MyBlock is responsible for the movement of our attachment motor wired to port A on our robot. This motor is located on the front of our robot. The MyBlock allows us to tell the motor direction, power, and duration.
- MyDArm: The MyDArm MyBlock is responsible for the movement of our attachment motor wired to port D on our robot. This motor is located on the backside of our robot. The MyBlock allows us to tell the motor direction, power, and duration.
Use a Master Program
For EV3, when you download to the robot, it downloads the whole project in no particular order. It's very time consuming to click through to all the programs find the particular program you want. Therefore, we created a master program which has the missions we want to run in order we want to run them. In our master program, we give a number to all of our programs and have a counter that's an endless loop, so if we have five missions, the counter won't go out of range to six, but instead back to mission one. All we need to do is click on the right and left arrows keys to go back and forth between the desired missions, meaning that we can skip over missions and go back quickly, when we are running during the competition. It saves a lot of time and makes thing more organized.
Use Utility Code
Some crucial utility code that we use, but not to directly get points on the mat include Check Counter Range and Mission Number to Program Name, which are both a huge part of the master program (see above).
- Mission Number to Program Name: Every mission has a number that corresponds with it in the master program and that number is converted into its program/mission name (ex. door). This makes it easier to tell which program it is, rather than having to memorize the programs and its number.
- Check Counter Range: This makes sure that the counter runs a never ending loop of the missions (from mission five straight back to mission zero). That way, it's really easy to skip missions and come back, thus saving time.
Use Error Correction
To ensure our position around the field, we use error correction, which corrects the robot if it goes too far or misses a line. It uses the motor sensor to calculate how far the robot has gone. In our programs, when the robot is expecting to find a particular colored line on the field, we know approximately the distance the robot should have to go to find that line. If the robot goes too far (the rotation sensor reading is greater than the expected distance), then it backs up, turns slightly, and goes forward again to find the colored line. It's nice to have this as a back up in case our robot doesn't make it to a crucial spot in our mission. It ensures that the mission run more effectively and accurately.
Use Data Wires and Variables
For building majority of our Myblocks, we use variables and data wires. Data wires are embedded in the myblock and connects the variable block to the function which we want to be a variable in our Myblock. Variable blocks allow us to plug in different amounts as we reuse the same basic functions. For example, for MyMoveInInches (see above), we connected a data wire from a variable block to the power slot of a motor steering block, which as a myblock, enables us to plug in a different percentage of power each time.
Documentation and Organization
To keep track of so many programs and myblocks, we have created new folders, commented all our programs, kept track with change logs in each program, a programming notebook, and created a master program.
- Every time we finalize our programs for a tournament, we create a new folder that only has the missions we're going to run during competition, and every time that we advance to a new tournament, we start anew with a new folder and only transfer programs and myblocks that we want to continue using.
- In all of our programs, we use comments to explain the what the block(s) does, as well as documentation for why we choose to program it a certain way (i.e. having the robot move for time instead of distance).
- When the programs are close to being finalized or when we advance to the next tournament, we insert a change log to keep track of changes that we make and why, so other team members don't accidentally change it back. Also, it shows our improvement and what we've learned.
- We have a programming notebook with tabs organizing all of our pseudo codes, notes (ex. improvements and errors in trial runs), and printed programs. It's nice to have a hard copy in case technology fails us and easier to look
- Lastly, to keep our missions organized,we have a mater program (see above). It keep the programs for missions in a short and chronological order that makes it easy to comprehend and work with.
Pseudo Coding
Before we program missions, we pseudo code it! Pseudo coding is the process of writing/documenting every movement of the robot during the mission, so it's clear and carefully planned out. This process catches a lot of errors that would come up in programming without any pre-planning, and saves the time that would take to fix those mistakes. It's easy to comprehend and may seem time consuming, but pays off in the long run.