Mind Storm Robot Ideas

FLL Programming and Design Suggestions

As of September 2006, I am adding the newest entries to the top of this file. Michael Schuh


NXT Memory Issues and Help

Sender: mnfll-announce@yahoogroups.com
Date: Tue, 05 Sep 2006 23:58:10 +0000
Subject: [mnfll-announce] NXT Memory

Doug Frevert also addressed this issue last week on his NXT blog on the www.hightechkids.org website. See there also for more details.

-------

Dear FLL Operational Partners: This statement along with a excerpt from the User Guide will be posted on the FLL International Web site (http://www.firstlegoleague.org/default.aspx?pid=21330) by Wednesday morning EST, September 6. There will also be links from the FLL International Home page and the US and Canada landing pages. In addition, we will have a link to this statement and the User Guide pages as part of the Kickoff Documents for teams who may have missed the email blast.

We thank you for your support in getting this message out to teams as quickly as possible, and appreciate your patience as we prepared the release statement. If you have any questions regarding the distribution of the statement, please feel free to contact me directly.

Regards,
Fred

NXT Memory

Statement for FIRST LEGO League Teams

The FIRST LEGO League Challenge requires complex programming and teams should expect that it will take time to learn programming techniques for the MINDSTORMS NXT set.

The NXT memory brick is large enough for the FLL Challenge. It has 10 times as much memory as the RCX brick. The NXT brick has 256 Kbytes of memory, and approximately 125 Kbytes are used for firmware and thus not available for programming.

A number of programs and files have been preinstalled on the NXT brick, which take up about half of the available memory space.

Teams can maximize memory space by:

  • Downloading the newest firmware from inside the NXT software
  • Deleting unused programs
  • Deleting unused sound and graphic files
  • Deleting preinstalled files and programs
  • Create subroutines to reduce the number of programming blocks needed

Please read the MINDSTORMS Education NXT Users Guide (included on a separate CD with the LEGO MINDSTORMS Education NXT software) for a detailed description of how to manage NXT memory and firmware downloads. This information can also be found when activating the Help function from inside the NXT Software.

LEGO is producing documentation that describes how to create efficient NXT programming in order to assist teams. In addition, LEGO is developing a number of new, additional programming blocks that will be more memory efficient.

The expected release date for the documentation is mid to late September and the programming blocks should be available early to mid October. Additional improvements to the NXT platform are continuing and LEGO is planning to release an upgrade patch in 2007 that will further improve the compression of NXT programs.

Teams can access documentation and new programming blocks through the FLL International Web Site once they are ready and will receive an email blast once these links are active.

Answers to NXT memory questions can be found in the MINDSTORMS Education NXT User Guide and the HELP function. For LEGO MINDSTORMS Software (NXT, Robolab and RIS) support in North America only, contact LEGO Education Customer Service – 866-349-5346.


Loading NXT software on machines slower than 800 MHz

From Michael Schuh
September 4, 2006

Our team found that the LEGO NXT software "requires" an 800 MHz or faster Windows XP system for installation.  We have succeeded in installing an running it on a 600 MHz Pentium III laptop that is running Windows XP.  The trick is to use regedit to change the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\~MHz key to a value of 800 or greater and then install the software.  After it is installed, you can change the key back to whatever it was before you changed it.

More how-to notes: Caution, use regedit with care because it can be used to change many things in your OS and even make your OS stop working.  Nothing in the directions below should damage your machine.

  • Go to Start and then Run and type in regedit.
  • Navigate to the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\~MHz key
  • Write down what the value of the key is.  In our case it was 600.
  • Change it to 800 (you will probably want to select "Decimal" in the "Base" box) by double clicking on ~MHz or right clicking on it and selecting Modify.
  • Close out regedit by selecting the File/Exit menu option.
  • Install the LEGO NXT software.
  • Use the instructions above to change the registry key back to what it was before you changed it to 800.

We have used the 600 MHz laptop to create and load a program on the NXT and it worked fine and performed as well as the old software did for the RCX.

Thanks to 8th grader Jonathan Wilde and his dad for figuring this out and for Jonathan doing the installation on our laptop and showing that this works.

Michael
DogBots Coach and FLL Tournament Organizer


Books on Robot Building and Programing

Thu, 9 Oct 2003 13:30:35 -0700 (PDT)
From:  Polle Zellweger acm.org>
To:  NCaFLLnullyahoogroups.com

I have looked at all of the books that have been mentioned so far (see the messages below this one for these books, Schuh), and I own many of them.  By far my favorite is Dave Baum's Definitive Guide to Lego Mindstorms, Second Edition, which just came out at the end of last FLL season.  I HIGHLY recommend it.

It explains both building and programming issues very clearly, with many example robots and programs in RIS 2.0 code.  As a coach, it's a fairly quick read up through Chapter 8 (skipping the NQC parts, since we can't use that in FLL) to get an excellent overview of important basic knowledge.  Further chapters can be read as needed.

I started my team building and programming the Tankbot, which is much simpler than the Constructopedia Tankbot (even inexperienced kids can build it in less than 1/2 hour), then moving on to the Bumpbots and the simpler Linebot.  We spent about 3 meetings on these basics.  Other robots can be used as illustrations for more specialized issues later.

Good luck!

Polle Zellweger
UFRs 1780
Palo Alto

 Date: Thu, 9 Oct 2003 11:06:08 -0700 (PDT)
From: Ben Rivera yahoo.com>
    To: NCaFLLnullyahoogroups.com

Check out the usfirst site http://firstlegoleague.org/challenge/teamresources. It has great info for coaches and alot of links to some great sites that give you info on how to build robots. Good luck.

 Date: Thu, 9 Oct 2003 10:07:35 -0700
From: "Sanjay Gangal" ibsystems.com>
    To: yahoogroups.com>

Here are some books I found useful. I have made these books available to the kids in the class and they look at the pictures to see if they would like to try something for a specific challenge. They have been able to use the books and then improvise to do some of the challenges:

  1. Jin Sato's Lego Mindstorms : the master's technique / by Jin Sato; translated by Arnie Rusoff.
  2. Creative projects with LEGO mindstorms / Benjamin Erwin.
  3. Building robots with Lego Mindstorms : the ultimate tool for Mindstorms maniacs / Mario Ferrari, Giulio Ferrari ; Ralph Hempel technical editor.
The Mindstorms kit comes with a manual that shows how to build three types of robots (roverbot, inventorbot, and acrobot). These are again excellent starting robots for kids to get familiar with the pieces. This manual has some cool ideas on how to build attachments for light sensors, touch sensors, gears, etc.

With this year's kit I also got a new manual which had some more cool ideas.

Finally, you can go to the official mindstorms website and there are a lot of design submissions.

Sanjay Gangal

 Date: Thu, 9 Oct 2003 07:23:24 -0700 (GMT-07:00)
From: "cnsanfordnullyahoo.com" mindspring.com>
     To: NCaFLLnullyahoogroups.com

We started out our kids building projects from the book "Lego Mindstorms - Robotics Invention System 2 Projects".  The book is available online at www.syngress.com, where you can buy it and download the .pdf file.  You then can print chapters as projects for the kids to build.

It doesn't help much with programming however.

Good luck!

-Curt Sanford
Tweeters176
San Francisco

How to set the default value of the USB transmitter tower with RIS2.0

 

From Edmond Macaluso

Date: Sun, 11 Sep 2005

For the USB IR Transmitter, to change the DEFAULT power level setting (transmission range of short, medium, long) there is a separate software utility for with RIS2.0. Windows PC: Go to Start:Settings:Control Panel:LEGO USB Tower:

You should set the default setting to "short", because medium and long will often fail. Unfortunately, the default value when you install is "long" and therefore, if you don't change the default, it resets to "long" EVERY time you run the software.

The Mindstorms software might also report that batteries are low when communication fails, however, often the batteries are just fine and the message is due to a non-communication problem which is resolved by using "short" range transmission.

Ganging up Light and Touch Sensors on the Same Port

mnFLL

Date: Thu, 15 Nov 2001 11:15:37 -0600

   From: "Cochran, Ted (MN65)"

htc.honeywell.com>

Subject: RE: repeatability of missions with fresh or old batteries

BTW, touch sensors can be ganged up with light sensors on the same port.  Read the touch sensor with the light sensor control block; the light sensor typically reads between 30 and 70 when the touch sensor is off, but will read over 90 when the touch sensor is depressed.  Thus it is easy to use all five sensors on a robot--sensor ports are not a constraint.

Message: 13
   Date: Thu, 15 Nov 2001 11:43:13 -0600
   From: "Timothy E. Jump" bsm-online.org>
Subject: RE: repeatability of missions with fresh or old batteries

This is true on RoboLab, but RIS (at least version 2.0) restricts input ports and won't let you stack touch sensors and light sensors on the same port. At least, it wouldn't let me.

Message: 16
   Date: Thu, 15 Nov 2001 12:43:19 -0600
   From: "Cochran, Ted (MN65)" htc.honeywell.com>
Subject: RE: repeatability of missions with fresh or old batteries

The trick is that RIS won't know it's looking at a touch sensor--you read the input port value as a  light sensor value regardless of whether you really want to know about the light sensor or the touch sensor; it's just that the touch sensor looks like a light that's brighter than what the light sensor ever actually sees.

Message: 17
   Date: Thu, 15 Nov 2001 11:48:02 -0700
   From: "Savitt, Steven" atk.com>
Subject: RE: repeatability of missions with fresh or old batteries

My experience is as Ted reports.  From either Robolab and RIS you program the port as if only a light sensor is connected to it.  Then you connect a touch sensor to the same port.  When the touch sensor is in the out position (open circuit), the light sensor and its program will perform exactly as if the touch sensor was not connected.  Now, when the touch sensor is in the "in" position (closed circuit), it "shorts" out the light sensor and this is seen as an extreme value (>90) by the light sensor interface. So, when you get to the point in the mission that you want to see if the touch sensor is closed (or want to just wait for it to close), you simply see if you have light sensor reading > 90 (or just wait for a light sensor reading > 90).

 

Repeat Until does not work with RIS2.0

Message: 1

   Date: Wed, 14 Nov 2001 09:13:35 -0500

   From: "Quealy, Mike"

pios.com>

Subject: RE: A technical question

From our testing, Joel appears to be correct--the Repeat Until does not seem to work reliably for us, with RIS2.0 under Win2000.  Using the Repeat While has been working fine.  Don't know why.

-----Original Message-----
From: Joel Stone jrstonenullmn.mediaone.net
Sent: Tuesday, November 13, 2001 8:11 AM
To: mnfllnullyahoogroups.com
Subject: Re: [mnfll] A technical question

We experienced the same problem with "Repeat Until" using RIS 2.0 - I was ready to hang it all up when this happened along with all the other little challenges.  What can one do when a loop doesn't work??

I changed to "Repeat While", and it works perfectly now.

Avoid using "Repeat Until" in RIS 2, it randomly turns into "Repeat Forever" (about 1 in 5 times I have found).

