It was no surpise, multiple people wanted to be starters. Since this my teams 4th year, the girls first selected team members who wanted to start but have never started. This filled two positions. They drew straws to to determine the other two out of the 4 girls who wanted to be starters.
A Master Program allows you to combine all your missions in one program. It is a big time saver and reduces stress. The starting team just presses one button to move to the next program versus hunting and pecking through the menu structure. A good master program allows you to navigate backwards and forward over runs.
Building a simple Master Program
A simple master program uses the wait block and my blocks. For information on My Blocks, see the EV3 help. Word of warning, kids love picking icons for their My Blocks. They will spend hours if allowed. It works by waiting for the middle button to be released before running the next program. If you have a young or inexperienced team, I would recommend this master program. It is simple to understand and program.
Building a Robot Nerd Master Program that displays the program and allows you move forward and back.
I know, what the hell is this. It looks complicated. If you team understands loops and switches, then it is actually simple. The big concept is the variable block, which stores a value in memory. To teach the concept of memory and variable block, assign one team member to be the memory block. You ask and give her a new number. This worked for teaching this concept to my team.
The Robot Nerd Master Program displays the active program and allows you move forward and back over the programs.
- Create my blocks for each program you want to include in your master. See the EV3 help for instructions on creating a my block.
- Create new program.
Add a Variable Block as the first block. Set it to number and write. Name it count and set the value to 1. The variable tracks the active program to run in memory. You add or subtract 1 to move between programs.
Displaying the Active Program
So the starting team can see the program that they are going to run, we want to display the active program. We read the count value and pass it to a switch. The switch reads the numbers and runs the block in the corresponding case statement.
- Add a variable block and set it read.
- Add a Switch that takes a number input.
- Connect the Count variable and switch block, the yellow wire.
- Add a case (the plus button) for each program you want to run. In this example 4.
- Number the switches, 1-4 in this example. Set the first one to the default.
- Add a display block to each switch. I recommend adding numbers to the label.
If you were to run this now, it would display “1. Door”. We set the variable to 1.
123 Lego – Running the first mission
The next step is triggering a program to run and then increment the Count variable by 1.
Running the Program
To achieve this, we add a switch block triggered by the brick button (Brick Button – Compare – Brick Buttons). We set the switch brick button properties to the middle button and state to 2, indicating the middle button was pressed and released.
Like the display logic, read the Count variable and pass it into a switch. Instead of the display, the associated My Blocks (the program) is in the case statement.
Automatically Moving Forward to the next program
Next we want to increment the count variable by 1 so will move to the next program. There is a catch, we do not want to increment the count variable if it is set to the last program. In this case, we don’t want to go from 4 to 5. This requires some comparison logic.
- Read the Count Variable
- Compare the Count Variable to the number of your last run. If the count variable does not equal the max value, 4 in this example. The Compare block will pass a true or false.
- Pass the compare results (true or false) to the switch. If the is true (Count does not equal 4), run the true case.
- In the true case, read the Count variable.
- Increment the Count Variable by 1
- Write the new Count Variable.
Moving Back a Program
Things happen and sometimes you want to go back a program. You could exit out of the master, restart it or hunt and peck to find your program. Here’s an idea, let’s add some logic that allows you to go back. To do this, all you need to do is subtract 1 from the Count Variable when it is not equal 1.
In the code below, you press the left button. If the Count Variable is not 1, is subtracts 1 and updates the Count Variable.
Moving Forward a Program
You are at a tournament and realize your runs are over 2.5 minutes and need to skip over a program. Just like moving back, all we need to do is increment the Count variable by 1. This logic already exist, we just need to trigger it with the right button. You could make this logic a My Block.
Coast your motors
In a master program, if a run program ends when the motors ending with a stop, the motors lock. You cannot roll the robot or adjust a motorized arm. For example, the starting team can not roll the robot into position or position the arm. This is simple to resolve, just set the last move or motor blocks to coast in your run My Blocks. This unlocks the motors.
Beware of Master Program Ghost
I cannot explain why this happens but it is like the motor rotation sensors drift. The issue is similar to the gyro drifting (which is more of a demon than a ghost). We did figure out that adding a Motor Rotation Sensor and setting it to reset for each motor is our ghost buster.
Lego Pneumatics are a little hidden secrete for FLL teams. Lego Pneumatics uses air to power an actuator. They can be great for powering an attachment or distributing power.
For Food Factor, the Code Crackers used pneumatics to turn the thermometer. Bumping into the wall to triggered the switch, raising an arm up to move the thermometer.
For Senior Solutions, the Capital Girls Too team used pneumatics to distribute power and had the motor trigger the switch. It was used to release the ball and pick up the green medicine.
What is great about pneumatics, kids love them and will try to use them. All you have to do is make them available and use the Edge method to educate them. Everyone loves pumping the pump and seeing how much pressure they can get in the tank. For Nature’s Fury, the Capital Girls actually set a requirement they would use pneumatics. The girls team came up with really cool self-contained pneumatics powered attachment for getting the buildings that is triggered by an arm. The Code Crackers team are using pneumatics as part of their Nature’s Fury research presentation.
Lego Pneumatics are available from Lego Education and can be found on eBay.
For our run strategy meeting, we used the elements pictures from www.techbrick.com glued to index cards. Each team member has a scoring sheet from techbrick and the field mat has Avery round label stickers 5472 with the mission points next to each mission model.
We appointed a team member to facilitate the strategy session, treating it like a core values challenge. The team uses the cards to layout mission runs, taking into account attachments, location and difficulty. After about an hour, the team had a run strategy. If everyone starts talking over each other or if a couple team members are dominating the session, we use a talking ball. You have to have the ball to talk. This allows the shy team members to have a voice. The next step is for each team member to rank their run preferences. Meeting availability and run preference are used to form sub-teams. Below are the two teams run strategies. What always surprises me is how they sometimes go down the same path but with a different thought process. In looking at their strategy, they stayed the same for runs 1 and 2, deviated for a couple runs and then both elected to get the supplies when going for the red. The debate is also interesting.
Sub-teams require more meetings for the coaches but work great for our teams. We find that sub teams make the team more productive. With only three team members present, they are able to focus better, ask hard questions, and challenge themselves to tackle more advanced programming techniques. Having all 7 or 10 people working on a robot or program at one time is just not productive.
Our meeting strategy is to meet as an entire team once a week to work on project, core values and common tasks. The sub teams meet once a week to work on their specific runs. There are team rules about robot changes that could impact other sub teams.
The Nature’s Fury Challenge is out. I am a believer in using tactile approaches with kids; it just works. After watching the challenge video and going over each challenge at the board, each team member is given 10 sheets of paper. Each team member gets their own color. As the image above shows, the Capital Girls team members ranked their individual mission preferences and placed a piece of colored paper next to the mission. Who knew the color of the paper each person got would turn into a core values challenge? The paper has their name, mission rank and mission name. This allows them to see who wants to work on what. Using these preferences and meeting availability schedule, collected via Doodle, we can start looking at sub teams.
Typically we would divide the board into zones and have sub teams work on zones. Given this year’s challenge, we are modifying this approach. We will use element images courteous of TechBrick to makeindex cards. The team will determine the types of attachments needed for each element and note the attachment options on the index card. The index element cards will then be used to outline runs and element order. A very tactile approach. Using the runs and schedule availability, I hope to have our sub teams defined.
The Code Crackers, as part of their strategy kick off, went on a catapult tangent. They have the idea of catapulting all the emergency equipment, people and pets into the red zone. I’m hoping they get catapults out of their system soon. Again, the difference between boys and girls.
After getting familiar with the challenge, the Code Crackers did deviate from their original robot plan to address the debris mission. They now have a four wheel robot instead of a three.