ooo I had some problems with that darn tooth-sensor.
Can anyone please give some examples to deal with it?
A real normal example.
I am really desprate
You need to post more info about what you have tried so we know where to start with advice. We found that the default encoder code from Kevinâs site was enough to get it working so we could see tooth count interrupts.
You need to post more info about what you have tried so we know where to start with advice. We found that the default encoder code from Kevinâs site was enough to get it working so we could see tooth count interrupts.
Remember to pay attention to the Forum section that this is posted in: âeasyC for FRCâ
ooo I had some problems with that darn tooth-sensor.
Can anyone please give some examples to deal with it?
A real normal example.
I am really desprate
Have you tried the test code that comes with EasyC? Go to Open Project and navigate to where the test code is and open the GEARTOOTHTEST.ECP project. On my computer it is here:
C:\Program Files\Intelitek\easyC for FRC\Projects\Test Code\GEARTOOTHTEST.ECP
Also make sure you download and install the newest version of EasyC to make sure the test code is up to date (look here). There were some problems with the earlier test code because the print statement wasnât formatted correctly, so the tooth count was being output in the bajillions. Iâm not sure if it has been fixed yet, because our gear tooth counters are in the crate. But this will help you with testing it out. Remember the tooth count is output to a long variable, so the output must be formatted for a long variable. Also look in the Help section of EasyC. Look for gear tooth counter and it will tell you how to use it.
Good luck!
Sorry I really didnât give any details.
The sensor itself works fine.
I need an example code which uses the gear-tooth sensor as a distance measure
My idea:
when the distance is X (found by the gear-tooth) the drive function stops the cart, the geear-tooth sensor âcalibratesâ to zero again and turns(I know how to do that)
I tried some varients how to do that but the gear tooth sensor didnât âcalibrateâ to zero and the cart didnât turn.
If someone think of an idea like this and can give an example how he did it Iâll be glad
Aha! Well thatâs a different story and pretty ez to do. Thereâs a variety of ways to implement it but a simple way is to first figure out how many counts your sensor returns per inch (or foot or cm or whatever units you are using) then use this:
void driveTo ( double distance )
{
double d = 0;
int speed = 0;
d = GetGTSensor ( GTS_DIG_IO ) ;
d = d/ GEAR_COUNT_PER_INCH ;
while ( d < distance )
{
if ( (distance - d) < 12 )
{
speed = 127 + (distance - d) ;
}
else
{
speed = 175 ;
}
drivePID ( 127, speed ) ;
d = GetGTSensor ( GTS_DIG_IO ) ;
d = d/ GEAR_COUNT_PER_INCH ;
}
PresetGTSensor ( GTS_DIG_IO , 0 ) ;
Drive ( 127, 0 ) ;
}
Notes: This hasnât really been tested yet so there is no guarantee. It is very simplified, so accuracy probably isnât that great. However, as you wanted, notice the PresetGTSensor line, which resets your GTS back to zero. Just drag the Gear Tooth Sensor over and use the preset option. The input is distance that you want to travel (in inches) it drives an arbitrary speed (I chose 175) until the distance left is < 12 inches then slows down proportional to the distance left. drivePID is a function we have that aids in control by keeping the robot driving straight. So this function stays locked up in the while loop until the distance traveled (d) is equal to or greater than the desired distance (distance). The Drive (127,0) call is an EasyC function to stop the robot when the distance is achieved. (Again not tested, so if you use this, feedback would be appreciated!
I understood the idea of the whole thing and it is very helpful. ammm in addition, 127,0 in drive doesnâ stop the robot.
You are forggeting that the drive doesnât use values of pwm.
to stop the robot I wiil write 0,0 (speed, direction)
but that one was great.
I will test it tomorrow.
Can you or anyone else give another varient?
TNX ahead.
edit:
d = GetGTSensor ( GTS_DIG_IO ) ;
d = d/ GEAR_COUNT_PER_INCH ;
d equales both of those lines?
Thanks for pointing out the âDriveâ error. I forgot that we modified the code so that 127 is âstop.â That was way back near the beginning! But you are correct, the unaltered Drive would be Drive(0,0) equals stop.
Yes d equals both of those lines. The first line gets the absolute gear tooth count (which isnât distance), then the second line CHANGES d to equal the number of inches travelled. If you find any other problems be sure to post, because remember others are looking too, and we donât want to lead anyone astray!
Yeah got it.
But doesnât the EasyC wonât allow to do that.
I mean let the âdâ to equale both things, but Iâll try that today.
Tnx anyway.
Actually EasyC (which is just a specialized GUI for âCâ) does allow it, because I copied it directly from our EasyC code. All programming languages (that I am aware of) allow this type of variable manipulation. You should keep in mind that while assignments may LOOK like algebra, they really arenât. So statements like d = d/45 are perfectly valid, because you are assigning to d the value of the expression d/45. Also another misconception you might have is that all of the lines of code are evaluated simultaneously, which is not correct. Programs are always executed line by line. Which means that
d = GetGTSensor ( GTS_DIG_IO ) ;
is executed first THEN:
d = d/ GEAR_COUNT_PER_INCH ;
is executed. d DOES NOT equal both simultaneously, but it does equal the last value assigned to it. If you are still uncomfortable with this, you can easily change it like this:
long temp_d;
temp_d = GetGTSensor ( GTS_DIG_IO ) ;
d = temp_d/ GEAR_COUNT_PER_INCH ;
OR you can simply put it in one line:
d = GetGTSensor ( GTS_DIG_IO )/ GEAR_COUNT_PER_INCH;
Every single one of those results in the same output
Yeah Yeah I got it tnx man. Works fine!@
Very good to hear! A bad thing about this particular code, though, is that your robot canât do anything but drive until it reaches itâs goal. If you need to evaluate other sensor data you should add the function calls to the while loop.