A more autonomous teleop?

[Monochron]

As no one has mentioned it yet I figure I will add a bit of warning against over-automating.
Automating robot tasks can be a really powerful tool as long as it is used appropriately. Be careful of automating too many tasks though or tasks that rely on a lot of different variables.

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.)
Even worse was that on occasion a bug would crop up where the automation could not be interrupted. It took us a long time to catch what the issue was because it was so intermittent and in the meantime we would drop a ball and have to wait while our pick-up moved to "carry" position and then all the way back to "pick-up" position. It was pain and we looked pretty bad on the field.

I think it was in one of 254's publications that they said automation is best used for tasks that a human cannot do efficiently, or that a computer could do more efficiently. Stacking totes in this year's game lended itself to automation. If a tote was fully inside your gripper (as detected by sensors) then it was likely that you were going to be able to lift it.

In our situation automation didn't really speed anything up. We still had to wait for the grabber to move between pick-up positions and the grabber itself either needed many more sensors to be sure the ball was captured or needed the operator to visualy verify that the ball was captured.

[thatprogrammer]

Originally Posted by Monochron

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.

[Monochron]

Originally Posted by thatprogrammer

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?

We did use a sensor to tell us when the ball was in, but that didn't eliminate the problem of the ball unseating itself, getting defended against, or otherwise losing grasp while going back to "carry". A more complete solution would have to constantly react to the current state of the ball throughout the back-to-carry maneuver, because the likelihood of losing the ball with our grabber was too high.

My point was that the way we designed our ball carrier didn't match the automation we tried to use, not that automation shouldn't be done on ball pick-ups. Because our back-to-carry maneuver was so slow (on the order of couple seconds after first acquiring the ball) automating that portion made no sense.

[Chirag]

4761 used several photoelectric sensors donated by Rockwell Automation to automate our tote loading at the human player station. Our robot was basically made of two conveyors, one being able to move up and down along extrusion rails to reach different heights, the other being stationary on the bottom of the robot. We had a break-beam emitter and receiver pair at opposite sides of the moving conveyor to detect when a tote was completely on the conveyor, a few diffuse sensors along the extrusion to detect different heights for the conveyor to move to, and another break-beam set on the main conveyor at the ground level of the robot to detect when a tote was completely off of the moving conveyor. All our operator did was press and hold a button while we were at the chute and the robot loaded the totes for us slightly faster than our human player could send the totes through the chute.

Here's a video of the whole routine in action

We also tried automating the moving conveyor to move to the top of any stack with the press of a button using one of the diffuse sensors to make for quicker stacking/ capping but it wasn't as reliable as we wanted it to be.

Our robot didn't have these sensors originally and each component was manually moved by the operator. After we added these features between districts, I was amazed by the power of automating features in the robot. In my opinion, we went from being one of the slower robots to being able to keep up with most of the robots at the competitions we attended.

[BBray_T1296]

Originally Posted by R.C.

Do you have a part # for this guy? Curious what you guys used.

Thanks!

We used Optek OPB720B

[ShinyShips]

Originally Posted by team-4480

As an example, the robot would automatically lift the tote to a height each time it grabbed one.

We did this and a little more this season. We used encoders on our lifts, converted encoder ticks to inches and created levels at certain heights, with each button press the tote lift would go up/down a level or up/down half a level. We also used wobble switches on the front of our robot to allow our driver to more or less line up the robot and press a button to make the robot drive up to the tote, line up, and lift the tote to the next level.

This automated pick-up went to our driver so most of the time as the operator I only had to worry about our Can lift and this let me watch the field a little more.

[I_AM_Clayton]

We used a string potentiometer on the the top of our robot and connected it to our lift and used that to calculate distance from the top and have our lift to go to set positions.

[jgwentworth96]

For applications in which multiple linear positions are required, string potentiometers are a life saver. Our team also utilizes laser distance sensors and limit switches. Our robot was fully autonomous last year and I can tell you the hardest parts are sensor placement and coding. Good luck!