Default code question

[Roger]

I can flesh out CyberWolf_22's answer with a more long-winded answer. He snuck in while I was still typing. (Young whipper-snapper! ) His answer I assume is correct as it does work on the robot. One thing I've learned is to know what does or does not need fixing.

There are some twists in the code which should be cleaned up, and actually Kevin Watson (of kevin.org) suggested removing Default_Routine() because of conflicts and using a modified version to use with his code. I'll assume you at least understand the C commands.

p1_x = 255 - p1_y;
p1_y = 255 - pwm05;

Why x and y is switching? Dunno. My guess is when this code was written the joystick controls were different. I rewrote this so x was x and y was y. You can test it on your own robot by switching it back. The "255 -" part just reverses the number from 0~255, to 255~0. Again, you can test this. Nothing like real-life testing to prove things.

Why pwm05? This is the sneaky part. Look above where all the pwm's get mapped from various joystick controls. pwm05 is set to p1_x. If you use

p1_x = 255 - p1_y;
p1_y = 255 - p1_x;

then p1_y will actually be set to 255 - ( 255 - p1_y ), not what is intended. The programmer just sneaked the number from another variable.

Why they mapped out all the pwms like that probably goes back to the dark ages of this code. There is a lot of code in Default_Routine() that is, well, default code, in case you didn't customize it for your own use. I commented most of it out and just used a simplified version of the above.

The second part,

pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);

is one of those things you just have to trust. What, you thought I knew the answer? Like your senior programming friend, I know it works so why try to fix it?

Well, actually, back in January I did have to figure it out, and you can do the same. I made a simple spreadsheet that plugged in a range of p1_x and p1_y. Sometimes you just have to do the math. All I know is that it mixes the forward-backward of the joystick with the left-right to get how much power the two left and two right motors get.

Limit_Mix() is just a fancy function to limit the range of numbers to 0~255. The adding of 2000 just makes it easier for C variables, shifting the number line to a positive vaule, and is subtracted out when returned.

One thing that spreadsheet did show me was the secret of reversing the motors on one side, which is why I made it. If your robot is a "standard" built one with four motors, two on left and two on right, then two of your motors are backwards. That is, they spin in the opposite direction to the other side's motors to make the robot go forward. In past years we've (meaning the robot builders -- they don't want me building things!) just reversed the wires on those two motors. Red to black instead of red to red, which is a big no-no. This year they decided it was a programming problem (funny how it always ends up a programming problem), and I knew there was a simple solution. I did the spreadsheet to test out different combinations and the answer is:

pwm13 = pwm14 = Limit_Mix( 2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix( 2000 + (256 - p1_y) - (256 - p1_x) +127);

Andy, you have the programmer's mindset, posting your question at 1:24 AM -- the best programming is done after midnight!

Roger.

[Jake M]

The two equations that combine the X and Y values look confusing because they're simplified for space. There's actually some theory behind it. The un-simplified version looks like this.

pwm13 = pwm14 = Limit_Mix(2000 + (p1_y - 127) + (p1_x - 127) + 127);
pwm15 = pwm16 = Limit_Mix(2000 + (p1_y - 127) - (p1_x - 127) + 127);

Make more sense? There's three basic steps.

1: subtract 127 from the joystick values, so that the range is -127 to 127, rather than 0 to 254.

2: The theory behind the equation is that as Y changes, the motor outputs increase or decrease with each other. As X changes, the motor outputs become farther apart. Think about it. If Y increases, increase the output to both motors, to make them go forward. If X increases (left turn) you put one wheel forward, and the other in reverse. Thus, the basic idea of step 2 is that one wheel is Y + X, and the other is Y - X.

3: Add 127 to the final result, to make the range 0 to 254 once again.

And as for the one reversed motor, we usually just wire it in reverse, rather than make the code more complicated. For one, our main programming mentor would (bleep) about it if the code wasn't exactly perfect, and it makes it that much easier to understand months later.

[Roger]

Thanks for the explaination, Jake. I probably would of figured it out eventually, and may try again to work it out in my mind.

Originally Posted by Jake M

And as for the one reversed motor, we usually just wire it in reverse, rather than make the code more complicated. For one, our main programming mentor would (bleep) about it if the code wasn't exactly perfect, and it makes it that much easier to understand months later.

We did that for several years, just reverse the wires, but like what the hot dog commercial says, we have to answer to a higher standard, that of FIRST safety rules. Or at least that's what our shop says. Even if it isn't in the book, I agree with them. Red to Red, Black to Black. This year I watched the inspectors do their thing and (like inspectors everywhere) you never know what will catch their eye.

Besides, that's what comments are for. Months later? Try years. Or just an hour later.

   //Put modified joystick numbers into the four motors
   //The (256- ) part reverses one side's motors so no reverse wiring is needed!

   pwm13 = pwm14 = Limit_Mix(2000 +        p1_yNew  +        p1_xNew  - 127);
   pwm15 = pwm16 = Limit_Mix(2000 + (256 - p1_yNew) - (256 - p1_xNew) + 127);

It's unbalanced, but so are the original motor positions. I don't disagree with your programming mentor; robots are perfectionists. But life and robots are full of quirks, and that you gotta live with.