GTS Counting

[gnirts]

I have installed the GTS sensors on both sides of the robot. The documentation indicates that the pulse from the sensor is a 39 microsecond wide rising pulse for a clockwise rotation and an 83 microsecond wide pulse for a counter-clockwise rotation. How would one differentiate between the widths of the pulses in the interrupt handler?

I have a feeling that I need to set the interrupt to fire and high and low transitions, and use a timer to monitor the length of the pulse. However I have no idea how to set that up on the PIC. Is there any documentation or example code I should be aware of? Can a timer even measure in microseconds?

Thanks in advance,
Robinson

[gnirts]

No one knows?

I am getting really worried, we are shipping soon....

[Alan Anderson]

I didn't bother trying to find a way to make the RC detect the direction. The code already knows which way the motors are being commanded to turn, so it can count up or down appropriately for each sensor pulse.

[teh_r4v3]

A timer can go down to 100ns if you want I believe... but at that point the interrupts will be taking over way too many processor cycles. Plus you would have to deal with lots of overflows if incrementing a variable if you keep on the timer at all times. Our team also decided to skip the direction sensing. For us, it wasn't worth it. Although the robot has already been shipped, if you want to tinker around in the fix-it window or at your first competition, I would recommend taking a look at the timer documentation in the PIC18 reference manual to see your prescaler options.

[dcbrown]

I can "guess" at the wheel direction except when we are coasting down or we're at idle (PWM=127). I wanted to know if we were being pushed off our spot when idle so what I was planning on doing was polling the GTS interrupt bit looking for a high value and doing a count while it was high. I'd leave the GTS interrupt routine on so the count would be missing the GTS ISR compute time. If the 50us interrupt latency is correct in Easy C, then either I'll never see the GTS bit going one way or have a really small count for that direction but should see a much larger part of the pulse (the 2x part) when going the other way. This was put in the housekeeping loop of the code - we tightly poll for about 1ms then come out for the other housekeeping portions and then right back in again. The code is just looking for "hints" and once it has seen 10 pulses it stops looking until the next 25ms sample time.

I never got to try the code out before the 'bot shipped though so I don't know if that would work or not.

DCBrown

[The Lucas]

If you really want to try to time the interrupt, Kevin timed the rising and falling edge of a beacon tracker interrupt in his navigate.zip code. It is old 2004 code and indented for a different purpose, but you could use it for a guideline if you are so daring.

I agree with Alan, just use motor direction. Thats what I do for the GTS on our aiming mechanism. Good Luck!

[Greg Ross]

Originally Posted by The Lucas

I agree with Alan, just use motor direction. Thats what I do for the GTS on our aiming mechanism. Good Luck!

I would REALLY like to KNOW for sure that the wheels are turning the way I told them to. This could be very important in a PID control scheme. For instance, when testing some PID code for controlled turning using the gyro, instead of the robot turning in place, I have witnessed it backing up! The reason being that the drill motor on the "backing up" side was turning its "natural" direction, and overpowering the motor on the other side turning its "anti-natural" direction. Had I had feedback from a gear tooth sensor telling me which direction the wheel was turning, I could have compensated.

Maybe when I get one of those round TUIT thingies, I will make a gear tooth sensor version of Kevin's encoder code that will get the rotation direction right.

[Mark McLeod]

Originally Posted by GW (Greg) Ross

Maybe when I get one of those round TUIT thingies, I will make a gear tooth sensor version of Kevin's encoder code that will get the rotation direction right.

If you can just mass produce some of those round TUIT thingies I'd be a customer . I need a lot.

[Astronouth7303]

If you really need direction, I recomend going with quadrature.

The pulses off the GTS are so miniscule that by the time I got to the bottom of my ISR, the pulse had already passed. Just camera or high-priority interrupts could screw up timing. This is using PIC C, not EasyC.

[gnirts]

Originally Posted by Astronouth7303

If you really need direction, I recommend going with quadrature.

The position of the axle makes using a GTS much more practical. Right now for getting direction I use a voting system with the two factors being the PWM output of that motor and the accelerometers. But I don't trust those accels, as by default any code that Kevin would write is better than mine. (I pretty much just ported the gyro code and integrate to speed.)

The pulses off the GTS are so minuscule that by the time I got to the bottom of my ISR, the pulse had already passed. Just camera or high-priority interrupts could screw up timing.

Wow! I had no idea that pulses would be that short compared to ISR run time length. I was going to time my ISR using a digital out and a oscilloscope before we shipped but didn't get a chance. How many ASM instructions do you go through from the beginning of the service routine to the end of the GTS handler? You could try putting the test for the GTS interrupt as the first one, although others still firing would have an effect I guess (though I thought that interrupts would usually just wait for others of the same priority to finish and then fire right after them). Would triggering an interrupt on both rising and falling edges of a pulse and recording the amount of time in between work? One pulse is about twice as long as the other.

This is using PIC C, not EasyC.

Of course. I don't trust EasyAnything.

[Greg Ross]

Originally Posted by Astronouth7303

If you really need direction, I recomend going with quadrature.

The pulses off the GTS are so miniscule that by the time I got to the bottom of my ISR, the pulse had already passed. Just camera or high-priority interrupts could screw up timing. This is using PIC C, not EasyC.

Do you mind sharing your code? I haven't run the numbers myself, but it SEEMS like you should be able to differentiate a forward vs. reverse pulse. I'm wondering if you weren't trying to do too much in your interrupt routine.

Originally Posted by teh_r4v3

A timer can go down to 100ns if you want I believe... but at that point the interrupts will be taking over way too many processor cycles.

I believe the 100ns number means that the timer counter increments that fast, but you have control over how many times the counter increments before it interrupts. I THINK that in your gear tooth sensor ISR, you should be able to set the timer to go off in 60 μs, and then in your timer ISR, check the gear tooth sensor line again. So then, all you really need to do in your gear tooth sensor ISR is to increment your gear tooth counter, set your timer, and return. Then in your timer ISR, if the line is still high, decrement your counter by 2. (At this point you might need to turn off your timer, so you don't get keep getting interrupted EVERY 60 μs.)

Note: If necessary, you can optimize your ISR code to add and subtract the VALUE of the I/O line, rather than TESTING the state, and conditionally subtracting.

[Mike Bortfeldt]

After getting one of these, I was looking for a fun project to do, and decided to try to determine the difference in the GTS pulse widths between a clockwise and counter-clockwise rotation. The end result is that I have a small PIC processor receive the GTS pulse and indicate a clockwise rotation by changing the state of an output pin. A counterclockwise pulse changes the state of a second output pin.
These signals could then be connected to any two of the RC's digital inputs 3-6, and the interrupt on change capability of the RC can utilized as desired. Our robot doesn't use gear tooth sensors, but if a team or two going to Atlanta would like to play around with one of these, then let me know and I'll bring a couple. All you would need to connect them up to an existing GTS is a couple additional PWM cables. A little bench testing with a GTS seems to indicate that it works fine, but I have not tried it on an actual robot.

Mike