Skip to main content

Some thoughts on FLL competition...

Today I had the chance to be a referee for the Forsythe Alliance competition (Forsythe County school district) held in Cumming, GA. 40 teams showed up and each team competed in 6 runs with their scores being added together for a grand total. Competition started at roughtly 9am and ended around 4pm with a 1 hour lunch in between and small breaks. All in all, it was a blast and I got to meet a lot of great kids, supportive parents, and very committed coaches and teachers. This county has really gotten behind their kids... check out more here.

Anyway, here are my overall observations and opinions, none of which are based on scientific fact or any advanced statistical calculations - mainly just guessing and memory:

1. Mission most often attempted - Satellite

The surprising part about this mission wasn't that so many teams tried for it - it was the number of teams that tried and failed! Most teams lined it up using SET (standard eyeball trajectory) and I would estimate that 1 in 3 failed. Very surprising, isn't it? It takes 10-20 seconds of your time, so you should make sure you nail it every time.

2. Mission least often attempted - Car/Truck switch

Again, not surprising considering the work needed to get the points (two conditions must be met), but what was surprising was that the teams who did attempt it (maybe 1 out of every 10) got it to work.

3. Sensors hardly used at all

I saw a total of 30 teams come through my table, but none (ZERO) used sensors for any portion of the competion. Repeat - ZERO. With all the colors on the table, black lines, and angled lines, I thought for certain that at least 1 or 2 teams would use a Light sensor to help in some navigation... maybe the Ultrasonic to detect some of the Uranium or Corn items, but not a single one. Pre-programmed movement was the name of the game.

4. No jigs/templates

Once again, I saw no teams using any kind of template or jig device to line up their robots. A few teams did use the small colored lines that go around the inner edge of the base, but not in a way that I would consider as extremely accurate. For example, one team would line the wheels of its robot up with the left-most colored lines, but they didn't line the front of the robot up with any particular line - the result was that the movement they programmed kept missing the target (Corn) because the robot wasn't placed at the proper North-South starting position (N-S-E-W is written on the table, FYI). They had to run the same program 3 times and used trial and error to get the proper starting position. This should have been determined during testing.

5. Direction sheets

I saw 4 or 5 teams with a small "instruction manual" that they had written that had things on it such as the program name to select for a certain mission, the order they wished to run the missions, etc - one even had a "failover" selection in case one mission failed, they knew which missions NOT to run that might interfere with later missions. Very well thought out. I hadn't seen this before and was surprised. In the heat of the game, these teams were very methodical and didn't panic.

6. Wheel issues

Two teams consistently ran a mission that should have worked (oil rig) but a tire had not been checked before the competition and was either off the rim or not in alignment with the other wheel, causing the robot to rotate. Both times the teams grabbed their bot (penalty oil barrel) and ran it again, same result... grabbed the bot (another penalty) and went on to another mission. Check your tires! This is such an easy fix but can cause HUGE problems.

7. Hastiness

So many teams were stressed and reacting quickly to their robot. This caused many teams to reach and grab their robot (penalty) before it entered the base. One team grabbed the robot as it just entered the base and managed to rip off a large portion of a motor and attachment assembly - they wasted 30-40 seconds fixing it and missed out on 2 missions at least. Slow down - deep breaths... yes, time is ticking away, but hastiness caused too many mistakes for me to remember.

8. Program selection

I can't tell you how many teams wasted precious seconds trying to find the proper program for a mission or combination of missions. Cycling through the program files does take time. The best team I saw that managed this properly by having one teammate finding the program while the other handled adding/removing components. Good teamwork.

9. No RCX

30 teams - all using NXT. I didn't see a single RCX. Of the 10 teams I didn't see, there might have been... not sure.

10. False starts

A few teams were penalized because they pushed the start button before the competition countdown completed. We were very strict with this because so many teams were racing for the satellite and it had to be fair. Don't push your start button until the countdown hits zero.

Popular posts from this blog

Celebrating 25 Years of MINDSTORMS

In celebration of the 25th Anniversary of MINDSTORMS, we take a trip through history. Please also visit ROBOTMAK3RS Community every week as we highlight different projects all through 2023 in celebration of the anniversary. Some of the early history is based on the content shared by  Coder Shah  in our  MINDSTORMS EV3 Community Group . Some of the text and links may have been edited from his original posts for consistency and clarity.  1984 - Kjeld Kirk Kristiansen watched a TV program called "Talking Turtle," where MIT professor Seymour Papert demonstrated how children could control robot "turtles" using LOGO, a programming language he developed. 1988 - The collaboration between MIT and LEGO resulted in LEGO TC Logo in 1988, which allowed students to control LEGO models using computer commands. The video shows Papert demonstrating TC Logo. 1990 - LEGO TC Logo was hampered since the robots you built had to be tethered to a personal computer. LEGO and MIT...

Celebrating MINDSTORMS with a Remix - Part 3

The ROBOTMAK3RS continued their celebration of the 25th Anniversary of MINDSTORMS through these Fall and Winter remix projects. Each ROBOTMAK3R was tasked with selecting one LEGO set of their choice and combining it with a MINDSTORMS set. Below are the five amazing models they came up with. Braill3 by Jerry Nicholls Braill3 is an EV3-based LEGO Braille bricks reader. This robot uses its fingertip, made from three touch switches, to read messages written using the LEGO Braille bricks and will speak out what it detected. If it sees a simple maths problem it will attempt to solve it and give the answer as well. To learn more about the process of creating this machine, read Jerry's blog . Braill3 can be viewed here . Set Review: The Braille Bricks set is well thought out. The ratios of the letters is suitable for general use and the addition of some punctuation and arithmetic operators is excellent. There is a card showing what bricks there are and their quantities, but no form of sort...

ROBOTMAK3RS Review: LEGO River Steamboat

I thought the LEGO River Steamboat would be an interesting set for a ROBOTMAK3R review for a few reasons. First, the LEGO designer of the model is Marina Stampoli, a long-time collaborator of the late ROBOTMAK3R Vassilis Chryssanthakopoulo s. From earlier collaborations with Vassilis, I  knew Marina was incredibly talented, with an eye for aesthetics and functionality. Her background in architecture is particularly useful for her relatively new position at LEGO. Her other sets include the Magic of Disney (21352), Message Board (41839), and Red London Telephone Box (21347). Second, watching Marina's reveal video  and reading her designer interview made this set even more tempting to build. The gearing mechanisms running through the model gave way to many opportunities for automation using LEGO robotics elements. Since ROBOTMAK3RS is all about adding interactivity and automation to LEGO brick, I thought it would be fun to see where and how LEGO robotics could be added to this s...