Disc Lauching Velocity

[mikegrundvig]

This is a great open source package to track movement of objects and such:

http://www.cabrillo.edu/~dbrown/tracker/

We used it last year with good success. It's very easy to use and works great.

-Mike

[Ether]

Originally Posted by compwiztobe

We powered a 360mm circumference pulley off of a CIM at 12V, and measured about 5200rpm under no load (the tach actually pegged out, so we measured at 3V, 6V, and 9V and extrapolated).

questions:

1) could you post the tach values at 3, 6, & 9 please

2) was this measurement done with the belt in place and tensioned?

We had about 12in of contact with the belt.

What did you use for backing support for the belt? i.e. Steel, Aluminum, Teflon, etc etc

[Aren Siekmeier]

3V - 800rpm
6V - 2300rpm
9V - 3500rpm
with belt in place, tight, and backed by delrin

[Fastnate]

Check out this spreadsheet that I made to roughly calculate the resulting linear and angular velocity of a disc based on the shooter wheel size and speed.

Let me know if you have any questions about it.

[Ether]

Originally Posted by compwiztobe

3V - 800rpm
6V - 2300rpm
9V - 3500rpm

That extrapolates to more like 4400 rpm, not 5200. No?

[Aren Siekmeier]

Originally Posted by Ether

That extrapolates to 4400 rpm, not 5200. No?

A linear extrapolation gives me 4900 rpm (using excel's questionable fit, not sure if its lsq or what), but we guessed it should be following a quadratic trend (since we are increasing the voltage, but keeping the load the same), so that put us (forcing an intercept of 0) at 5200. The fits would be better if we included the origin as a data point (since it does, in fact, not spin, with no voltage applied...). In any case, the numbers are close enough for our purposes - we are happy to be within 20% right now (if this were for my lab, however, it would be a different story).

[Ether]

Originally Posted by Fastnate

Check out this spreadsheet that I made to roughly calculate the resulting linear and angular velocity of a disc based on the shooter wheel size and speed.

Let me know if you have any questions about it.

Is anybody using a shooter with a wheel on each side like that?

[Ether]

Originally Posted by compwiztobe

A linear extrapolation gives me 4900 rpm (using excel's questionable fit, not sure if its lsq or what), but we guessed it should be following a quadratic trend (since we are increasing the voltage, but keeping the load the same), so that put us (forcing an intercept of 0) at 5200. The fits would be better if we included the origin as a data point (since it does, in fact, not spin, with no voltage applied...). In any case, the numbers are close enough for our purposes - we are happy to be within 20% right now (if this were for my lab, however, it would be a different story).

Not to annoy you, but I think this is worth discussing because there are some things to be learned here.

I was trying to help you understand the mystery behind your earlier comment:

Originally Posted by compwiztobe

These numbers are lower than we had previously been estimating, but hey that's why we test.

If you plot the 3 points for which you actually have data, two things are clear:

1) the graph's 2nd derivative is negative (it's concave down), and

2) the X intercept is not trending toward zero.

These two observations comport well with what would be expected based on the system that's being modeled: it takes some non-zero voltage to move the belt, and the losses are greater at greater speeds.

So to get a good extrapolation you need to take the above two things into account.

Forcing a zero-intercept and fitting a quadratic gives a trendline which clearly violates those two observations, and gives a misleading answer.

If you fit a quadratic to your actual data (without forcing it to go through zero), the quadratic will be concave down (as expected) and will extrapolate nicely to 4400 rpm at 12 volts.

If you run 4400 through your calculations, you'll see it agrees much more closely with your observed frisbee speed.

[Ken Streeter]

Originally Posted by Ether

Is anybody using a shooter with a wheel on each side like that?

1519 has been prototyping with a two-wheel shooter of that type. (One wheel on each side of the disc.) Whether or not we end up actually using that design depends upon the accuracy we can attain with it.

We have prior experience (Aim High 2006 and Lunacy 2009) with a horizontal layout two-wheel shooter with one wheel on either side of the game piece and had pretty good success both years. In Rebound Rumble 2012 we used a single-wheel (vertical orientation) shooter because it imparts huge spin, which was helpful for shots using the backboard of the goal.

Anybody else trying a two-wheel (one on either side) frisbee shooter?

[Aren Siekmeier]

Originally Posted by Ether

Not...speed.

I agree with all of the logic presented beyond your initial assumptions, as well as how the 4400 figure agrees better with our measured frisbee speed, except that we know there was some non-negligible spin down, so it seems to me that 3000 ft/min to 2400 ft/min is not much of a problem. Also,
1) my understanding of our system tells me that the load due to friction should be constant (once you get going), so a fixed load under increasing voltage will be a decreasing percentage of stall, so you approach 100% of free speed linearly as voltage increase, while the free speed itself increases linearly with voltage (all loose approximations). Under this model I was expecting a positive concavity, which in fact the data has if
2) you include the origin as a data point (we regularly observe no speed at no voltage)

