A more autonomous teleop?

[team-4480]

Hi!
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!

[thatprogrammer]

Hey. Check out this thread I recently made, it has some excellent info on this topic: http://www.chiefdelphi.com/forums/sh...d.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.

[jman4747]

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.

[Oromus]

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-gam...ackThread.java The programming in the code() function just loops constantly.

Hope this helps!

[GeeTwo]

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.

[BBray_T1296]

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.

[Knufire]

Originally Posted by team-4480

Hi!
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!

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.

[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.

[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.

[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.

[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.

[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.