Strategy
This page contains strategies for you to consider in developing your robot and programs. This is not meant to be a source for the answers to your problems. Every robot, team, and coach are unique. No two are alike. There is no "one" solution that fits everyone. Rather, this page is intended to help you to gain a better understanding of what the
true problem is and what things you may want to consider when developing your own solution to the problem.
Language and Coding Strategies
NXT-G, RobotC, Function Libraries, MyBlocks, configuration variables, menus, controllers, etc. etc. These are all programming languages and concepts that you should consider when designing programming.
Do you spend time writing low level functions to move or to stop the robot? The programming language probably already has these in place.
But how can they be improved or made more useful?
Use of Parameters
Parameters are values that you can pass to a function that give it information about what you want it to do. For example, a parameter might be used to tell a function the "diameter" of a wheel and the function that uses it might convert that "diameter" into the wheel's circumference. In NXT-G, you can create your own MyBlocks to use parameters to pass information into and out of the custom block you created. In RobotC, functions receive parameters. The function itself can return a value of a defined type (integer, float, string, etc.).
Robot Design Strategies
There are many robot designs that you can use to successfully accomplish your missions. Strategies for designing robots include considerations for how the robot will interact with the missions to be accomplished. For example, does the robot need to turn, or turn often, or not turn at all? Does the robot need to follow or look for lines? Does the robot need to pick up things, push things, gather things?
Caster Wheels
Tricycles are very stable vehicles used by young children. The design of the tricycle helps to ensure that all three wheels are touching the ground at all times. Robots can use this design as well. Common three wheeled robot designs use two wheels for driving the robot and a third wheel that swivels freely (known as the "[caster wheel]l"). One of the advantages of using a caster wheel with two drive wheels is that it is possible to create a robot that has a zero turning radius (i.e., able to spin in place). One of the disadvantages of designs that use Caster Wheels is that the robot may be difficult to control.
Type of Steering
Robots with 4 wheels can be designed with steering systems (such as the Ackerman steering). One disadvantage of these designs is that there is often a minimal turning radius which may be a foot or more in diameter. Aligning with walls is also more challenging with 4-wheeled robots that use steering mechanisms.
Skid Steering
With Skid Steering, the robot utilizes one or more "skids" to help keep the robot upright. The skids "drag" along the ground--usually behind the robot. A disadvantage of Skid Steering is the inconsistencies that may exist between the surfaces that the robot needs to drive over. For example, your practice mat for FLL competitions may have more or less friction than the mats used for tournaments. These differences in friction may alter the performance of the robot requiring more (or less) power to turn the robot.
Bumpers?
Bumpers are used to help align the robot to the walls. The bumper should be flat without wires or other robot parts protruding or extending over the bumper.
Motor Matching
The motors used in Lego robotics are simple 9 volt DC motors. They have built in rotation sensors to enable a processor to control the motor as a "servo motor". The motor itself has no sophisticated control system. It's just an electric DC motor. If you give the motor power, it will turn. The rate at which it turns is determined by the amount of power you give it. The processor (robot's brain) determines how much electricity to give to the motor.
What difference does it make if one motor spins faster than another at the same voltage?
Please note that not every single motor will turn at exactly the same rate if given a certain amount of power. The motors used in Lego robotics are small and have small parts inside. These motors have been mass produced over a period spanning a decade or more. If you have a team competing in a robotics league, you probably have several motors. Some teams may even have dozens of motors at their disposal. These motors may have been manufactured on different days in different factories over different years. Some motors may have been used more or less than others. So, in summary, there may be minor differences in the performance of the motors. Some motors may spin faster or slower at any specific voltage. You're probably asking "
What difference does it make if one motor spins faster than another at the same voltage? So what?" The problem comes in that it usually takes two motors to move the robot. Most robot designs place one motor on the left side and another motor on the right side of the robot. Now, if the two motors are spinning at different rates for the same voltage (power level) it becomes necessary to make some adjustments if you want the robot to drive in a somewhat straight line.
The software you use to control the robot probably has a few functions or commands for controlling two motors simultaneously. In this way, the robot is able to synchronize one motor so that it matches the rotation of the other motor. This is useful in getting the robot to travel in a straight line. In NXT-G the "
Move" block synchronizes two or more motors. In RobotC, you can synchronize motors using the
nSyncedMotors and
nSyncedTurnRatio variables.
What the software does when synchronizing motors is to adjust the power to one of the motors so that it will stay in "synch" with the other motor. One motor will be treated as the "master" and the other motor is the "slave" motor. The power level to the "slave" motor will be regularly checked and adjusted so that the rotations will match what is needed according to the action you are trying to perform. So, for example, if you are trying to drive straight, then the robot will adjust the power level of the "slave" motor so that the motor rotates at the same speed as the "master" motor. In NXT-G you do not have to specify which is the master and which is the slave. All you have to do in NXT-G is specify the power level and the turning characteristics (left, right, none). In RobotC, you can specify which motor is the "master" and which is the "slave" by specifying the order in which the motors are listed for the function.
It's nice having software that will synchronize the motors for you. But please note that this software is not perfect. Please note that "synchronization" is a "process" performed by the robot. The motors are not physically connected to one another. Rather, sensors in the motor send information to the processor which then uses that information in algorithms to determine what power to give to each motor. The motors are not synchronized instantaneously. It takes a few milliseconds or microseconds to work through the algorithms needed to perform the synchronization process.
The process of synchronizing the motors needs to be performed each time a move command is given to the robot. Though the robot doesn't mind doing the process, you should be aware that any errors created through the process will also occur each time the move command is given. You might be wondering: "What errors? Aren't computers supposed to process commands without errors?". It's true that computers do not make errors when performing simple mathematical problems. However, this computer is controlling a device in the physical world that is subject to physical conditions such as temperature, humidity, friction, mass, inertia, gear backlash, and other physical characteristics. The robot and the motor are not working in a virtual world. They are working in the "real" world. This means that when the robot applies power to the motor, it may take a few milliseconds for the motor to get up to the desired speed. When synchronizing two motors, the "slave" motor may not have reached the desired speed in time and may need more power. Or, may be the "slave" motor jumped ahead of the "master" motor and now needs to be throttled back to maintain synchronization. These adjustments to the power are what result in possible errors (misalignment) of the robot.
The "crazy" thing about all of this is that there is a definite and pronounced (i.e. visible) effect that the battery has on the synchronization process. At high batter levels (recently charged), the "slave" motor will have more power faster and thus may respond more aggressively in the synchronization process. A weak battery (after using the robot for a while) will result in a less aggressive "slave" motor. The differences in batter voltage will result in definite changes in the performance of the robot. The robot will turn more or less, go further or not as far depending on battery level. You might have noticed this. At the beginning of a practice session, the program works just great. But by the end of the practice, the program needs adjusted to fix small errors in turns and moves. Once the battery is re-charged, the program then fails to work at the start of the next practice because it was "tweaked" from the adjustments needed to get it to work with a weaker battery level.
Motor Matching
To help the robot more easily perform the synchronization, some teams will attempt to measure the performance characteristics of each motor and try to "match" the motors that have similar characteristics. For example, if motor A turns 10 rotations in 4 seconds at power level 30 and motor B turns 11 rotations in 4 seconds at power level 30, then may be these two motors do not perform closely enough to be "matched" and placed on the same robot.
Some teams will go through an elaborate process to measure the performance of each motor and mark them in a way so that similar motors can be matched for the same robot.
Web Resources for Matching Motors
TechBrick (
http://www.techbrick.com/Lego/TechBrick/TechTips/NXTCalibration/index.htm)
Offers a description with images of the motor matching process. The process is fairly simple. Just place an axle between two motors (shown below). Push the motors flat against a surface. Run a program that has a simple "Move" block for each motor. Do not use the synchronized "Motor" block. Use the unsynchronized Motor blocks. Turn for a certain speed and time. Do not set the duration to degrees. Set the duration to a specified "Time". At the end of the specified time, are the motors still flat on the surface? Or, has one turned a little more than the other?
Problem with Motor Matching
Some coaches feel that "motor matching" encourages team members to spend time solving the wrong problem. The problem isn't that the motors perform slightly differently and therefore need to be matched before placed on a robot. It's true that motors might perform differently and that matching them will help the software in its algorithmic process. However, there are still many variables that can affect the performance of the robot. So you will still have to address problems with the robot's odometry (ability to move and keep track of its movements). The robot has software to attempt to make the necessary adjustments for differences between motors. The real problem is in how to design your program and strategy so that it will work perfectly even if the robot has encountered a few minor errors in the synchronization process. This is what team members should spend their time working on.
Even if the motors are perfectly matched, the program might still fail under changing battery conditions. Don't spend your time matching motors when all that is needed is to develop more robust programs.
Mission Control Strategies
Sensors
Environmental Conditions
Simple Missions vs Hard Missions
Time Management
