Unique ways of controlling your robot (driving)

[Jared Russell]

Originally Posted by jtkellertx

We use one joystick.

Having mechanums, we can move in any direction. Being of the video game generation, I had it programmed like a helicopter. Forward is forward, back is back, left is a left straife, right is a right straife, twist left is a left rotation, twist right is a right rotation. It makes a bunch of intuitive sense. You can think of it as a helicoper or think of it as a first person shooter. We use a Saitek Avaitor USB joystick, attached to a USB chicklet. The top buttons are for the launch, arm pick up, and arm drop.

More techie description:
+Y = Forwards
-Y = Backwards
+X = Right Straife
-X = Left Straife
+Z = Right twist (right turn)
-Z = Left twist

We played around with this configuration the past two years with our omni-drive, but our drivers felt that it was "too much" for one hand. You would be trying to strafe when you inadvertently would twist the stick.

Stiffer springs in the joystick would have helped, but we moved onto a different control system that has helped our omni-drive bots win regionals in back-to-back years.

Left stick:
Y axis is forward/backward
X axis is turning (e.g. single stick drive with a skid-steer bot)

Right stick:
Y axis does nothing
X axis strafes

It seems unintuitive on paper, but if you have experience driving skid-steer bots with a single stick, it lets you transfer that knowledge while allowing you to strafe when needed.

[BigJ]

Originally Posted by Abwehr

We played around with this configuration the past two years with our omni-drive, but our drivers felt that it was "too much" for one hand. You would be trying to strafe when you inadvertently would twist the stick.

Stiffer springs in the joystick would have helped, but we moved onto a different control system that has helped our omni-drive bots win regionals in back-to-back years.

Left stick:
Y axis is forward/backward
X axis is turning (e.g. single stick drive with a skid-steer bot)

Right stick:
Y axis does nothing
X axis strafes

It seems unintuitive on paper, but if you have experience driving skid-steer bots with a single stick, it lets you transfer that knowledge while allowing you to strafe when needed.

So, do you translate at angles by mixing forward/backward and strafing then?

[Jared Russell]

Originally Posted by BigJ

So, do you translate at angles by mixing forward/backward and strafing then?

Yes.

We don't translate at angles very often anyhow - the nature of our drive geometry is designed to strongly favor the cardinal directions.

[AmoryG]

Part of training drivers is giving them multiple options to steer the bot. We programmed our controller so if you hit a button, it switches between different drive modes. This made it so anyone could practice any mode they wanted to just by hitting a button, not by reprogramming the robot.

One reason why I made this thread was also show off their actual programming for controlling their bots. I'm very interested in what other programmers decided to do. I've always liked unique ways of doing things, not for the sake of being different, but being inovative. Inovation means something new and because I'm new to programming new is all I know. If anyone is willing to explain or share their code so I can study it and learn from what other people do, that would be great.

The drive mode my team uses in the competition was developped from an algorithm. When I was thinking of better ways of controlling the bot, I thought a single joystick mode would be definately better than the 2 joystick tank control. I like algoritms better than plotting points on the joystick. It's more clean in my opinion and easier to reprogram.

I thought of how the robot should moving according to the position the joystick is in. If I push it forward, it goes farward. The more I push farward the faster it should go. What if I push the joystick diagnal so it's in the top left corner? I think the robot should turn gradually left in a wide arc.

So, I looked at motor speeds and plotted them onto a graph.

forwards (255, 255)
backwards (0,0)
arc left (127, 255)
arc right (255, 127)

255 the motors will be spinning full clockwise. 127 the motors will not be spinning. 0 the motors will be spinning full counterclockwise.

And so on...

I eventually discovered a cool way of doing this based on this...

On the joystick y-axis would run from bottom to top where bottom is 0 and top is 255. On the joystick x-axis would run from left to right where left is 0 and right is 255.

leftMotors = -127 + (y-axis + x-axis)
rightMotors = -127 + (y-axis + oposite of the x-axis (x-axis mirrored))

