May 1, 2006

The MOVE block

In the NXT programming language, you use BLOCKS to program your bot. I'm going to cover many of them, but I figured I'd start with a rather important one... the MOVE block.







This is a fragment of the LEGO NXT software desktop... the MOVE block is represented by the 2 gears. You drag this block onto the desktop to begin configuring it.








After dropping it on the desktop, it becomes this green block. These blocks are nice in that they do show some visual information on the block. I can look at this one and tell that it has defaulted to controlling Motors C and B. I can also tell that is defaults to have the motors move "forward" - I use the word in quotes because it does depend on how you have the motors configured. If you turn the motors 180 degrees, the terms "forward" and "backward" switch. Likewise, if you say that "forward" is "motor turns counter-clockwise" be careful. Flip the motor vertically 180 degrees or spin it horizontally 180 degrees, and the controls change I can visually see how much power has been applied (the middle orange icon that looks like a little gauge) and the last orange icon on the bottom right tells me if the motors is configured to turn a specific number of degrees, for an unlimited time, for a specified number of seconds, or (in this case) a specific number of rotations.


This image shows the configurable controls for the MOVE block. You can see where you can select Motors A, B, and/or C to control. Direction is next (up arrow is forward, down arrow is backward, other symbol is stop). Steering isn't my favorite control because I just don't use it that often. You can configure a bot to perform a slow or fast turn in the direction of the motors you select (B or C) by dragging the little controller left or right. The power allows you to set the speed of the motor (how fast it turns) and the Duration drop-down menu allows you to select "Unlimited" (spins until a condition stops it or YOU do) or define a number (in the other field - it shows a 1 in the image) to correspond to "Degrees", "Rotations", or "Seconds." Finally, you can choose to "Brake" or "Coast"... braking stops the bot's motor(s) immediately but takes power to do so... coasting saves on battery power, but doesn't give you good stopping control.

More block coverage to come...

13 comments:

Dave Brown said...

I'm interested in using Mindstorms NXT to build a rudimentary Logo turtle for use in a elementary school program.

I notice you mentioned that the motor can be turned a specific number of degrees and then braked to stop.

Can you or anyone else comment on this motor's stepping accuracy? If, for example, you attached a long beam to it (preferably off to one side so it is unevenly loaded) and stepped it 1 degree at a time 360 times (with braking), would the beam end up where it started?

If the resolution of the degree stepping is less precise, that's not a big concern. I'm more interested in whether a NXT-based turtle has a chance of winding up where it started if it's told something like "repeat 12 [forward 100 right 30]".

Jim Kelly said...

Dave,

As soon as I can test this, I'll do it for you... it might be a few days or so... things are going to be busy for the next few days.

Jim

Jake Covert said...

Is this program RoboLAB 2.9, or the brand new program included?

Is it based on LabVIEW?

- Jake Covert
jakecovert [at] gmail [dot] com

Anonymous said...

I'm testing this now on my NXT set: 360 1-deg steps with pauses inbetween to see roughly where it will come out... It's within about 5 degrees. Another test is to ask the motor to do a reasonable number of back-and-forth moves to see if it keeps "homing" to the same location. I asked the motor to repeat a forward rotation of 120°, followed by a brief pause, and the a reverse 120° rotation and pause. After 50 repetitions of this... the motor is again back to the "start" position to better accuracy than I can eyeball it (I attached a 19-unit long beam to the motor for this). Does that sound good?

How about this added tidbit: every now and then during that last test, I pushed my thumb against the turning axle to increase the friction... a few times I even just held the axle while the motor "fought" me to try to turn it. It did not alter the accuray (i.e., regardless of load or even completely blocking the motor for a moment, the rotations were 120°, exactly as requested).

As to making a NXT-based turtle, it's certainly possible, but you have to ask how fast you want it to move, and what accuracy you really need. For instance, there is some play (a couple of degees perhaps) in the motor, so even though the measurement accuracy is around 1 degree, it does not imply perfection under all circumstances. And of course if a wheel skids, all the encoder accuracy in the world won't help you.

