User Interface - Drivetrain Controls

[Siri]

What controls do you give your drivers to operate your robot's drivetrain? I'm not a programmer, so though I'm sure the technical detail would be useful to other, I'm personally asking more about the user interface/experience itself. Especially for more complex drivetrains (e.g. crab/snake/pivot), how to you control and present these additional degrees of freedom to your drivers?


I ask this specifically because my team made a 4-wheel independent pivot drive this year. It's a great drive train and has a lot of potential, but we're still experimenting with how best to control the additional DoFs. We currently have crab and snake drives, a center twist and a ball pivot. Mechanically we can handle automobile and tank drive, absolute and relative crab twists, and X-bias snake as well. None of us, including the drive team, is really sure how to most efficiently and intuitively present all this to the driver.

We work with their feedback (I'm actually a drive coach, not a programmer), but I'm willing to bet there are a lot of options we're unfamiliar with. We spent this season using Halo-like Xbox controls; unfortunately our driver doesn't play Halo. (We're inclined there's another solution besides simply changing this. ) Any input is much appreciated.

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

[Ether]

Originally Posted by Siri

we're still experimenting with how best to control the additional DoFs. We currently have crab and snake drives, a center twist and a ball pivot. Mechanically we can handle automobile and tank drive, absolute and relative crab twists, and X-bias snake as well. None of us, including the drive team, is really sure how to most efficiently and intuitively present all this to the driver.

Nice looking design!

The driver presentation problem for your 4-wheel independent swerve is no different from the driver presentation problem for a 4-wheel mecanum or 4-wheel omni.

On a flat surface, your drive cannot perform any vehicle motions that the mecanum or omni cannot. All three vehicles have the same three degrees of freedom: 2 translational and one rotational. So the driver presentation is the same.

So the good news is, you can ask around to see if any teams with mecanum or omni vehicles have developed interesting and intuitive driver presentations, and if so you can borrow from that. And vice-versa: if your team develops a unique and intuitive driver presentation, any team with mecanum or omni can do the same if desired.

The other good news is, your drive has the potential for significantly better maximum vehicle traction than mecanum or omni (because of the physics of how they work and how the floor reaction forces are directed).

Even though the driver presentation is the same, the algorithms to convert the driver inputs to wheel speed (and angle in the case of your drive) are completely different problems. The bad news is, these algorithms are probably more complex for a swerve drive since both wheel speed and wheel angle must be carefully coordinated and tightly controlled.

~

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

[Siri]

Originally Posted by eagle33199

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.

I'm glad this works for you, it's our goal as well. We have somewhat limited programming resources (i.e. returning people) currently, so I'm trying to narrow down the options we ask for. We definitely want the drivers to try the promising UIs in person, though. (I was a driver throughout my student membership, I don't underestimate the importance of this.) Thanks for the on board OI switch idea. I foresee that saving a lot of time!

Too many options: I completely agree. Part of what we're trying to figure out here is how to limit our DoFs. We certainly don't need them all.

Originally Posted by Ether

...On a flat surface, your drive cannot perform any vehicle motions that the mecanum or omni cannot. All three vehicles have the same three degrees of freedom: 2 translational and one rotational. So the driver presentation is the same...

In general, our DoFs are the same. Independent-turn pivot does allow X & Y-bias snake drive, which (as far as I know), one can't do in mecanum or omni. In a sense, we also actually have more than one rotational DoF, because we can select the centerpoints of our twists. I haven't tried the math for mecanum concerning this, so I'm not sure how complicated/possible varying the CP would be on that platform. (Independently driven omni would seem to allow for this as well, but again I haven't tried.)

As far as holonomic control strategy though, that's exactly what this thread is for. We've talked to a few teams in person and received some helpful information. Many have tended to go the Halo route though, so I'm asking to see if people have other strategies. When we do figure out a successful theory, I fully intend to share it.

Maximum traction: That was one of our main reasons for trying pivot this year. It's definitely (albeit unsurprisingly) worked. We can push most standard tank drives off-axis for the same reason. Some we can push head-to-head as well, but that's more power transmission design than holonomics and transverse vs inline frictional coefficients.

Algorithms: Yes, much more complicated. It's an interesting learning curve, but we're getting there. Nonadrive definitely has its benefits, though (albeit not just in control theory).

Originally Posted by JesseK

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.

Thanks for the example! This type of constraining is exactly what we're going for; I think we've just overwhelmed our driver to the point where isolating the best case is rather difficult. We're continuing to work on it, and examples are very helpful in that, thanks.

Two hands: This makes sense. We're actually doing one version of this currently: rotational+crab on one of the analog sticks and longitudinal snake on the other. It doesn't work so well for us, but perhaps a different combination.

