Category Archives: Programming



Help your team get ready to program their NXT or EV3 robot by “programming” a fellow team member to complete an obstacle course.

Your choice of anything to create an obstacle course! Ideas include:
Hula hoops
Tennis balls
Wood planks

Prepare an indoor or outdoor obstacle course for the team, with a mix of barriers to navigate and tasks to do. Your course might require that someone step over a string staked a few inches from the ground, drop a ball in a cup, navigate across a wooden plank, pick up an object, step through a ladder laid flat, and toss a beanbag into a bucket. Do not let the team members see the course until they are ready to start the game.

Instructions to the team:
You will be “programming” a robot to navigate an obstacle course. Choose one team member to act as the robot. This person will be blindfolded, so the only way they can get through the course is by following your precise instructions. You will have 2 minutes to view the course and discuss your strategy. The “robot” will not be part of this discussion.

Make sure that an adult coach or mentor or older team member stays close to the “robot” at all times to keep them from harm. For example, if the robot is programmed to move forward, expect them to continue moving forward until programmed to stop – so you may need to step in to make sure they do not hit a wall or walk into a street.

This game helps teach the team the importance of clearly and exactly communicating what the robot must do. Make sure the team understands how this game relates to programming for the FLL robot game. Having the robot teammate blindfolded prevents them from offering help or using their own initiative to navigate obstacles – just like the Mindstorms robot will only do what it is programmed to do.


EV3 FLL Master Program

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.

Getting Started

  1. Create my blocks for each program you want to include in your master.  See the EV3 help for instructions on creating a my block.
  2. Create new program.

Variable Block

master1-countAdd 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.

Unlimited Loop

master2-loopAdd a loop and set the exit condition to “unlimited”.  The loop runs listening for actions inside.  The rest of the blocks will be inside the unlimited loop.

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.



  1. Add a variable block and set it read.
  2. Add a Switch that takes a number input.
  3. Connect the Count variable and switch block, the yellow wire.
  4. Add a case (the plus button) for each program you want to run. In this example 4.
  5. Number the switches, 1-4 in this example.  Set the first one to the default.
  6. 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.

  1. Read the Count Variable
  2. 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.
  3. Pass the compare results (true or false) to the switch.  If the is true (Count does not equal 4), run the true case.
  4. In the true case, read the Count variable.
  5. Increment the Count Variable by 1
  6. 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

shutterstock_203925415The program worked perfect when run as a standalone program but does strange things in the master.   I call this 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 EV3 Line Detection

One area to improve consistency for FLL is to use sensors.  I recently had a coach ask me about line detection and how to program it.  I know of three ways to program and teach line detection.

portviewFor the sample line detection programs, there is a color sensor in port 3 and the drive motors are in ports B and C.  Before starting to program, ensure the color sensor is positioned so it can detect color.  My team was having issues with detection this year and trouble shooting revealed the sensor was to low.   It should be about three pennies above the mat.  Use the port view to check if the sensor is detecting color.  (I will update the image with the color sensor).  Also watch your speed when detecting a line.  Start slow, fast speeds will sometimes miss.

Wait Block Line Detection Method


Steering block set to on.

The most basic line detection method is the wait block.  The wait block method has three blocks, a steering motor set to on, a wait block set to the color sensor and color compare, and a steering block set to off. Start with a slow speed and test your way up to a faster speed.


Wait block set to color sensor and compare color. The color is 5, red. Note the port number 3.

Steering block set to off, which makes it stop.

Steering block set to off, which makes it stop.

Loop Line Detection Method


The Loop Line Detection Method is very similar to a wait block and functions exactly the same.  The only difference is the loop replaces the wait block.  The loops exit’s condition is exactly the same as the wait block.


Recovery Line Detection Method



The Recovery Line Detection Method builds on the loop method but utilizes logic blocks and a rotation sensor.  It is designed to recover if the robot does not detect a line.  This method was developed by my Capital Girls Too team for the Senior Solutions green medicine bottle mission.  For the medicine bottle mission, the goal was to pick up the green medicine bottle and return it to base.  The catch was it could be in a different place.  My team soon realized if their robot did not line up correctly, it would not detect the green bottle and keep going.  Their solution was to measure rotations to make the robot return to base if the color was not detected.  It took a couple meetings and some understanding of the rotation sensor and logic block but they use it all the time now.  We even made a badge for it so they got rewarded when they used it.


Like the other line detection methods, the steering block is set to on.   The two sensor blocks, color and rotation, pass false to the logic block until their condition is true.  The logic block uses “or” logic, meaning it will pass true once the color is detected or the rotations are achieved.  Once a condition is met, the logic block pass true to the loop’s exit condition, which is logic, and the loop exits.  The last block is motor off.

It works with other sensors

The detection logic in the methods above will also work for the touch, gyro and ultrasonic sensors.   Once the team has an understanding of loop, switch and logic blocks, they can do amazing things.  Check out the program flow StartingPoints poster for teaching program logic.

Robot Nerds Needed

robotnerd1, a web application to simplify planning, organizing and sharing for robotics teams is looking for beta users.

To qualify for a free Robot Nerd T-shirt or sticker, participate in our private StartingPoints beta at  If prompted for a code, use ROBO.



