A more autonomous teleop?

[BBray_T1296]

The sensors we used to automate our cube are:

Beam-break sensors, which is an all-in-one IR sender/reciever that trips anytime something reasonably reflective is in the way. The totes were plenty reflective for several inches, and using the retro-reflective vision tape will trip them from several feet away. Putting something dark and matte behind the sensor (or just lots of open air) keeps them from tripping falsely.

We also use hall-effect sensors (can find at WCP) which detect when a magnet passes in front of it. Our tote lifter was on a chain run, and we mounted a magnet to one link of chain, and placed beam-breaks at the top and bottom in the necessary positions. The stacker simply lifted until the sensor tripped and lowered until the other one tripped.

Both these options are great because they work without contact. We found using mechanical limit switches can be tricky as they can bend over time and the positioning changes. Without contact the sensors aren't going to move, heck all of our sensors were simply Velcro-d on, so we could manually adjust them if necessary.

[R.C.]

Originally Posted by BBray_T1296

The sensors we used to automate our cube are:

Beam-break sensors, which is an all-in-one IR sender/reciever that trips anytime something reasonably reflective is in the way. The totes were plenty reflective for several inches, and using the retro-reflective vision tape will trip them from several feet away. Putting something dark and matte behind the sensor (or just lots of open air) keeps them from tripping falsely.

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

Thanks!

[Jacob Bendicksen]

If you're interested in automation, I'd highly recommend taking a look at 4488's robot from this year. Completely automated other than driving and picking up cans - I loved it.

[Knufire]

Originally Posted by R.C.

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

Thanks!

Sensors with similar functionality were included in the 2011 KOP, Rockwell Automation 42EF-D1MNAK-A2. I know 469 uses some sligthly smaller units from Allen Bradely. 5188 got a few from AutomationDirect this season. I know some teams have had luck getting them ultra cheap from China on Ebay.

[MaGiC_PiKaChU]

we added a limit switch to detect when totes entered the bot at worlds... It would then stack them as they came really fast! Using the 1114-like ramp at school we were able to stack 6 totes in about 10 seconds instead of 22 when doing it manually.

I would also recommend adding sequences you use often to your controllers, as it will be more consistent and save time(like flipping RCs or dropping the yellow totes on the step)

[jajabinx124]

Team 2052 used a photo switch sensor for our robot this year, which is a sensor that detects the presence or change of light, and used it to detect whether a tote was ready to be lifted by our lifting mechanism or not (the light would change when the tote was ready to be lifted up).

We had an override for that sensor in case it didn't work.

[MaGiC_PiKaChU]

Originally Posted by jajabinx124

We had an override for that sensor in case it didn't work.

You don't want to learn about this the hard way

[EricH]

1197 carried an ultrasonic sensor inside one of our intake arms. If something was detected, the arms would snap shut and the wheels would pull whatever was in there into the robot until it hit a pair of heavy-duty limit switches (or rather, their trigger plates). A bit of sensor magic on the lift and we had a pretty fast stacker.

[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