banner I have been a Lego League coach since 2007. This year, I wanted to document the season to give rookie coaches a resource to help them through to competition. The process can be intense, but it can also be a lot of fun for you and your team.

I hope to cover enough through my posts, but if I leave anything out, please feel free to leave a comment, or contact me.

Motor Tip #1

Author: fllCoach | Files under Programming

[Update: Due to the comments left by several experienced coaches, the tip as originally written has been revised in the comments below. Please be sure to read all the comments in their entirety to understand this tip fully.]

When you are programming your robot, the motor block will be your most commonly used piece. The interface gives you several choices on how long to run your robot. They are: rotations, degrees, and seconds. Here is your first tip:

NEVER use seconds

Running a motor for X number of seconds may sound like a good idea, but your robot will start out going the distance you expect and then start going a shorter and shorter distance over time. See if you can figure out why before reading on to the next paragraph.

When you set your robot to run, say, 5 seconds, it may travel a distance of 10 inches in your first run. But the more often you run the robot, you’ll find that the robot will only travel 9 inches in those 5 seconds, then 8, then less. The reason is battery power.

As your robot is running its battery out, less and less power is going to the motors, so the motor travels less rotations in a fixed amount of time.

Let’s also look at rotations as a measurement. Rotations are better than seconds, but rotations are generally measured in whole numbers. While you can put 1.5 or 2.2 rotations into the duration field, there is a better and more accurate way to set the distance.

What you want to do is use degrees for your distance measurement. This will be the most consistent way of setting distance to travel. You won’t ever need to get down to the single degree since getting to the closest 5 degrees is usually good enough. But at least you’ll be dealing with whole numbers instead of decimals. Make sure you program your robot using the right landmarks and you’ll find that using degrees will get you where you want to go most of the time.

8 responses. Wanna say something?

  1. Dean Hystad
    Oct 6, 2010 at 14:49:36

    I pretty much disagree in one way or another with all the advice in this tip.

    Never use Seconds
    Normally using time to control your robot is bad because it is not consistent, but sometimes it is the best choice. It all depends on what the robot is doing.

    Whenever you intentionally drive your robot into an obstacle (a field model, one of the walls) you should use a timed duration. If you use rotations or degrees for duration and the motor gets stuck, your program will sit forever waiting for the Move block to complete.

    As for controlling arms, grabbers, etc… My team always uses time. Stalling when moving a robot arm is very common. Start using time instead of degrees and you’ll almost never suffer a touch penalty because the robot arm is “stuck”.

    Rotations vs Degrees
    Using degrees to specify duration is no more accurate than using rotations, but it is more consistant. The motor duration is in degrees even if you tell it to use rotations. The move and motor block convert the rotations to degrees during the compile.

    If you use the data plugs to set the duration you have to use degrees. The duration data plug on the Move and Motor blocks always assumes the duration is in degrees. If you set the duration to rotations, and the number coming across the wire is 1, the motor moves 1 degree, not 1 rotation.

    The rotation sensor reports motor position using degrees. Start using degrees now and you won’t have to change everything later when you start using sensors and data wires.

  2. fllCoach
    Oct 7, 2010 at 11:16:00

    While I see your point about getting stuck, I would still rather use degrees. The reason being is that if I get stuck, it’s probably because I didn’t start my robot in the right place. I am willing to take the 5 point penalty to pick up the robot and try to run the mission again with the robot in the right starting spot.

    However, if my robot isn’t going the right distances because I set my duration to seconds and the battery is running low, I can’t charge the battery during the run. All my missions will be off and there is nothing I can do about it. I might not even get the right amount of charge between runs at the competition.

    Certainly, if you make sure your battery is charged enough, this won’t be a problem. But I would rather eliminate that variable and not worry about it during the competition.

  3. Alex Kolotov
    Oct 7, 2010 at 06:40:20

    You are both right. I think that compilation of both views will cover completely the topic.

  4. Dean Hystad
    Oct 7, 2010 at 19:22:01

    Hey fllCoach, read more carefully next time. Time and degrees or rotation duration both have their place. Time is sometimes the correct choice, and reasons are given why and when.

    I don’t see how you can perform some of the missions without intentionally driving the robot into a field model. When doing so I suggest using time for the duration. My team often squares up to walls or runs into models as part of the robot navigation. If you aren’t doing this you are missing some tools in your FLL toolbox.

  5. fllCoach
    Oct 7, 2010 at 23:20:27

    I never said duration using seconds didn’t have its place. I did say I saw your point. I just prefer not to use it and explained why.

    I agree that you should use the walls during the missions. But we use the touch sensor to know when to stop.

  6. Stan Khaykin
    Oct 12, 2010 at 13:54:40

    I agree with Dean Hystad, and politely disagree with fllCoach – mainly for saying “NEVER use seconds”. We use odometry to get to most places on the field, but switch to timed moves in order to complete certain missions. The timed moves are usually extremely small (half a second or so), and are designed specifically to avoid stalling the motors indefinitely (the motor may still stall, but only until the timed block completes execution). This works well even with diverse battery levels, since most navigation is by odometry, not by time. Also, since the timed block usually results in a temporary motor stall (by design), the exact position of the robot is known at the completion of the block.

  7. fllCoach
    Oct 13, 2010 at 09:01:23

    That makes sense to me. The battery definitely wouldn’t interfere with such a short timed duration. So the revised tip would be:

    “Use seconds only for short bursts to make sure you know where your robot is, not for an extended period of time to travel to a particular spot.”

    Thanx for the comments, Dean and Stan. I’m here to learn as much as I am here to teach.

1 Trackback(s)

  1. Oct 31, 2010: Go Until… | Lego League Coaching

Post a Comment