Breaks are Nice

This week, we have only had one meeting, a Capital Girls starting team practice. It is nice to have a slow week but we will pick up on Sunday when both teams meet. I did have my daughter and son practice their projects lines and my daughter did some run logging and tweaking. The truck run has not been consistent but after logging over 20 runs and making adjustments, C made adjustments that got it consistent.




Don’t Touch the Table!

We have a rule, Don’t Touch the Table!  It applies when the robot is running so no one bumps the table and throws off a run.  I should follow this rule.  Last week, I noticed a flaw in our table design, some nails were starting to pop up.  Simple to fix, pull out all the nails and use some liquid nails.  Out table is a light weight table, thin backing board supported by some stiffeners.  Saturday morning, fixed the table.

Saturday afternoon at the Code Crackers practice I noticed the robot looked like it was a roller coaster, bobbing up and down hills as it moved.  That’s strange, why would it do that?

Then it gets more interesting, the robot would pivot in some areas and not others.  Must be something wrong with the robot.  Must be friction from the mat!  

Sunday at the Capital Girl’s practice, I noticed other strange things.  Sometimes the robot would make this strange sound, like the motors were dragging.  After this sound discovery it became apparent, the board had very small chasms between the stiffening boards.  Not enough to notice when looking at it but enough that the light sensors would drag and create all kinds of friction and inconsistencies.

Needless to say, I spent Columbus Day building a new table.  Good news is all the programs work and consistency is back.  So remember the rule, “Don’t Touch the Table”.


Sometimes you have to fail to succeed

Last night, I had a sub-team meeting with the Capital Girls working on the truck and ambulance mission.  This team made great strides, they had a great attachment and a working mission after their first meeting.  At the start of their second meeting, it would veer off into the buildings.  Turns out the friction from the truck and ambulance wheels play a big role in the success or failure of this mission.  Something that looks simple can be very hard.

This will happen during every teams season and is very frustrating.  Something will work, then it want.  Sometimes it is battery level but for the most part, there is no rhyme or reason. I tell my team we just increased the sample size and it is better to know now than later.  The more your teams test, the better they will understand the characteristics of a mission and can adjust.   The girls did not realize it was the truck and ambulance wheel friction that was causing the inconsistency until after 20 runs.  By then the meeting was over.  They have some stuff to figure out. 

You can count on luck, it has helped us, but having a large run sample size really matters for having a consistent robot and knowing what to expected at tournament.  Log each run, note if it was a happy or sad face.  I don’t like using the terms successes and failures, the terms are to black and white and just because a mission did not work perfect does not make it a failure.  If you learn something from an unsuccessful run, then you succeeded at learning something.  Download a copy of our Mission Log to use with your team.  It uses :) and :( faces to indicate how the team felt about the run.




How do you keep code safe?

Many teams have horror stories about a team member changing or saving over someone’s program.  To avoid this nightmare, teach your team to do code management and version control.  If you are a software developer, this should make complete sense.  Create a GitHub or CodePlex project and go.  Sounds simple but trust me, figuring out these solutions is not easy.

My teams took the easy path, we use DropBox.  You can get 2 GB for free!  What is great, you can share files and programs with the entire team.  No more thumb drives!

We use a naming convention for files and backup all program files after each meeting.  We can get back to any point in time and are protected against a computer crash.  Below is our process.

File Naming Convention:

When programming, the teams follows a naming convention for program names.

{RUN Name} – V {Version Number}

The version number is incremented when a team member starts a new program unit.  For example, using the Nature’s Fury Challenge, a unit might be triggering the airplane and the next unit could be picking up the water.   Some of the team members, not all, break up units using My Blocks.  My Blocks also follow the same naming scheme.  I love My Blocks, the only issue is the 15 minutes you lose waiting on a kid to pick an icon.


dropboxfoldersAfter each practice that involves programming, we do a backup.   In the team’s Dropbox program folder, we create a folder based on today’s date, e.g. 9-6 and copy the team’s program folder into the newly created folder.  This backup process enables the team to get back to any point in time.

badge_outsidetheboxTwo 8th grade boys came up with new base escape program.  It uses dual color sensors to know when the robot reaches the base black border line.  To avoid being tripped up by the black text in base, both color sensors have to detect black.  The “And” logic block triggers the loop exit when both sensors detect black,  I thought this was outside the box thinking.   To see how we enable youth to understand and apply program logic, see the Program Logic Poster.


Code Crackers Research Kickoff turned into a Sumo Challenge

The Code Crackers team hurt my feelings. I spent all this time creating this Nature’s Fury guide, and they just went in their own direction. In the end, their approach worked for them, and I got over it. They listed all the Nature’s Fury disasters they could think of, including going out-side the box with Solar Flares, Zombie Apocalypse and my favorite, Limnic Eruption. Using the process of elimination, they ended up on floods.

Once they were ready for a break, we decided to put their base robot to work.  I pulled out the Sumo Challenge Board and challenged them to find an object, push it out of the white ring without the robot going out of the ring.  Below is the video of a somewhat successful run.  The object was moved around and we had to keep legs out of the way.

Here is the program the team wrote. It did not work perfectly, but it gets the job done

Ultrasonic Following Program

Ultrasonic Following Program