Speed Sensor

[Nitroxextreme]

I'm looking for some kind of sensor that can measure speed/velocity of a moving wheel. I considered encoders/gear teeth sensors but I'm out of interrupts.


Ideally I'd like to find something that would return an analog value based on the speed...

Any ideas?


Thanks

[Mike]

What about using a seperate board, and have it communicate to the IFI board via a serial connection?

[Shu Song]

You can use accelerometers, which you have to integrate to get the speed. I don't know if they are included in the kit this year, but they were definitely in the kit last year.

[Chriszuma]

What about using a seperate board, and have it communicate to the IFI board via a serial connection?
Well then you would lose your serial port. What you could do is get one of those fancy 360-degree position sensors (they run about $50 though), because it outputs analog voltages, looping back to zero when it gets to the top of its range. You could take the difference in position to get the speed. You would have to gear it down substantially though, since it would be mighty hard to detect limit resets when it's going half a turn every loop.

[Tom Bottiglieri]

There is a 2 axis accelerometer in the kit this year.

An accelerometer will give you an accurate velocity reading (after a simple integration. Remember: position, velocity, and acceleration are all interconnected) for the robot as a system. If you are checking overall velocity, this will be fine. If you need each individual wheel's velocity, it may not be the best solution.

If you can tell me, how are you out of interrupts? There's good ol' interrupts 1 and 2 (as configured in Kevin's encoder code), but you can also set your code to run interrupts off pins 3-6. Do you really have 6 interrupt driven sensors? I'd be afraid of interrupt overflow before I ever worried about not having enough hardware interrupts to work with. See the interrupt source at www.kevin.org/frc for more info.


Well then you would lose your serial port. What you could do is get one of those fancy 360-degree position sensors (they run about $50 though),
There is also a gyro included in the kit this year.

[Alan Anderson]

I'm looking for some kind of sensor that can measure speed/velocity of a moving wheel. I considered encoders/gear teeth sensors but I'm out of interrupts.
There are six general I/O pins on the Robot Controller which can cause interrupts. We used three encoders on our robot last year, and I know exactly how to modify the interrupt code to handle more. Just how many interrupting devices are you using, anyway?

[fowlerm]

Well then you would lose your serial port.
There are two serial ports on the controller that you can use - the TTL level port (USART2) and the RS232 program port (USART1).

[Alan Anderson]

There are two serial ports on the controller that you can use - the TTL level port (USART2) and the RS232 program port (USART1).
The TTL port is likely to be unavailable for such a custom circuit, since it's the preferred way to communicate with the CMUcam.

[kaszeta]

I considered encoders/gear teeth sensors but I'm out of interrupts.

Out of interrupts? How many are you using? Coming from someone whose team had 4 interrupts running at once last year, be very, very, careful.

[lupjohn]

I'm looking for some kind of sensor that can measure speed/velocity of a moving wheel. I considered encoders/gear teeth sensors but I'm out of interrupts.


Ideally I'd like to find something that would return an analog value based on the speed...

Any ideas?


Thanks

Hi all;
the dual axis accelerometer has an X and Y output that are analog voltage that is proportional to acceration. There for the input to the controller would use 2 analog ports and need to have a support routine relating the Analog to digital output to acceleration of the robot in the X and Y directions. This could be done with integer math only and could even be written as inline assembler code for optimal speed. Just a few thots from an old mentor. LRU.

[Kevin Watson]

If you can tell me, how are you out of interrupts? There's good ol' interrupts 1 and 2 (as configured in Kevin's encoder code...Actually, I've got updated encoder code that can use any of the interrupts. The first two are just like last year's (optimized for velocity control) plus the upper four are optimized for position control, but can also be used for velocity control. I'll have it up after I finish some documentation.

-Kevin

[Kingofl337]

The Kit includes a accelerometer, a gyro, and two gear tooth sensors. You can use EasyC and drag and drop them into the code. There is also information in the help file on getting them going.

[SoftwareBug2.0]

What about using a seperate board, and have it communicate to the IFI board via a serial connection?
Do as Mike says, except have the external processor output a pwm signal which you then have another circuit change into analog, since that's what you're hoping for.

[intellec7]

A tachometer (an AC motor in reverse) gives voltage and frequency output porportional to the velocity of its shaft, but these arn't very precise at low speeds.

I have heard many different things in regards to using a microcontroller other that the RC, is it allowed? Can I forexample use a PIC or someother microcontroller to handle low level stuff?

[Tatsu]

I think so, the rules dont specifically write about how we cant make a PIC. as long as its outputs go to the RC, they're okay..

We're going to use 2 low-g high precision Motorolla accelerometers (1 axis) run it through a kalman filter on a PIC or STAMP or whatever and output an analog signal..

be sure to eliminate every possible source of bias before your integrator (PIC in this case) or else your v measurements will be vastly off

[Workaphobia]

Actually, I've got updated encoder code that can use any of the interrupts. The first two are just like last year's (optimized for velocity control) plus the upper four are optimized for position control, but can also be used for velocity control. I'll have it up after I finish some documentation.

-Kevin

Will that work with any encoder, or only quadrature encoders?

[Kevin Watson]

Will that work with any encoder, or only quadrature encoders?Quadrature only.

-Kevin

[BradAMiller]

Will that work with any encoder, or only quadrature encoders?

The code will probably work with any single input encoder provided that you tell it that the B Channel is an input that is always high or low (disconnected or jumpered). The code will read what it thinks is the B channel and it will see the same value, making it always count in the same direction.

For example, in the interrupt service routine for EasyC you connect the A channel to pins 1-6. When the interrupt on the A channel happens, the code reads the B channel to decide whether to count up or down. It doesn't matter if the B channel is actually connected to an encoder - it only sets the count direction.

If you decide to use EasyC it has built-in encoders that only look at a single input.

Brad

[Kevin Watson]

The code will probably work with any single input encoder provided that you tell it that the B Channel is an input that is always high or low (disconnected or jumpered). The code will read what it thinks is the B channel and it will see the same value, making it always count in the same direction.

For example, in the interrupt service routine for EasyC you connect the A channel to pins 1-6. When the interrupt on the A channel happens, the code reads the B channel to decide whether to count up or down. It doesn't matter if the B channel is actually connected to an encoder - it only sets the count direction.

If you decide to use EasyC it has built-in encoders that only look at a single input.

BradActually, the new software I described, and Jon had a question about, does require a quadrature input.

-Kevin

[Workaphobia]

The code will probably work with any single input encoder provided that you tell it that the B Channel is an input that is always high or low (disconnected or jumpered). The code will read what it thinks is the B channel and it will see the same value, making it always count in the same direction.

That's what I thought initially, but then I figured that if the phase B input is constant, then every change in the phase A input will be interpretted as the encoder moving back and forth repeatedly, instead of always forward.

If you decide to use EasyC it has built-in encoders that only look at a single input.

That's good to hear. I graduated last year and had no chance to check out the new tools for this year, so I still think of these problems in terms of hand-typed code.

[6600gt]

This maybe a little of topic but can a PIC output a analog value directly?
It would make life a lot simpler.

[Matt Krass]

You can use onboard PWMs or software/timer generated PWMs to create a make shift ADC. Simply feed the output to a small capacitor connected to an analog input with a resister between the capacitor and the analog input that leads to ground.

Take a look at this: http://www.piclist.com/techref/scenix/lib/io/osi1/pwm/pwm_vp.htm

[Tatsu]

Just use a DAC. big deal.
DACs arnt very hard to make, you could even just take a reference esign from TI or AD