FLL Programming and Design Suggestions

• Books on Robot Building and Programing
• Ganging up Light and Touch Sensors on the Same Port
• Repeat Until does not work with RIS2.0
• Repeatability of Missions
• Making a Negative rotations sensor count positive
• How My Blocks Work
• mnfllyahoogroups.com List Details
• Allowable FLL Parts
• Light Sensor
• Blank RCX Screen and Motor Caution
• Clever ideas from MN State Competition
• Dual Light Sensors
• Light weight FLL Playing Fields
• Removing LEGO-MINDSTORMS from Startup
• Unrecognized Brick Error
• External Power Supply for the RCX

Books on Robot Building and Programing

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 <benlriverayahoo.com>
    To: NCaFLLyahoogroups.com

Check out the usfirst site "http://www.usfirst.org/jrobtcs/flg_tm.htm". 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" <sanjay.gangalibsystems.com>
    To: <NCaFLLyahoogroups.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.

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: "cnsanfordyahoo.com" <cnsanfordmindspring.com>
     To: NCaFLLyahoogroups.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

Ganging up Light and Touch Sensors on the Same Port

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" <tjumpbsm-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)" <cochran_tedhtc.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" <steven_savittatk.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

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 jrstonemn.mediaone.net
Sent: Tuesday, November 13, 2001 8:11 AM
To: mnfllyahoogroups.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

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" <steven_savittatk.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)" <cochran_tedhtc.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" <steven_savittatk.com>
 

__________________________________
__________________________________

Message: 1
   Date: Mon, 24 Dec 2001 19:59:37 -0700
   From: "Savitt, Steven" <steven_savittatk.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

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

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" <jrstonemn.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

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: CTheuerkaol.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.

mnfllyahoogroups.com List Details

   Date: Thu, 22 Nov 2001 11:15:57 -0600
   From: "Rose, Fred  (MN65)" <fred.rosehoneywell.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.)

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:

In MN:

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

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 sbputzhome.com

-- Steve Putz

Light Sensor

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

   Date: Thu, 24 Jan 2002 22:39:51 -0600
   From: "Cochran, Ted (MN65)" <ted.cochranhoneywell.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 <grin

Clever Ideas From the MN State Competition

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

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

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 <munoaem.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" <sally.mancinieds.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" <sally.mancinieds.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

Removing LEGO-MINDSTORMS from Startup

> --- In NCaFLLyahoogroups.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

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: RoboticsLearningTalkyahoogroups.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

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: