OK, this is probably posted somewhere here, but I can’t think of where to look, or what it’s even called.
Basically, I’ve been told that once again, the Drill Motors are faster in forward than in reverse. I remember I did something crazy with the EEPROM last year, and while it worked, it wasn’t exactly efficient. So, I’m wondering if anyone knows how much faster (percentage wise) the Drill Motors are, and two, how I would make some sort of algorithm to reduce the output accordingly. I know it’s possible, but I haven’t had any experience with Min or Max, and I have no idea how to make “pretty” algorithms :p.
So far, I know that one side would need to be reduced at all times. Depending on which the robot is going (simple if/else statement). I just need to figure out what goes on the inside of that loop, and yeah, it’s confusing me a bit :). So, if anyone has the heart to help a poor confused programmer, please do :p.
I don’t know how much faster the motors are, but I have already made an algorithm for reining in some automatic control tests.
bb_man_pot was a pot (sending in the opposite of assumed input) that we used to control the percent of speed. You could replace this with a variable. To only affect positive speed, you could put this in an if statement.
p1_y=p1_y-127*(254-bb_man_pot)/255+127
Keep in mind that it might not be practical to limit your forward speed just so the forward/reverse speeds are equal.
well, that’s sort of what i want (i think). and it wasn’t to make forward and reverse speeds equal either. from what i’ve been told, one drill motor runs in reverse, one runs forward, no matter which way you’re going. the way they’re mounted, it’s always like that (unless you mount them funny). so, unless you leave it to the driver, which i don’t want to do, you have to reduce the motor output on the side going forward. that way, the robot goes straight, instead of curve (Because on skid-steering, when one side is faster, you turn). i think that algorithm should work, i’ll play around with it tomorrow and see if it works.
Right…I hadn’t remembered that one drive train was running the opposite direction on many robots. Our software last year just ignored that fact, as it did not affect driveability very much. It might matter for autonomous control. Now that I realize your/our problem, there may be better algorithms to deal with it. Actually, you could apply mine, sort of, to one half of each motors range. The way it seems to be is:
----0+++++
+++++0----
The motors extend further in their ‘positive’ range than their ‘negative’ range. So, when each motor is in it’s ‘positive’ range, you apply my algorithm with the right replacement for (254-bb_man_pot). But one motor’s ‘positive’ range is between 0 and 127 and the others’ is between 127 and 254.
This might make the algorithm simpler because it would only have to deal with a ‘positive’ or ‘negative’ value. I’ll play around with it and see what I get.
We ran into a similar problem last year. In order to compensate, I added a multiplier to whichever motor was running in “forward” of approx. 90%. If you want to see the code, it’s in CogCode2k2, available at my website: http://www.robbayer.com/software.html.