Did you automate any robot processes (in teleop)?

[RoboMaster]

What was your experience this year in automating robot processes to aid the drivers? Meaning: controlling a mechanism or maneuver without direct button/joystick manual control of motors or actuators. Instead, more like press a button and the robot does a sequence of events automatically. Or, it manages a task simultaneously so that you can focus on something else.

Examples:
-align robot with peg manually, but press a button and it hangs quickly and perfectly. Or, it even drives up and aligns itself.
-some sort of control that automatically adjusts height of arm/lift for different peg levels.
-aligning with tower (using camera, maybe)
-deploying minibot in one step/button press, which might include driving up, aligning, deploying, and driving away/retracting deployment so that minibot doesn't crash down on it if yours doesn't stay at the top.
-if you used the camera and mounted it in the frame with motors, pressing a button that aligns the camera in a certain view for some driver process.

Of course this excludes autonomous. I mean stuff that helps the drivers in teleop. I wouldn't really say that drive adjustment for perfectly straight driving (gyro) would count. That's a little too unrelated to what I mean.

How did you accomplish this? When did your programming know when to stop and/or go to the next action? Time, encoders, limit switches, other? I'm sure PID was used by someone out there for the actual motion. How did you program it? A state machine? A simple yet clever thought process? Something like the default code for line following in autonomous? Did you have any manual overrides in case it didn't work in a match? Was something too hard or take too long to code or debug, so you ended up not using it?


Our team:
We decided to try doing some of this, but it would be second priority to getting basic manual control of all actuators. Then we ranked what we should focus on programming first:
1. Return to pickup position (after hanging a tube)
2. Pickup a tube after driving up to it. After this, the drivers can just drive away. They don't have to worry about aiming carefully and holding their position while being bumped by opposing robots.
3. Lift positions for the different peg heights. This would definitely need an encoder on our lift motors, which might be difficult to mount and take too much time to figure out.
4. Release and hanging of tube. In our opinion this would be the most complex, since it would have many actions for adjusting the tube and our manipulators for backing out.

We ended up only programming the first two for starters, and we couldn't get the second one working. Because of time issues (cough cough only have 6 weeks cough not our fault cough really ) we had to cut down on some capabilities of our robot to finish it in general. Therefore we couldn't use all the sensors (limit switches) we wanted, which would make automating these processes easier.
The second automation item was completely time based (run X for Y seconds, then A for B seconds, then stop), which for us was tricky and we didn't have enough time to debug. I am not a fan of time based actions, since the outcome can be so variable depending on battery charge, amount of testing, mechanism accuracy/slop/reliability, or other variables. Sensors, especially limit switches, are much more concrete and direct in telling you that you've reached a limit or achieved your goal.
We used state machines for our processes, including our autonomous mode (which we had to nix for the same above reasons ). This is because teleop runs iteratively (loops instead of running from start to finish, like autonomous independent), which is how state machines are run. Therefore we could use similar, automated code in autonomous and teleop, instead of independant code in autonomous and different, independent code in teleop.
For our automated processes we have an override switch, in case a process is running out of control or a limit switch is broken and won't let us run properly. We checked the position of the joystick throttle and used that as a simple switch (up = on, down = off).

[davidthefat]

Not as much as I wanted to. Apparently the software is on the bottom of the totem pole on my team. Never listening to programmers' requests and having the programming delayed.

[liam.larkin]

We have several. We are a big believers in automating as much as possible.

-So we are using a home made 10 turn string pot to give us preset heights for the pegs.
-A combination of IR and Sonar senors on the back to line us up with the pole (minibot)
-A Sonar sensor in the front for when we are in the lane to pick up a tube. We can pick from the ground fine but we found its faster to just get it directly from the human player at least for us. Sonar gets us the right distance away from the wall and starts our tower/lifter capture sequence.
-Gyro chip used in combination with many of these to ensure we stay on course.

So far thats it we will see how things go and maybe we will be adding on.

[MrForbes]

We have a few automated features, hopefully they'll work!

1. Tube pickup is not really automated yet, but it is designed so that we can drive into a tube, and as we're pushing it we drop the arm, expand the claw, and raise it. We do not need to stop or time the grabbing.

2. Arm height for hanging tubes is adjustable with a 6 position rotary switch on our console, just select a height and the arm raises the tube to where it belongs to hang it.

3. Minibot deployment is automated, using 3 limit switches. After driving next to the tower, the driver and operator each push and hold a button, then the arm swings out, and stops when it either hits the pole, or misses the pole and swings too far. It waiits for a moment for the minibot to drive off the arm, then retracts and stops when it's fully retracted.

There is also an automated slow speed driving system that runs the drive motors at a limited speed to allow easier maneuvering with our rather high speed geared drivetrain.

[sircedric4]

We automated our elevators heights this year. We are using a PID controller and the encoders on the toughbox transmission which is driving our elevator chain.

We have several buttons for the various peg heights, and all our students have to do is press the button for that height and the elevator PID's to it. We do have an override switch because we weren't sure we would get the PID to work this year. It works great though. It is the first year we finally got PID to work on a robot.

Our wrist, claw setup is also automatic based on button presses, but as that is all done with pneumatics it is relatively trivial to call the valves in the right sequence.

We were going to add the line followers for teleop to help our driver line up the robot, but determined that he had enough to do without adding more complexity to try and remember. Often times automating systems is more trouble than it is worth, resource wise, when you have this awesome free wetware in the form of the drive team member.

[BJC]

We automate pretty much every robot action. I can't tell you much more until our robot is revealed.

[pfreivald]

We have a two-joint screw-driven arm that is controlled at both joints by encoder feedback. Each peg, the floor, and the feeder slot all have their own button, and in addition there are 'bump' buttons that will tweak the arm position to compensate if necessary for a weird tube angle.

[Tom Bottiglieri]

My rule for automation that takes control away from the drivers is that the software should only make things the driver can do faster. If a driver is not capable of doing something manually at all (or is really slow at it) it's probably more of a mechanical or strategy problem than a software problem.

For example: bringing the arm to a preset scoring position with a button press: good. The driver can do it but control makes it faster and more accurate.
Trying to use sensors to fix the fact your drivers can't pick up a tube across the field: not so good. This is a hack to fix inherently broken mechanical device or strategy. Software can fix this in a pinch, but it would be better as the software person to preach to your team early on for non-reliance on software. This seems backwards coming from a software engineer, but you'll end up with a better robot and it means less frustration for you.

[demosthenes2k8]

We have automatic height presets for the elevator (and eventually, hopefully, the arm), line following with a single button (as well as the possibility to integrate it with sonar to be more precise with where we stop), minibot deployment automatically (still needs work though), and, since we developed our framework to support multitasking, and thus store all input into a concurrent Proxy task, the ability for a driver to hold down a button to disable receiving that joystick's input. (Our line following code is literally setting the joystick values in the Proxy task, not taking over the wheels)

[mathking]

We have (or will) preset positions for each arm height we want: 6 peg heights, driving height and 2 pickup heights (floor and human player). We also have a "foreman" setting meant to keep the grabber and tube at a constant position relative to the ground as the arm raises. We are also automating our arm braking, so that the disc brake actuates whenever the arm is raised and not moving.

We spent more time trying to make the controls more responsive to the driver than making tasks purely automated. We tried to make the design as mechanically simple as possible. For example, to pick up off the floor our forearm goes forward to rest on the roll cage, parallel to the floor. In this position the grabber is just over the bumpers and the rotating part of the "claw" is raised so we can drive over the tube and push it. As soon as we see that the tube is moving (via camera) we can actuate the claw and bring the tube up to driving position.

[ktress357]

We (team 357) have a few automated features, which worked great in testing!

1. Tube pickup is automated somewhat, the operator still drops the arm, but when the distance sensor picks up the tube, the claw closes.

2. When we push the button to go score, the distance sensors aligns the bot to the correct distance from the wall, but the driver still has to center the bot somewhat on the rack we wish to score on.

[AcesJames]

176 has automated the following processes

1 - Peg height is preset. Operator presses a button for each peg height. Height is controlled by an encoder.

2 - "Home" button puts elevator at floor, brings claw to the ground, and opens claw

3 - Deployment is controlled by 1 button. Operator presses the button, and the deployment arm swings out, a limit switch is triggered when the poll is hit, causing a cylinder to actuate and push out the minibot. Upon contacting the tower, the minibot motors start running, and by this point the robot has autonomously moved itself away from the tower.

4 - Angle of our robot's wrist when we approach the peg is controlled by a button. The wrist is set to "scoring position" which is the angle the wrist is most commonly at when a tube is dropped onto the peg. This value is also used in our autonomous scoring.

[pafwl]

We built our own string potentiometer that uses a 10 turn pot to tell us the towers height. Using that as a starting point, our hotrod-tube-picker-upper is positioned based upon how high the tower is. When close to the floor it is relaxed and ready to get a tube from the floor. When above a certain low point it is in capture mode. This mode is used if we want to get from human player.

The operation of capture and release is the same. Just pull and hold the trigger. Depending on where the tower is this runs an automated process using state machines to keep track.

The capture is a 3 step process. We go under the tube driver or operator pulls trigger.
1: Flick up finger to get tube.
2: Flick up wrist to put us in the correct pisition
3: Raise the tower to the midpoint.

Operator just holds trigger. If they miss the tube, they release trigger and tower down, process opens the hot rod for next try.

The tower moves to the different heights at the press of a button. Again the operator holds down the button. When it arrives at the correct height, the operator keeps pressing the button and the tower does station keeping to keep us there.

Finally Minibot deployment alligns uses a short range IR detector looking for the pole and the gyro to tell us how far to search if necessary. When it detects the pole, it properly aligns the robot to the pole. When ready the driver just presses and holds another button for this. To release the minibot the operator and drive must press the same button on their joysticks.

The going theory is to allow the driver and operator to look cool, calm, and collected while waving to their moms.

Good Luck...

You can see video at....
http://www.frc272.com/2011Season/2011with816-2.wmv

[Jared Russell]

Arm preset heights and the claw automatically rolls when the user wants to get a tube, but stops when a tube is in the gripper (via mechanical switches).

[Danny Diaz]

Our 2011 robot's name is PHunky's Revenge, which is built and controlled very similar to our 2007 robot, PHunky's Dilemma. It uses a "mimicry arm" on the operator console, which is a 1/12 scale model of the robot arm. Using encoders on the joints of the arm, the operator moves the operator console arm (AKA the "Lewis Arm") to a desired position, and the robot arm moves to match that position. You can find a full write-up of the design in the book, "FIRST Robotics: Rack 'N Roll: Behind the Design."

-Danny