Monthly Archives: October 2013


They dropped the robot!

On Friday afternoon, I walk in from work to see four Code Crackers team members around the table and the robot in pieces.  This was not a peaceful experience for me.

Our teams have a concept called Open Table.  It is times with team members can get together to catch up or get ahead outside of planned meetings.  These meetings are youth led and managed, I don’t even attend but will check in if I am around.

After getting through the shock of the robot in pieces, I asked what is going on.  Turns out one of the youth was pulling the robot out of it storage case and dropped it.  He was unaware it was connected to the charging cable and it slipped out of his hand.  After the dropped, the robot was fine but one of the motors was not working.  I don’t have the full picture of how this happened but it did.

The next logical step for the team was to replace the motor, hence the robot being in pieces on the table.  I was frustrated at first.  How this happened made no sense to me.  I got even more frustrated when I used another robot to test the motor to find it worked just fine.  The boys where also frustrated.  I started asking questions, did you test the connections?  Did you try a new cable?  Why didn’t you call me?  Seeing they were feeding off my emotions, I realized I needed to take a deep breath and calm down.

After calming down, I realized they did the right thing,s which made me proud.   I don’t think they tested the connections and suspect it was a loose or bad cable.  When it was dropped, everyone was called in the room.  Two were working on research.  They did some trouble shooting and came to conclusion it was a bad motor.  Before replacing the motor, they took lots of pictures so they could rebuild the robot after they took it apart.  The robot works and they finished up their program.  

I taught them the Capital Girl’s Kiddycat rule, when you handle the robot, hold it like a cat. One hand under the robot and another holding the robot.  I also apologized for my emotions.  I did not loose my cool but you could tell I was frustrated with them.  I told the youth that dropped the robot that from now on, he is the person who should handle the robot.  He knows what can happened and will take the precautions so it does not happen again.

We did not take a picture of the robot in pieces.  After the experience, I wished we had.  The featured image is from Sunday.  I was burned out from a Girl Scout camp out and had the boys work on their own.  When I came downstairs to check on them, I discovered my son had taped a blanket to the wall to block the sun.  It was interfering with their sensors.  When the tape did not work, he used my wood claps.  I admire their innovation and luckily for my son, the tape did not mess up the walls.

I felt guilty about my first reaction.  I do think it was an accident but at first I thought they were playing around and dropped it.   I know how much time they have spent and what this season means to them.  This is their last FLL year, they really want to do well and are putting in the time and energy to be very competitive.  To have it collapse two weeks before tournament would be a terrible thing.  In the end, I think it was a great experience for them and for me.  Yes, they missed the fact it was most likely as simple as a connection or cable but they did the right things.  They documented the robot and worked together to figure out. They showed their independence, team work and core values, which is what it is all about.






Yes, you have been corresponding with an 8th grader

Last week, the Code Crackers met with flood experts at the USGS.  This meeting was originally scheduled for Friday, October 4th but then the government shutdown happened.

What was great about this meeting is all I did was get a contact.  One of the mature team members actually did all the emails and copied me.  When we met the expert in the USGS lobby, she thought I was the person she had been corresponding with me.  I indicated that person she had been communicating with was this 8th grader.  Priceless.

This meeting enforced something for me, have your team solution before you meet with experts.  Sharing the team solution with experts is a great experience for the kids and is a practice judging session.  They get questions about cost, technology, who pays, etc.  It is great.  Ideally, you can meet to gather information and then meet again to share the solution.

Both the Capital Girls and Code Crackers shared their solution with experts this year and the information and experienced gained was very beneficial.  The Code Crackers learned they had a great innovation, their flood car barrier is self-rising, it does not rely on electricity. Electricity outages are very common in floods.  The Capital Girls gain great insight on existing solutions and implementation factors, like how much a search robot should cost and deployment size considerations.  This type of meeting also highlights what needs more consideration.  For example, when the Code Crackers where asked how much the flood barrier would cost, the team realized they had something to think about.  It is also created a coaching moment.  One team member said $7,000.  After the expert meeting with the team, I asked how did you come up with that cost number?  It gave me the opportunity to teach the lesson that you don’t have to have all the answers.  Instead of making something up, be honest.  Tell the person asking the question that you have not considered the cost.  Honesty always pays off.  


