Chief Delphi - Disc Lauching Velocity

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)

- - Disc Lauching Velocity (http://www.chiefdelphi.com/forums/showthread.php?t=110940)

AnimeOtakuStar

10-01-2013 19:13

Disc Lauching Velocity

We're looking to find the exiting velocity of a disc from a launcher. Please provide the basis for your calculation. Thanks~!

From MOE 365

JakeD

10-01-2013 19:24

Re: Disc Lauching Velocity

Its a dynamics problem but the calculations can change based on how your device is set up. A description of your shooter should be enough to figure out the equations and what variables you'll need to plug in though.

Mr MOE

10-01-2013 19:34

Re: Disc Launching Velocity

Quote:

Originally Posted by JakeD (Post 1212582)

Agree. We were wondering if anyone actually measured the velocity of their discs when they exited the shooter/launcher. If so, what did you record and what were the shooter parameters that resulted in that specific velocity (if you are willing to share)?

Thanks.

scaryone

11-01-2013 12:08

Re: Disc Lauching Velocity

Measuring B velocity and wheel RPM this weekend. Will post results

Ether

11-01-2013 13:10

Re: Disc Launching Velocity

Quote:

Originally Posted by Mr MOE (Post 1212595)

We were wondering if anyone actually measured the velocity of their discs when they exited the shooter/launcher. If so, what did you record and what were the shooter parameters that resulted in that specific velocity (if you are willing to share)?

Thanks.

^This^

It would be a service to the CD community.

roystur44

11-01-2013 15:08

Re: Disc Lauching Velocity

Here is a neat device that can help you out with your velocity numbers.

http://www.bhphotovideo.com/bnh/cont...G&A=details&Q=

I good video analysis program is UberSense on a Ipad or Iphone

http://www.ubersense.com/

IKE	11-01-2013 15:47

Re: Disc Lauching Velocity

Quote:

Originally Posted by AnimeOtakuStar (Post 1212573)

We're looking to find the exiting velocity of a disc from a launcher. Please provide the basis for your calculation. Thanks~!

From MOE 365

I am going to choose to answer a different question. When working on target velocities, we timed how long it took to throw the discs various distances effectively. At what speeds did the discs have ample drop (loosing altitude) and at what threshold dip the trajector appear relatively flat. We chose to do this over a 50' distance as this would be the theoretical super shot, just to see what sort of velocities were required.

This does not give you the "muzzle" velocity, but it does give you the average velocity, and you know you should probably target faster than that at the muzzle.

If you simultaneously take times at teh 25' mark, then you will have the average velocity for that distance as well, and you can use the 3 points to see the trend for speed (total time give total average velocty, timing at 25' mark allows for 25' average as well as the 25-50 foot average by subtracting the two.

billbo911

11-01-2013 16:14

Re: Disc Lauching Velocity

I have an Arduino Sketch that you are free to use to create a Chronometer. All you need is a couple of sensors to attach that can sense when the disk passes. You may have to change the Interrupt type from "RISING" to "FALLING" depending on the sensors you use.
Just edit the distance value in the code to match the separation distance between the sensors and it will spit out the velocity in ft/sec whenever the two sensors are triggered by a passing object.

Code:

/*******************************************************************************************

* This Sketch is for a Chronometer that uses the "micros" function to capture two points in*

* time and determines how much time has elapsed between them in microseconds. By knowing    *

* the distance between the to sensors, the velocity of the object can be determined.       *

* Bill Kendall, Jan. 11, 2013                                                              *

*******************************************************************************************/



#define SENSOR_DIST 6  //This value is the distance between the sensors in inches



unsigned long event1 = 0; // value in 'micros" at the time of this first trigger

unsigned long event2 = 0; // value in 'micros" at the time of this second trigger

int calculate = 0;  // If set to 1, a calculation and display of the velocity will occur

unsigned long duration = 0; // Amount of elapsed time between events

unsigned long velocity = 0;



void setup (void)

{

attachInterrupt (0, ISR0, RISING);  // Interupt 0 (pin 2) calls "ISR0" Thie is the first trigger

attachInterrupt (1, ISR1, RISING);  // Interupt 1 (pin 3) calls "ISR1" This is the second trigger

Serial.begin(115200); // connect to the serial port



}



void ISR0 (void)

{

  event1 = micros(); // record the microseconds counter

}



void ISR1 (void)

{

  event2 = micros(); // record the microseconds counter

  calculate = 1;  // Allow the velocity calculation code to run.

}





void loop (void)

{

  if (calculate != 0);

  {

    RunMath ();    

  }

}



void RunMath (void)

{

  duration = (event2 - event1); // elapsed time between triggers in u seconds

  velocity = ((SENSOR_DIST/duration)/12)*1000000;  // Calculate velocity in feet per second

  Serial.print("The projectile is moving at ");

  Serial.print(velocity);

  Serial.println(" ft./sec.");

  calculate = 0;

}

DonRotolo

11-01-2013 21:11

Re: Disc Lauching Velocity

Quote:

Originally Posted by IKE (Post 1213163)

Can you share some of your findings? I'd really be interested in knowing what a good range of 'times' for the 25 foot distance is, for a fairly flat trajectory.

ehochstein

11-01-2013 23:47

Re: Disc Lauching Velocity

Quote:

Originally Posted by billbo911 (Post 1213187)

I built a limit-switch triggered arduino timer tonight, I'll do some testing with the team tomorrow and report my results here. We will be shooting at a fridge around 24' 9" away using two different types of wheels. The first an 8" AM Pneumatic wheel and the second an 8" plaction wheel.

You can see a video of our shooter here; http://www.youtube.com/watch?v=ThZCOtjVJmw

billbo911

14-01-2013 13:02

Re: Disc Lauching Velocity

I've "refined" my Chronometer sketch (read that as "I now have it working correctly"). After testing it, I found it wasn't quite what I wanted, so I fixed it.

Please enjoy!

Code:

/*******************************************************************************************

* This Sketch is for a Chronometer that uses the "micros" function to capture two points in*

* time and determines how much time has elapsed between them in microseconds. By knowing    *

* the distance between the to sensors, the velocity of the object can be determined.       *

* Bill Kendall, Jan. 11, 2013                                                              *

*******************************************************************************************/



float SENSOR_DIST = 6;  //This value is the distance between the sensors in inches

float distance;

unsigned long event1 = 0; // value in 'micros" at the time of this first trigger

unsigned long event2 = 0; // value in 'micros" at the time of this second trigger

int firstint = 0;  //Set to 1 if Interrupt 0 has occurred

int calculate = 0;  // If set to 1, a calculation and display of the velocity will occur

unsigned long duration = 0; // Amount of elapsed time between events

float velocity = 0;



void setup (void)

{

attachInterrupt (0, ISR0, FALLING);  // Interupt 0 (pin 2) calls "ISR0" Thie is the first trigger

attachInterrupt (1, ISR1, FALLING);  // Interupt 1 (pin 3) calls "ISR1" This is the second trigger

distance = (SENSOR_DIST/12.0); // Convert sensor spacing to feet

Serial.begin(115200); // connect to the serial port



}



void ISR0 (void)

{

  event1 = micros(); // record the microseconds counter

  firstint = 1;

}



void ISR1 (void)

{

  event2 = micros(); // record the microseconds counter

  calculate = 1;

}





void loop (void)

{

  if (calculate == 1 && firstint == 1)

  {

    RunMath ();    

  }

  delay (500);

}



void RunMath (void)

{

  duration = (event2 - event1); // elapsed time between triggers in u seconds

  velocity = (((distance)*1000000)/(duration));  // Calculate velocity in feet per second

  Serial.print("The projectile is moving at ");

  Serial.print (velocity,2);

  Serial.println(" ft./sec.");

  calculate = 0;

  firstint = 0;

 }

Aren Siekmeier

14-01-2013 13:35

Re: Disc Lauching Velocity

With our latest shooter setup, we measured frisbee exit velocity very roughly with a 60fps camera as well as launch surface speed (under no load) with an optical tachometer. When making 3pters from 30" directly above the auto line, we measured an exit speed of roughly 2400 ft/min (+/- a few hundred), with the launch surface going about 6000 ft/min under no load (one-sided with no noticable slip, so you can see there is some spin down in our implementation, but it spun back up within a second). These numbers are lower than we had previously been estimating, but hey that's why we test.

Ether

14-01-2013 13:55

Re: Disc Lauching Velocity

Quote:

Originally Posted by compwiztobe (Post 1214971)

With our latest shooter setup

Would you please describe your latest shooter setup, to give some context to the numbers you posted.

Quote:

with the launch surface going about 6000 ft/min under no load

How do you know it was 6000 ft/min, i.e., how did you measure that?

cseabury

14-01-2013 14:16

Re: Disc Lauching Velocity

There is a nice software package for the I phone. "Vernier Physics."
Take a video of the frisbee launching past some landmarks of known separation, mark those spots, and you can get the time in between.

Aren Siekmeier

14-01-2013 14:44

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1214993)

Would you please describe your latest shooter setup, to give some context to the numbers you posted.

How do you know it was 6000 ft/min, i.e., how did you measure that?

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). This gives a tangential velocity of 360mm*5200rpm/25.4/12=6100 ft/min.

We had about 12in of contact with the belt.

To measure exit velocity, we took several 60fps videos of the launch, and measured a 4ft travel out of the shooter in 6 or 7 frames, averaging about 2400 ft/min. The low frame count of course makes the uncertainty on this figure substantial (about 300ft/min per measurement, 100ft/min over 10 measurements).

mikegrundvig

14-01-2013 14:50

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

Ether

14-01-2013 14:50

Re: Disc Lauching Velocity

Quote:

Originally Posted by compwiztobe (Post 1215033)

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?

Quote:

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

14-01-2013 15:18

Re: Disc Lauching Velocity

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

Fastnate

14-01-2013 15:24

Re: Disc Lauching Velocity

1 Attachment(s)

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

14-01-2013 15:39

Re: Disc Lauching Velocity

1 Attachment(s)

Quote:

Originally Posted by compwiztobe (Post 1215047)

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

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

Aren Siekmeier

14-01-2013 15:44

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1215064)

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

14-01-2013 15:45

Re: Disc Lauching Velocity

Quote:

Originally Posted by Fastnate (Post 1215053)

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

Ether

14-01-2013 16:58

Re: Disc Lauching Velocity

3 Attachment(s)

Quote:

Originally Posted by compwiztobe (Post 1215068)

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:

Quote:

Originally Posted by compwiztobe (Post 1214971)

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

14-01-2013 17:01

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1215069)

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

14-01-2013 17:36

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1215106)

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

14-01-2013 19:23

Re: Disc Lauching Velocity

Quote:

Originally Posted by compwiztobe (Post 1215136)

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

15-01-2013 00:32

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]

Ether

24-01-2013 01:15

Re: Disc Lauching Velocity

Quote:

Originally Posted by billbo911 (Post 1214939)

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

24-01-2013 12:28

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1215106)

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

24-01-2013 13:18

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1220969)

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.

nathannfm

24-01-2013 14:10

Re: Disc Lauching Velocity

Quote:

Originally Posted by Orion.DeYoe (Post 1221123)

You'll never get 53,000 RPM (free load speed of a CIM) out of a CIM attached to anything.

Ummmm...

*5,300 RPM

Ether

24-01-2013 14:28

Re: Disc Lauching Velocity

Quote:

Originally Posted by billbo911 (Post 1221140)

...

Thanks for the detailed answer.

I was wondering if you could achieve a similar result using only one sensor instead of two by interrupting on both rising and falling edges of that sensor (using the diameter of the frisbee as the distance).

billbo911

24-01-2013 14:33

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1221176)

Thanks for the detailed answer.

I was wondering if you could achieve a similar result using only one sensor instead of two by setting up one pin to interrupt on both rising and falling edges. Or doesn't the hardware support that?

