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.
Nov
26th

Motor Tip #2

Author: fllCoach | Files under Programming

Smooth Motor Movement

You may have noticed that if you put two motor blocks together with a certain duration of degrees, the robot does kind of a stutter-step. It pauses for a split second between blocks. There is a way around this to produce smooth motor movement.

First, let’s do it the obvious way. Create a new program and add two motor blocks, each moving forward at 50% power for 200 degrees. It should look like this:

If you run this program, the robot will pause in between the execution of each motor block.

The way around this is to use a motor structure much like what is described in my Go Until… post. What you want to do is run the motor with an unlimited duration with a Wait Until rotation sensor block to terminate it. If you put two of these structures together, one after the other, the robot won’t pause in between.

So let’s take the example above and create a new program with what I just described. It should look like this:

To duplicate the first example, this new program would need to go 400 total degrees. The Wait Until rotation sensor blocks count from the beginning of the program. So in the first Wait Until block, you would put a condition of “> 200.”

But in the second, you need to put a condition of “> 400.”

If you have a large program with a lot of Wait Until blocks, counting the cumulative rotation degrees could get harrowing. You can make it easier on yourself by adding a Rotation Sensor Reset block before you start your motor at unlimited duration. Then you only have to count the degrees for the one movement. The Rotation Sensor Reset block can be found in the Sensor section of the Mindstorm interface:

Add the Reset block in front of the second Motor Unlimited block:

Then click the Reset radio button and set the degrees to 0:

You can now put “> 200” in the second Wait Until Rotation Sensor block and your robot will go a total of 400 degrees.

Notice on the second and third programs, I put a motor stop block at the end. Remember that the motor unlimited block will coast after the Wait Until block condition is met unless you put on the brakes. Your robot will continue on its path and you’ll wonder why your program isn’t working the way you programmed it. My team learned that lesson several times this year. Get in the habit of always putting a motor stop block after your last Wait Until block and you won’t have that problem.

Smooth transitions can come in handy in various situations. I can think of at least two off the top of my head, but won’t bother to describe them in this post. I’m sure you’ll encounter your own cases where you’ll find them useful.


9 responses. Wanna say something?

  1. Pebblekeper - Angie
    Nov 26, 2010 at 11:22:11
    #1

    YEAH!!! What a timely post! We have been trying to program just going over to the small bone – but it keeps skipping. The boys keep saying our computer is broken . . . .We’ve tried degrees, rotations, seconds – it still is not consistent. Go Until – Rotation Sensor – turn until – Rotation Sensor – makes Sense!!! I can’t wait to have the boys play with this little tip. So timely – as they had worked a couple of hours on it this week – that they will see the sensor tip in action as a solution!!! Thanks. (Can you tell I’m excited?)

  2. fllCoach
    Nov 26, 2010 at 16:16:44
    #2

    Glad I could help. This post has been in my queue for a while since I digressed into tournament mode.

    If you ever run into other difficulties, please let me know and I’ll see if I can help. I’m starting to run out of tips.

  3. Gremlin
    Nov 28, 2010 at 21:37:30
    #3

    Cuiousity: the crew I coach doesn’t use the wait block as outlined in the post. They poll the rotation sensor inside a loop using the comparison logic in that block to terminate the loop. Anybody know if one way or the other executes with better temporal precision? I might guess the “wait” would, but the kids have never had a problem with using a polling loop. On the other hand, in some environments “wait” relies on system interrupts and has worse timing than brute force polling. The loop also allows things like checking multiple conditions, as in: start drive, then loop until robot light sensor finds dark OR we’ve gone farther than reasonable (Oops–missed the dark spot or line) in which case take corrective action. This sometimes helps if you have a mission with the speed cranked up to a somewhat risky level; most of the time it works just fine, but sometimes you miss and have to back up. It’s place to teach kids to think about risk and reward.

    On a related note: is there a significant time overhead for using a MyBlock? For example, in most standard programming languages there is a (small) overhead in manipulating the stack and cpu registers in order to make a function call — all hidden from the programmer unless you look at what’s going on at the assembly language level. I’ve never tried to measure this in NXT-G. Might be a good off-season “goofing around with the NXT” assignment for the team — unless someone else already knows the answer!

  4. fllCoach
    Nov 29, 2010 at 08:42:57
    #4

    I’m not qualified to answer either of these questions. Perhaps Dean or another experienced NXT programmer can.

    However, I do know of coaches that have done what you have. That is, put a motor block within a loop and watch the rotation sensor while also putting in a time-based contingency. I’ve haven’t tried it yet, but they use it in competition, so I’m sure it works. This was a simple explanation of how to make smooth motor movements. I would guess a motor unlimited block within a loop would work the same.

    As for the overhead of a myBlock, I doubt it’s significant. In fact, I believe it will help in the size of your program when loading it in your NXT brick. I’ve heard that one program with multiple missions fits better than missions in separate programs. So your memory overhead is probably more of a concern than any execution overhead.

  5. Dean Hystad
    Nov 30, 2010 at 17:01:06
    #5

    The wait block is a convenience routine that does nothing different than a sensor read/compare inside a loop. Personally I think teams should avoid using the Wait blocks as their lack of data plugs really limits their usefulness.

    I’ve run a few tests timing My Blocks and can’t see any difference in execution speed. The scheduler in LabVIEW is unlike anything you’ve ever seen (being data flow oriented), and issues like rolling and unrolling the stack don’t come into play.

  6. Tim David
    Dec 10, 2010 at 08:52:07
    #6

    Thanks for the tip! One small clarification – the code in the example uses Move blocks, not Motor blocks. In NXT-G, Motor blocks can only control one motor at a time.

  7. Darren
    Jan 5, 2013 at 10:10:37
    #7

    Gremlin: I don’t know the answer to your question, but MyBlocks do save memory space on the NXT.

2 Trackback(s)

  1. Dec 8, 2010: Motor Tip #3 | Lego League Coaching
  2. Aug 25, 2012: How to Use this Site | Lego League Coaching

Post a Comment