oposite of the x-axis means that if on the x axis it were really 255, it would count as 0 in the code.

[matt.winkler]

Originally Posted by Battering_Ram

I have been driving two years (171) and we have had tank drive both years. I really like this because it isolates the two sides of bot. But I will admit that I want to try the halo style so i will email my programmer right away. In my opinion I believe the one joystick is cramming to much onto one contoller, I'd rather isolate and have more precision(imo). But variety is the spice of life so I think its great how everyone does something different.

I have been involved on team 171 since the 1998 build season and to my knowledge, we have always done two independent joysticks with skid steer/tank style control. We have always had 2 operators. One operator is in sole control of driving and the second operator is in control of nearly all motor functions of the robot. I know that this can be tougher for some teams, but if your operators are in tune with each other, this can prove to be very efficient. It allows each of the operators to focus on a specific area of the competition and it removes some delays that may happen with other control styles.

Please keep in mind that I am not intending to bash any single joystick control system or any other very innovative control systems. I am only stating how we have done our robots in the past and the reasons behind our choices.

[Alan Anderson]

Originally Posted by AmoryG

Part of training drivers is giving them multiple options to steer the bot. We programmed our controller so if you hit a button, it switches between different drive modes. This made it so anyone could practice any mode they wanted to just by hitting a button, not by reprogramming the robot.

That was one of the things I did with our programming team pre-season. Our drivebase software for the past few years uses a "speed" and "turn" value, mixing them to derive the motor control PWM outputs. The values are traditionally derived from tank-style joystick input, with speed being the average of the sticks' y-axes and turn being the difference. I showed them how to derive them instead from a single joystick, driving in arcade mode. Then we split the direct speed and turn inputs to get them from different joysticks, driving like an RC airplane with separate throttle and rudder.

I preferred the airplane mode. Everyone else liked tank mode best.

I eventually discovered a cool way of doing this based on this...

On the joystick y-axis would run from bottom to top where bottom is 0 and top is 255. On the joystick x-axis would run from left to right where left is 0 and right is 255.

leftMotors = -127 + (y-axis + x-axis)
rightMotors = -127 + (y-axis + oposite of the x-axis (x-axis mirrored))

oposite of the x-axis means that if on the x axis it were really 255, it would count as 0 in the code.

That "cool way" is exactly what the default code does for single-joystick control. Take a look at its use of the LimitMix() function.

[AmoryG]

Is it really? I understood what it did, just not the logic behind it. How did they get those numbers? And by cool, I meant neat 8} not cool like "that's not what coool people do". Actually, I think we did try that code, but for some reason the controls were a bit different.

[AustinSchuh]

My favorite control setup is where you have a wheel and a throttle stick. The wheel controls turn radius not difference in power or something like that. The throttle stick is used to give the bot forward velocity. To deal with the fact that you can't do an in place turn that way, we have a button that you press to turn in place.

We currently implement this with motor power only, but I would like to implement it in using a PID controller. I just haven't been able to put good enough sensors on our bot to achieve that. Not enough resolution on the quadrature encoders.

[Alan Anderson]

Originally Posted by AmoryG

How did they get those numbers?

Are you asking about the inputs to the Limit_Mix() function in the default code?

  pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
  pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);

The 2000 is just to force the compiler to use 16-bit arithmetic. Otherwise it would decide that because p1_y, p1_x, and 127 each fit in eight bits, the addition and subtraction should be done with eight bits, and there could be overflows and unexpected results. Limit_Mix() itself subtracts 2000 when it returns the value.

The first line adds the x and y values, correcting the offset so that when both inputs are neutral (127) the sum is also neutral.

The second line does the same thing as the first, but it "mirrors" the x value by subtracting it from 254 first. Then it obscures that step by combining the new +254 and the -127 from the first line into a single +127.

[AmoryG]

Weird, it's mine exact. Wonder why it didn't seem the same when I was controlling it.... I guess I feel a bit stupid recreating the code that was right infront of me. What I don't understand is where is the code that says if(x-axis + y-axis < 0) motors = 0 or there the other way around if it's more than 255?