I'm sure it is possible, here is a quote from the Arduino Interrupt Reference page.

Quote:

attachInterrupt(interrupt, function, mode)....

...
mode:
defines when the interrupt should be triggered. Four constants are predefined as valid values:

LOW to trigger the interrupt whenever the pin is low,
CHANGE to trigger the interrupt whenever the pin changes value
RISING to trigger when the pin goes from low to high,
FALLING for when the pin goes from high to low.
The Due board allows also:
HIGH to trigger the interrupt whenever the pin is high.
(Arduino Due only)

You would have to craft the ISR carefully, but it should be possible using the CHANGE mode. My only concern is that the second interrupt would occur before the processing of the first interrupt had completed.
Although, given the timing measurements we are seeing for this year's challenge, that should not be too much of an issue.

Orion.DeYoe

24-01-2013 14:36

Re: Disc Lauching Velocity

Quote:

Originally Posted by nathannfm (Post 1221173)

Ummmm...

*5,300 RPM

Lol yes, if you look I have corrected the post. That was a typo (a pretty major one I might add).

Ether

24-01-2013 14:55

Re: Disc Lauching Velocity

Quote:

Originally Posted by billbo911 (Post 1221181)

My only concern is that the second interrupt would occur before the processing of the first interrupt had completed

If your two sensors are only 12" apart, you'd have the same concern, since that distance is roughly the same as the single-sensor approach (wherein the distance is the diameter of the frisbee).

So as you said, since the frisbee speed is plenty slow, it's not a concern.

The reason I brought this up is, using the single-sensor approach it might be easier to set up to measure the speed of the frisbee as it is passing thru the shooter at various locations. This might produce some very revealing data about slippage.

billbo911

24-01-2013 15:12

Re: Disc Lauching Velocity

Quote:

Originally Posted by Ether (Post 1221195)

...
The reason I brought this up is, using the single-sensor approach it might be easier to set up to measure the speed of the frisbee as it is passing thru the shooter at various locations. This might produce some very revealing data about slippage.

Excellent idea!!
I'm not certain it would give any useful information that the off board Chronograph couldn't supply, but it would always be present and available for measurement. Real time feedback during a shot may not be possible, but by no means impossible.

We plan on using our free standing unit to profile our system. We will also make it available at the Sacramento Regional to any team that would like to test with it.

Now, you have piqued interest. I just HAVE to write the code for a single sensor Chronograph!!
Stay tuned for code.

billbo911

24-01-2013 15:45

Re: Disc Lauching Velocity

Quote:

Originally Posted by billbo911 (Post 1221202)

[size="4"]...

Now, you have piqued interest. I just HAVE to write the code for a single sensor Chronograph!!
Stay tuned for code.

As promised...
This "should" work for a single sensor It is untested, but based off a working two sensor version. I left the original code in place but commented out.
BTW. it is already set up to print it's data to an I2C connected LCD. Modifying it to send data to the cRio would be quite simple.

Code:

/*******************************************************************************************

* This Sketch is for a Chronograph that uses the "micros" function to capture two points in*

* time and determines how much time has elapsed between them in microseconds. By knowing   *

* the distance between the to sensors, the velocity of the object can be determined.       *

* Bill Kendall, Jan. 15, 2013                                                              *

* I2C LCD Display function added 01/18/13                                                  *

* Modified for single sensor 01/24/13                                                      *

*******************************************************************************************/

#include <Wire.h>

#include <LiquidCrystal_I2C.h>



LiquidCrystal_I2C lcd(0x3F,20,4); //Create object "lcd" at address 0x30, 20 X 4 display



//float SENSOR_DIST = 12;  //This value is the distance between the sensors in inches

float DISK_DIAMETER = 11.0;  // Diameter of Frisbee in inches.

float distance;

unsigned long event1 = 0; // value in 'micros" at the time of this first trigger

unsigned long event2 = 0; // value in 'micros" at the time of this second trigger

int firstint = 0;  //Set to 1 if Interrupt 0 has occurred

