User Interface - Drivetrain Controls

[s_forbes]

As someone who has had the privilege of driving robots in competitions, I would echo most of Jared's points. Especially the part about separating the primary drive functions to different hands. In 2008 we implemented an RC car controller (seen here) and every team member with driving experience quickly picked it up and preferred it to the traditional 'tank drive' style of control.

Having never played with omnidirectional FIRST robots, I can't say which method works best. I did have the fun problem of figuring out the omnidirectional control set up for our underwater robot however, which had a lot of stuff to cover:

- ROV has 5 degrees of freedom of motion (pitch, yaw, and translation in x y and z)
- Manipulator has 2 degrees of freedom (grasp, rotate)
- Camera tilt
- Various other functions (lighting, torpedo launching, camera centering)

To have the ROV actually be driven well, we wanted all of these operations to be controlled by one person. The solution we came up with was using a PS2 controller and mapping the different movements in a sensible way. Left joystick covered translational movements on the horizontal plane while right joystick covered turning left/right and moving up/down (surprisingly similar to first person shooter game controls... they must be doing something right). Claw open/close and ROV pitch were controlled by the PS2 triggers, and all other 'less critical' operations were put on the buttons. A neat feature of a PS2 controller: all buttons and triggers are pressure sensitive and can basically be used as analog controls.

As usual, putting a lot of thought into the control system only gets you so far. The driver needs gobs of practice for it to pay off!

As a last little note, I would also add that working with smaller controllers (as in video game controller, RC controller, etc. instead of large PC joysticks) gives more fine control over movements. Human fingers are good at precisely manipulating objects; I could never grasp why so many teams use large joysticks that require arm and wrist movements.

[Jon Stratis]

Originally Posted by s_forbes

As a last little note, I would also add that working with smaller controllers (as in video game controller, RC controller, etc. instead of large PC joysticks) gives more fine control over movements. Human fingers are good at precisely manipulating objects; I could never grasp why so many teams use large joysticks that require arm and wrist movements.

I wouldn't be so sure of that. We've found that using standard video game controllers, while cool, overall gives you less fine control than joysticks. It can be more difficult to get low speed, fine control using thumbs with a short joystick than it is to use your hands with a longer joystick. Move your thumbs 2 centimeters forward and you're at full speed. Move the top of a joystick two centimeters forward, and you're still going pretty slow.

[kamocat]

How about this:
Use a sprung resistor-based steering wheel for turn.
Use a foot pedal for forward speed.
Use a sprung lever for strafe.
Use a switch swap the front and back of the robot.

To make these, you can buy a cheap 3-axis USB joystick, take it apart, and wire your own potentiometers to it.

[JesseK]

Descent 2 is a fps-style game from a long time ago that was waaay ahead of its time in graphics and gameplay. It still has a cult-like following, though none of us ever expect there to be a Descent 4 because of ... well who knows why that company sits on its hands and the liscensing.

Like an underwater ROV, the ship in Descent 2 is in ultra-low gravity and has 6 degrees of freedom (roll, pitch, yaw, x, y, z). The default controls for that game were a single joystick with a 4-direction hat and 4 keys on the keyboard, however I'm sure that was only because of the rudimentary technology of the time (like the OS, lack of USB, etc). The ballistics in the game also meant you had to aim ahead of the target's movement as well.

In playing the game at my peak I could control roll, pitch, and yaw while varying strafe movements in order to circle-strafe and hit a target as it moved in a somewhat predictable line. It relates to FRC since a good pilot of Descent 2 would understand what's possible on-field with a true-holonomic drive train. It's the same without the roll, pitch, and z. Flying in Descent 2 would allow a driver to come up with the best way he/she is comfortable driving rather than having to conform to what the programmers and everyone else thinks is best. These days you can use multiple input devices instead of just the joystick/keyboard. However, the game's actual value is probably only realized if a potential driver plays the game well ahead of the build season since you really don't want to have to take excessive time trying to decide during the season.

(Descent 3 missed the mark -- it's not as responsive control-wise, though some of the environments were nice. D3 also kept crashing on me at the time. If they never make a 4th I will resolve myself to making a 6-DoF quadrotor or ROV when I'm done with grad school.)

[BEEKMAN]

