A more autonomous teleop?

We want to really step up our programming and autonomous game for next year. Our idea is that if there less human invention with the robot, the better off we will be. As an example, the robot would automatically lift the tote to a height each time it grabbed one.

What we need your help with is which sensors we can play with before next build season that might help us achieve better autonomous periods as well as teleop periods.

So far, we thought of using a sonar sensor and push sensor but I image there are many more to play with. I really want to take our code to the next level with more and better sensors so any ideas would be greatly appreciated! Thanks!

Hey. Check out this thread I recently made, it has some excellent info on this topic: http://www.chiefdelphi.com/forums/showthread.php?t=137836
In the future, try to search these things and post if you don’t find any threads. That being said, it’s easy to search and not find a thread because your search terms weren’t specific enough. Don’t worry if that happens, we’ve all made that mistake. :smiley:

I think it’s okay to have a new thread since a specific application is mentioned and is in a appropriate sub thread.

The first thing is to nail down what your robot needs to know to complete the given task. Next what sensors tell you this information consistently. Third which of these outputs the simpler, faster, and easier to work with signal and corresponding data type. Fourth what is the sensor going to touch physically and where will it be. Fifth where will you get it and how much will is cost.

For this you want the robot to lift a tote to a given height once it is in the robot. So #1 you need to know if the tote is in the robot. But you really need to know if the to is in the correct position to be successfully lifted. That is to say that you don’t care how far into your robot is is the important part is whether or not it is all the way into the robot. Rangefinders, and switches both give you this information but rangefinders will give you more than you need and are (albeit very slightly) more complex to program and wire.

A switch of some kind will usually be cheaper than a good rangefinder and will operate more consistently. Industrial grade limit switches are also made to work forever +/- a day or two and will give you very detailed operating parameters and dimensions in there datasheets. Another point about industrial switches is they tend to be more robust or like this switch which has a probe that bends after the switch is thrown so the part that does the switching is protected form shock or over travel. Cost wise it’s $27 which isn’t very bad but when you consider that company gives you a $30 voucher in the kit every year…

So that was the process I would go through to pick a sensor for that application. Unless that is you meant the position control on the lift.

We actually did your example: our robot could automatically lift a tote to the appropriate height when it gone one. Here’s how we did it:

Our robot got its totes from the human player station. A tote would slide through a ramp inside our robot and come out on the other side. There was a small touch sensor inside the ramp, so we could see when a tote was sliding through the ramp. After a delay of 1-2 seconds, we’d have our lift move to the appropriate position, taking the new tote with it.

We combined that with some more code and created a button that, when held, automatically stacked all totes coming through the human player station.

Generally, automating your robot is about two things: being able to detect whatever you need, and having a robot that can accurately do the task without human input.

The file relating to our automatic stacking can be seen here: https://github.com/FRC-1902/2015-game/blob/master/2015%20Robot/src/com/explodingbacon/robot/ToteStackThread.java The programming in the code() function just loops constantly.

Hope this helps!

We tried similar “semi-automation” this year and did not succeed. Our approach was to use minimal mechanical auto-alignment and use proportional or encoded sensors. We noticed that many teams succeeded using more mechanical assurance of alignment of the game piece (commonly through an active intake feeding into a limited space), then had a very simple (usually binary, often non-contact) sensor. I have encouraged this sort of setup for our off season game, and we will probably use it as our starting point in future years.

Our robot was similar to 148’s in that it was a multibot with one part stacking at the feeder station, and the other ferrying stacks/collecting RCs. Our stacking robot (called ‘the cube’) was fully autonomous. It detected an entering tote, stacked it up to 6, then went into an unloading position with the retaining gate open, waiting for the other half (‘the jack’) to remove it. Once it detected the stack was gone, it reset itself to begin the next stack. There was of course a manual override in case it messed up, which could be controlled by the second driver.

On the topic of second drivers, automating half of our robot allowed our robot to only be driven by a single operator. The secondary driver became a second human player, assisting the first by queuing up totes to be thrown through the chute faster. Using this method, by the off-season we were passing up to 30 totes/match into the robot. Had the ‘jack’ been more complex, the second driver could have assisted, but it wasn’t necessary this year.

You’ve hit it on the nose. I’d argue that a lot of teams are more limited competitively by poor driving rather than their robot’s capabilities. Making your robot easier to operate will go a long way to performing better on the field. There’s two parts to this, picking the right sensor, and finding the right control algorithim.

If you’re just starting out with sensors, I would highly recommend you start with encoders. Enoders simply tell you one thing; how far something has turned. Almost all off-the-shelf gearboxes for FRC have built in places to mount an encoder. For example, I noticed from pictures on your website that you were using the kitbot chassis this past season. You can purchase two encoder kits from AndyMark that will mount onto the drivetrain gearboxes on your chassis, and start experimenting with making your robot drive for a specific distance and stop.

The other side of this is software. The most common way to control something based on sensor feedback in FRC is called a PID loop. There are various tutorials and guides both on Chief Delphi and on the internet about how PID loops work.

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.

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.

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


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.

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.

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.

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)

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.

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

We used Optek OPB720B

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.

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.

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.