View Single Post
  #2   Spotlight this post!  
Unread 20-08-2010, 11:54
JesseK's Avatar
JesseK JesseK is offline
Expert Flybot Crasher
FRC #1885 (ILITE)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 3,704
JesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond repute
Re: User Interface - Drivetrain Controls

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

Drive Coach, 1885 (2007-present)
CAD Library Updated 5/1/16 - 2016 Curie/Carver Industrial Design Winner
GitHub