Unofficial FLL FAQ06-c - RCX Robot
UFAQ Table of Contents
Q16.1) We have switched from time delays to using the rotation sensor, but have still not improved our accuracy. What are we doing wrong?
A) When properly understood the rotation sensor can greatly improve your accuracy. Unfortunately there are lots of
pitfalls. Here are some things to consider during your experimentation.
- RCX rotation sensor deficiencies. There is a known problem with the rotation sensor. If the axle rotates too fast or
slow, the rotation sensor will loose counts. The best range is from 50 to 300 RPM. 300 RPM is the speed of an unloaded motor.
- Speed. Assume you are driving at 60 MPH down the highway and slam on your brakes when your odometer clicks over to
some magic number. Because of the car's inertia, it will take you some distance to stop. The same experiment at 5 MPH and you stop much sooner. The same thing holds true for a robot.
- Battery power. Closely coupled to speed is battery power. As batteries die, the robot will start traveling slower
and will affect the accuracy.
- Stopping method. Using the car analogy, the difference in accuracy is much better if you slam on the brakes rather
than just coasting to a stop. Make sure you brake the motor and not 'float' or coast it.
- Sample rate. The RCX/NXT cannot watch your rotation sensor all the time. It has other jobs to do. It may doing something
else the instant the rotation reaches the terminal count. When the RCX/NXT 'finally' does look at the rotation sensor count, the robot will have traveled some distance. This will cause the distance the robot travels to vary by some small amount each time.
- Peeling out. Robots that start and stop quickly may actually lose traction on the mat.
- Non deterministic effects. Friction is not deterministic. Each run, the friction gods roll their dice. This causes
fluctuations from run to run. This is especially nasty during turns when wheels scrub sideways.
- Resolution. The basic resolution of the rotation sensor is 16 counts per revolution of the axle that pierces the
sensor. If the wheel is on the same axle, your best possible accuracy is 1/16th of the wheel circumference. Not too bad if you are using the tiny balloon wheels, but fairly bad if you are using the large 'bicycle' wheels. A trick advanced teams use is to gear up the rotation sensor so that its axle rotates more often than the wheel axle. This increases the basic resolution of the robot. Just be careful not to rotate it faster than 300RPM.
- Full halt. When programming multi leg paths, place a short pause (1/10th to 5/10th sec) between legs. This allows
the robot to come to a full rest and makes it more repeatable.
- Slowing down. What would you think of a driver that went the speed limit until they hit a red light and then
slammed on the brakes?
Q16.2) What is the LEGO lamp used for?
A) Many things including:
1) Decoration.
2) Debugging aid. Much like you would use a beep in your program to indicate whether the code actually got to a
particular point, you could tell the light to light instead.
3) Used in combination with a light sensor and pulley wheel you can have a makeshift second rotation sensor.
4) Something nobody has thought of, but will revolutionize FLL.
Q16.3) Are lubricants allowed?
A) No. It is quite explicit in the rules that lubricants are NOT allowed. Be aware that many lubricants will attack the plastic used in LEGO elements, rendering your robot a horrible mess. If you are trying to reduce friction on an axle bearing, design the support properly. An axle supporting the weight of a robot should not pass through just one beam.
Q16.4) There is a rule against stickers and the like on the robot. What can I legally do to mark ownership of major LEGO parts?
A) The ban on stickers was instituted to prevent their use as structural elements and to keep the robots looking
LEGO-ish. Although it is technically illegal, a small sticker with the team name on an RCX/NXT is not likely to cause
problems. Make it small and obvious that it is not aiding in the structural design of the robot. Better yet
(and now even legal!, see rule 5), use a Sharpie pen to write the identification mark in a hidden spot. Make it obvious that
the mark in no way is affecting the behavior of the LEGO or the robot.
Q16.5) Our robot does not drive straight. What is the matter?
A1) This is a constant irritation with FLL teams. In fact, it is very rare for the average robot to drive
straight. A full answer to this question is beyond the scope of the FAQ.
A2) Nothing is the matter. Remember that no two motors are alike! Try to find the two motors that are most
similar.
A3) Work with what you have. "When life gives you lemons, make lemonade".
A4) Brainstorm with your team to determine what all the factors might be that would cause the hook. Then run
some experiments to isolate the problem.
A5) Some information is provided in the FLL Team Manual.
A6) Read the document Building LEGO Robots for FIRST LEGO League
Q16.6) I understand that I can minimize the 'not driving straight' problem by matching motors. What is that and how do I do it?
A) Matching motors is simply trying to find the two motors that are the most similar in behavior. To find a matched
set, place the same sized gear on each shaft. Turn the motors on in the same direction. Now face them towards each
other and let the gears mesh. If the motors match, there will not be any movement between the motors. By movement I
mean that one motor will not try to walk around the other. The more motion between the motors, the more difference
between speeds.
Q16.7) We're having trouble with the rotation sensor binding up the motor. What are we doing wrong?
A) Don't snap the rotation sensor into your robot. Allow it to float on its axle. The wire should be enough to prevent
the sensor from moving with the axle. Snapping it into place seems to cause binding, probably because the hole isn't in precisely the right place. If the wire is not enough to constrain the sensor, try a belt to rubber band it gently into place. A rotation sensor that flops around will not be as accurate.
Q16.8) Why does our robot travel different distances for the same amount of time?
A) Because of many reasons. The largest being that your battery level is dropping and the motors are not working as
hard or fast. Switching from time to using the rotation sensor is one way to minimize this problem. Other issues are varying friction or other effects that change from run to run.
Q16.9) What is better, wheels or treads?
A) It all depends. Each has pros and cons. Consider making a single robot that can switch back and forth between wheels
and treads. Run various experiments to see what makes sense. All things being equal, treads require more power than
wheels and tend to kill batteries faster.
Q16.10) What is a light sensor good for? Why do we need one or even two?
A) The prime use for the light sensor is to follow or sense lines on the mat. So far, each year the primary tasks have
been located on or near lines that can be followed. The light sensor is the device that lets you do this. Some teams
will even use both light sensors to optimize their line following algorithm. There are other ways to use a light sensor
and that is why you get two.
Q16.11) We have commanded both RCX motors to go forward and yet the robot spins in place. What's wrong?
A) Nothing is wrong. Forward and Backwards are very arbitrary. How the wheels turn for a forward command is dependent
on the mechanics and the wiring. To get the robot to go forward, rotate the connector on either the motor or the RCX
port 90 degrees on the offending motor.
Q16.12) Why does our robot not stop at the proper rotation count?
A1) The ability of the robot to stop on the exact count is primarily a function of how fast your robot can stop. If you have a fast robot, it may take a second for it to come to a stop. During this time you may travel several inches and continue to increase your rotation sensor counts. As batteries die, the robot slows down and now the robot will not travel the same distance during its stop. Slow robots are not affected as much. Another issue is how often the RCX checks to see if your rotation sensor count has been meet.
A2) For those using RoboLab there is a ‘feature’ in the Wait For icons that introduce some latency and hence add to the overshooting problem. If you double click the icon, it will open up a subvi. Do NOT edit this subvi. If you do, it will affect all your programs and can only be fixed by reinstalling the software from disk. This subvi is what RoboLab does to accomplish the wait. It is a 'spin loop'. In other terms, it sits in an infinite loop testing the sensor for a particular condition. When true, it bails out of the loop. The 'problem' is the authors put a 2/100 second pause inside the loop. This means that you will not sample the rotation sensor as fast as possible. The solution is to make appropriate modifications to copies of these icons. This works great for the light sensors and touch sensors. The rotation sensor has the added complexity that it can go both positive and negative.
Q16.13) What type of navigation do teams use?
A) Having a good way to navigate to the missions is one of the key aspects of the table performance rounds. Different teams use differing approaches that include:
- "Dead reckoning" with the rotation sensor to help provide more accurate odometry can work very well for robots that are precise in their movements. Through careful construction and appropriate gearing, some teams manage to build robots with a high degree of precision and can use dead reckoning with the rotation sensor and alignment jigs.
- "Physical orientation" is another approach. The robot can bump itself up against walls and/or mission models in order to align itself in a known location. This can be used to "reset the error" that has built up after doing a few turns or traveling a long distance by dead reckoning.
- "Feedback orientation" uses the external sensors (touch sensor and light sensor) to interact with the environment and figure out where one is by finding features such as lines, craters, or light spots on the mat, or by finding where physical objects are (the walls, mat, or mission models).
Winning teams will likely make use of all of these navigation approaches to some extent.
Q16.14) Our program works great, but it requires the handler to position the robot correctly within about half a millimeter of the right way. Otherwise, the rest of the round is hopeless. Any suggestions, please?
A1) Find a repeatable way to position the robot by alignment with landmarks on the mat, or through use of a jig or similar aiming device. This approach tends to be pretty straightforward to implement, but requires extra time for the handlers, and is still error-prone.
A2) Change the programming so that the handler doesn't need to position the robot 100% correctly. This can be pretty difficult.
A3) Always start the robot from the same place in base. Perhaps right up against the wood borders in the corner of the base.
A4) Look at your robot design and see if it can be made less sensitive to exact positioning. What is the failure mode and can a mechanical rather than programming solution fix it?
A5) Have your kids think of other things that are aimed like compasses, telescopes etc. How are these things aimed? Is there any part that is used for aiming? Maybe they could add that to the robot to increase the accuracy.
Q16.15) What type of driving base is best to solve all the missions?
A) It may well be the case that one base may not be able to solve all the missions. Many teams will made modifications to the robot as the match progresses to do various things. I saw a robot once at the end of a match that looked NOTHING like how it started off.
Q16.16) What do I do if I have an old serial tower but no serial ports on my computer?
A) If your computer has a USB port there is a solution. You can purchase a USB to serial converter. One such model
that worked for a fellow coach is the Keyspan USA-19HS for about $40.00.
UFAQ Table of Contents
Home
Disclaimer: This FAQ is not an official FIRST document.
It is an accumulation of knowledge derived from six thousand messages posted to
the FLL forum over three seasons. It has been reviewed by numerous people, but may
still contain errors. Use at your own risk.
Readers are encouraged to submit errors, suggested wording changes, new topics,
or comments to Skye Sweeney at skye@fll-freak.com
Copyright 2003-2006 Skye Sweeney; Last Updated on 10/28/2006