Demos: We currently have a few different drive versions for demos/competitions, including one that disables everything except the kicker (great for young kids--highly recommend it). Never considered controlling maximum speed for the demos/pit. Smart, thanks.

Decent 2: I read the Wikipedia navigation section for the original Decent. Interesting. (Ambiguous and a little worrisome, but interesting.) Care to give me a hint, or do I need to go track down a game first released in '96?


Kamocat: 3D mice are indeed awesome. We've used them in graphical representations for higher-level calculus, and they work fantastically. Has any FRC team done this, though? The vertical axis would prove interesting in robot control, and accommodating snake is still not entirely straight-forward. Certainly a creative idea. Given our team's resources, though I'm personally not quite ready to spring for an $80 mouse that my driver's never used and my programmers have never programmed, to be used in a dynamic live action environment I've never seen it applied to. Now if I could wrangle a donation...

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

[Ether]

Originally Posted by Siri

Independent-turn pivot does allow X & Y-bias snake drive, which (as far as I know), one can't do in mecanum or omni.

A rigid vehicle operating on a flat surface has a maximum of only 3 degrees of freedom: 2 translational and 1 rotational. Any possible motion of the vehicle (on the flat surface) can be accomplished by the appropriate combination of these three degrees of freedom. Any motion your drive can do (on a flat surface) can also be done with a mecanum or omni vehicle.

For example, if you want the vehicle to revolve around a central point while at the same time rotating about its own axis (like the Moon around the Earth), that motion can be specified in terms of the 3 degrees of freedom mentioned above, and the mecanum, omni, and your drive can do it.

Or, if you want the vehicle to spin its back end around and pivot around a point located between the front wheels, a mecanum or omni can do that as well (again, as a combination of the 2 translational and 1 rotational degrees of freedom of the vehicle).

Or if you want the vehicle to go forward in a straight line while simultaneously spinning around its center, a mecanum or omni can do that too. (Although it would require a very talented and dextrous driver to do so!)

Any conceivable vehicle motion on the flat surface can be accomplished by the proper (time-varying) instantaneous wheel speeds (and angles). As long as the drive motors have the necessary dynamic response to create the necessary time-varying wheel speeds (and angles), the desired vehicle motion can be accomplished.

The "inverse kinematic problem" is to determine, given a desired instantaneous vehicle motion, what each of the four wheel speeds should be (in the case of mecanum or omni), or what each of the four wheel speeds plus wheel angles should be (in the case of your drive), to achieve the desired instantaneous vehicle motion.

The "forward kinematic problem" is to determine what vehicle motion will result from an arbitrary choice of wheel speeds (and angles). In general, this has no solution. Only properly coordinated sets of speeds (and angles) will result in vehicle motion without "scrubbing" the wheels on the floor.

Considering the above, the way to give your driver "complete manual control" is to allow them to independently command forward/reverse, strafe left/right, and spin CW/CCW. All possible motions of the vehicle can be accomplished by these three degrees of freedom. But, this may NOT be the best "driver presentation", depending on what types of motion the driver wants to do, because it may be too difficult for the driver to think that fast. For example, as mentioned above a mecanum or omni vehicle is mechanically capable of going in a straight line while simultaneously spinning, but I highly doubt a driver could do it without computer assistance. If a competition required this type of motion, you would want to provide a gyro and/or accelerometer or whatever on the vehicle so that the driver commands could be interpreted as field-oriented commands and then translated on-the-fly by the cRIO into the correct wheel speeds (and angles).

There's an excellent text which discusses this (cf especially Chapter 3) if you want to research it further:

Mechanics of Robotic Manipulation
Mason, Matthew T.
Cambridge, Mass. : MIT Press, c2001

~

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

Decent 2: I read the Wikipedia navigation section for the original Decent. Interesting. (Ambiguous and a little worrisome, but interesting.) Care to give me a hint, or do I need to go track down a game first released in '96?

And that statement makes me feel old. Really old. I'm using Dosbox to run a ton of games from that era and older (MOO, MOOII, Descent, Descent II, Lost Vikings, to name a few...) on my laptop. Mostly I only play them when traveling (it's a nice way to kill a few hours on an airplane!)... but it's sad to know that i don't have to "track down" any classic computer game - just go pull it off the top shelf where I've archived it all...

That being said, if you're going to try tracking it down in order to experience it... be careful. There are a ton of sites out there that allow free downloads of games from that era, classifying them as "abandonware", making you think it's ok... but for a vast majority of those titles, someone still holds the copyright and downloading it from those sites is copyright infringement, just like downloading music or movies illegally. The game is only abandoned in the sense that the company doesn't support it anymore.

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