View unanswered posts | View active topics It is currently Tue Sep 02, 2014 4:07 am






Reply to topic  [ 14 posts ] 
Moter Encoder not reaching target 
Author Message
Rookie

Joined: Mon Aug 13, 2007 11:18 pm
Posts: 4
Post Moter Encoder not reaching target
Hello I am working on a project that drives on the rubber tank tracks. I have noticed that possibly because of greater friction that the robot never quite reaches the target. In the debug screen it gets close, but when it gets close it slows down so that it does not overshoot, but does not seem to have enough power to reach the mark. I am using a PID update interval of 10 and have sync motors. I was thinking about trying to code in a margin of error or doing a time lapse check to make a decision if the encoder value is not getting greater, but thought I had better check to see if someone else has a smarter ideas.
So does any body have any smarter ideas?

Thanks


Mon Aug 13, 2007 11:29 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
I ran into that problem for quite awhile and finally figured out a way to stop it.

When controlling motors, "motor[motorA]=50" means run the motors at half power and it maintains that power output. What you have to do is set up each motor to have speed regulation with the following code:

nMotorPIDSpeedCtrl[motorA] = mtrSpeedReg;

What happens now is when you say "motor[motorA]=50" it is going to put the motor at half speed and adjust the power levels to maintain this speed. This is great for motors when they undergo strain, they will up or lower the power level to maintain that speed.

When using the encoder target, the NXT ajusts the power depending on the distance but when it gets close, it dosent give enough power. With mtrSpeedReg on, it will ramp up the power to just enough to get you right on target.

Also one last thing to make sure is when using the motor encoder target, make sure the motors are in brake mode and not float, that way the motor can brake right on the encoder target and not coast past, that can cause some problems too.

Good luck, I hope this helps you out B-)

Scott

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Wed Aug 15, 2007 3:02 am
Profile WWW
Rookie

Joined: Mon Aug 13, 2007 11:18 pm
Posts: 4
Post 
Thanks starwarslegokid

I have tried that, I think
I have inserted it in a cut down version of the motor_synchronisation demo code, but still the same result it gets to about 859. Is it friction? Can it be overcome? Will it get worse if the project gets heavier?



task main()
{
const int nMoveSize = 900;
const int nSpeed = 50;


bFloatDuringInactiveMotorPWM = false;

nMotorEncoder[motorA] = 0;
nMotorEncoderTarget[motorA] = 0;

nMotorPIDSpeedCtrl[motorA] = mtrSpeedReg;
nMotorPIDSpeedCtrl[motorC] = mtrSpeedReg;

nSyncedMotors = synchAC;
nSyncedTurnRatio = 100;
nPidUpdateInterval = 10;



nMotorEncoderTarget[motorA] = nMoveSize;
motor[motorA] = nSpeed;

while (nMotorRunState[motorA] != runStateIdle)
{}

wait1Msec(20);

}


Wed Aug 15, 2007 5:55 am
Profile
Rookie

Joined: Mon Aug 13, 2007 11:18 pm
Posts: 4
Post 
Hi again
Look this is a bit crazy, but when I change the nMoveSize to -900 it overshoots by about the same amount as it is short when nMoveSize it a positive value. And it does not matter whether you go forward or backwards

What is going on here? Is this something wrong with my brick or a bug in the code?

I would love a suggestion, but i can carry on in the meantime not needing %100 accuracy for now atleast I can now reach the target.


Wed Aug 15, 2007 6:37 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
I played around with the default code and I see whats happening. It appears when the motor gets near the target, the motor state goes from idle to hold, and when in hold it disables the speed control to slow the motor down onto the target. In your case this is bad because its not ramping up your power, I don't know if this is a bug or the way the software was designed.

I made some code for you to try out, its simple but it will do the same thing. If you run this code and cant get to your target, your motors are undergoing allot of strain and you will have to change your design or gear down the motors. Let me know what you think

task main()
{

int target;
int c;
target=900;

nMotorEncoder[motorA] = 0;
nMotorPIDSpeedCtrl[motorA] = mtrSpeedReg;

nMotorEncoder[motorC] = 0;
nMotorPIDSpeedCtrl[motorC] = mtrSpeedReg;


while (true)
{

nxtDisplayTextLine(2,"Encoder A=%d", nMotorEncoder[motorA]);
nxtDisplayTextLine(3,"Encoder C=%d", nMotorEncoder[motorC]);
nxtDisplayTextLine(4,"C=%d", c);

motor[motorA] = (target-nMotorEncoder[motorA]);
motor[motorC] = (target-nMotorEncoder[motorC]);

// make shure it stays on target before ending //
if (nMotorEncoder[motorA]==target && nMotorEncoder[motorC]==target)
{
c=c+1;
if (c>50)
{
PlayTone(2000, 10);
wait1Msec(2000);
return;
}
}
else
{
c=0;
}
}
}

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Sun Aug 19, 2007 12:28 am
Profile WWW
Rookie