int calculate = 0;  // If set to 1, a calculation and display of the velocity will occur

unsigned long duration = 0; // Amount of elapsed time between events

float velocity = 0;

int sample = 0;

int flasher = 13; //LED attached to pin 13



void setup (void)

{

attachInterrupt (0, ISR0, CHANGE);  // Interupt 0 (pin 2) calls "ISR0" Thie is the first trigger

//attachInterrupt (1, ISR1, RISING);  // Interupt 1 (pin 3) calls "ISR1" This is the second trigger

//distance = (SENSOR_DIST/12.0); // Convert sensor spacing to feet

distance = (DISK_DIAMETER/12.0); // Convert disk diameter to feet



pinMode(flasher, OUTPUT);

Serial.begin(115200); // connect to the serial port



lcd.init();                      // initialize the lcd 



  // Print our characters on the LCD

  lcd.backlight();  //Backlight ON if under program control

  lcd.setCursor(3,1); //Start at character 3 on line 1

  lcd.print("2073 Cronograph");

  delay(2000);

  lcd.clear();

  //lcd.setCursor(2,1);

  //lcd.print("From YourDuino");

  //delay(1000);  

  lcd.setCursor(8,0);

  lcd.print("2013");

  lcd.setCursor(3,1);

  lcd.print("Ultimate Ascent");

  lcd.setCursor(2,3);

  delay(1000);   

  lcd.print("PGHSRobotics.com");





}



void ISR0 (void)

{

  if (firstint == 0)

  {

  event1 = micros(); // record the microseconds counter

  firstint = 1;

  }

  else

  {

  event2 = micros(); // record the microseconds counter

  firstint = 0;   // reset firstint

  calculate = 1;

  }

}





/*void ISR0 (void)

{

  event1 = micros(); // record the microseconds counter

  firstint = 1;

}





void ISR1 (void)

{

  event2 = micros(); // record the microseconds counter

  calculate = 1;

}*/





void loop (void)

{

  if (calculate == 1)

  {

    RunMath ();    

  }

  delay (500);

}



void RunMath (void)

{

  digitalWrite(flasher, HIGH);

  delay(250);

  digitalWrite(flasher, LOW);

  duration = (event2 - event1); // elapsed time between triggers in u seconds

  velocity = (((distance)*1000000)/(duration));  // Calculate velocity in feet per second

 sample ++;

  lcd.clear();

  lcd.setCursor(1,0);

  lcd.print("Frisbee velocity is");

  lcd.setCursor(3,1);

  lcd.print (velocity,2);

  lcd.print(" ft./sec.");

  lcd.setCursor(9,3);

  lcd.print("Sample #");

  lcd.print(sample);  // Prints # of samples since reset

 /* Serial.print("The Frisbee is moving at ");

  Serial.print (velocity,2);

  Serial.println(" ft./sec.");*/

  calculate = 0;

  firstint = 0;

 }

billbo911

30-01-2013 16:45

Re: Disc Lauching Velocity

Quote:

Originally Posted by billbo911 (Post 1221226)

Code:

/*******************************************************************************************

* This Sketch is for a Chronograph that uses the "micros" function to capture two points in*

* time and determines how much time has elapsed between them in microseconds. By knowing   *

* the distance between the to sensors, the velocity of the object can be determined.       *

* Bill Kendall, Jan. 15, 2013                                                              *

* I2C LCD Display function added 01/18/13                                                  *

* Modified for single sensor 01/24/13                                                      *

*******************************************************************************************/

#include <Wire.h>

#include <LiquidCrystal_I2C.h>



LiquidCrystal_I2C lcd(0x3F,20,4); //Create object "lcd" at address 0x30, 20 X 4 display



//float SENSOR_DIST = 12;  //This value is the distance between the sensors in inches

float DISK_DIAMETER = 11.0;  // Diameter of Frisbee in inches.

float distance;

unsigned long event1 = 0; // value in 'micros" at the time of this first trigger

unsigned long event2 = 0; // value in 'micros" at the time of this second trigger

