Some thoughts on FLL bot design

Yesterday, I was able to closely observe 24 teams present their FLL robots to my team of 4 technical judges. During each team's presentation, we were asking questions about their building and programming solutions as well as questioning them on their logical/tactical reasoning and teamwork as it applies to coming up with a robot to compete. During all of my observations and questioning, I kept a list of those things that I thought would be of interest to readers and/or other FLL competitors. These are in no particular order:

1. A noticeable lack of using sensors - I would estimate that 75% of the robots I saw did NOT use sensors, other than the built-in rotation sensor on NXT bots and encoding/rotation sensors on RCX bots. The Light sensor was the most frequently used with the Touch sensor coming in 2nd... what I found interesting was that most of the bots programs were pretty much 90% or more MOVE blocks and all movement was based on table positioning and lining up the robots (either using jigs or aiming visually).

2. Aiming - as mentioned earlier, most robots (probably 80% or more) were aimed using a visual point-and-aim method. Interestingly, when asked about the lack of consistency in test runs and competition runs, most teams admitted that their aim was off and very few indicated that using a jig was an option (or other fixed/sturdy object useful for placing the bot in the exact same spot every time).

3. Confusion over turning rates - many of the teams indicated that they switched to "rotation" movements instead of degrees because they couldn't figure out why their robots would be programmed to turn 90 degrees but would typically only turn 40-50 degrees. This told me that there's still not a good understanding (either by students or teachers/coaches) of how a wheel-circumference turn and a motor rotation are not 1:1. Most teams that answered this question about their design seemed to think that programming one wheel to turn 90 degrees in a forward direction and another wheel to turn 90 degrees in a reverse direction would result in the robot spinning in place 90 degrees and were surprised when this wasn't the case- TEACHERS/COACHES PLEASE LISTEN: it is VERY important for students to learn to program using degrees. Using time isn't a good option because it is so easily affected by battery power and rotational movement programming is okay, but it's probably debatable if the accuracy is the same as with using degrees.

4. Teamwork - one of my questions that I liked to ask was this: "If I were to pick one of the team members at random and ask him/her to run the robot on every challenge, would that person be able to do so?" - I was basically trying to find out how many of the team members were cross-trained - many of the teams consisted of individuals who ONLY knew about the physical robot, some ONLY knew about the research portion, and others ONLY focused on the programming. While this is probably typical considering time constraints and interest amongst students, I cannot imagine that any team will benefit from not knowing a little of every aspect of the competition. It's just my opinion, but I think that any student participating in the FLL challenge should have an opportunity to contribute to robot design, robot programming, and the research portion. We all tend to focus on our strengths, but coaches and teachers need to encourage those students who might tend to "blend into the background" and get them more involved.

5. Programming - I would sometimes encounter a team where only 1 or 2 was handling the programming. They typically would do all the talking and were very good at describing their work. But when asked if they had cross-trained their team and demonstrated the program in its entirety so the entire team understood the programs, most of them were at a loss for words. I asked one team where the SOLE programmer had all the information what would have happened if that member were sick or stuck in traffic and couldn't make it? Keep in mind that we did NOT allow the coaches/teachers into the Technical presentation. Teachers/Coaches need to make certain that ALL the team members have at least a cursory knowledge of the programming environment - even better, having every team member trained on each program and able to EXPLAIN how each program works is even more impressive.

6. Tactical Planning - Only seen in a couple of teams, I was overly impressed by some teams that had done a sort of comparision on which challenges they wished to attempt compared to points awarded. Some teams were able to explain clearly their reasons for NOT attempting a challenge OR for leaving a challenge for last (typically, not enough points to go after since time was limited). Other teams were able to combine challenges in a way that I hadn't seen before - when asked, they also were able to explain WHY they chose the path/route they did - very impressive. Some teams were SO FOCUSED on doing all the challenges and then couldn't complete 25% of them successfully!!! One team in particular had worked on combing 3 of the hardest (IMO) challenges in one run and were able to nail it almost EVERY TIME!