Another problem that can trap you is repeating until rotations = x.   I am guessing that the RCX may not be able to see every value that the sensors send to it.

I suggest always coding for greater than values instead of equal to, then the RCX can't skip past one value by mistake.

Good luck - let us know when you figure it out!

 

Repeatability of Missions

Message: 2

   Date: Wed, 14 Nov 2001 16:56:36 -0600

   From: "Stone, Joel"

GourmetAward.com>

Subject: repeatability of missions with fresh or old batteries

Thanks for the great ideas about running the motor power levels up and down gradually during motion.  My kids tried that and it does help.

However, it still seems extremely difficult (if not impossible) to have a mission repeatable with both old and new batteries.

The worst case seems to be during a powered turn.  Imagine driving 20 MPH in your car and turning the steering wheel 90 degrees right.  The car will make a gradual right turn.

Now drive at 30 miles per hour, and turn the steering wheel 90 degrees, but rotate the steering wheel quicker (Lego analogy: with new batteries).

The combination of increased vehicle speed and increased steering wheel rotation speed will cause a substantially different vehicle arc path along the road.

In fact when the turn is completed, the car will be pointing in a different direction AND be in a different location, even though the mileage meter (rotation sensor in Mindstorms) shows the exact same distance traveled.

The turn ending up in a different pointing direction is really bad news in the Lego challenge, because a subsequent forward command with new batteries leads to a vastly different angle than the same forward command with weak
batteries.

Any ideas on how to overcome this problem?  The only thing I can think of is to make all turns with minimal forward motion.  But this will result in slow jerky movement around the table, and will cause more time to complete a
mission.  Two minutes may not be enough time using this method.  Also, my kid's car only turns with forward motion!

Another problem:

To move 100 rotation stops forward, they programmed 5 rotation stops at power level 1, then 5 rotation stops at level 2, then 5 rotation stops at level 3, etc. up to full power.

Then the reverse is done to bring the car to a stop.  5 rotation stops at power level 8, then 5 rotation stops at power level 7, etc. all the way down to 5 rotation stops down to power level 1.

This works fine with new batteries, but with weaker batteries, the car stalls at power level 3 or 2 or 1 during the deceleration.

Once the car stalls, the program stack "freezes" because it is waiting for the rotation sensor to reach 100 rotation stops.  The car will sit there all day not moving because the batteries are too weak to propel the car, and the
rotation wait will never end.  Not a good situation.

Message: 3
   Date: Wed, 14 Nov 2001 18:02:16 -0600
   From: "Savitt, Steven" atk.com>
Subject: RE: repeatability of missions with fresh or old batteries
 

Joel (and others having the same type of problems in robot navigation):

