View Single Post
  #9   Spotlight this post!  
Unread 21-08-2015, 10:19
thatprogrammer's Avatar
thatprogrammer thatprogrammer is offline
Registered User
AKA: Ahad Bawany
no team (None)
Team Role: Programmer
 
Join Date: Apr 2014
Rookie Year: 2014
Location: Florida
Posts: 610
thatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond reputethatprogrammer has a reputation beyond repute
Re: A more autonomous teleop?

Quote:
Originally Posted by Monochron View Post
I'll give an example; in last year's game we realized that our ball-pickup mechanism was rather slow so we decided to automate a lot of the process. The operator would hold down a button to drop our grabber and turn on our intake roller and then release the button to stop the roller and return to a "carry" position. In general it worked well but would occasionally cause us to have problems if the ball was falling out of our grabber, if we didn't approach the ball straight-on, or even if we were getting defended while trying to pick up. Basically it gave our drivers even more tasks to be mindful of (making sure to kill the automation if it was going to make us drop the ball or miss the ball, etc.)
.
A lot of teams automated their pick ups in 2014. I think what might have not been done in this case was designing with that automation in mind. Perhaps you could have optimized it more by adding a beam break to tell when the ball was in, and made the intake go back to 'carry' by itself?
My point is: Automation should be considered during the design process, doing it too late is often sloppy.