I had a great time - met some GREAT teams and coaches and saw some extremely well-designed robots. I saw professionalism, sharing, courtesy, and respect exhibited. I hope all the teams had a great time. I'm hoping they're seeing how working on a team can be fun. I also hope they see that math and science can be interesting and challenging and rewarding.

Lastly, I need to say hello to some teams that I met and spoke with - Nifty Muffins of Doom, Girls in Black, RoboChiefs, and Radioactive SPAM - I hope all of you had a GREAT TIME!



Anonymous said…
Though I haven't actually read it yet, only scrolling past it to see if it was the most recent. I must comment though, you have very lengthy thoughts Jim:-)
Anonymous said…
Having now read through the post, I must say. It was worth the time:-)

I find that with our team, the most difficult part is with the cross training. We try hard to make sure that everybody knows about our robot (and out research) but there are always some people who work almost exclusively with either the research or the robot. I worked mostly with our research presentation, slides, and research paper (but I was certainly not the only one, thanks to KT)

Some steps our team took to make sure every one was able to answer the judges questions, and to avoid one person dominating the conversation, we made up tech and research binders. These contained all of our programs, our slides, skit, research homework, research paper, pictures of our robot, robot wiring diagram, tech and research highlights.....everything. We all had to read them and they were passed around before each judging session.

Also, we (try to) make sure that everyone can run all of the missions. We use tag-teaming to run our missions, so sometimes we only get to run one mission, but we are still (sort of) proficient with the other missions.

The lack of sensors on robots is one thing I also noticed. And it saddens me to think that thanks to the NXT, students can simply program their robots every move. I say simply not because it is easy, but because when compared to writing a line following algorithm, or using other sensors to navigate the table, it is the easy way out.

