I know this has already been posted before, but I cant seem to find it. Will some point me in the direction on how to solve the sensitive joysticks.
Thanks
Are you talking about using software to change the values of motors based on joystick input? You can either use a formula that you make up or use a lookup table. If you need more information or code examples Ill post some.
Are you looking for a solution to make the joysticks less sensitive, so if you let go of them they don’t wobble back and forth? If you are looking to stiffen up your joysticks, just do what Team 228 has done for the past few years. Unbolt the handles from your joysticks, and you’ll see instantly how the large weight of the handle affects the joystick.
To solve this problem, Team 228 machines custom [ambidextrous] handles for our joysticks using HDPE rod and/or PVC pipe. If you’d like to use some of the custom buttons on the joysticks, again this is not a problem because we also have added buttons to them as well. In the end, our lighter joystick handles on the Kit Of Parts joysticks provide for much better driver controls.
Here’s some CAD drawings I made in 2006 that use a piece of PVC pipe and two custom machined HDPE plugs to make light-weight custom joystick handles:
http://www.team228.org/gallery/46/slideshow/bds-38.jpg
And here’s the finished product (except for the three grooves which had been forgotten to be machined into the PVC):
http://www.team228.org/gallery/47/slideshow/bds-039.jpg
And here’s a picture of very similar handles we used on our 2005 Operator Interface. The only difference was that these handles were one solid HDPE rod that was hollowed out for the button. They were slightly heavier and harder to install the buttons inside them, but they worked equally the same.
That’s brilliant! I had never thought of modding the joysticks FIRST gives us. 68 just uses the old-style very stiff joysticks that (I’ve heard) FIRST gave us in the KOP. They return to 127 like they are supposed to.
I might suggest this for Holly’s OCCRA team; we are running short on the good joysticks.
JBot
A much easier solution to the wobbly joysticks is to simply slice the joystick springs in half. This is what 1281 did to our main drive joystick this year. This increases the spring constant, which greatly improves the ‘feel’ of the joystick.
Warning: Do this only if you have a spare joystick to fall back on. This may also decrease the life of your spring since you’re asking more of it than it was designed for.
Personally, I find that it isn’t so much the floppiness of the beige joysticks that is a problem, but the lack of feedback. With a good joystick, if you put it in any given position, there will be a force on your hand indicating the direction to centre. With the very weak springs in the KOP beige joysticks, that force is very small. Cutting the springs or adding brace elastics or something similar increases feedback greatly.
Other options:
-Find ANY other gameport joysticks
-Find a team that participated in 2003 (stack attack) or earlier that has spare joysticks, because the black ones included in the KOP pre-2003 were awesome.
-Ebay, ebay, ebay.
Art, thats an excellent mod to the kit joysticks. You should make a white paper for the teams that don’t have access to the CH Flightsticks. I bet those are every bit as good. That the guys at the blue alliance could make
a howto.
hmmmm… I shall forward this idea to Greg:) . if you have any other ideas for shows or things you would like to see covered send an email to:
[[email protected]](questions@the bluealliance.net)
We simply dont use the white ones that are supplied for us in the kit.
We like to use the older ones, which are no longer being produced, from previous years. I think they’re usually available on ebay. They tend to not wobble around as much.
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)
Before doing anything to change the joystick, I strongly encourage teams to calibrate the victor and joystick pair, as outlined in the Victor manual. Repeat this process anytime you change a joystick, Victor or when the controls don’t feel ‘right’. It’s quick, easy and ensures that full forward on the stick means full forward on the motor.
Once you’ve gotten good about that, start looking for old CH flightsticks. Compared to the past few years of sticks, they are excellent. My favorite aspect is the clear separation of the axis. Most sticks have something like a ball joint, the flightsticks had two joints, one for each axis. Difficult to explain but obvious when it’s in front of you. I felt it allowed for more precise and responsive driving.
-Andy A.
Look closely at thispicture and you can see what he is describing. There is one axis that rotates inside of the other (Bad way of describing it).
Doing calibration this way is quick, easy, and simple. It specifically calibrates that Victor to that joystick, which is good when you’re using that joystick to control the motor. But it also means that when you’re trying to control a motor with some other process – autonomous control, for example – things can end up not working quite right.
The not-so-easy solution is to write your software so that you can calibrate the joysticks to some internal representation of the desired control (and ideally have the Victors set to the “default” calibration). If done correctly it’s still quick and simple for the operator.
Interesting. I never knew that this was possible, and upon reading it, I am not sure that it is necessarily a very good thing.
I believe that by default, a Victor looks for a PWM pulse corresponding to 127 as neutral, 255 as full forwards, and 0 as full backwards. By recalibrating the Victor, you will adjust this calibration, which will give you better performance for that particular output/victor pairing.
However, this problem can be fixed in software instead of in hardware, leaving all of your Victors in the same known configuration. You can program your RC to output the joystick values, find the max and min, and write a little function to scale the joystick values to reach 255 and 0. This lets you adjust joystick behavior in software, and is very easy to see and change.
Maybe someone with more experience knows something I am overlooking?
There are basically two camps when it comes to Victor Calibration. The programmers who want to do it in programming, and everyone else.
Personally I like the idea of a hardware calibration more, just one less thing to debug. It’s built into the victor for a reason and is idiot proof.
Programmers on my teams have at times complained about it messing with the autonomous move as Alan described. My response is usually to point out that the autonomous mode lasts 15 seconds or so, the rest of the match is up to the drivers. It really can do wonders for driveabilty, and I have to wonder just how badly it can throw off an automove.
The point is that you need to calibrate somehow. Hardware calibration is always an option and requires no special knowledge. If you can whip up some code to do it, just as good. Whatever it is make sure you do something before you start hacking up joysticks and adding springs, particularly CH flightsticks.
As an aside- The calibration method used in the victors can be repeated as often as necessary. It can also be returned to the factory setting.
-Andy A.
Best way is to do a Proportional control with a pair of quad encoders. This works for both autonomous and operator control. Plus if you add a little Integral they will automatically wind up in a pushing match. You can use the same encoders for positional control.