Control Problems

[Inverted]

We have our bot set up for one-joystick drive, with the two-motor transmissions hooked up to PWMs 13-16. here's the set-up:

(right side)
PWM 13 = PWM 14 = Limit_Mix(2000 + p1_y + p1_x - 127)

(left side)
PWM 15 = PWM 16 = Limit_Mix(2000 _ p1_y + p1_x + 127)

The wheels go forwards and backwards correctly, but turns like a boat (turns left when you push the joystick right; turns right when you push the joystick left).

Any idea why this isn't working??

[6600gt]

2000 _ p1_y

Isn't that supposed to be a - not underscore

2000 - p1_y

[Keith Watson]

It sounds like the left and right sides are swapped.

[Inverted]

Originally Posted by 6600gt

Isn't that supposed to be a - not underscore

2000 - p1_y

Whoops, yeah. Guess I got a little shift-happy when I typed that out. In the code it's a -.

Originally Posted by Keith Watson

It sounds like the left and right sides are swapped.

I figured that much, but when I tried to mess with the terms, switching the + and -, I only succeeded in making the whole control scheme inverted (how ironic). By that I mean that if you turned the joystick upside down, it worked perfectly. Then I figured that if the controls were inverted, everything would work if I made everything the opposite of what it was, so it looked something like:

PWM 13 = PWM 14 = Limit_Mix(-(2000 + p1_y + p1_x - 127));
PWM 15 = PWM 16 = Limit_Mix(-(2000 - p1_y + p1_x + 127));

That isn't the correct placement of the +'s and -'s, but you get the idea. Unfortunately, that just made the wheels spin out of control, unable to be feathered. Any idea what I could be doing wrong? I was thinking of just reversing the polarity of the motors on one side so the code would be the same for both sides, but I'd rather mess with the code than screw with the wiring.

[Kevin Sevcik]

Originally Posted by Inverted

Whoops, yeah. Guess I got a little shift-happy when I typed that out. In the code it's a -.



I figured that much, but when I tried to mess with the terms, switching the + and -, I only succeeded in making the whole control scheme inverted (how ironic). By that I mean that if you turned the joystick upside down, it worked perfectly. Then I figured that if the controls were inverted, everything would work if I made everything the opposite of what it was, so it looked something like:

PWM 13 = PWM 14 = Limit_Mix(-(2000 + p1_y + p1_x - 127));
PWM 15 = PWM 16 = Limit_Mix(-(2000 - p1_y + p1_x + 127));

That isn't the correct placement of the +'s and -'s, but you get the idea. Unfortunately, that just made the wheels spin out of control, unable to be feathered. Any idea what I could be doing wrong? I was thinking of just reversing the polarity of the motors on one side so the code would be the same for both sides, but I'd rather mess with the code than screw with the wiring.

It's terribly important that those 2000 terms stay positive. Think it through, though. If p1_x controls the left and right turning, and your turning is backwards, wouldn't it make sense to make make p1_x the opposite of what it is in each of those formulae?

[Keith Watson]

Originally Posted by Inverted

I figured that much, but when I tried to mess with the terms, switching the + and -, I only succeeded in making the whole control scheme inverted (how ironic).

When I encounter problems like this where I'm not sure if my logic or formulas are working I create some test cases on paper with real numbers and see what happens. When I do the math on the original code it appears to me that the steering is reversed - based on the comments! But I don't have a working robot in front of me to verify.

You went to far in modifying the code. If this original doesn't work:

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

then either swap the pwm vars between formulas or change just the way the x and y values are mixed like this:

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

[Inverted]

Before I left the shop today I copied down the X and Y values given when I moved the joystick in all directions, and I was going to do the math on it tomorrow to see what was going wrong (or something, I'm not really sure what I was looking for). For some reason I think I messed with pairs of terms, instead of individual terms, which probably explains the problem. Though, when I originally switched the signs of the whole Limit_Mix operation, I did leave the 2000 positive, but changed everything else, and got the same result, or something similar.

Thanks for the suggestion, I always overlook the 'simple' solutions. I'll try that tomorrow and see if it works.

[Keith Watson]

Originally Posted by Inverted

Though, when I originally switched the signs of the whole Limit_Mix operation, I did leave the 2000 positive, but changed everything else, and got the same result, or something similar.

I wouldn't expect 2000 - p1_y to work.

[kevinw]

Originally Posted by Keith Watson

It sounds like the left and right sides are swapped.

Not to bypass the theory and the important lesson of completely understanding it, but couldn't you simply swap the pwm outputs for the left and right side and move on?

[Rick TYler]

Just say "no" to PWMs 13-16. (Are you using open-loop driving?)

[gnirts]

Originally Posted by Rick TYler

Just say "no" to PWMs 13-16. (Are you using open-loop driving?)

Yes, like Rick said PWMs 13-16 can be glitchy, especially in combination with interrupts.

See the Motors and the High Port Numbers post, but to summarize it in the words of M. McLeod:

Originally Posted by Mark McLeod

For these pwms 13-16 alone, the software gets direct control to generate a timed pulse of between 1 and 2 ms duration, 1.5ms being neutral.
Any interrupts, interrupt the software timing these pulse widths, but the software doing the timing doesn't know this. Just like none of your other regular code is ever aware an interrupt has occurred. So the software happily generates what it thinks is a neutral pulse of 1.5ms, but any interrupt handler that pops in, suspends the execution of your code, does it's thing, and returns control will extend or stretch the time of your pwm pulse by the amount of time it took to service that interrupt.
So instead of a 1.5ms pulse, for example, you'll end up with a 1.8ms pulse.

Good luck to all,
Robinson

[Inverted]

Originally Posted by kevinw

Not to bypass the theory and the important lesson of completely understanding it, but couldn't you simply swap the pwm outputs for the left and right side and move on?

I did that, but since the motors are facing opposite directions, one side went forward while the other went back. So pushing the stick forward made it turn left, pushing it to the right made it go straight, and so on. Ugh, this is so annoying.

[hoag]

If anything is moving in the wrong direction, you could just subtract the Limit_Mix result from 254. (To reverse direction)

for the right motor I use
(254-(Limit_Mix(2000 + p1_y + p1_x - 127)));


for the left motor I use
(Limit_Mix(2000 + p1_y - p1_x + 127));


I've used this setup for all of my team's robots.

[KenWittlief]

Originally Posted by hoag

If anything is moving in the wrong direction, you could just subtract the Limit_Mix result from 254. (To reverse direction)

not in this case. His foward and reverse was correct. Left and right were wrong.

if he inverted the PWMs to the motors then forward would go backward.

[hoag]

Originally Posted by KenWittlief

not in this case. His foward and reverse was correct. Left and right were wrong.

if he inverted the PWMs to the motors then forward would go backward.

I was replying to his previous post where his forward and reverse were not correct.

Originally Posted by Inverted

I did that, but since the motors are facing opposite directions, one side went forward while the other went back. So pushing the stick forward made it turn left, pushing it to the right made it go straight, and so on. Ugh, this is so annoying.