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?

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.

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?

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.

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

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

suwandi_wieming

Rookie

Joined: Mon Sep 17, 2007 5:31 amPosts: 28Location: Indonesia

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

suwandi_wieming

Rookie

Joined: Mon Sep 17, 2007 5:31 amPosts: 28Location: Indonesia

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...

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

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.

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

Sun Sep 23, 2007 3:28 pm

suwandi_wieming

Rookie

Joined: Mon Sep 17, 2007 5:31 amPosts: 28Location: Indonesia

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..

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