Joined: Mon Aug 13, 2007 11:18 pm
Posts: 4
Post 
Thanks for that
I have tried that it get there sometimes but sometimes it is getting stuck at 898 or 899 in about equal distributions. Very interesting alternative and a lot more accurate.
Unfortunately I need to reach the target and better to make compensation for overshooting rather than never getting there (that is not to say I am very grateful for your contribution).

"I played around with the default code and I see whats happening. It appears when the motor gets near the target, the motor state goes from idle to hold, and when in hold it disables the speed control to slow the motor down onto the target. In your case this is bad because its not ramping up your power, I don't know if this is a bug or the way the software was designed. " Were you getting the same result of it overshooting when you changed the target to a negative value?

I am still very intrigued by the fact that it falls short by about 20-30 when target is positive and overshoots by 20-30 when negative. I am beginning to think that maybe I did something in the view>preferences menu when setting the the power off option to never. I should really have done a hard reset before writing the above sentence which I will do and post if successful otherwise still experiencing same issue.

Thanks


Thu Aug 23, 2007 4:22 am
Profile
Rookie

Joined: Mon Sep 17, 2007 5:31 am
Posts: 28
Location: Indonesia
Post thanks to starwarslego kids...
something i didnot understand...
why you add const int???but you can run without const???
and what the function of this componen???
nMotorPIDSpeedctrl ????
thank you...


Tue Sep 18, 2007 1:34 am
Profile YIM
Rookie

Joined: Mon Sep 17, 2007 5:31 am
Posts: 28
Location: Indonesia
Post hi
to : starwarslegokid
I already run your program,but the variabel of c not + from 1 until 50 but move to 50 at the first time....
how can it be???

to:everyone
I want ask again
1.after I use powerOff() (is that right that powerOff()is to turn off the nxt?),can I use alive() ??? how to write the program???? if not possible,so what the function of alive()????is that use after the nxt is sleep???

2.what the different between nAvgBatteryLevel and nImmediateBatteryLevel ???

3.And the last what the function of bNoPowerDownOnACAdaptor ???
is that can it know our batteray is still charge or not???

if can,please give me an simple example for easy to understand...
thanks you very much...


Wed Sep 19, 2007 12:47 am
Profile YIM
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
Whoops, it looks like I need to add c=0; at the begining so it knows where to start.

nImmediateBatteryLevel: gives you an one imediate reading of the battery level. Motors can cause voltage drops and spikes, good for watching this happen.

nAvgBatteryLevel: takes multiple readings and averages them together. Gives you a more reliable reading of the battery level, but takes longer.

bNoPowerDownOnACAdaptor: If you have the nxt rechargable battery, you can connect it to a battery charger while inside the NXT. if you set bNoPowerDownOnACAdaptor = true, the robot will not turn off automaticaly if the rechargable battery is at full charge.

ill get back to you on power off and alive, i need to look on my home computer

If you have any more specific questions on programing, dont be afraid to post it under NXT programing. I check the forum often so i can get back to you. B-)
viewforum.php?f=1

Scott

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Thu Sep 20, 2007 12:18 pm
Profile WWW
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
alive()
The NXT has a timer that will automatically turn off the NXT off after a set time period. I you use alive, it will reset the counter to 0, delaying the turn off. Doing this repeatedly will keep the NXT on.

Once the NXT is off, you have to manually turn it back on

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Fri Sep 21, 2007 4:16 pm
Profile WWW
Rookie

Joined: Mon Sep 17, 2007 5:31 am
Posts: 28
Location: Indonesia
Post thanks...
how about the example program???
like that???
task main()
{
while ( true );
{
wait1Msec(1000);
powerOff();
wait1Msec(1000);
alive();
}
}
is that true or not???


Sat Sep 22, 2007 2:14 am
Profile YIM
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
Deleted Post

I made a mistake :-)

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Last edited by starwarslegokid on Mon Sep 24, 2007 1:57 am, edited 2 times in total.



Sun Sep 23, 2007 3:28 pm
Profile WWW
Rookie

Joined: Mon Sep 17, 2007 5:31 am
Posts: 28
Location: Indonesia
Post hi...
i try it and then...
1.after I run it,it just done...
2.after done going to first menu...
3.after 1 sec,it turnoff automatically...
4.never alive...
how can it be???
i don't understand...
do you already try it???
or my program still wrong???
thanks..


Sun Sep 23, 2007 10:56 pm
Profile YIM
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
ahh it looks like i made a mistake copying my code over, and i got a totally different result.

Your code is correct, ignore my previous post. Alive doesn't prevent a called shutoff.

Sorry for the scare :-)

Scott

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Mon Sep 24, 2007 1:54 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 14 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


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

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.