Quote:
Originally Posted by Sohaib
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?
|
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.