How much precision can be expected out of these motors?, Robot crashes and scares cat instead of coming back. Options

[Black Puma]

Just got the Mindstorms NXT kit today and built the first project (tribot?).

I've been trying to get the thing to just go in a rectangle - out five seconds, turn 90°, straight, turn 90° ... etc. ... coming back to the original place.

If I go to "view" and "motor rotation", it seems to be reasonable. If I turn a wheel 360°, the screen is within 10-15°. It seems that the rotation sensors are functional.

But when the motors are moving the machine, it's waaaaay off. The programmed 90° turns end up being more like 45° and the robot ends up doing a semicircle and crashing under the kitchen table. So much for a rectangle.

I've experimented with number of rotations ("2 rotations" in place is about 380-400°), time, etc. I've had it come to a complete stop with one second pause between turns, and it's tough to judge rotation.

I don't expect a great degree of either precision or accuracy with this kit, but I'd hope that a 90° turn would be within say 20° instead of 45+.

Is this huge discrepancy normal?

If so, I can live with it I guess. I just don't know how much "give" I should expect, or how to improve the accuracy.

Thanks for any information.

[Robolab 2.9]

Hi, welcome!

So this sentence: "If I turn a wheel 360°, the screen is within 10-15°. It seems that the rotation sensors are functional." I don't understand. You are saying, if you turn a single wheel 360 degrees, that the screen displays 10-15? That shouldn't be correct - if the wheel is turned 360 degress, the encoder is too, so the screen should also say 360.

Also: "The programmed 90° turns end up being more like 45°" Did your program say something like, rotate BC in opposite directions for 90 degrees? If so, then 45 degrees is actually pretty accurate. When you define degrees, it is not the angle that the robot turns; rather, it is the amount each wheel turns. Here is an explanation: http://thenxtstep.blogspot.com/2006/10/rea...bmission-2.html

Also, if you could upload your program, that would help as well.

Good luck,

Richard

[Black Puma]

Hi Richard, Thank you so much for the welcome and the information.

So this sentence: … I don't understand.

I'm sorry that was not clear. I meant that the result was within 10-15° of the expected answer. I was just grabbing the wheel and turning with my hand, which is quite inaccurate, so I thought it a reasonable result at the time. I experimented more carefully and was pleased to discover that the tolerance is actually much better, within my measurement error of a couple degrees.

it is the amount each wheel turns

Thanks for pointing this out. Yes, I did set the motion block to rotate BC in opposite directions 90°.

I made the faulty assumption that because the NXT kit made by LEGO &c. that the software would be similarly simplistic. Thank you for the link. I immediately saw why my assumption was impossible in actuality. I'm continually being pleasantly surprised at how capable the kit really is.

With some experimentation I was able to modify the program to travel a rectangular circuit of 20 or 25 feet and stop within inches of the start point. That was very gratifying.

[mato92]

Hi, if you want a really straight move, you can buy Hitechnic Gyro sensor - with this sensor, you can make many more than only balancing robots. I don't have this sensor yet, but I'm going to have one.

[Brian Davis]

I immediately saw why my assumption was impossible in actuality.

Although if it's any help, we've seen that question several times in different forums. The fact that it's impossible for the native FW to do that (because it doesn't know the size of the wheels you've put on, or how far apart they are, or if the vehicle is skid-steered, steered like a car, or something else entirely) is perhaps surprisingly not something that occurs to everyone.

With some experimentation I was able to modify the program to travel a rectangular circuit of 20 or 25 feet and stop within inches of the start point. That was very gratifying.

Yes, it is. Actually, it's even gratifying for me to hear about you doing it (again, you might be surprised how often this issue comes up).

--
Brian Davis

[Robolab 2.9]

With some experimentation I was able to modify the program to travel a rectangular circuit of 20 or 25 feet and stop within inches of the start point. That was very gratifying.

That's great, congratulations!

I made the faulty assumption that because the NXT kit made by LEGO &c. that the software would be similarly simplistic.

The software is relatively simple compared to *what's out there*, but can still be otherwise sometimes And have you seen some of the crazy stuff that's been built with LEGO before?

I immediately saw why my assumption was impossible in actuality.

Heh, it's not completely impossible. As Brian mentioned, you'd just need to be able to input some parameters - width of robot base, size of wheels, etc. But for now, what you're doing is great.

Hope to see many more things from you,

Richard

[Black Puma]

Richard, Brian:

Thanks for the feedback and encouragement.

I ran into one of those situations that make you want to beat your head against the wall. I learned to program on a microcontroller 30 years ago, then moved onto big machines. So, I'm used to seeing stuff that drives you crazy.

As I mentioned, last night the robot made the circuit successfully. I did it a half-dozen times or so. I logged off the computer, took the robot to my room for the night so the kids wouldn't monkey with it.

Late this morning I brought the robot down, logged into the computer, and ran the same program again… fail. The 90° turns were no longer 90°.

