User Interface - Drivetrain Controls

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


~

[GGCO]

Xbox 360 controllers. Joysticks are WAY too inaccurate considering your whole arm is involved with moving them. For the most precise control, thumbs win.

[AdamHeard]

Originally Posted by GGCO

Xbox 360 controllers. Joysticks are WAY too inaccurate considering your whole arm is involved with moving them. For the most precise control, thumbs win.

I actually disagree here.

I've wasted too much of my life accumulating too many level 50's in Halo 2/3 (Glad I'm done with that...), and used a 360 controller to drive 294's 2007 robot. It worked, I THOUGHT I liked it; During practice while coaching my new drivers who use a separate joystick for throttle and steering (actually, same setup as on the 360 controller, just using joysticks), I found I personally much prefer the joysticks and was able to perform better with them.

[Siri]

Jared - thanks very much for the "rules of thumb". Those will help a lot in refining our UI. Given how Daisy drives, I'd definitely agree your rationale is well founded! The 2 DOF per hand thing will prove interesting, but I think it's wise. We've run into the same problem as well.

Ether - Thank your for the article. I understand that one can technically parameterize snake-like & dynamic relative twist movements for any truly holonomic drive, but I hadn't tried the kinematics for either. I've never heard of an omni bot implementing snake-like movement, but that shouldn't have lead me to ruling out the option. My oversight, apologies. Also, if you're already out there, please feel free to step forward. And link your white paper, because that's just plain cool.
I had actually intended my comment concerning snake/pivot control to ask how such bots manage their additional input (not output, sorry) variables--namely wheel orientation--in using their DOFs (or perhaps I should say freedom in general). This was a nomenclature failure on my part, sorry.

BEEKMAN - I'd be interested in learning more about your mecanum's UI mapping. The technical detail would go over my head, but the "pretty much anyone can drive it" comment is very compelling. Feel free to PM me if you're still worried about thread hijacking.

Decent II: Interesting. I'll bug our video game gurus and see if they can dig this up (legally).

Joysticks: I have to agree with eagle, while your wrist may have less manual dexterity than your thumb, the joystick scale is much larger than a game controller's analog sticks. (Though I'd guess some of this is up to the speed control, etc algorithms.) Our current driver is starting to lean back towards joysticks, but it does understandably seem to vary based on how much of a gamer one is. A steering wheel though, that's an idea. Wonder if our driver's ever doing to get her license.

[Dkt01]

Ether-
We actually ended up doing what we called a "Pac-Man drive". Our system compared the values for the x and y axes and only used the greater of the two. For example if the left joystick was in a position where x=.8 and y=.2, the robot would move right at 80% speed.
You are correct in saying the robot would only go forward/backward or strafe, but no combination. This solved our unwanted rotation problem.
We also used a custom dead band because the XBox controllers never went back to the exact same spot, but other than that we never had any issues. Unfortunately the directional arrows on the left never gave us usable input values, otherwise we may have used them for something.

[Ether]

Originally Posted by Dkt01

Our system compared the values for the x and y axes and only used the greater of the two. For example if the left joystick was in a position where x=.8 and y=.2, the robot would move right at 80% speed.
You are correct in saying the robot would only go forward/backward or strafe, but no combination. This solved our unwanted rotation problem.

I'm glad you found a solution that worked. In the heat of battle or in a time crunch, you've got to go with what works.

But now that you're in the off-season, you might want to go back and ask why you were getting the unwanted rotation. It seems odd that you could strafe with no rotation, and you could go forward/reverse with no rotation, but you could not go diagonally without rotating. Could you tell us a bit about how you programmed the wheel speeds?

~

[Dkt01]

Ether-
Since our team doesn't have much as far as an off-season program, I can't get very specific. We basically used the LabView holonomic drive. We added in a PID control which used gyro readings to keep the robot facing the same direction. The PID adjusted robot rotation to compensate for the unwanted rotation. For some reason, no matter how much we tuned the PID, the robot rotated when driving at angles other than 0, 90, 180, or 270. This year, depending on the game, we may try to build off this system so it can work at other angles. We spent a lot of time this year learning LabView (none of us had used it) and dissecting SubVI's to see how they functioned, so we ran out of time to work out all the bugs.

[Ether]

We basically used the LabView holonomic drive. We added in a PID control which used gyro readings to keep the robot facing the same direction. The PID adjusted robot rotation to compensate for the unwanted rotation. For some reason, no matter how much we tuned the PID, the robot rotated when driving at angles other than 0, 90, 180, or 270.

Thanks for the clarification. If you guys figure it out, I'd be very interested to hear what you found, if you're willing to share.

~

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

[JDM]

2199 used mecanum drive for the first time this year. We found that using any combination of joysticks wasn't intuitive, but with a three-axis joystick (as Jared pointed out) it was too easy to twist by accident. What we did was to use the bottom "throttle" controller on the joystick as a multiplier for the twist (from zero to one). This actually worked surprisingly well to keep us straight when we wanted, rotating easily when we needed to, and helped control the rate of rotation (it was pretty darn fast).

On top of that, we used CAN w/ speed control and cubed all joystick inputs. There were no other controls other than the trigger to activate our kicker. I noticed with this that new drivers were able to reach a level of competency much faster than with tank drive (which worked very well for us, but we've also had very experienced drivers).