However, I claim no particular authority in the assumptions about the system I based this on, so if in fact the load increases with speed enough to change concavity, your figure would be more appropriate. Thanks for the explanation.

In any case, for the benefit of others, the 4400 rpm figure Ether has arrived at would give a belt speed of 5200 ft/min and thus an expected exit speed of 2600 ft/min, compared to our measured 2400 ft/min (+/- 100), showing much less spin down.

[Alan Anderson]

Originally Posted by compwiztobe

Under this model I was expecting a positive concavity, which in fact the data has if
2) you include the origin as a data point (we regularly observe no speed at no voltage)

It's possible that you will also observe no speed at some nonzero voltage. Try a few more data points and you'll have a better characterization of the system.

[billbo911]

Here's a quick video of some testing with a Chronograph taking direct measurements of the Frisbee as it leaves the shooter. The values being called out in the 8-10 range are the voltage applied to the Mini CIM driving the 8in wheel. The numbers being called out in the 18-20 range are the feet per second being measured.
http://www.youtube.com/watch?v=Ue3QB...ature=youtu.be

If there is one thing we discovered, the consistency with which the disc is pushed into the launcher is more important to repeatability than just about any other factor.

Here's part two.
http://www.youtube.com/watch?v=1uAov...ature=youtu.be

We modified the code on the Chronograph and set it up to use retro tape, as is the original design of these sensors. We then suspended it over the flight path .

[EDIT] I just discovered I had not set the distance between the sensors in the Arduino code properly. It was still at 6" while we were videoing, but the sensors were 12" apart. So, the velocities I was calling out were half the actual velocity of the disks. [\EDIT]

[Ether]

Originally Posted by billbo911

I've "refined" my Chronometer sketch

I've never used an Arduino so I'm curious: Does anyone know what is the interrupt latency (the elapsed time from the occurrence of an interrupting event until all the context switching has completed and the user-written code in that event's ISR starts to execute)

[Orion.DeYoe]

Originally Posted by Ether

Not to annoy you, but I think this is worth discussing because there are some things to be learned here.

I was trying to help you understand the mystery behind your earlier comment:




If you plot the 3 points for which you actually have data, two things are clear:

1) the graph's 2nd derivative is negative (it's concave down), and

2) the X intercept is not trending toward zero.

These two observations comport well with what would be expected based on the system that's being modeled: it takes some non-zero voltage to move the belt, and the losses are greater at greater speeds.

So to get a good extrapolation you need to take the above two things into account.

Forcing a zero-intercept and fitting a quadratic gives a trendline which clearly violates those two observations, and gives a misleading answer.

If you fit a quadratic to your actual data (without forcing it to go through zero), the quadratic will be concave down (as expected) and will extrapolate nicely to 4400 rpm at 12 volts.

If you run 4400 through your calculations, you'll see it agrees much more closely with your observed frisbee speed.

Your extrapolation would line up perfectly with the properties of the motor. You have to remember that the motor won't move at 0.001 VDC. It takes a little (or a lot of, depending on the load) voltage to get it to start moving. This would account for the non-zero intercept. I would have to agree with the 4,400 RPM number (that's a little above the normal operating speed of a CIM). Everyone seems to be doing all of their calculations on disc exit velocity using the FREE LOAD SPEED of the motor. This is incorrect. The "free load speed" is the speed of the motor's shaft when you hold the motor in your hand and give it full power (12 VDC in this case). The normal operating speed usually ends up being about 80% of that number due to friction and inefficiency of the mechanism. You'll never get 5,300 RPM (free load speed of a CIM) out of a CIM attached to anything.

[billbo911]

Originally Posted by Ether

I've never used an Arduino so I'm curious: Does anyone know what is the interrupt latency (the elapsed time from the occurrence of an interrupting event until all the context switching has completed and the user-written code in that event's ISR starts to execute)

From the sources I have been able to find, the latency for interrupts on the Arduino is around 18-20 clock cycles. On an Amtel atmega168/328 running at 16MHz, that translates to 1.25us. Considering the resolution of the "micros" command is 4us, the worst case error using two interrupts to calculate the velocity is 11us.

Now, we are currently measuring Frisbee velocity over a 1 foot span and seeing maximum velocities in the 40ft/sec range. 40ft/sec is a measurement of approx 25,000us. Therefore, an error of 11us only yields a velocity error of .044%. In the FRC world, that is negligible.

I also have to believe that much of the latency in the interrupts is negated by the way we are triggering them. The majority of the error is introduced by the "micros" command resolution of 4us. In this case, the max error is in the neighborhood of 8us or .032%. Again, close enough for FRC.