View Single Post
  #5   Spotlight this post!  
Unread 08-03-2008, 08:48
Chris_Elston's Avatar
Chris_Elston Chris_Elston is offline
Controls Engineer
AKA: chakorules
FRC #1501 (Team THRUST)
Team Role: Engineer
 
Join Date: Feb 2004
Rookie Year: 2001
Location: Huntington, Indiana
Posts: 751
Chris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond repute
Re: Trackballs and CMUcam

Quote:
Originally Posted by SL8 View Post
I was thinking about doing this during our fix-it window but I was wondering if the ultrasonic sensor was necessary?
I dunno if my student programmer is watching this thread, but this is what he explained to me the problem was.

When using the CMU camera, he doesn't get a real time reading from where the ball is all the time. He just samples it every now and then and updates a varible in the gyro control.

Sometimes, the CMU camera samples the vision system and it returns nothing, it does this on the way to the ball. This doesn't stop the robot from driving forward however. It keeps driving and correcting to the last "good" location of the ball.

So with the CMU camera is giving us flakey data, it was hard to figure out if it gave us flakey data on the way to the ball or if we truly did arrive under the ball. At ship time, we did not have our encoders working, and I dunno if he plans on using encoders or not when we get to our regional, so he chose a sensor instead of measuring it out with an encoder.

Being under the ball or driving past the ball for SURE would return nothing from the camera, camera would lose sight of the ball under it or as we drove past it so that's where the extra sensor comes in.

Our programmer came up with this:

If camera data > 0
Update gyro control varible with pixel error from camera
If camera data = 0 keep driving to last known pixel error

Do all the above, until sensor =< than 20 inches, meaning it sees something
20 inches away, either the rack or ball. When nothing is in front of the sensor it see somewhere around 270 inches.

Then our programmer changes states in the software, from:
State 1 (seek the ball and drive to it using camera until sensor)
to
State 2 (drive to "x" degree for so many seconds or inches)
to
State 3
to
State 4

The above basically eliminates any dead reaconing, and allows the robot to do whatever it wants to do and get there how it needs to get there before changing to state 2.

If you watch a match where we knock down the first ball, and the robot just STOPS, that means we are still having issues with our sensor detecting the rack, that may be a good reason to switch over to an encoder when we get to Boilermaker.

Bottom line, it's not perfect yet, but the concept and control theory worked. That's what important that the programmers did what they set out to do.
__________________
Team T.H.R.U.S.T. 1501
Download all of our past robot's source code here:Repository

Favorite CD quote:
"That can't be their 'bot. not nearly enough (if any) rivets to be a 1501 machine." ~RogerR: Team #1369