[Alan Anderson]

Originally Posted by AmoryG

What I don't understand is where is the code that says if(x-axis + y-axis < 0) motors = 0 or there the other way around if it's more than 255?

Look at the Limit_Mix() function. Doing that is the whole reason it exists. It limits the result of mixing the x and y axes of the joystick. The extra 2000 can be a little confusing, but I expect that you now understand why it is there.

[AmoryG]

I don't have the code infront of me, and I don't remember its full content, but yes I understand what it does.

[BigJ]

Originally Posted by AmoryG

One reason why I made this thread was also show off their actual programming for controlling their bots. I'm very interested in what other programmers decided to do. I've always liked unique ways of doing things, not for the sake of being different, but being inovative. Inovation means something new and because I'm new to programming new is all I know. If anyone is willing to explain or share their code so I can study it and learn from what other people do, that would be great.

Team 1675 developed their own Mecanum algorithm this year, based off an article explaining a drive system for 3+ wheel Omni systems. The main premise is that it calculates all angles using "b-rads", a measure of an angle using 8-bit numbers instead of degrees or radians.

It has worked pretty well for us, barring some mechanical problems. Here is some example code because Our forum is going through overhaul and I REALLY don't like the code blocks there. too hard to read.

/*!
* \file omniTest.c
* \author Jon C. Anderson <jon.c.anderson@gmail.com>
*
* \note This code is for educational use only.
*
* Controlling an holonomic drive is not very difficult. The force that can be
* exerted by omni-wheels correlate directly with a sine function that is phase
* shifted based on the desired heading. The angular velocity of the wheels is
* basically the magnitude of resulting sine function at the angle of the wheel
* to the "front" of the holonomic drive scaled by the desired fraction of the
* maximum speed.
*
* This file shows how to control an omni-directional robot with 4 wheels
* evenly spaced 90 degrees from each other. This also approximates a robot
* that uses Mecanum wheels with a pitch of 45 degrees in the diamond setup.
*
* This code is based on "Holonomic Drive Platforms: How to Drive a Robot That
* Has No Front" by Jack Buffington published in SERVO Magazine for April 2005
*/

#define WORD unsigned short int
#define BYTE unsigned char
#define INT16 short int
#define INT8 char

#include <stdio.h> /* for printf */

BYTE calcMotorVelocity( BYTE Speed, BYTE Heading, BYTE MotorAngle, INT8 Rotation );

BYTE mySin( BYTE Angle );

const BYTE sinTable[] = {
128, 131, 134, 137, 140, 143, 146, 149, 153, 156, 159, 162, 165, 168, 171,
174, 177, 180, 182, 185, 188, 191, 194, 196, 199, 201, 204, 207, 209, 211,
214, 216, 218, 220, 223, 225, 227, 229, 231, 232, 234, 236, 238, 239, 241,
242, 243, 245, 246, 247, 248, 249, 250, 251, 252, 253, 253, 254, 254, 255,
255, 255, 255, 255, 255, 255, 255, 255, 255, 254, 254, 253, 253, 252, 251,
251, 250, 249, 248, 247, 245, 244, 243, 241, 240, 238, 237, 235, 233, 232,
230, 228, 226, 224, 222, 219, 217, 215, 213, 210, 208, 205, 203, 200, 198,
195, 192, 189, 187, 184, 181, 178, 175, 172, 169, 166, 163, 160, 157, 154,
151, 148, 145, 142, 139, 135, 132, 129, 126, 123, 120, 116, 113, 110, 107,
104, 101, 98, 95, 92, 89, 86, 83, 80, 77, 74, 71, 68, 66, 63, 60, 57, 55,
52, 50, 47, 45, 42, 40, 38, 36, 33, 31, 29, 27, 25, 23, 22, 20, 18, 17, 15,
14, 12, 11, 10, 8, 7, 6, 5, 4, 4, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 1, 1, 2, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 16, 17, 19, 21, 23, 24,
26, 28, 30, 32, 35, 37, 39, 41, 44, 46, 48, 51, 54, 56, 59, 61, 64, 67, 70,
73, 75, 78, 81, 84, 87, 90, 93, 96, 99, 102, 106, 109, 112, 115, 118, 121,
124, 128 };