I spent the day diagnosing why since AFAIK nothing changed. (Well something did, but I'm not aware of any different conditions.)

I ruled out batteries. Same behaviour with new alkalines, fresh-charged NiMHs, the previous batteries (alkalines with most their charge still). Checked voltages with multi-meter.

I wrote a series of tiny programs to test things and rule things out.

What I found is that if I set the steering full left or full left, one motor turns more than the other. (See "Motor Test 03" and "Motor Test 04".)

It's completely symmetrical.

• If I set the steering slider full left, the "B" motor turns too far.
• If I set the steering slider full right, the "C" motor turns too far.

If I swap the cables, the effect still holds; the motor attached to the problem port turns too far.
It happens both under load and without load.

For me, this is completely reproducible.

It seems to be the software is out of whack. I looked for a calibration feature, but couldn't find anything.

It's only on the turns. If I simply make the robot move forwards and backwards, there is no problem.

- - - - -

I've done further experiments rotating both motors independently in opposite directions, and the robot turns as expected. Turning with one wheel also works as expected. (See Motor Test 05-07).

Anyhow, learning the quirks with any new system always turns up unexpected behaviours.

[Robolab 2.9]

Ah! This is that random problem that drives you crazy sometimes... let me guess: it is rotating the correct amount, then one motor jumps and turns it too far right? This is because some random feedback drove the synch software crazy, and it is trying to "correct" it while it's only making it worse. Because of this, it is advised one usually uses two move blocks in parallel to spin in place, two motor blocks consecutively to spin in place, or use one motor to turn the robot.

Hopefully that helps some.

Richard

[Black Puma]

Ah! This is that random problem that drives you crazy sometimes...

Thanks for the information. It's helpful --- and nice to know that in this case it's not just that I'm crazy.

it is advised one usually uses two move blocks in parallel

A follow-up question, if I may.

Is there a way to split the program flow beam for parallel action, then rejoin them into a single program flow beam?

When I'm done figuring out turning, I have my work cut out for me writing up my notes and publishing them on my blog.

[Robolab 2.9]

Of course, as many questions as you'd like.

Hmm, I don't think there is any need to rejoin it. You can end it just leaving it there, after the last block. Then whenever you need another parallel section, just draw another beam out from there.

Richard

[Black Puma]

I don't think there is any need to rejoin it. You can end it just leaving it there, after the last block. Then whenever you need another parallel section, just draw another beam out from there.

Ahhh... yes, yes. That makes sense. I played with this a bit and find it very useful.


I have to apologize that I didn't articulate my question well. I was making assumptions, and then asked for an answer based on my assumption. But... you answered a related question that came up very soon.

My question should have been, "Is there a preferred way to synchronize two paths of execution?". The branched path of execution is perfect if both motors are to run for the same duration. I was thinking if two paths of execution were to require different amounts of time to execute and were not known ahead of time. (I have to deal with this frequently on other projects.)

I can split a beam into two paths of execution, but it appears that I cannot rejoin them. I was assuming that would imply waiting for both paths of execution to complete.

I can use alternatives, such as using a temporary variable to indicate whether the branched task has completed, then busy wait for that side task. (See attached image.)

Attached File(s)

 task_wait.jpg ( 67.41k ) Number of downloads: 17

 

[Brian Davis]

Is there a preferred way to synchronize two paths of execution?

"Preferred" is in the eye of the beholder, but there are some ways that are perhaps easier than others. I use one based on one of the underlying rules (perhaps I should say The underlying rule) of NXT-G:

A block or structure will not execute until all the datawires supplying it are valid.

So if at the end of a sequence, you wire out something as simple as a logical "true" on a datawire to a logic block on the other sequence, that second sequence will be held up at that block until the datawire has a valid value on it. You can actually use this to synchronize two parallel sequences fairly tightly, in both directions. Here's an example that shows another unusual way to do this, using a Loop or Switch as the "blocking" item in a sequence:



Loops and Sequences follow that primary rule in spades: they will not begin to execute until all the wires feeding into them (or across their boundary) are valid. So in the above example, the upper empty Loop doesn't execute until the datawire feeding it inside is valid (carries either a true or false), and the moment it does become valid the Loop immediately exits (becasue the exit condition is satisfied). Doing this on both branches makes both sequence wait at that point until the partner is also there. This is a little better than using an actual NXT-G variable (essentially, the wires are variables - they're just "write once, read many times" local variables).

--
Brian Davis

[Black Puma]

That's brilliant by being both simple and elegant.


Brian, Richard:

Thanks again for taking the time to explain the way that the hardware and software works. That's "teach a man to fish" type of stuff.

[synapticbackfire]

That's brilliant by being both simple and elegant.

Welcome to the World of Brian Davis, to some of us he is like a Celeberaty.

Well, to a guy who is a Computer monkey who uses his Physics Degree to wipe his tears about not working "In the Feild" he sure is impressive.

[Black Puma]

LOL.

As a computer scientist I can appreciate mathematical beauty when it pops up. Each programming environment that I've worked in has one or more unique features that allow one to gracefully address certain problem domains. Even ugly languages that are easy to make fun of (like PHP) have their beautiful moments.

[Brian Davis]

Even ugly languages that are easy to make fun of... have their beautiful moments.

True... but that doesn't mean they are always easy to find. One of the things I like about NXT-G is it really forces me to think "differently" about how to accomplish some things. That's fun, and a growth experience, and a challenge. Sometimes, what I really dislike about NXT-G is that it forces me to do things differently, and that can be a challenge. Note the symmetry.

--
Brian "sometimes it's about the journey, sometimes just the destination" Davis

[Black Puma]

True... but that doesn't mean they are always easy to find.

Absolutely. I didn't mean to imply that one runs across them every day. The rarity of those moments contributes to the delight I experience when encountering them.

NXT-G ... really forces me to think "differently" about how to accomplish some things. That's fun, and a growth experience, and a challenge. Sometimes, what I really dislike about NXT-G is that it forces me to do things differently, and that can be a challenge. Note the symmetry.

LOL. Life can be like that.

[Black Puma]

I just posted part one of my notes summarizing this thread here.