There will always be a certain amount of increasing errors in robot position uncertainty when navigating by dead reckoning (i.e. using the rotation sensor on the robot to measure the distance traveled or the angle of a turn.  Try to think of ways to periodically use instances of landmark navigation in which you use objects of known fixed position on the playing field to determine exactly where the robot is located and exactly which way it is turned.  Some specific techniques to consider are:

1.  Run the robot into a wall to "square it" with the wall.  This will take out all the cumulative turning errors up to that point of the mission.  It will also let the robot know exactly where it is in terms of one of the table dimensions (left/right or front/back).

2.  You could then back the robot away from the wall, turn it approximately 90 degrees, and then run it into the perpendicular wall to learn where the robot is in the other table dimension.

3.  Consider using the light sensor to watch for the crossing of one of the black "leads" as another method of landmark navigation.

4.  Consider building the robot to follow along one of the four walls during certain parts of the mission such that the walls are serving as a continuous landmark.

Two ways to avoid the motors stalling under low power settings as the batteries wear out:

1.  Some teams change batteries frequently.  While this strikes me as wasteful, it gets the job done and provides a long-term supply of batteries for a Walkman or other device that really doesn't care how worn down the batteries are.

2.  Avoid using the lower power level settings that cause the stalls, or if the stall occurs at motor turn-on, then start the motor for a short period (0.1 sec) at full power just to get it turning, and then continue with the lowest power setting you can use to keep the motor turning.  In general, a motor  needs higher power at turn-on to overcome friction and inertia, but then will keep turning at a much lower power setting.

Hope this helps.

Message: 5
   Date: Wed, 14 Nov 2001 21:52:09 -0600
   From: "Cochran, Ted (MN65)" htc.honeywell.com>
Subject: RE: repeatability of missions with fresh or old batteries

Get the kids into the habit of calibrating speed by timing the robot over a fixed distance every so often.

Having programs with blocks of code that can be parameterized with the distance traveled per unit time will then allow them to quickly retune the programs as the batteries age.

You can even auto-adjust for battery power every day (or even every mission),  if you want, but the technique might be too advanced for many teams to "discover" and debug at this late date (The description is for Robolab; I'm sure you can do the same in RIS):

Start the robot in a corner of the base, and time how long it takes it to run over the baseline (zero timer, go forward, wait for darker, put timer into container, divide by number of inches traveled).  For illustrative purposes, lets say the distance is known to be 12", and the robot takes 24 tenth-second ticks of the timer.  This means that it takes 2 tenths of a second per inch.  So, to go 36", the robot needs to run forward for 72 tenths -seconds, which you can do by starting it forward, then waiting for a zeroed timer to hit 72. Load the 72 by multiplying the value of another container (preloaded in inches by the main program) by the calibration value you loaded into the first container, and stringing that to the wait-until-timer icon.

If the robot, later that same day, takes longer to do the known distance, your calibration routine will be multiplying inches by a bigger value.

Use the highest resolution you can to calibrate the timer (inches might be too small.  Half-feet might be better...)

Advanced teams might learn that they can even pass these values as variables to a subroutine to simplify things further.

A similar technique can be used for turns--start with the back on one wall, and turn until a sensor hits the other wall, and track how long it takes (or how many rotations).

Combined with the landmark identification method Steven described (use touch sensors and hit walls on purpose, or use the light sensors to identify ice leads as they are crossed), this method can help quite a bit with navigation.  In fact, you might have to do at least a couple landmarks, since the challenge designers were clever enough to furnish the loose pack ice to scramble timers and rotation sensors....

For the truly fanatical, there was an article published (or at least referred to) on lugnet a month or two ago that described a dead reckoning competition involving traversing a six foot square (I think it was 6, or maybe it was 8) and returning to the starting point.  The winning lego robot used PID control loops, and was accurate to within IIRC a few centimeters. (I think they got to use two rotation sensors, though :-)

           From: "Savitt, Steven" atk.com>
 

__________________________________
__________________________________

Message: 1
   Date: Mon, 24 Dec 2001 19:59:37 -0700
   From: "Savitt, Steven" atk.com>
Subject: RE: best robot for positioning around board reliably

Joel and others,

Here's some suggestions for your kids on improving robot navigation performance.  It expands on responses that Ted and others have provided.

Try to encourage your kids to find creative ways of using the various local landmarks provided on the playing field in getting your robot to navigate to the exact spot of interest (e.g. exact center of the bulls eye). The available landmarks include the black ice leads which can only be sensed through the use of the light sensor, the 2x4 border of the playing field that is probably best sensed using the touch sensor, and any of the larger table props that can also be sensed using a touch sensor. The process of using the touch and/or light sensor to determine when the robot has reached a specific point is called "landmark navigation" because you are looking for a local landmark to determine accurately where you robot is located once it reaches that landmark.

The more common alternative form of navigation is called "dead reckoning" which I suspect is mostly what your team's robot is currently doing. In "dead reckoning", the robot is typically "aimed" in a certain starting direction, and then a series of programmed forward motions and turns is executed with support from the rotation sensor in an attempt to end up at a desired spot on the table (e.g. go straight for 200 counts of the rotation sensor, turn 12 counts, go straight 30 counts, turn -12 counts, etc.) The problem with dead reckoning is that even though the RCX is keeping an accurate count of the rotation sensor movement, the actual distance traveled or angle turned by the robot will vary due to the amount of slippage or "give" of the rubber tires on the smooth table surface. Due to the amount of error or slip in each motion of the robot while dead reckoning, the positional uncertainty of the robot will grow as your mission proceeds. So by the time the robot has accomplished a couple of turns and straight movements to get to the center of the bulls eye, for example, the positional uncertainly is large and all the robot "knows" at that point in the mission is that it is somewhere in the neighborhood of the bulls eye, but not consistently right at its center where it needs to be for the highest score.

Navigating by dead reckoning is not all bad. It is the only way you can navigate for any segments of a mission where there are no usable local landmarks. It is usually faster, albeit much less accurate than landmark navigation. The higher performing robots you refer to in your query are likely using a combination of both dead reckoning and landmark recognition.

I serve as the technical mentor to the Meadowbrook Sasquatchers team that achieved the 285 point score a the Rosemount tournament that you mentioned in your query. For the mission of delivering the new instrument to the bulls eye center, their robot selectively follows one edge and then the other of the ice lead that runs from the starting position to a point close to the bulls eye. It uses the rotation sensor to determine when it is approaching each ice lead fork so it knows when to switch from following the left edge to the right edge in order to take either the right fork or left fork to stay on the proper path through the maze of ice leads. Once it has traveled a distance that places it as close as the ice lead gets to the bulls eye, it uses dead reckoning to turn toward the bulls eye and then move a short distance to the center of the bulls eye. While this solution provides the needed navigation accuracy, the process of line following across the entire playing field consumes substantially more time than would be done if the robot was programmed to dead reckon rapidly to the general area of the bulls eye, and then use any of the local landmarks to navigate accurately to the
center of the bulls eye.

Hope this provide the requested suggestions your team was looking for.

-Steven Savitt

Meadowbrook Elementary School
The Penguin Patrol and The Sasqwatchers

-----------------------------------------

-----------------------------------------

Date: Sat, 22 Dec 2001 20:32:02 -0600

From: "Cochran, Ted (MN65)"

htc.honeywell.com>

Subject: RE: best robot for positioning around board reliably

Using the rotation sensor is a dead reckoning, or open loop, control strategy--it's better than just using the timer (also open loop, but less accurate), but the robot performance will still vary with initial position, battery power, tire skidding, etc.  For those long missions to the far side of the table, it helps to take advantage of landmarks, like the black leads and the walls.  Touch sensors will tell you when you hit the wall; light sensors can tell you when you hit a lead.  Some teams even follow a lead all the way across the table using the light sensors--that's called closed-loop control, and it helps with precision but at a cost in speed.

Some teams also use the walls or the leads to get home again.

Hope that helps,

--tc

Making a Negative rotations sensor count positive

Message: 8

   Date: Sat, 17 Nov 2001 22:50:37 -0500

   From: "Quealy, Mike"

pios.com>

Subject: Rotation sensor

We have rebuilt our robot several times lately, and this last time the rotation sensor was installed in the opposite direction, resulting in negative numbers when it goes forward, instead of the positive numbers we were used to.  We would rather not rewrite our programs to accommodate this. Is there a way to reverse the polarity of the rotation sensor in the settings somewhere?  We have not been able to find it.

Message: 9
   Date: Sun, 18 Nov 2001 00:01:26 -0600
   From: "Joel Stone" mn.mediaone.net>
Subject: Re: Rotation sensor

If you are using subroutines and variables, you can set a DISTANCE variable to a positive value and run the subroutine.

In the subroutine, you can use the MAKE NEGATIVE command to flip the sign to negative, and then in your rotation test change the "greater than"s to "less thans".  Be sure to make the DISTANCE variable positive at the end of the subroutine so it is set back to its original value.

With all the other problems of commands that don't work (Wait Until and Repeat Until), I would have the kids move the rotation sensor back to the other side and use positive numbers!

 

How My Blocks Work

   Date: Wed, 21 Nov 2001 23:36:38 -0000

   From: Cwit163297null

AOL.com

Subject: Re: RIS 2.0 programming - "my commands"

The "My Blocks" are not static or edit protected and are not Program specific they are User specific ie how the kids logon to the RIS program.

So if the kids  login in under "super duper robo builder" and create a my block in one program then move on to create another program and edit the my block they have changed the block potentially for all the programs.

Also if they call up a file created by " super duper #1" logged in under another user  name ie  "super duper #2" and each super duper has a my block of the same name but different elements RIS gives the kids an error or asks to rename the block.

If you don't change the  block name when asked - my kids beleive it uses the current version of the my block  rather than the old version in place when the kids last saved the program being opened so they nearly always change the name. Yup the list gets longer every day.

These ever-changing  blocks may cause problems depending on what the kids want the block to do and how they want to manage the blocks.

Took us 2 days to work through that the my blocks are dynamic. This process was a great programing expr for a few of my kids as they had to go step by step what changed - what happened - how could it happen - now what did they really change - then prove it. For rest of the team this was way too rigerous to stick with (part of being  9 & 10).

 Date: Sat, 24 Nov 2001 21:14:30 EST
   From: CTheuerknullaol.com
Subject: Re: question on myblocks

Yes, the team is using RIS 2.0 and thanks for the info on where the macros are stored.  Through some experimentation, we found that if a program with a myblocks macro is saved on one computer, then the program is transferred to the second computer, the myblocks transfer with it.  If there is already a myblocks macro on the target computer, RIS will ask for the myblocks to be
renamed.

mnfllnullyahoogroups.com List Details


   Date: Thu, 22 Nov 2001 11:15:57 -0600
   From: "Rose, Fred  (MN65)" honeywell.com>
Subject: RE: Attachments WHY

John is correct, here is a bit more.

Yahoogroups (before that it was egroups, before that onelist when I created this list) is a free service. In return banner ads are placed on each message. Depending on your email program, these may come across as HTML attachments, particularly in mnfll-announce (that list was created only last year so the ad requirement is a little more obnoxious, some of you, including sally, are on both lists). Nothing we can do about it, except pay a yearly fee. It seems a reasonable tradeoff.

mnfll is open to anyone to join and post. i moderate it and watch new signups fairly closely and would remove anyone sending spam, etc.

mnfll-announce is also open to anyone to join but only the moderaters (at this time tim jump and me) are allowed to post. many people don't want the large email discussion that comes with a list like this. there is no need to belong to both, all messages to mnfll-announce are also sent to mnfll.

also about 10-15% of mnfll list members are from outside mn.

we also have a mnfll-judge (moderator post and approve to join) and a mnfll-plan for the planning group.

hope you have a great holiday (i am taking the day off just need to keep up with some work email, it's not a holiday all over.)

 

Message: 7

   Date: Thu, 25 Oct 2001 14:18:19 -0500

   From: "Rose, Fred  (MN65)"

honeywell.com>

Subject: FLL Topics, Oct 25

 

3. Awards for 2001.  In Minnesota we will differ slightly from the awards posted on the FLL website and in your coaches manual.  Our awards are published on:

http://www.hightechkids.org/fll/tourn_Directors/tournament_directors.htm

The primary difference is that we do not have a technical interview award as the technical interview is part of the judging process anyway.  We changed the name of some awards slightly to better reflect what we think they are really about.

Remember, at a tournament, in addition to competing with your robot, your teams will go to two stations: presentation and technical.  At the technical station your team will run the robot through its paces and be interviewed by judges looking at the programming and design of your robot.  At the presentation station, your team will present a three-minute presentation on the hypothesis question presented in the material by FLL.  More on that in the next item.  In addition, at the presentation station your team will be interviewed by the judges.  Your total score in a tournament is based on your results in both the robot performance area (the Arctic Impact Challenge), and the technical area (programming, creativity and design categories), and the presentation area (presentation and teamwork categories).  More on the scoring will be posted as we get closer to the tournament.

4. Presentation/hypothesis.  When solving a technical or scientific problem it's important to understand why you are doing it and the context of your solution.  Last year it was volcanoes, this year it's the Arctic.  This year there is a specific question which are team must address.  Below is what is posted on our website and how we approach the presentation problem here:

Hypothosis Assignment (also known as the Presentation Award)

From FIRST's Problem Description:

To further the efforts of the expedition - ARCTIC IMPACT, FLL teams will use their expertise to analyze the data and theorize whether the cause of global climate changes are directly related to human interference, or if the Earth is experiencing a natural patterned cycle.

In MN:

You will present your findings in front of a panel of judges. You have approximately 3 minutes to make your presentation. It can be in any form you want (skit, posters, Powerpoint, straight discussion or speech, etc.). After your team's presentation, the judges will ask the team questions about your findings, how you did your research, as well as questions about your teamwork, the functions of your team members, etc. This presentation and interview are used to judge the Presentation and Teamwork awards. Observance in the technical judging area (where Design, Programming, and Creativity are judged) also factors into the Teamwork award.

Don't forget to spend time on this aspect of the problem.  Last year we had teams come up to the presentation station and basically say "Presentation? What presentation?".  It doesn't have to be fancy but this is an important part of the program.  Building robots is fun but we build them for reason.

5. Lesson plans. Remember that weekly lesson plans are on the Coaching 101 section of www.hightechkids.org/fll. At this point, we have teams in a wide variety of stages, but don't worry if you are just getting started. Reports from coaches tell me that even with a couple practices even young teams can score some points. If you are a new team, remember to focus on basic skills like having a robot go forward and back, turn, etc. A basic robot and basic functions can get you a long way that first year (or any other for that matter).

Fred

"Knowing is not enough; we must apply. Willing is not enough; we must do." Goethe

Allowable FLL Parts

Date: Sun, 21 Oct 2001 01:44:47 -0700
From: "Steve Putz" home.com>
Subject: Summary of LEGO Mindstorm Parts Lists, Sources, etc.

Several inventories and lists of LEGO Mindstorms kits and parts relevant to FIRST LEGO League competition have been shared recently.  Here are some web pages that consolodate some of the relevant information and links, including some sources for getting kits and parts.

    http://groups.yahoo.com/group/NCaFLL/files/parts/

Enjoy, and send any comments or corrections to sbputznullhome.com

-- Steve Putz

Light Sensor

Date: Fri, 25 Jan 2002 01:38:55 -0000
From: "cwit163297" AOL.com>
Subject: Re: RCX failure to respond

My team found out that new batteries caused the light sensor reading
to drop when over a black line compared to old batteries.

Could be sensor change or a stronger source light variation with
voltage - either way seems not to be unique.
 

Craig Wittman

Here is a link http://www.plazaearth.com/usr/gasperi/light.htm to a website that discusses the internals of the light sensor.

Blank RCX Screen and Motor Caution

Someone wrote in and asked about why their robot screen goes blank after their robot is turned on.

   Date: Thu, 24 Jan 2002 22:39:51 -0600
   From: "Cochran, Ted (MN65)" honeywell.com>
Subject: RE: Re: RCX failure to respond

I know for a fact that letting one of these motors stall for any length of time can be hard on batteries and hard on motors.

One last tidbit--a stupid lego motor trick.  One of the kids on my team discovered by chance that if you hook two motors together using a single connector (no rcx, no batteries, no nothing), and if the connector is oriented the right way, you get a pretty decent generator.  Its an efficient one, too--turn one motor by hand and it makes the other one go very nicely. hey couldn't think of anything creative to do with that phenomenon (four of them spent a whole practice session playing with it), but if they allow four motors next year, I might tell them about synchro motors

Clever Ideas From the MN State Competition

Date: Mon, 28 Jan 2002 21:12:54 -0600
From: "Cochran, Ted (MN65)" honeywell.com>
Subject: RE: Judge's comments on what they saw that was unusual and
unique

> >Any other real creative and innovative uses of Lego parts would be
> >interesting to see in the State Tournament summary if possible!

Putting the light sensor onto the forklift so it could be lifted out of the way for the iceshelf mission--seems obvious, but not everyone did it!

Having a swappable rear wheel--either a swivel wheel for the missions requiring turns or a wheel locked in place for out-and-backs.

Having a manual transmission that let the clutch be used on an arm for one mission (to permit flexibility), and then by sliding two gears over let the arm be locked to the gear train for the next.

The robot with the dog's face.

All manner of clever stored energy devices--knock an axle out of a claw with the ice core loop, and the claw clamped down hard.  Use the ice hut to trip the container with the barrels so they'd fall right in.

A couple of nice hopper-and-conveyer-belt systems for barrels.

We have digital photos of every robot, or nearly so.  It may be a week before I have time to download, crop, label, and upload them, but they'll be there.  I'll probably need help getting the team names correct!

I was on the whole extremely impressed with the mechanical designs. There were far fewer exploding robots--the ones that send motors and wheels skittering all over the place whenever they hit something.  There were also far fewer robots that were geared too fast--big wheel mounted directly on the motor axle, for example. The most advanced teams are clearly not being hampered by the limits of legos, although reliability is still an issue (and I think some of that IS due to the limitations of legos). There could be some improvement in the use of multi-axle gear trains (having intermediate gears that do more than serve as an idler, for example) and in multi-axis gear trains (the bevel gears weren't used much, and they could have helped some of the teams who needed more compactness). But overall, the mechanical designs were just fabulous!

The Division 1 final was awesome--two perfect table runs, with the medicine barrel determining the winner.

There was a big improvement in the sophistication of navigation.  Many robots did line finding and/or following.  Some robots squared themselves up to the wall in mid-mission using touch sensors, and not just brute force. Lots of bogey wheels to help in following lines. Lots of clever uses of balance--to dump barrels, for example. Rotation sensors were all over the place.  Several teams used more than three sensors, using the software to overcome the 3 port RCX limit.  A large number of reconfigurable designs that started out as a nice compact robot and ended up as little more than the RCX and a box of subassemblies, all removed after they had served their purpose.

That said, we still have a long way to go in programming sophistication, and that may be an area for increased educational resources next year.  There were many many programs that consisted of very long strings of commands in Robolab (or tall stacks in RIS), and that clearly caused maintenance problems for teams.  I have to believe that an awful lot of time was spent debugging those long chains of commands!  Lots of dependence on timers, too. Relatively few teams used subroutines effectively; multitasking wasn't all that common, either.

There were exceptions, though.  One team had a routine for driving in a straight line--you put the number of inches you wanted to travel into a container (positive for forward, negative for backward), and then called the subroutine, and that's just what the robot did.  Simple, yet sophisticated. Another team built a routine for calibrating the light sensor into their program, so that it didn't require a test, change, download cycle--they did it on the table, before each competition.

 

Dual Light Sensors

Date: Wed, 13 Nov 2002 21:49:52 -0800
From: "Robotics Learning - Steve Putz" RoboticsLearning.com>

Hi, I realize it has been nearly a month since this was posted but I thought I would take a crack at an answer anyway on the off chance you were still wondering.

The reason why two light sensors are better than one when following  a line is because with one light sensor a robot would be forced to turn in a circle if it loses track of a line. This often happens when turning corners for example and often results in the robot catching the line at 180 degrees where it goes back the way it just came. With two sensors, one on each side, the robot can be programmed to turn a given direction based on which sensor no longer sees the line. If done correctly the robot doesn't lose the line for long before turning back towards the line.

I have a Robolab file on my site if you would like to look at a simple example of how this might be done. It can be found at http://robotics.megagiant.com/files/double_light.vi

I hope this helps.

-j.

James Isom
Marin Robot League - "The Unknowns"
http://robotics.megagiant.com

 

Light Weight FLL Playing Fields

   Date: Mon, 10 Feb 2003 10:25:37 -0500

   From: "Mancini, Sally A"

eds.com>

Subject: RE: Call for Volunteers, MNFLL/INSciTE 2003/4

Table builders!
We are working on a design for a light sturdy portable model for the next
FLL season.  Our small prototype boarder railings look good.  I will forward
more information (materials list) later when we have tested the new lighting
structure for stability.  So far it looks great.  We are tired of hauling
and storing the heavy wood version.

Thanks, Sally

   Date: Mon, 10 Feb 2003 09:47:35 -0600
   From: Ray Muno aem.umn.edu>
Subject: Table building

A comment I have on table building is that the table surface should be
made of MDO (Medium Density Overlay) plywood.    This is plywood that is
used for things like signs and such.  It is standard plywood but it has a
very smooth paper face.  It weighs the same as regular plywood but has a
face that is as smooth as MDF (Medium Density Fiberboard) but no where
near as heavy.  To get a smooth wood face on plywood, you have to pay way
to much.  MDO is a better alternative, in my opinion.  We made our tables
out of this and it worked very well.

   Date: Mon, 10 Feb 2003 10:59:45 -0500
   From: "Mancini, Sally A" eds.com>
Subject: RE: Table building

Ray,
We are about to test a light weight plastic board as our surface (more
later--once we get the boarders and lighting finished).  Price is around
$20.00 for the sheet.

Sally Mancini

   Date: Mon, 10 Feb 2003 12:39:23 -0500
   From: "Mancini, Sally A" eds.com>
Subject: RE: A lighter, portable table?!?!?!?!? Count me in!

Yes we cut the board in half for easy storage...more in a few weeks since we
are going away on vacation

Sally Mancini

 

Installing LEGO Robotics Invention System version 2.0 on Windows XP-Pro

Michael Schuh
Date: Sat, 25 Dec 2010

I was able to install and run Robotics Invention System 2.0 on Windows XP Professional December 25, 2010. I wanted to see if it would work on XP Pro to help a friend make good use of an old RCX kit.

The most helpful webpage was Jennie's LEGO MindStorms Notes. I used her Installation Instructions. I also have copies of her instructions and the zip files from her website in case they ever go away. Contact me if you need them. If you don't want to run the executable to stop the RIS 2.0 software from starting every time you login, you can edit the registry by following the instructions at the LosAltosRobotics.org website.

I tried running RIS 2.0 in compatibility mode but this complained about wanting me to install QuickTime eventhough we already have the current version of QuickTime.  Jennie's LEGO MindSorms Notes have a page on this one too.  She recommends installing an older version of QuickTime - Version 6.5.2. I did not have a QuickTime problem when I ran without compatibility mode; however, it did run in full screen mode. Her Fix 2 tells how to configure the software so that all non administrator users on a machine can run RIS 2.0.

If you get an error message: A critical error has occurred. You may be running out of memory, or you may need to reinstall Robotics Invention System 2.0, then follow Jennie's suggestion for fixing this or delete the C:\Documents and Settings\[username]\Local Settings\Temp\Ris 2.0.mov.#res file every time you run RIS 2.0. I wrote a Windows batch file called "RIS.bat" with the contents

del "%TEMP%\Ris 2.0.mov.#res"
"C:\Program Files\LEGO MINDSTORMS\RIS 2.0\RIS2.exe"
Be sure and change "Administrator" to the username for whoever is logged in and running the LaunchRis2.exe code.  The RIS.bat file is a text file.  It would be nice to associate the Robotics Invention System icon with the RIS.bat file.  Let me know if you know how to do this.

 

 

The Robotics Invention System 2.0 Freeze XP (Hyperthreaded CPU) page says that the updated USB Tower drivers also work on Windows 7.

Removing LEGO-MINDSTORMS from Startup

Date: Sat, 11 Oct 2003 16:55:30 -0000
From: "Michael Schuh" boardsailor.com>
To: NCaFLLnullyahoogroups.com

> --- In NCaFLLnullyahoogroups.com, Venkat wrote:
> > Folks,
> >
> > I heard there is some magic registry settings that needs to be
> > tweaked to prevent the Lego Mindstorms program from launching
> > everytime I start my laptop. I run Windows 2000, and just removing
> > from Program Startup doesn't appear to do it.
> >
> > Thanks,
> >
> > Venkat Rangan

After I installed RIS 2.0 on a Windows XP Professional computer yesterday, the RIS software started up every time I logged a user in.  There are two ways to stop this.

The first is to go to the Start/Run and start the program "msconfig".  Go to the right most tab, "Startup", and deselect the LaunchRIS2 entry.  Reboot and you will likely get a message saying "things have been changed and do you want to continue and do you want to see this message again".  This is no big deal so tell it you don't want to see it again and all should be fine.

The second is to go to Start/Run and start "regedit".  Work your way down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and select "RIS2PostReboot" with the left mouse button and then got to the "Edit" menue and use "Delet" to remove the entry.  This will fix it for good.

I have used both methods with success.  BTW, I use the msconfig approach to turn off almost all of the entries under the "Startup" tab to speed the booting and performance of my home computer.

Michael

Unrecognized Brick Error

Date:  Thu, 30 Oct 2003 14:32:36 -0800
(PST)
From:  Karen Mahoney yahoo.com>

If you call Lego Customer Support on this, it is a known issue.  They don't consider it a true bug.  The chip only recognizes tenths of a second because of it's refresh rate.  So any number you put into the hundreths place gets rounded off.  Even if you think you have hundreths of a second, you don't.  The software doesn't allow it because the ancient chip used can't handle it.  Stick to tenths of  a second.  If you have a block with less than .05 seconds, you will be rounded to zero and invalidate the loop.  Until you fix it, your program will freeze.  We did this song and dance last year.  Good Luck.

Karen

----- Original Message -----
From: sanjay_gangal
To: RoboticsLearningTalknullyahoogroups.com
Sent: Wednesday, October 29, 2003 11:18 AM
Subject: [RoboticsLearningTalk] Unrecognized brick error

I get an 'unrecognized brick error' message while attempting download of a program. I am able to repeat this effect with this simple program (in RIS 2.0,  RCX 2.0)

================
Repeat
Forward 0.01
until touch 1
Stop motors ABC
================

Download - program works
Exit

Come back
Download
Save
Exit

Next time you come in (that is the third time) - the program gives this error message:

'Unrecognized Brick Error'

On Windows 2000 machines, at this point you cannot modify the program - you just have to rewrite.

On Windows XP, the program will work if you change 'Forward 0.01' to 'Forward 0.1'.

The bottom line is that if you use timing of less than 0.1 seconds, the program gets completely hosed.


External Power for the RCX - RCX Power Circuit

We sometimes use an external power supply for our RCX Version 1.0.  We have successfully used the power supply that came with the LEGO train which is a 12 VAC 7 VA toy transformer and we have used the transformer that came with the Botball Handyboard which is a 12 V DC 500 mA transformer.  We have used the train transformer a bunch and it works fine and have only used the Botball HandyBoard transformer a little but it appears to work fine.  I got the following from "LEGO® MINDSTORMS(tm) Internals" at http://www.crynwr.com/lego-robotics/
Mathias Uhr reports that the power circuits are different between revisions. He writes: I disassembled all versions of the rcx bricks and had a look at their power circuits. Here are the results:
    • RCX 1.0 (with power plug)
      • The two inputs (plug and batteries) are completely independent. There isn't even a direct ground connection between them.
      • The external power source is rectified with a bridge rectifier (4 diodes), filtered with 6 caps of 330uF each and then stabilized with a voltage regulator ic.
      • The positive pole of the battery first runs through a diode to avoid voltage applied to the batteries from the external source.
      • The internal batteries don't get disconnected when an external power plug is inserted - at least not mechanically.
    • RCX 1.5 (mine says "1.0" on it, but has no power plug) and RCX 2.0
      • The RCX 1.5 and 2.0 versions seem to have an identical circuit.
      • The sophisticated stabilization circuit is omitted (no caps, no regulator, no rectifier diodes and no plug of course).
      • Instead, there's a big cap (1000uF) - probably to keep the memory when changing batteries - and a ferrite "ring" (probably for some kind of filtering if someone still connects an external power source) behind the battery input.
      • I couldn't find a diode behind the positive battery pole.
      • The piezo beeper sits where the 6 caps have been in 1.0, no longer under the display.
      Conclusions:
    • The RCX 1.0 (with power plug) is the one to get! it has a great power circuit. Lego is obviously cutting costs by omitting all these parts in RCX 1.5 and 2.0. Since you can use 2.0 soft- and firmware for the 1.0 as well, there is no reason to use something else. Get as much of those sturdy oldies but goldies as you can!
    • Because of the rectifier circuit in the 1.0, the polarity of the external power plug doesn't matter, you can even attach an ac source (which i tested) and even more than 12v (which i didn't test, don't sue me!). I wouldn't recommend this though, cause the regulator ic would then probably produce too much heat.

      • For my "accu pack application", this means that it is perfectly safe to attach an accu pack (or any other power source) of up to 12v to the external power plug of an RCX 1.0 along with normal batteries in the brick! It has, however, to be tested first, which ones get consumed quicker. For charging, the accu pack can remain connected, as long as the charger's voltage doesn't rise above 12v. but I still recommend you disconnect it from the RCX..


Changes Log:

11 Sep '05 Added How to set the default value of the USB transmitter tower
12 Dec '03 Added External Power Supply Section
15 Nov '03 Added Unrecognized Brick Error Section
11 Oct '03 Added RIS Startup Section
09 Oct '03 Added Book recommendations
11 Sep '03   First Published Version