Re: Disc Lauching Velocity
 

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

Re: Disc Lauching Velocity
 

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?


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

Re: Disc Lauching Velocity
 

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

Re: Disc Lauching Velocity
 

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.

Re: Disc Lauching Velocity
 

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

Re: Disc Lauching Velocity
 

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).

Re: Disc Lauching Velocity
 

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

Re: Disc Lauching Velocity
 

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.

Re: Disc Lauching Velocity
 

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?

Re: Disc Lauching Velocity
 

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.

Re: Disc Lauching Velocity
 

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.

Re: Disc Lauching Velocity
 

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]

Re: Disc Lauching Velocity
 

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)

Re: Disc Lauching Velocity
 

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.

Re: Disc Lauching Velocity
 

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.