The Candy Drawer

On the VA/DC list serve, the topic of team motivation and how to get youth to try new things came up.  To keep the team motivated and focused, I hate to admit it but I use candy.   In our robotics practice area, I have a candy drawer.  It has dividers and has multiple types of candy.  When I see the team needs some motivation or focus, I just indicate that once they finish what they are working on, they can have candy.  Candy has amazing powers. 

badge_linedetectormasterTo develop FIRST skills, I use a Robotics Badge reward system.  To learn about the badge system, check out the blog post Boy Scout and Girl Scout Methods.


Master Program

This past week, both my teams focused on master programs, a program that let’s you sequence your runs by pressing a button.  It is a great time saver but does require some advanced programming understanding.  There are several version of a master program, simple (only moves forward) to complex (navigate forward and backwards across programs). Only try this if you team is ready for it, my teams are experienced but it still takes hours.

Following the EDGE (Educate, Demonstrate, Guide, Enable) Method from Boy Scouts, we begin the master program development in the summer with a excise called Master DJ. The teams are challenged to write a program that will play different sounds after a button is pressed or sensor is triggered.  Once this is mastered, the activity calls for them to be able to navigate the sounds backwards and forwards.  The last activity is for them to display what is going to be played if they press a button or trigger a sensor.  The Master DJ is very fun for youth and helps them develop advanced logic skills.  What I find interesting is how many different ways a master program can be written.  Each team has a different approach.  I will warn you, limited the playlist/sounds.  The youth will spend more time deciding on what sound to play than finishing the program.  

Once the team knows how to write a sequencer program (Master DJ), I have them read the Master Program Chapter in Winning Winning Design!: LEGO MINDSTORMS NXT Design Patterns for Fun and Competition by Trobaugh, James JeffreyDesigns.

Now that they understand the logic and the goal of a master program, we have a requirements discussion.  They will typically start with simple and evolve to complex.

The simple master, feature image, typically uses a wait block that waits for a button to be pressed before moving on to the next block.  A youth who understands the wait block or loop can typically finish this in about 20 minutes.

VaribleThe complex version, one that allows navigation backwards and forwards relies on a combination of variable, loop, math and a switch blocks.  The switch will read the number variable and run the corresponding My Block.  The variable blocks stores a variable, like a number, in memory.  The variable block allows you to write and read the number.  This is a concept that takes youth sometime to understand.  To teach this concept, I assign one of the team members to be the variable and other team members to be the buttons and switch block. By acting as the program, they are able to grasp the variable concept.   If they can understand a concept, they can figure out how to implement it.   Sometimes stepping away from the computer and making it real is the best approach for teaching advanced programming.

Tip, don’t wait for all the programs to be done before having your team develop a master program.  Use sound files to start.  Once the programs are done, then they can switch out the sounds with My Blocks.  Also, a master program can be done independent of the robot but you will need the robot to test it.


Technical Judging Prep

For technical judging, my teams will carry in two documents this year, robot design and program summary presentations.  The key word here is summary, we used to carry in every program and more information about the robot and process than anyone could care about in 5 minutes.  For some great examples of these summaries and what we are using to guide our technical prep, visit  To download our technical robot design presentation template, click here.  My teams have to populate the content, the template only helps guide them to telling a story.

My teams have not found a formula that works for them in technical, so we are no experts but we are learning.  In the past, they talked over each other and just were not great at explaining their work.  We tried a room captain that controlled who talked and a presentation script.  The challenge with these approaches is when the team was taken off course, they froze up and did not know how to react.

Based on our experience, have the team practice talking about their program and robot.  When you think about it, teams start building and programming around August.  They will most likely not remember the details after three months.  After observing this last year, we gave each team member a team notebook with a robot design and programming section (available for download under resources).   Every week, we try to put the programs on the big screen and make them present them.  Everyone takes turns.  You can’t expect them to remember what a block they wrote weeks ago  when you can’t remember what you had for lunch yesterday.  Practice explaining and fielding questions.

Have a starting team assigned to technical.  Last year, we had decided to show the green medicine run and the girl who would run the mission was not on a starting team but knew this run.  When the judge asked to see more runs, the team froze.  We focused so much on not talking over each other and the script that the team was not fluid.

