RPM Sensing Options

[schenkin]

Hello all. I am trying to figure out a way to measure rpms, eventually this will lead to an approximate muzzle velocity of our ball shooter.

So far, I've come up with a couple of possible sollutions:

1. Use a seperate controller (probably our edubot), to count up encoder interupts, poll this data at a set interval from the main controller (probably over a few digital in/outs), and from this get rotations/time. The main problem with this is that I haven't gotten the encoder code to run properly on the edubot. If someone could help with this, i'll post the problems i'm having.

2. Use an analog device which outputs speed as variable voltage. So far i've been playing with just using a standard DC motor to generate a current, and feeding that back into the controller, but I have no idea what the sensed voltage range is in the A/D controllers, and I very much doubt that the output is going to be even close to linear. Is there an actuall sensor that will do this for me?

Any help would be appreciated! So far this forum has served me well!

[Greg Marra]

That's a really interesting idea. I had never thought of using the EDUbot controller as an auxillery processor on the main RC. Innovative thinking!

Good luck!

[Manoel]

That's a really interesting idea. I had never thought of using the EDUbot controller as an auxillery processor on the main RC. Innovative thinking!

Good luck!

It's a pretty good idea, indeed, but rule R49 states that electronic components must cost under 200 bucks, and the EDU has a retail price of $ 249. Coincidental, isn't it? :ahh:


<R49> The total cost of all non-Kit items may not exceed $3,500.00 USD. No individual COTS electronic
component shall have a value of over $200.00 USD. No individual non-electronic item shall have a value of
over $400.00. The total cost of components purchased in bulk may exceed $400.00 USD as long as the cost of
an individual component does not exceed $400.00. The following items are EXCLUDED from the total cost...
calculation:

[BorisTheBlade]

that and you have to keep in mind that it would have to be powered off the main battery not the normal battery that the edu bot controller uses.

[Jared Russell]

Why not use an encoder/gear-tooth sensor/banner sensor feeding into the main RC?

Using interrupts is easy as long as your counts don't get too rapid. We're using just one piece of reflective tape and a banner sensor for our flywheel.

[BrianBSL]

Not cheap, but within the "controls" budget limit. Does all the encoder work for you (just set the scaler up right, the right voltage range, and read the analog value) http://www.usdigital.com/products/etach2/

But unless you have some major reason for not dealing with the encoders on the RC, thats the most reasonable way.

[b_mallerd]

Wouldn't it be possible to just use the gear tooth counter along with the timer? So you know how many gear teeth pass for however many seconds...and then you have the speed that the wheel is turning in gears/min...all you have to do is count how many gears there are and use that as a reference to figure out RPM.

[Matt Krass]

Hello all. I am trying to figure out a way to measure rpms, eventually this will lead to an approximate muzzle velocity of our ball shooter.

So far, I've come up with a couple of possible sollutions:

1. Use a seperate controller (probably our edubot), to count up encoder interupts, poll this data at a set interval from the main controller (probably over a few digital in/outs), and from this get rotations/time. The main problem with this is that I haven't gotten the encoder code to run properly on the edubot. If someone could help with this, i'll post the problems i'm having.

2. Use an analog device which outputs speed as variable voltage. So far i've been playing with just using a standard DC motor to generate a current, and feeding that back into the controller, but I have no idea what the sensed voltage range is in the A/D controllers, and I very much doubt that the output is going to be even close to linear. Is there an actuall sensor that will do this for me?

Any help would be appreciated! So far this forum has served me well!


We tried both, ended up with #2 for simplicity, its not perfectly linear but its pretty close, it worked out well for us

[schenkin]

Sorry I didn't reply earlier, I thought I would get an email notification when new messages where posted. And I did, but only for the first one.

Anyhow, so long to the Edubot idea. I thought about using optical encoders like we are using to keep the robot going straight, but i'm not sure I understand how to get speed from that. Obviously you can get distance from the encoders, and then divide it by time, but how do I know how long it has been? I can't just keep track of loops can I? Wouldn't the interupts change the timing? Is there an internal clock I can tap into?

A gear tooth sensor would work too, but I had the same concerns.

That standalone tachometer is pretty awsome, and would save us alot of trouble, but I'd rather not spend that kind of money if I can avoid it.

--Sam

[BrianBSL]

Sorry I didn't reply earlier, I thought I would get an email notification when new messages where posted. And I did, but only for the first one.

Anyhow, so long to the Edubot idea. I thought about using optical encoders like we are using to keep the robot going straight, but i'm not sure I understand how to get speed from that. Obviously you can get distance from the encoders, and then divide it by time, but how do I know how long it has been? I can't just keep track of loops can I? Wouldn't the interupts change the timing? Is there an internal clock I can tap into?

A gear tooth sensor would work too, but I had the same concerns.

That standalone tachometer is pretty awsome, and would save us alot of trouble, but I'd rather not spend that kind of money if I can avoid it.

--Sam

The PIC has timer interrupts that you can setup to make a pretty reliable counter.

[schenkin]

How exactly would I utilize that? Keep in mind that I thought myself to program the robot, which means I have little to know experience with what lies below the surface of the code. I do ok, but little of what I write is pretty or sophisticated.

[Kevin Sevcik]

Use digital in 14. It corresponds to pin RC0 on the PIC, which coincidentally is the clock for Timer 1/3 when they are used as (a)synchonous counters. Look at the PIC reference on www.kevin.org/frc (http://www.kevin.org/frc/) Specifically, look at the TIMER section and the PORTC section. Note that I haven't tried this yet, but this is how I'm planning on doing things. You can get pretty good resolution and update rates since the max frequency is 50kHz, and you just sample it and clear it every PID loop, so you don't have to deal with the variable update rates of some other methods. Best of all, no interrupts needed.

[Joohoo]

The interrupt file in http://kevin.org/frc/2005/ has many timers in it I used the file to do the same thing the only thing that you need to do is to get the speed from more than one gear tooth so it is more accurate. you need to make a circular array or something like that :confused: I'm still trying to understand it (circular array) myself(thank god for mentors)