Maniac (whose thoughts are almost as long as Jim's)
Robolab29 said…
At the end, which three missions were the hardest that you were reffering to? We have something similar: Drop ATP, start Self-Assembly, manipulate Individual Atoms. All in one big sweep. The team even nicknamed it the 'Bermuda Triangle' because they thought it was the hardest but funnest to program. Through that, they learned to line-follow, slow-down for accuracy (this is a rookie team), and are able to nail it as well.

As to sensors, there are only 5 specific teams who do it annually. RCX teams use time. NXT teams use rotations. I'm glad m rookie team decided upon using them.

To aim, sadly 97% of the teams point-and-shoot, and this is a real-time calculation, and most of that actually do the whole mission, some doing half a mission.

At the beginning of each year, I teach the team about measuring distance and using wheel circumference to find rotations. This tends to impress judges.

Robolab 2.9
Limit Busters 585
Blue Knights 1178
Unknown said…

a very interesting blog entry indeed - though I tend to be shy of ones that extend over more than one single screen, I've read it twice.

Guess it reflects a typical penomenon of our time: as efficient division of labor ever might be in terms of manufacturing something, it nonetheless spawns a lack of insight into global interrelationship as well as missing commitment to the end result. Both things we could do very well in the generations that are poised to take responsibility in the years to come.

Anonymous said…
Are you gonna put up some pictures from the event? I'm curious to see what some of these bots look like.

I found your comment regardign the lack of team cross-training intresting. How big are the teams in the competition? I certinly agree that the lack of crosstraining is a problem, however it is a problem that is not unique to FLL. At my day-job we have different groups, the dynamics, electrical, sturctures and such. No-one in any one group has a clue what is going on with the others, and most of the engineers don't even really understand whats goign on with the end product.

Unfortunately, I do not have any pictures - we, the technical judges, were seeing 8 teams in a row, with a small break... then another 8 teams... then a quick lunch... then 8 more teams. As soon as one team went out the door, the next team came right in. It left no time for taking pictures.

As for teams - the largest team we interviewed was about 10 members and the smallest was 3. Most of the teams that I remember had 6-7 members which seemed to be a good number for sharing the load.

One of the FLL goals is team-building and you do see it working - some teams are more cohesive and others, not so much. The strongest teams I interviewed seemed to know who had the strongest building or programming skills but didn't ignore the other team members and made sure to include all members in the Q&A. One team in particular made it a point to have EVERY member answer at least one question - I was very impressed.

Anonymous said…
I don't know how the event is scored, but why not give bonus points for each sensor used?

So two if teams got the same score, the cunning device using sensors would trump the point and shooters.
David Levy said…
"Using time isn't a good option"
Over short distances where the destination may be a wall or a model, using time is actually a pretty simple technique. The problem with using rotation/degrees is that the vehicle tends to get caught up on a move block if the vehicle hits an obstacle before completing its planned rotations.
I'll try not to make this too long, but here's how technical judges scoring system went:

1. We had 8 categories to rate each team - a few of them included inventive usage of sensors, programming, and structural design.

2. Each of the 8 categories were rated as Exceptional, Good, Fair, or Needs Work

3. The scores were also weighted - each checkmark in the Exceptional column had a multiplier of 4 (x4), Good was x3, Fair x2, and Needs Work x1.

4. Minimum score was 8 and Maximum was 32. (8 checks in the Exceptional column = 8 x 4 = 32 and 8 checks in the Needs Work was 8 x 1 = 8)

5. Judges also checked Yes/No/Not Applicable in order to vote on "Team Spirit Award" and "TeamWork Award" (names might be different, memory's not so good)

6. We also had a comment area to provide comments and I used this to point out teams that were exceptional in an area that might not be judged (such as first-timers attempting 2 or 3 challenges ONLY but doing them right every time)

Of the teams I judged, I don't remember any team scoring less than 19 and the highest score I awarded was 29.


You are correct - what I was really referring to was the accurate explanation by most teams when asked why they didn't use time as a movement option - almost ALL of them were able to explain that they noticed when battery power got low, the robot didn't move as far as they planned (and, likewise, with high battery power, sometimes the robot had a little too much oomph!)

Anonymous said…
How did the kids do in terms of speaking? What about their research and the writing portion?

I've been shocked by the poor spelling over at Nxtlog and can only hope that the kids competing do better with their talking than they do with their writing.

Hi, Brenda.

Most of the competitors were very well spoken... there were the shy ones, of course, but none of the kids disappointed me in terms of the presentation abilities... keep in mind, at this age, they're doing great just to be able to stand up and give a presentation to complete strangers in a competitive environment!

As for NXTLOG, yes, I've noticed the spelling (I'm a moderator) and a lot of it comes from visitors from non-English speaking countries - so many of the kids adding comments and projects are doing fairly well considering they're not native-English speakers.

As for those who ARE native speakers, I'm hesitant to comment :) I do see a lot of "ur" for "your" and "Im" for "I'm" and similar simple words. I'm not wanting to preach to anyone (I have an English degree and make PLENTY of spelling and grammar errors) but yes, it does concern me at times. I'm not sure what the answer is, either. If we (the moderators) rejected every comment and submission that had multiple spelling errors, you'd be shocked by the amount of rejections. I take that back - no, you probably would not. Suffice to say, NXTLOG would be VERY slim in terms of submissions and comments. Again, I don't have an answer other than to encourage kids (and adults) to look up words they're not sure about and to pay more attention in English class ;) (easier said than done, I admit - someone HAS TO KNOW how to make English class more interesting).

Anonymous said…
I am a member of the women in black team you met on Sunday you were talking about, and this feed back was really good. We thank you for your time and we were wondering what were the three missions in a row you were referring to?

Hi, Emily! Sorry I got your team name wrong! Women in Black! How did your team do?

If I remember, the 3 that I'm referring to were stain proof fabric, nano motor challenge, and bucky ball. They might not be the most difficult, but it was the route the bot moved and the preciseness of the movements that impressed me.

You ladies impressed me - especially with your teamwork. Your bot was called "Moxie" (I think) and you scored high on the programming and structure sections if I remember. I hope you all had fun!

Anonymous said…
Hi Jim:

We met in the Judge's room (you signed my book - thanks). Great post! I'll have to save it for my team next year as we didn't make it to the State.

As for the sensor use, I'd like to disagree. One of our main goals during the season in our robot design was KISS. Since we were new to NXT, we wanted to get as much done without the use of sensors to start with, yet we were penalized for not using them in the qualifier (in our opinion). The FLL manual didn't call out sensor use, but the Georgia Judge Advisor did. We believed that if you can solve the missions and keep a simple design, it should have been good enough. Oh well. More lessons learned for next year.

To all: Being a judge was one of the most difficult jobs I've had (I was a floor judge at the event). Every team was excellent and deserved awards. The Shadow Tigers (Georgia's entry to the World Festival) will do a great job representing the state. And the Nifty Muffins of Doom blew everyone's socks off by scoring 371 on their final round.

