Something that can make a big difference in coding is the addition of an exponential response curve to the code, which makes the robot sound nicer, drive easier and just make it generally a much nicer drive. Here is how we implemented this post season in our '06 robot.
First, a graphing calculator was used to generate the exponential function from a list of data (we used a Texas Instruments TI-86) of our desired data. In our case we wanted a deadband of 5 units on either side of 127 (122-132) to reduce the chance of bumps causing unwanted motion, we also wanted the PWMs to start at a value 10 off of 127 (137 and 117) to reduce the grinding sounds and useless joystick travel caused by having Victor outputs too low to move the robot. (ideally this number would be determined experimentally, but in our case we just guessed) It was decided that a 128 value lookup table would be used since the forward motion and reverse motion parts would be mirror images, however, in retrospect, a 255 value one would be a bit easier and less error prone. So, we entered (6,10) and (127,127) into the calculator’s “List” and had it calculate the exponential function of best fit, which ended up being Y = 8.8158853016587*1.0212271323857^X where X is the joystick input.
For lookup table creation we used a Excel spreadsheet which I’ve attached instead of explaining. The numbers from the Excel spreadsheet were then exported in comma delimited form, and Word was used to replace the ","s with ", "s. This was copied into the code, so lookup table in the code looked like:
rom const unsigned char pwmlookup[128] =
{
0, 0, 0, 0, 0, 0, 10, 10, 10, 11, 11, 11, 11,
12, 12, 12, 12, 13, 13, 13, 13, 14, 14, 14, 15,
15, 15, 16, 16, 16, 17, 17, 17, 18, 18, 18, 19,
19, 20, 20, 20, 21, 21, 22, 22, 23, 23, 24, 24,
25, 25, 26, 26, 27, 27, 28, 29, 29, 30, 30, 31,
32, 32, 33, 34, 35, 35, 36, 37, 38, 38, 39, 40,
41, 42, 43, 44, 44, 45, 46, 47, 48, 49, 50, 51,
53, 54, 55, 56, 57, 58, 60, 61, 62, 63, 65, 66,
68, 69, 71, 72, 74, 75, 77, 78, 80, 82, 83, 85,
87, 89, 91, 93, 95, 97, 99, 101, 103, 105, 107,
110, 112, 114, 117, 119, 122, 124, 127
};
We then added a bit of code to change the output differently for >127 and <127 numbers which looked as such:
if (p4_sw_trig == 1) //triggers on flipping of the first switch
{
if (p1_y >= 127) //sets a new value for the use in drive on joy 1 Y
{
tbldp1_y = 127 + pwmlookup[p1_y - 127];
}
else
{
tbldp1_y = 127 - pwmlookup[127 - p1_y];
}
if (p2_y >= 127) //sets a new value for the use in drive on joy 2 Y
{
tbldp2_y = 127 + pwmlookup[p2_y - 127];
}
else
{
tbldp2_y = 127 - pwmlookup[127 - p2_y];
}
if (p1_x >= 127) //sets a new value for the use in drive on joy 1 X
{
tbldp1_x = 127 + pwmlookup[p1_x - 127];
}
else
{
tbldp1_x = 127 - pwmlookup[127 - p1_x];
}
}
else
{
tbldp1_y = p1_y; //standard, acts as if it/then statement doesn't exist
tbldp2_y = p2_y;
tbldp1_x = p1_x;
}
I’m 99.9% sure this code is the right version, but it is possible that this is the incorrect version which makes robots always drive backwards
The “tbld” values were then used in the place of the “p” values. Note, this code is longer than it really needs to be since it is supposed to accommodate both one and two stick drives, as well as being able to be disabled via switch. And, if a 255 value table was used this code would greatly simplify (for just two stick drive, constantly enabled) to
pwm01 = pwmlookup[p1_y];
pwm02 = pwmlookup[p2_y];
The decreased low end sensitivity of this code worked very well for increasing the driveability of our '06 robot while still maintaining full speed capability when the sticks were pushed fully forward/backward.NOTE: This was on a 6WD robot that had no turning problems, on a long 4WD lots of power may be needed to turn causing this code to be more of a detriment to driver effectiveness than an aid.
smooth1.xls (24 KB)
smooth1.xls (24 KB)