[artdutra04]

Originally Posted by daltore

Why is it necessary to cap the values at the maximums and minimums? Does the processor not automatically do this? I've always found it easier to subtract values from full drive and having the motors that need to be full power just have values greater than 255 and subtracting values from the other wheels instead of just starting from half power for everything. That way, you get full speed, but everything still works fine. I've never done a holonomic function, but this usually works fine for homemade arcade drives and the similar.

It's much better to code defensively, as opposed to rely on other things to fix your mistakes. I could have used unsigned char for the calculations to save memory, but then any overflow values would wrap back around and reverse motor direction. So I used int variables for the calculations and then manually check to make sure they are all within bounds. It's a safety measure.

Originally Posted by daltore

Also, please correct me when I say the obvious thing I'm missing, but the algorithm doesn't quite look right:

            LF = RR = lefty - leftx + 127 ;
            RF = LR = 255 - lefty - leftx ;

The first one would seem to stop the front left and rear right motors if the joystick goes to the upper right or bottom left, which would defeat the purpose of being able to translate diagonally, wouldn't it? As for the second one, it looks like it would barely have any power even when the joystick was straight forward, and again stopped when going to the upper left or bottom right. I know I'm probably missing something here, but I can't seem to get it. Is this what the adding 63 is supposed to solve? I figured that was to offset the below 127 motor values for spinning.

I'm designing a robot to drive this way for practicing during Elevation, and I've not yet had time to start (notice the 4 weeks between BEST competition and VEX).

Any clue what I'm missing?

I derived those equations from taking the eight directions (N, NE, E, SE, E, SW, W, NW) and writing down the necessary motor values needed to make them work. From there, I worked backwards to get the algorithm above. You can test this by plugging in values that you would get from a transmitter for the above scenarios, and then testing calculate the output signal at the motors.

For example, the robot is moving right at "full speed" while spinning slightly:
255 = GetRxInput ( 1 , 4 ) ; // Left Joystick, X Axis
127 = GetRxInput ( 1 , 3 ) ; // Left Joystick, Y Axis
180 = GetRxInput ( 1 , 1 ) ; // Right Joystick, X Axis

// Half the input signal (so code does not overflow past 255)
128 = leftx / 2 ;
64 = lefty / 2 ;
90 = rightx / 2 ;

// Drive Code Algorithim (note how "full speed" only sends half speed values to the motors to avoid saturation).
63 = 63 = 64 - 128 + 127 ;
63 = 63 = 255 - 64 - 128 ;
192 = 255 - RR ; // Reverse Direction of RR motor
192 = 255 - LR ; // Reverse Direction of LR motor

// Spin Code Algorithim (Since we were only at half speed values before, the spin values have room to work with)
36 = 63 - 90 + 63 ; // RF
165 = 192 - 90 + 63 ; // RR
36 = 63 - 90 + 63 ; // LF
165 = 192 - 90 + 63 ; // LR

Now is this algorithm perfect? No. In the N, E, S, and W directions the robot never travels at maximum speed; only when the robot goes diagonally do the motors reach their limits of zero and 255. You can overcompensate this by saturating the equation by not diving the leftx or lefty variables in half, but this will take away maneuverability. You can experiment with this by tweaking the constants to see how the system responds.

A video of this code working is available here: http://www.team228.org/media/video/view/9

Another thing to keep in mind is that this is entirely open-loop; there are no sensors for feedback. Forward is always relative to the front of the robot. By adding a gyro to the robot, getting the angle of the joystick ( angle = atan(lefty/leftx); // I'm pretty sure math.h does everything in radians. You can also write a lookup table to save the processor from imploding. ), getting the angle of the robot (you'll also need to integrate results to keep track of robot angle over time), then you can then use slightly different algoritms to make sure the robot always goes in the direction of the joystick - no matter what way the robot is pointing.

But that's a good exercise that one should experiment with and learn on their own. I posted the my basic holonomic drive code just so people can get past that initial hump of figuring out how to make it work (and judging by the number of teams I see with omni/mecanum drive that never strafe, this hump can be high).