View Single Post
  #10   Spotlight this post!  
Unread 28-01-2006, 14:40
David Brinza's Avatar
David Brinza David Brinza is offline
Lead Mentor, Lead Robot Inspector
FRC #0980 (ThunderBots)
Team Role: Mentor
 
Join Date: Feb 2003
Rookie Year: 2003
Location: Glendale, CA
Posts: 1,378
David Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond reputeDavid Brinza has a reputation beyond repute
Re: Speed Sensor for Ball Shooter

Quote:
Originally Posted by 6600gt
Dosen't the photo sensor have only a 500us response time?
Note: This post really deals with measuring the ball speed, not the shooter...

Per the attached spec sheet from Rockwell Automation, the photo receiver 42SMR-7100 has the following response times:

1ms ON/1.5ms OFF

So, if you are going to measure ball speed based on the time the ball is blocking a single light beam, the sensor will indicate OFF ~1.5ms after the beam is blocked and ON ~1ms after the beam becomes unblocked. So the sensor will indicate the ball has passed through the sensor ~0.5ms faster than actual.

So, if you're blocking the beam across the full ball diameter (approx 18 cm) and the elapsed time according to the optical sensor is 14.5ms, the actual crossing time is 15ms. That would put the ball speed at 12 m/s - just barely legal !

In terms of assessing measurement error, the actual response times for the optical sensor are needed (plus any jitter, which should be small). Error in the assumed ball diameter (i.e. is the sensor measuring the full ball diameter or is the ball off-center or out-of-round?) also needs to be taken into account (this is probably the dominant factor, 1% error would require better than 2 mm knowledge). If you use the FRC controller timer interrupts as eugenebrooks has described in:

http://www.chiefdelphi.com/forums/sh...99&postcount=8

the timing measurement error is insignificant (better than 100 ppm).

I think we're going to try this...stay tuned!
Attached Files
File Type: pdf RockwellAuto7000Series.pdf (98.5 KB, 148 views)
__________________
"There's never enough time to do it right, but always time to do it over."
2003 AZ: Semifinals, Motorola Quality; SoCal: Q-finals, Xerox Creativity; IRI: Q-finals
2004 AZ: Semifinals, GM Industrial Design; SoCal: Winners, Leadership in Controls; Championship: Galileo #2 seed, Q-finals; IRI: Champions
2005 AZ: #1 Seed, Xerox Creativity; SoCal: Finalist, RadioShack Controls; SVR: Winners, Delphi "Driving Tomorrow's Technologies"; Championship: Archimedes Semifinals; IRI: Finalist
2007 LA: Finalist; San Diego: Q-finals; CalGames: Finalist || 2008 San Diego: Q-finals; LA: Winners; CalGames: Finalist || 2009 LA: Semifinals; Las Vegas: Q-finals; IRI: #1 Seed, Finalist
2010 AZ: Motorola Quality; LA: Finalist || 2011 SD: Q-finals; LA: Q-finals || 2013 LA: Xerox Creativity, WFFA, Dean's List Finalist || 2014 IE: Q-finals, LA: Finalist, Dean's List Finalist
2016 Ventura: Q-finals, WFFA, Engineering Inspiration

Last edited by David Brinza : 28-01-2006 at 14:47. Reason: Add note.