Jim: Thanks for judging and for being very generous with your time and energy. I look forward to seeing you again in the near future.

Hi, Mannie... it was nice meeting you as well.

We were NOT awarding points just because a team chose to incorporate 1 or more sensors. What we were looking for was unique programming or lessons learned when using sensors. All teams seemed to use the rotational sensors - and if a team was able to explain why they chose not to use other types of sensors, that was taken into account on the Logic/Planning judging. KISS is a great philosophy to use when designing robots, but you also have to ask the question - if sensors are available, how can they make our job easier? There were plenty of areas on the mat where the Light sensor could have been used to make up for the eyeball-aiming not being so accurate... the Touch sensor, likewise, can make up for over-compensating on movements and allowing for a bot to reverse direction.

Ultimately, all teams learn more and more as they run their bots.

Anonymous said…
thank you very much for that feedback. We greatly appriciate it. To tell you how we did, we placed 2nd place in teamwork.

Rob Torok said…
If the problem is how to encourage sensor use, it seems to me that it would be much more effective to devise a competition that makes it advantageous to use sensors rather than rely on dead reckoning...

[bias alert]
Perhaps something like, say, RoboCup Junior Australia? (-:
[/bias alert]

Fay Rhodes said…
Where can we find information on turning rates, wheel circumference and motor rotation?
Anonymous said…
Hi Jim,

This is a member of the NIfty Muffins of Doom. I am just going to say I appreciated the tips you gave us when you talked to our team. We enjoyed the competition.

Anonymous said…
The FLL challenge this year did not really encourage the use of sensors. Though there were a lot of lines on the challenge mat most of them were not conveniently placed. My team was only able to come up with two good uses for the light sensor, and both could have been done just as well using odometry.

Aside from coaching I also judge at FLL events and saw many programs of the "string of move block" type. When I questioned the teams on how they could make their programs easier to write, more robust, more modular (take your pick) they seldom had an answer. When I spoke to the team's coaches the source of the problem became evident. Often the coaches weren't tecnhically savy and didn't utilize the resources available, or they were afraid that teaching robotics to their team was breaking some sort of FLL rule. I did my best to inform them that coaching is teaching, and that teaching is not doing.

My team of 10 year olds did much of their programming using a tape measure and a protractor. To convert travel distances into motor duration they learned about circumference, radius and diameter, negative numbers, fractions, compound numbers, functional decomposition, modular design, etc.... Every team meeting provided numerous educational opportunities.

I can hardly wait for next year.
Anonymous said…
Hey wait our team the Bananos from MN can all run the robot we are going to the world festival
shomPaul said…
I teach my students a little differently about using sensors [or gears, guidewheels, etc.]. Designing is all about what a team is trying to accomplish. For example, when the robot interacts with an object, there is always variation in the interaction. The wheels might shift, part of the frame might loosen. etc... Solving missions is all about minimizing this variation, for which sensors can certainly help at times. I teach them that sensors have their own variation. Different concepts of positional registration must be applied at different situations. That's why I disagree with using and not using all depends on the context.

Popular Posts