This past year, our programmers went with three different systems. We realized that there are three types of people: Gamers, drivers, and others. Gamers are used to tank, robot oriented, manual drive systems. Drivers are used to turning, steering and accelerating. Others are used to nothing, therefore they want something simple, yet complex, and easy to use. We accomplished this with a LOT of fine tuned programming (I don't want to hijack this thread with a lot of programming) . Our mechanum system was programmed in such a way that pretty much anyone can drive it.

Another nice way to provide feedback in a simple way. For example, instead of a textbox saying "Drive motor failure on left front wheel" How about putting a top view of your robot, and making the corners of the robot blink depending on the status? Pictures are more user friendly, and make the driving experience a lot nicer (I can say this as a programmer and 2 year drive team member)

[kamocat]

One thing that makes driving a LOT easier (especially at slow speeds) is using speed-control with PID as opposed to open-loop control.
This does lead to two issues:

1. You must tune the PID
2. If the joysticks don't re-center perfectly when you let go, there is slight movement instead of the "stopped" you might want. (usually less than 1% full speed) This is because the "deadband" to deal with this is actually on the motor controller, not the joystick, and PID is a method of ensuring that the motors do what you tell them to.

[Ether]

Originally Posted by kamocat

If the joysticks don't re-center perfectly when you let go, there is slight movement instead of the "stopped" you might want. (usually less than 1% full speed) This is because the "deadband" to deal with this is actually on the motor controller, not the joystick...[/list]

if this is a problem, I suppose you could add your own deadband to the joystick commands before sending them to the controller


~

[Dkt01]

1756 used a mecanum drive train controlled by an XBox controller. The left joystick made the robot move straight forward, backward, left or right. We programmed the robot not to move at any angles because the PID couldn't keep the robot facing the same direction well enough. The right joystick controlled the robot's rotation.
While programming the robot we assigned one of the buttons on the right side of the controller to switch drive modes, but we disabled that for driver training and competition because it was to easy to change accidentally.
The controls seemed pretty good, our robot just got stuck too easily. We liked the XBox controller better than full-sized joysticks and are considering using a corded PS3 controller next year so we can have gyro/accelerometer input options.

[Ether]

Originally Posted by Dkt01

The left joystick made the robot move straight forward, backward, left or right. We programmed the robot not to move at any angles because the PID couldn't keep the robot facing the same direction well enough. The right joystick controlled the robot's rotation.

What I think I hear you saying is that you used closed-loop speed control for the wheels, but when you commanded the vehicle to go, say, diagonally, it tended to rotate somewhat, even though no rotate command was being given. Am I understanding you correctly so far? And when you then "programmed the robot not to move at any angles" what you did was to add logic to command only fwd/rev or strafe, but never a combination of the two, and that corrected the problem so that the robot would now move either fwd/rev or strafe, with no unwanted rotation. Is that also correct?


~

[Chris is me]

Originally Posted by kamocat

If the joysticks don't re-center perfectly when you let go, there is slight movement instead of the "stopped" you might want. (usually less than 1% full speed) This is because the "deadband" to deal with this is actually on the motor controller, not the joystick, and PID is a method of ensuring that the motors do what you tell them to.

The "deadband" is not a speed controller side problem... The speed controller deadband actually increases the number of possible PWM inputs that get you zero motion. Any "moving when centered" problem is on the joystick side. It's particularly notable on Xbox 360 controllers.

Regardless deadband is easy to fix with simple scaling functions, you don't even need PID.

[kamocat]

Originally Posted by Chris is me

The "deadband" is not a speed controller side problem... The speed controller deadband actually increases the number of possible PWM inputs that get you zero motion. Any "moving when centered" problem is on the joystick side. It's particularly notable on Xbox 360 controllers.

Regardless deadband is easy to fix with simple scaling functions, you don't even need PID.

Perhaps I was unclear.
In the LabVIEW software, the deadband is implemented in the "Motor SetOut" function, not the "Joystick get" function. In addition, the motor controllers themselves actually DO have a deadband for PWM-based control and for CAN voltage mode.
PID will render the deadband inneffective because it treats it as error. If the joystick is just barely off of centered, then well-tuned PID will make the motor go at 1/128th of its full speed, though you might intend it to be stopped.
Yes, it is easy to implement your own deadband, but it's important to know that until you do, the robot won't completely stop when you let go of the joystick(s).

Removing the deadband is not the purpose of PID. PID is used to ensure the motors run at the rate you tell them, regardless of battery voltage, friction, load, or variations in the motors themselves. (The speed range of the motors is limited by battery voltage, but within that limit they will still perform at your setpoint)