Quote:
|
May I ask HOW you know that these lines are NOT being executed? Could it be that they are executing, but simply not doing what you are expecting?
|
I looked at some printf stuff from our robot in varying conditions and concluded it was so. However, my memory is fuzzy and the last time I saw the robot was at the Boilermaker Regional, and the last time I checked this was at St. Louis. So, having the robot not handy, I can't test it easily, and it may be a figment of my imagination. It just now occurred to me to hook up Robovation and see if I can duplicate it; I'll do that in a bit, maybe.
Quote:
I can spot several chances for errors in this code. First: >>3 works great for positive numbers, but will only give you headaches if the number you're shifting is negative. (I'm almost positive.  I'll leave it as an exercise for the student to demonstrate yea or nay.)
|
Yeah, I wondered about that, but it seems to function correctly. I tested it in Dev-C++, and it worked there, and our robot doesn't seem to be doing a crazy-loony dance, so that seems okay.
Quote:
|
Second, if you're expecting the lines in questions to only do something when output is between -6 and +6 (as your comment seems to indicate that you might), you're wrong!
|
Fortunately, no, it is intended to be the way it is in that respect. The idea is that if there is nonzero output it will need a push to get out of deadband. I'll update the comment in my own code.
Quote:
|
Third, if output starts out between -6 and -1, it will first have 7 subtracted from it, and then immediately have 7 added back in!
|
I thought you had nailed it, but then I realized that, no, the 7 only gets added if output > 0, and is only subtracted if output < 0.
I'm sure I missed something, though. When I posted this, I had momentarily forgotten my motto, "No matter how irrational the problem seems, it's always your own dumb fault." Thanks for the help. Feel free argue with and make fun of me if my logic is fatally flawed.