This year we are focusing on summaries and cross-training, only highlighting the key aspects of the robot and programs.    They have done some really cool stuff, so that is where we are going to focus and there will be no scripted presentation.  We are also doing cross-training to avoid the technical blood bath we experienced last year.  If the person who did the work gets pulled in two directions, they will be prepared.  Every program and build task has been completed by a minimum of two and they both have to know how to explain it.  

For new coaches, think of technical as a guided conversation about the robot and programming.  Use the presentation slides/summaries to guide the conversation.  Also, when you practice, draw an imaginary line that the team will stand behind around the table. No one except the team running the missions should be able to reach the table.  The goal of this is take away the temptation of playing with mission pieces, which is a major distraction. Also, volunteer at a tournament.  It is one of the best ways to learn.

I am going to apologize for the following rant but I think this is important.  Technical Judges, please don’t split teams. I hate being the first team in a room, especially with experienced judges.  When you are first in the room, the judges who just met that morning are still figuring out their judging roles. When two judges start asking different questions at the same time or talking over each other, it really is not fair to teams who have worked months preparing.  I appreciate all the FLL volunteers, all I am asking is for judges to know your role before the first session.  Sometimes you have to comprise, stepping back and letting another judge take the lead.    



Introducing Fidget Sticks

Every team has one or more, a fidget kid.  It is the the team member who is always playing with the mission pieces, hair or just can’t keep still.  It becomes more apparent in the judging room where it is a big distraction.  I once had a youth start playing with mission pieces during technical judging.

You have two options, fight or embrace the fidget.  I tried fighting, it is useless.  To embrace the fidget, put something in the youth hands.  We call this a fidget stick.  For fidget sticks, I like to use Lego shocks.  They are entertaining and small enough they don’t cause a distraction.  Fidget sticks are a great tool to use.  I ordered 10 this morning from ebay.


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”.

Team Roles & Status


Last week, the Capital Girls worked out team roles and filled in the team roles worksheet (download here).  We actually do this as a core values activity.  There are many roles and some are more popular than others. Last year, no one wanted to be a starter but this year six girls wanted to be starters.  I loved their solution, instead of two starting teams they decided to do three teams.  This means more starting practices but I thought this was a great solution so everyone who wanted to be starter has a starting opportunity.

We are still continuing with robot sub team meetings and I do have one Capital Girls sub-team who is done programming.  As sub-teams finish their runs, the sub team meetings shift to documenting and tweaking runs.  Team meetings are now focused on practicing the research project presentation, technical judging and core values.

The code crackers had a victory this week, they came up with a solution for the truck and ambulance.  They started with a big plow but the friction from the truck and ambulance wheels made any program inconsistent.  I was very proud of the team.  After last Sunday, the sub-team sent a team email saying they were stuck and needed the help of the entire team. It took some guts for 8th graders to say we are stuck.  After some experimentation, one team member came up with a solution that traps the truck and turns it up so not all wheels are touching.  It was a simple yet effective solution.


Team 3455 Foothill Lego Lovers Core Values Poster

Core Values Poster

badge_CoreValuesFor Core Values, consider having your team make a Core Values Poster.  This can be a fun and rewarding activity.   It is a not a requirement but helps the team articulate to the judges how they embraced core values for the season.  For the core values session, take the post in for display.  Most likely the judges will look at it during the challenge or after the challenge.   Use the poster to show how the team exhibited core values.  It is a also a great memory aid for the team.

To create a Core Values poster, download the Core Values Poster Guide.   Have the team populate the bullets points under each section.  Using a guide, poster board or tri-fold and pictures, create a Core Values Poster.  Label each section, list the bullet points and use pictures that pertain to the bullets.   Let the kids get creative.   If you are in Girl Scouts, think of a Thinking Day Poster.  It should take the team between 1 and 2 hours.  You can break this up, one meeting to answer the questions and then another meeting to create the poster.  This allows time for pictures to be printed that illustrate the points the team wants to share.  You can also have an individual team member work on the poster.  It is also a great opportunity to get another team parent involved, ask them to facilitate the poster meeting.