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 :p ) 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 (http://www.chiefdelphi.com/forums/showthread.php?p=999263)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. (http://www.amazon.com/FIRST-Robots-Rack-Behind-Design/dp/1592534112)"

-Danny

[kws4000]

I'd LOVE to do a micro-arm!:cool:
Problem: Encoders and costs, and the poetntial of them getting knocked out of alignment.

We're just having at least 4 seperate "slam" size buttons send bollean signal to robot, then set motor speed until difference between programmed value and encoder value is something else, then slow it down until we hit that value.

Our mentor wants to add another 2 swtiches and a button for teleop linetracking, but I find it redundant, as long as we have the camera sending raw video to the DS.

[Madison]

We have several software-assists in place.

1 -- A button press orients to the drive back to its starting configuration. This allows the driver to hold the reorient button while driving toward the scoring rack so they can focus on where to go instead of worrying about overrotating.

2 -- Camera assisted scoring. By holding a button, the robot uses the gyro and camera to find the scoring peg column and align itself. http://www.youtube.com/user/teamxbot#p/u/3/8YaR1kKhUWw

3 -- 5 preset heights available at the touch of a button -- human player load, ground load and stored are all the same position.

4 -- Automated human player loading. Placing a tube into the whisker automatically extends it so human players can load the robot without driver interaction.

[Borntolose]

This year we programmed nine or ten different heights for the arm that can be reached at the press of a button. Also, the driver can hold down a button on his joystick and the robot will track the lines on the floor up to the peg. We also used some IR sensors to align ourselves with the base of the tower to deploy our minibot accurately.
We also considered using IR sensors to track the low walls between the opponents feeder lanes and our alliance zone in order to reach the pegs that have no lines to track. We gave up on the last idea because it was too complicated.

[mathking]

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. (http://www.amazon.com/FIRST-Robots-Rack-Behind-Design/dp/1592534112)"

-Danny

I love it! Do you have any video?

We seriously considered doing this for this year. We did it in 2004 (the design and the kids' explanation of it to the judges were instrumental in our winning the Engineering Inspiration Award in Pittsburgh that year) and it worked very well. It is a very cool solution.

[apalrd]

We automate pretty much every robot action.

Only what we want to automate.....

Seriously though, we spent a lot of time working on driver controls this year. In addition to automated preset positions, we have sequencing functions (do a score sequence) and modify sequencing based on entry and exit of states (to avoid certain death or the possibility of death). For the driver driver (not the operator), we worked on some algorithms to handle driving the way he wants, listening as best as we can to what he wants and making the robot do it.

If the software can do it faster, then the software will do it. Otherwise, humans will do it. For us, if we can tune the controls well enough, most things are software controlled.


Way back in 2007,we had a slide function that would calculate the angles of the two joints to slide the tube in and out while maintaining a consistent height.

[RoboMaster]

Wow, this is really interesting! Clearly automatic peg height settings is an often automated process. I'm glad to see that some teams got PID working; I've always wanted to try and get that to work. Also good point that pneumatics don't need to know when to "stop," that makes them handy for automation. I've never thought of using sonar for minibot alignment. And using sonar for grabbing the tube is a great idea.



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.

Very true, I agree. Our robot specifically has override functions and manual control of everything by default for the above reasons.

[Chris is me]

Our robot has no automation of any kind in teleop...

We don't really have any arm sensors, as we don't have a string pot and we can't figure out how to mount anything else. It's a dead axle, so mounting a pot isn't trivial. Same with an encoder. Plus, we don't have any #25 idler sprockets to spare.

With a single articulated joint, I'm not concerned. With under 5 minutes of practice, a non-driver was scoring tubes consistently. We designed the robot mechanically so that floor pickup and scoring could be done blindly.

I am a bit concerned for autonomous though! We have drive encoders, a gyro, and an ultrasonic...

[Travis Hoffman]

- Basic limit switch protections for arm travel in both directions as well as soft limits monitored by our arm's angle sensor.

- Automated arm positions - arm angle monitored by Cherry AN8 (http://www.cherrycorp.com/english/sensors/Rotary_Position/an8.htm) Hall-effect angular position sensor - can switch to good old reliable single turn potentiometer if this isn't robust enough.

- Positions selected by a gamepad joystick and an execute button (we are trying really hard to avoid the need for a custom button box/use of the Cypress IO board):

NW - Score Left/Right Column, High Peg
W - Score Left/Right Column, Middle Peg
SW - Score Left/Right Column, Low Peg
N - Load Tube from Slot
Center Neutral - Arm Home/Tube Transport Mode
S - Load Tube from Floor
NE - Score Center Column, High Peg
E - Score Center Column, Middle Peg
SE - Score Center Column, Low Peg- Will automatically extend the arm, close the roller claw's pneumatic "gripper", and initiate "suck mode" when the floor load mode is engaged.

- Will automatically retract the arm and stop the claw's motors when leaving floor load mode. There are no sensors in the claw to make it fully automatic, but the rollers and polycord belting all slip even with a tube acquired to make such sensors unnecessary. It's a looooong way to the claw if you want to wire even a single limit switch sensor - adds lots of wiring/weight relative to the value of the function. Anyone got any sources for a cheap, compact, lightweight *wireless* limit switch? :)



For most everything else, we will expect our pilot and copilot to handle the duties, including being very capable of operating the robot in full manual mode without any semiautomatic assists whatsoever. That, in fact, is what they have been practicing first and what they will be practicing the most. Our arm is simple enough this year to make that a relatively easy thing to do.

By the way, I really like the two-button "missile key" approach to deployment someone mentioned earlier. The usual way we typically prevent early deployment of a match-ending mechanism (ramps in 2007, servo pawl ratchet lock to keep us hanging in 2004) is to use a covered toggle switch. This would require the use of the Cypress board and a custom box, which again, we are trying to avoid, for simplicity's sake.

[rick.oliver]

- ... got any sources for a cheap, compact, lightweight *wireless* limit switch? :) ...

I asked our controls team to install a virtual coupler for wiring out to our gripper motors, to-date they have not found one. :D

[rick.oliver]

Our controls team uses two proximity switches to limit the arm rotation; one is set in the "home" position and the other is set for the floor pick up position on the oposite side of the machine. They installed an encoder on the arm shaft and use it to set the arm location in autonomous. They also programmed the capability to move the arm to specific locations for floor pickup, feeder station acquisition and hanging positions on each side of the machine (front and back).

They also installed and coded a gyro to ensure that we drive straight in to the grid and back out in auton. The arm extension and gripper rotation are accomplished by time in the code during auton.

[Phalanx]

We've got some automation for teleop.

Arcade Buttons for:
Get Tube:
Lowers our elevator to floor height and once there swings down/out an arm, grabs the tube off the floor and swings the arm back inside our robots frame (once at floor level it takes 3/4 of second). Works consistently.

Score Tube:
Moves the elevator to a preselected height based on 2 toggle switches.
1 switch is bottom, middle, top, the other switch is +8" or not.
Swings down/out the arm, grabber releases the tube on the peg. (1-3 seconds depending on the height total) *** This still needs a little tweaking ***

RESET:
Reset elevator, arm, grabber to default positions. Just in case something weird happens, we can reinitialize.

None of these automated functions care what position they begin from, they will adjust and adapt accordingly, even in mid function. This is done with 1 encoder, 1 limit switch, and some timed delays.

And lastly, just in case the automation fails there is still a manual override using a 3rd joystick.

[Madison]

Our robot has no automation of any kind in teleop...

We don't really have any arm sensors, as we don't have a string pot and we can't figure out how to mount anything else. It's a dead axle, so mounting a pot isn't trivial. Same with an encoder. Plus, we don't have any #25 idler sprockets to spare.

We've found a reasonably easy way of dealing with this and perhaps it'd be helpful to others.

We used a 10-turn pot. on the last chain stage that drives our four-bar linkage. We drill out a Tetrix wheel hub for the pot. shaft -- usually .25" -- and use its set screw to fix it to the shaft. We then laser cut a plastic sprocket and bolt it to the hub, but you could just as easily match drill a small AM sprocket. It's a bit clunky, perhaps, but the additional feedback is very helpful.

[Clayton Yocom]

We did a lot of nifty stuff for both the driver and operator.

Almost the entire movement of the arm is autonomously modified in some way or another, and we have pre-sets for where the arm should go to score. At last count I believe there are 14 buttons on the operator side of things, which sounds like alot until you realise that the operator now barely has to even touch the joystick.

For the driver, we have an invert controls switch (for picking up a piece from the station after scoring, without turning around manually), and a camera-lock key-combination. Camera-lock aligns the robot to the centermost pole in its view. Pretty nifty for scoring ;)

I find it interesting that this year's game is a very good testbed for autonomous code within the teleop functions (we even made some SubVIs for when we needed a function in both). It will also be interesting if the complicated, but very controlable driver/operator systems not using autonomous code will do better than those who use autonomous code.

[MagiChau]

For this year I will have a button for positioning the arm into floor-load based off of encoder values. There will be arm positions for scoring, based off of encoders. Had to put in some if then statements for speed modifiers so the arm doesn't zoom past the correct position or ram into the floor. I find this year's game very educational for programming with all the different things you could try for being more effective at accomplishing this year's objective.

[Chexposito]

We did presets for both the arm and wrist on all six positions. We had automatic shifting, but some people didn't want that... We also have our roller claw set up to suck in toobs automatically all the way in and keep them there. We also have it set up to where the robot automatically does the three things required to hang a tube automatically set up. There might be some servo stuff for making our camera follow our arm, but that's not official yet... I like the camera's current servo limits because we can look down on the electronics board and the components surrounding it.