--
Brian Davis

Brian Davis said...

The program is not RoboLAB 2.9, but a new programming environment (also built on LabVIEW by NI). It's hard (for me) to compare them, but there are clearly some similarities, but a lot of difference as well. For instance, you get to use named variables, but you have less control over seperate "tasks".

--
Brian Davis

Brian Davis said...

Dave Brown wrote:

> Can you or anyone else comment on this
> motor's stepping accuracy?

I tried the test you suggested on my NXT (like Jim, I'm in the MDP), asking the motor to turn 1 degree 360 times, with a slight pause inbetween. The result was a 360° cumulative rotation, to within an accuracy of a couple of degrees. Considering that the mechanical slop in the geartrain is on the order of a degree or more, I think this is acceptable.

Another test I tried out was to have the motor turn 120° forward, pause, and then turn 120° in reverse and pause, and to repeat this process 50 times. The end result was the motor returning to within one degree of the inital position. Perhaps more impressive, I did not let the motor run in a stress-free" environment: during that test, I pushed my thumb against the axle to vary the load on the motor, and even stoped the rotation completely several times, blocking the motor from turning. As soon as the motor was released, it dutifully completed its rotation and continued. Personally, I'm fairly impressed by this :).

> I'm more interested in whether a
> NXT-based turtle has a chance of
> winding up where it started if it's
> told something like "repeat 12
> [forward 100 right 30]"

I think that depends on how you design the turtle, and what you mean by "where it started". After all, there's a lot of things going on besides the motor accuracy in such an application. For instance, the tires can not skid at all, or change their radius of curvature at all, you have to reduce mechanical slop as much as possible, etc.

--
Brian Davis

Daniel Wittenaar said...

I'm glad to hear that the accuracy of the new motors is very good.

I hope to test this as soon as possible when my set is comming in somewhere in august or oktober as what they are saying right now to me from Shop@Home...

I'm really looking forward to take this into testing and find my ways to make it as good as possible..

Brian Davis said...

Well here's another fun thing on the motors - after building my first NXTbot, I just programmed it to go straight, using a Move block. I noticed it seemed to adjust to keep its path straight... so I kicked it (gently!), and watched it correct back to a straight line. This was so much fun to watch I ended up spending the next ten minutes just gently nudging the moving 'bot slightly, just to watch it correct.

The precision isn't perfect... but it's worlds better than with the RCX, even with the rotation sensors. And for a kid, it's virtually automatic.

--
Brian Davis

Anonymous said...

I programmed a simple move block to move forwarded unlimited number of times. It moves about 1 rotation of the wheels and stops. Any help would be greatly appreciated. Tried calling the Lego NXT support line with no avail.

George

Anonymous said...

Anyone had trouble with a Move block being skipped in a reasonably long program? We've got a program that exacutes a bunch of move forward, turn, play a tone, move backward, turn, play another tone, etc. sequences. After eight or ten movements, the program seems to skip a move block. If we add another block before the skipped block and run again, it will skip the block before the one that was being skipped earlier. If we pull out a block, it will skip the block after the one that was being skipped earlier. We've got some rather complicated blocks in the chain (myBlocks that ramp the motors to minimize skidding and slipping, etc.) But it doesn't seem to be the myBlocks that are being skipped. I've been searching around, but haven't yet found anything that seems to relate to our problem.

Jim Kelly said...

I would suggest you post this problem on a recent post... not many people go back and review these older posts and I'd hate for your problem to be overlooked.

Jim

Joseph Cumberbatch said...

This is great stuff! I am being introduced to this technology today as a result of trying to help my daughter "think through" some home work she is doing. It has been of immense benefit to me. You've made my day. Keep up the great work you are doing! I really appreciate it.

Joseph Cumberbatch said...

I learnt a lot from these posts. Thanks guys. Keep up the great work you are doing!

Related Posts Plugin for WordPress, Blogger...