What things does your team do to ease things on drivers during the teleop? Does this limit driver control and do you have an over ride?
As a rookie team this year, we used a drive equation on the controller to allow the driver to control the robot precisely at low joystick inputs and still have full speed when they need it. We used a cubic function to do this.
Any neat implementations teams have out there?
Only have one driver. I’m a huge proponent of this. In 2012 and 2014 we were able to set up our control systems to be simple enough that it only took one driver to drive.
Automate as much as you can. I realize that the 7 +/- 2 rule isn’t a one-to-one with usability, but its worth considering. Try to leave your driver’s brain open to the game rather than the operation of the robot’s mechanisms.
Model controls after video games. We tend to use an xbox controller, so modelling the control system after video games helps to make the robot immediately intuitive to drive.
I see, thats quite interesting. Any things in particular that you automate?
Often teams automate certain sequences, like arm height presets or shooting methods which require multiple steps. Basically automate anything that is done with the robot predictably and in the same way every time.
In 2012, the big thing we automated was the dual sided collector. It was bit tricky, but with 3 banner sensors we were able to automate it so it would only collect 3 balls, so for the most part our driver just had to drive over the balls and not really worry about the 3 ball limit. It also handled spacing between balls, to help with consistency when shooting each ball.
Last year, thanks to the mechanical team, we were able to come up with a really simple setup. The collector and shooter were part of the same apparatus, so we only needed on limit switch in the collect position. Basically we had a pass button, a shoot button, and a lop (grenade) button.
When the mechanical team is working on designing the systems, it’s important to keep the conversation open about what processes should be automated, and how to automate them. Figure out what sensors you’ll need early on, and try to order extras.
Also the conversation is important to have if you’re trying to with the IIC award. It takes a lot of cooperation and clever thinking from a mechanical, electrical, and software standpoint to win. That being said, if you design a robot to perform well in autonomous and target the awards, there’s a good chance your robot will be good at the game as well.
I always describe our code as taking suggestions from the drivers on what to do. 
If the robot doesn’t want to do what you are asking, good luck changing it’s mind.
This years bot had a variable power shooter, and a claw that was positioned by two independent motors. We were confident enough in our code that there was no way for the manipulator to command the motors directly.
We were able to boil the interface down to a bunch of shot presets, and a couple intake buttons. Each shot preset would move the claw to the correct position, and change the shot power, all automatically. The intake buttons let us spin the rollers in, spin them back out, and move the claw to the intake position. The shoot button waits until the shooter and claw are in position, and then fires.
For the shooter, we had a state machine and control loop which would run the sequence of actions to load the shooter, lock it in place, and change the power. For the claws, we had a state machine to run a homing sequence at the start, and a control loop to move them to the requested positions.
My goal has always been to boil the interface down to the simplest set of buttons/joysticks possible to give the driver a very accurate, simple, and powerful interface. We don’t want them to not be able to do what they need to do because the interface is too simple, but we also don’t want them doing things manually that are best done by a robot.
Interesting, I’ve always held the opposite viewpoint, that 2 drivers are better than one. What does your other driver do during the match then?
I’m more for one driver as well if you can. With a one driver set up, you can get shots off in a shorter window of time, as well as avoid potential mis-communications. I think the most effective setup was probably 1114’s. They had two drivers, but the main driver also had a button allowing them to shoot and the operator would set it up for certain shots. I think that’s how they managed to pull of those crazy angle shots on Einstien this year.
I’ve always held the same opinion. In 2012, we gave our driver the button to climb the bump. He would always stop, hit the button, and then climb the bump. When we took it away from him and gave it to the manipulator, we were able to climb the bump at full speed. It might be harder to train two people to work together, but in my experience, it is worth it.
I’d say it’s more of a robot-complexity determined thing. If all my robot does is drive, shoot, and pick up something (and you’re doing these things in a very simple way), in many cases that second driver is slowing things down. At least, that’s what 2220 found this last year. Our second driver essentially served as a second coach and strategy analyst embedded in the drive team. Worked out pretty well in my opinion.
In comparison, 2011 was a fantastic year for two drivers for us (when the robot was working), because we were running a swerve drive and driving that was a big change for our driver, who was used to tank-style drive.
With some robots, there’s a clear decision to be made, but with the majority I think it’s really a team preference thing. Your “second driver” doesn’t need to have their hands on the controls to be useful during a match.
We send out our lead programmer. It’s his job to run diagnostics and make sure everything looks green. This allows our driver to focus on driving and our coach to focus on coaching. This is especially important when something goes critically wrong with the robot mid match.