int firstint = 0;  //Set to 1 if Interrupt 0 has occurred

int calculate = 0;  // If set to 1, a calculation and display of the velocity will occur

unsigned long duration = 0; // Amount of elapsed time between events

float velocity = 0;

int sample = 0;

int flasher = 13; //LED attached to pin 13



void setup (void)

{

attachInterrupt (0, ISR0, CHANGE);  // Interupt 0 (pin 2) calls "ISR0" Thie is the first trigger

//attachInterrupt (1, ISR1, RISING);  // Interupt 1 (pin 3) calls "ISR1" This is the second trigger

//distance = (SENSOR_DIST/12.0); // Convert sensor spacing to feet

distance = (DISK_DIAMETER/12.0); // Convert disk diameter to feet



pinMode(flasher, OUTPUT);

Serial.begin(115200); // connect to the serial port



lcd.init();                      // initialize the lcd 



  // Print our characters on the LCD

  lcd.backlight();  //Backlight ON if under program control

  lcd.setCursor(3,1); //Start at character 3 on line 1

  lcd.print("2073 Cronograph");

  delay(2000);

  lcd.clear();

  //lcd.setCursor(2,1);

  //lcd.print("From YourDuino");

  //delay(1000);  

  lcd.setCursor(8,0);

  lcd.print("2013");

  lcd.setCursor(3,1);

  lcd.print("Ultimate Ascent");

  lcd.setCursor(2,3);

  delay(1000);   

  lcd.print("PGHSRobotics.com");





}



void ISR0 (void)

{

  if (firstint == 0)

  {

  event1 = micros(); // record the microseconds counter

  firstint = 1;

  }

  else

  {

  event2 = micros(); // record the microseconds counter

  firstint = 0;   // reset firstint

  calculate = 1;

  }

}





/*void ISR0 (void)

{

  event1 = micros(); // record the microseconds counter

  firstint = 1;

}





void ISR1 (void)

{

  event2 = micros(); // record the microseconds counter

  calculate = 1;

}*/





void loop (void)

{

  if (calculate == 1)

  {

    RunMath ();    

  }

  delay (500);

}



void RunMath (void)

{

  digitalWrite(flasher, HIGH);

  delay(250);

  digitalWrite(flasher, LOW);

  duration = (event2 - event1); // elapsed time between triggers in u seconds

  velocity = (((distance)*1000000)/(duration));  // Calculate velocity in feet per second

 sample ++;

  lcd.clear();

  lcd.setCursor(1,0);

  lcd.print("Frisbee velocity is");

  lcd.setCursor(3,1);

  lcd.print (velocity,2);

  lcd.print(" ft./sec.");

  lcd.setCursor(9,3);

  lcd.print("Sample #");

  lcd.print(sample);  // Prints # of samples since reset

 /* Serial.print("The Frisbee is moving at ");

  Serial.print (velocity,2);

  Serial.println(" ft./sec.");*/

  calculate = 0;

  firstint = 0;

 }

I have verified the above code works quite well as long as the sensor is aligned with the center of the Frisbee as it passes by.

If this alignment is not possible, or convenient, a simple modification to "DISK_DIAMETER" is required. Just enter the chord length of the Frisbee where the sample will be taken. Two digit precision is all that is needed.

Ether

30-01-2013 17:00

Re: Disc Lauching Velocity

Quote:

Originally Posted by billbo911 (Post 1224714)

I have verified the above code works quite well

Very cool! Thanks for posting that update :)

You've inspired me. For teams on a really tight budget that can't afford an Arduino, I wrote a small app that will run on any Pentium-based laptop or PC¹ with a parallel port. It uses that port's status pins² to get the elapsed time between rising and falling edges of a single sensor, or between the rising edges of two separate sensors, with +/- 2 μs accuracy.

If there's enough interest³, I'll clean it up and post a white paper.

¹especially on the old junker ones with 133MHz Pentium
²these are pulled up to +3.3 volts on most parallel ports and need only be grounded to generate a signal.
³PM me if you'd be interested.

All times are GMT -5. The time now is 05:35.