while (nMotorRunState[motorE] != runStateIdle || nMotorRunState[motorD] != runStateIdle) //while the encoder wheel turns one revolution { // This condition waits for motors D & E to come to an idle position. Both motors stop // and then jumps out of the loop }

motor[motorE] = 0; //turn both motors off motor[motorD] = 0;

wait1Msec(3000); // wait 3 seconds to see feedback on the debugger screens // open the "NXT Devices" window to see the distance the encoder spins. // the robot will come to a stop at the nMotorEncoderTarget position.}

Mon Nov 22, 2010 2:36 am

l0jec

Expert

Joined: Mon Oct 27, 2008 9:59 pmPosts: 139

Re: nMotorEncoderTarget[] not working..

Can you post the pragmas as well?

The most obvious things to check is that your wiring matches your configuration and that you do not have any hardware problems. I assume you have the encoders installed correctly and the encoder wires plugged into the motor controller?

The encoder's seem to be working, ie: we wrote a little code to watch the encoder values as we pushed the bot around and the values go up and down as expected

--marcel

Tue Nov 23, 2010 5:34 pm

MHTS

Guru

Joined: Sun Nov 15, 2009 5:46 amPosts: 1512

Re: nMotorEncoderTarget[] not working..

I usually don't use the built-in PID control so I am not 100% sure but if you are trying to use EncoderTaget, I would think it is using built-in PID control. If that's the case, you should enable PID in your pragma. I could be wrong though.

Wed Nov 24, 2010 6:25 am

l0jec

Expert

Joined: Mon Oct 27, 2008 9:59 pmPosts: 139

Re: nMotorEncoderTarget[] not working..

MHTS, I agree; it doesn't looks like PID is enabled in the pragmas.

nanoplane, can you see the encoder values go up past 1440 on both motors in the debug window when you run the program? I would suggest enabling the PID checkbox in the motor setup as MHTS pointed out.

Also, maybe just me, but I would add a small wait inside the while loop, perhaps 50ms or so.... This suggestion isn't related to the current issue; but is more a matter of best practice.

I never trust runStateIdle. If for some reason the motor is not stopping (e.g. PID decided to approach the target too slowly and PID doesn't give it enough power to reach the target), then your loop will never exit. Normally, I would tune the Kp of PID to give it more power to reach the target, but I am not sure how to do that with built-in PID. I would try the following instead. But since you said both encoders past 1440, the following won't really help you anyway.

our team is having that same problem, but we have tried everything including the sample programs and we seem to have no solution

Wed Feb 02, 2011 11:21 pm

jorge_the_awesome

Rookie

Joined: Sun Dec 05, 2010 11:58 amPosts: 28

Re: nMotorEncoderTarget[] not working..

The nMotorEncoderTarget functionality is also inherently flawed. You can't alter the constants, which is annoying, but primarily, when the motor gets close to the encoder target, it switches from speed based PID to encoder based PID (I think-correct me if I'm wrong). If the stress gets high, and the motor cannot turn, once the encoder based PID is activated, the motors become much less responsive to speed changes. When driving, this is a problem, because the robot can stop before it gets to the target.

Also, this isn't your problem, but the motors glitch when the sign changes, either by crossing zero or looping past 32767. And the encoder based PID doesn't activate for negative targets, so you get different results based on which direction you drive in.

The encoder ticks are not integers, they are longs, so it's not a problem until you go beyond 2147483648 encoder ticks, which, with standard NXT 2.0 wheels will have driven your little robot about 80.5 kilometres. I highly doubt you will ever have this problem.

The encoder ticks are in longs, yes.But the nMotorEncoderTarget is in pseudo-intergers.It will accept values greater than 32767, but it becomes very inaccurate.We tested it, and the behavior significantly changed between a target of 32767 and 32768.

We are having similar problems. One thing that does seem to help. If we play with motor speed we can get better results; that is a speed of 70 seems to work lots, lots better than speeds below this. A particular problem we are having is that the motor sometime does not jump out of the loop - It is basically at the target. If I touch the wheel driven by the motor ever so slightly, the program goes ahead and ends properly. Another thing I noticed in the debugger is that runstateidle does not seem to be reached; even when the program completes, runstate still seems to be running - is this correct?

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum