User Interface - Drivetrain Controls

[Jon Stratis]

This seems to be a question everyone has, regardless of what your drive train looks like. Even a basic drive train can be controlled multiple ways - 1 joystick with acceleration and twist on it, two joysticks with acceleration for each side, two with acceleration on one and twist on another... you get the idea.

When you get to thinking about more omni-directional drive systems, people tend to go with a Halo-like system, since a huge number of people are familiar with that. But even in Halo, there are multiple control systems - just look in the settings. You can change which axis on your two joysticks controls strafing and which controls turning, you can invert your controls, you can adjust the sensitivity... And all of those options are used by people somewhere.

We've found that the best way to present this to the drive team is to give them choice, just like Halo gives people choice. We've traditionally had the programming team implement several of the above options and let the drivers try each one out. They're usually able to tell us pretty quickly what they like and don't like. While the driver interface is controlled during testing with a switch on the OI, we usually end up disabling that switch before competition to prevent the controls from being accidentally changed.

Of course, you're going beyond what we've done in the past. Essentially, your drive system is set up so you can mimic a multitude of other systems. For use in demonstrations, this is great. But to speak honestly... for use in competition it may just have too many options. I've seen teams with similar drive modules limit the degrees of freedom in the past, and use that very effectively - use it essentially as a tank drive, with a switch to rotate the wheels 90 degrees when needed, for example. Having all the control in the world does you no good if your driver can't use it all intuitively.

[JesseK]

Find an old i486 computer. Download Descent 2. Have your drivers play Descent 2. Then have them play it some more. If they still don't know what they want out of controlling excessive degrees of freedom, then find new drivers because you'll never be able to appease them.

In my general opinion, the driver him/herself should give opinions on what's best for control based upon experience. Our 2009 driver of an independent linkage drive train (like crab, but with 4 independent pods that have only 2 physical states of rotation 90 degrees apart and driven by pneumatics) wanted 8 'states' created so he could dynamically manipulate the center of rotation relative to the trailer. Some of the states were more effective than others.

Some drivers (like me) want mostly manual control of the DoF's because we can visualize what's mechanically happening and then tweak it in-game for more control or to do a fancy move without slowing down. Automation prevents the robot from doing what will damage it, yet otherwise it's mostly driver freedom. Automation also does things like keep two different power plants (motor/gearbox combo) in sync, automatic shifting, etc.

Another component is the drive train design itself. Nonadrive proved that adding degrees of freedom to a drive train does not always lead to more complex code or more complex control. Indeed, the Nonadrive can be made with the VEX system without modifying the default code that comes with the VEX kit (I know because I built it and I've never reprogrammed my VEX controller).

====

I will say anecdotally that making the driver use two hands for different movements is much better than 1 hand for everything. That way muscle memory is specific to a hand rather than fingers on a hand. The whole hand-eye coordination concept is easier if one 'hand' has a job that the other 'hand' does not (such as rotation vs. lateral). This proved true even when we swapped from Mecanum to Skid Steer this year (2010) -- when our driver wanted to go forward without accidentally starving power to one side of the drive train because he was out of the turning deadzone, he could.

The final thing to consider in implementation of control is what can happen in a demonstration environment when you invite the CEO of XYZ sponsoring company to come drive the robot. Having a sort of 'manual override' of sorts to control maximum allowed speed (i.e. set it to 4fps rather than 12), maximum rotation rate, etc, on the control board would allow the newbies to drive it without hurting themselves (or the bot) and the veterans to truly show off what the drive train is capable of. This can also be used in the pits at a competition and on a cramped practice field.

[kamocat]

How about one of those joysticks used for CADing?
http://en.wikipedia.org/wiki/3DConnexion
It should give you four degrees of freedom: foward/back, strafe, rotate, and up/down.
That's probably one more than you need, but I think it would provide more accurate control than a joystick. All that's needed is a driver to TREAT it like a joystick.

[Jared Russell]

My "rules of thumb" regarding drive control (all are my opinion, but I like to think that they are based in some semblance of rationality):

1. The most basic functions of any drive are "drive straight" and "turn in place". If your robot cannot do these things mechanically, you are probably in for a long season. Likewise, your driver should have to exert zero thought in order to pull off these maneuvers. For this reason, I generally like having a single stick for each function - driving forward at 50% power without turning is much easier with a single stick setup than with two sticks, IMO. Likewise, in the past we have used gyros and encoders to ensure that straight is straight.

2. If I take my hands off the controls, the robot better stop. Common sense, maybe, but I've helped teams who wanted to use a throttle without a spring return to control speed. Bad, bad idea.

3. I am wary of multiple drive "modes". The driver has enough to do without remembering whether he is in "car" vs. "tank" drive mode. Either find an optimal drive mode to live in, or make the switching automatic. In some sense, this is like the Markov property for drive control schemes - only the current position of my hands should affect the drive at any moment. Multiple drive modes also means multiple failure modes.

4. No more than 2 DOF per hand. Ideally, one. This stems from when we were trying to control an omni-drive robot in 2007 using a single 3-axis (twist) joystick. Everybody who tried driving would inevitably end up twisting when turning, or strafing when trying to twist, for example. Separating control between 2 hands (one stick for translation, one for twist OR one stick for FB/twist and one for strafe) made things more intuitive for everyone. For standard drives, I like one stick for F/B and one for turning.

[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)