int main( void )
{
   /* This "Omni" bot has 4 wheels located 90 degrees from each other with
    * forward being at North
    */
   
   /*    PWM      Position  Position    Motor    *
    *   Output    (Compass) (b-rads) Orientation *
    *   ------    --------- -------- ----------- */
   BYTE pwm01; /*    NW        224     reverse   */
   BYTE pwm02; /*    NE         31     forward   */
   BYTE pwm03; /*    SW        159     reverse   */
   BYTE pwm04; /*    SE         96     forward   */
   
   BYTE mySpeed   = 254; /* Velocity scalar (0->stop, 255->full speed) */
   BYTE myHeading =   0;
   BYTE myTwist   =   0;
   
   pwm01 = calcMotorVelocity( mySpeed, myHeading, 224, myTwist );
   pwm02 = calcMotorVelocity( mySpeed, myHeading,  31, myTwist );
   pwm03 = calcMotorVelocity( mySpeed, myHeading, 159, myTwist );
   pwm04 = calcMotorVelocity( mySpeed, myHeading,  96, myTwist );
   
   printf( "m1:%i\tm2:%i\r\n\r\nm3:%i\tm4:%i\r\n", pwm01, pwm02, pwm03, pwm04 );
   
   return( 0 );
}

BYTE calcMotorVelocity( BYTE Speed, BYTE Heading, BYTE MotorAngle, INT8 Rotation )
{
   INT16 MotorOutput;
   
   Heading = MotorAngle + Heading;
      /* If your Mecanum drive is in the X configuration phase shift your heading
       * by 63 brads */
   
   /* MotorOutput = V * (scaler/divisor) + (zeroOffset - scaler)/2 *
    * MotorOutput = V * (Speed/256) + (256-Speed)/2                */
   MotorOutput = (((WORD)mySin( Heading ) * (WORD)Speed) >> 8) + ((256 - Speed) >> 1);
   
   MotorOutput += Rotation;
   
   /* Make sure that rotation has not caused an overflow */
   if( MotorOutput < 0 )
   {
      MotorOutput = 0;
   }
   else if( MotorOutput > 255 )
   {
      MotorOutput = 255;
   }
   
   return( (BYTE)MotorOutput );
}

BYTE mySin( BYTE Angle )
{
   /* This sin function is not very accurate, but should be good enough */
   return( sinTable[ Angle ] );
}

Our actual files all have a little more stuff in them, and we worked at making our code object-oriented this year, but nothing very very different from this.


You can check it out more here:

http://team1675.org/forum/viewtopic....start=15#p1352

(Out website is in overhaul so it may be a little funky.) Feel free to ask me any questions!

[AdamC]

I started driving 395's 'bot at the end of the Florida regional. We used to run a single joystick for our tank drive (Y did forward and backwards, X did pivots). I wasn't too fond of the very limited maneuverability the system provided though, so now we've gone dual joystick (using only Y axis to control the forward and backwards of each tread.) It's much more effective in my opinion. Although I always wanted to try a game controller, since I'm an avid Xbox player, and I think it would make the transition from racing game to robot racing easier.

[Nate Edwards]

We have switched between 1 and 2 several times:

2002 - 1
2003 - 2
2004 - 1
2005 - 1
2006 - 2
2007 - 2
2008 - 2 and Steering Wheel

We really liked the way it worked this year, we tried 1 with steering wheel, but you have more control we feel with 2 joysticks, so one driver had the steering wheel and other had the 2 joysticks. They really had to communicate well, which they did. The steering wheel was used mainly to help get out tight places and to turn left sharper, in both cases it proved to be the best solution for our particular bot as we consistently would get 5-7+ laps after the auto period.