Quote:
|
Originally Posted by Leav
thanks, that looks great and just what i need!
I have a couple of questions though:
|
Okay, I'm going as fast as I can!
Some of this code is specific to EasyC for Vex, but it should only take
slight tweaking to get this code to work for in EasyC for FRC.
Code:
GetRxInput ( 1 , 4 ) ;
GetRxInput ( 1 , 3 ) ;
GetRxInput ( 1 , 1 ) ;
The
GetRxInput() command gets the signal coming in from the Vex transmitter. The first number is the Rx Port, and the second number is the channel. So
GetRxInput ( 1 , 4 ) ; is getting the signal from RX Port 1, Channel 4. On the Vex Transmitter, here are how the channels are laid out:
Left Joystick, X-Axis: Channel 4
Left Joystick, Y-Axis: Channel 3
Right Joystick, X-Axis: Channel 1
Right Joystick, X-Axis: Channel 2
I am using the left joystick (both axis) to control the forward/reverse/left/right/diagonal movement, and the X-Axis on the right joystick to control the spin. There are also two additional channels (channels 5 and 6) on the Vex transmitter that are controlled via the push buttons on the back of the transmitter, but they weren't used for anything here.
2)Why did you cut all the joystick values in half?
Code:
leftx = leftx / 2 ;
lefty = lefty / 2 ;
spin = rightx / 2 ;
The way the signals are mixed here is that they are added or subtracted from 127 (neutral). Since the Vex Transmitter joystick values range from 0 - 255, using the operation
RF = LR = 127 + 255 - 0 ; would result in variable overflow, which wraps the PWM signal around to 0, and causes the motors to act weird, and causes lots of headaches...

This ensures that the variables will never overflow the 0 or 255 limit on the PWM signal.
3)something doesn't make sense:
let's say that the joystick is full forward with no spin
Code:
leftx = GetRxInput ( 1 , 4 ) ----->=127 ;
lefty = GetRxInput ( 1 , 3 ) ------>=256;
rightx = GetRxInput ( 1 , 1 ) ----->=127;
then:
Code:
leftx = leftx / 2 = 63;
lefty = lefty / 2 = 127 ;
spin = rightx / 2 = 63 ;
right?
and then:
Code:
LF = RR = lefty - leftx + 127 = 127-63+127=193 ;
RF = LR = 255 - lefty - leftx = 255-127-63=63;
RR = 255 - RR = 63;// Reverse Direction
LR = 255 - LR = 193 ; // Reverse Direction
and then:
Code:
RF = RF - spin + 63 = 63-63+63=63 ;
RR = RR - spin + 63 = 63-63+63=63;
LF = LF - spin + 63 = 193-63+63=193;
LR = LR - spin + 63 = 193-63+63=193;
so you end up with:
Code:
RF=63 ;
RR=63;
LF=193;
LR=193;
Quote:
|
Originally Posted by Leav
which would in my opinion induce spin on your robot (both right wheels goinf forward and both left wheels going back) while the stick is forward (assuming that vex motors use the same 0=full_backwards 127=stop and 256=full_forward configuration) as the FRC bots.
also, with full forward the motors only get up to 193 max 63 min values... (instead of 255 max and 0 min...) is this intentional?
|
This is correct, and will work exactly as planned. The robot will drive forward. Remember, when you have two motors, with each facing in opposite directions (such as the two transmissions on a tank-drive robot), you must spin the motors in
opposite directions to get the robot to drive forward. If you sent the same 255 signal to both transmissions, both transmissions would spin clockwise (or counter-clockwise, depending on the tranny). The robot would then spin in circles with a zero turn radius.
And yes, without doing an exponential curve to the values, you will only get half the PWM strength going through this algorithm when you are traveling orthogonally. This is because when you are traveling
diagonally, the values going to two of the corner motors are full speed (0 and 255), while the other two corners don't move at all (both are 127). For example, to go to the "Northeast" or travel towards "2 o' clock" relative to the front of the robot, the PWM signal to the motors will be:
Code:
255* / --- \ 127
127 \ --- / 0*
* These may be reversed depending on the rotation of the motor.