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]

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 -.


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]

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]

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]

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]

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]

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 (http:/http://www.chiefdelphi.com/forums/showthread.php?t=43321) post, but to summarize it in the words of M. 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]

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]

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]

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.

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.

[Pittiho]

IN RESPONSE TO:
"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."



Hi my name is Holly, I am a mentor for team 1228, (the team with this problem) and I have taken your advice and plugged these numbers into the formula, and it seems like the formula creates the backward turning that we are experiencing...
If I put in a value for full power to the right (x axis=255) and neutral on fwd/rev (y axis=127). THe values that the program returns are (right motors=full power=255) BUT...that would make the robot go into a LEFT spin (correct)? Because the right wheels are in full forward motion?

[Mark Pierce]

If I put in a value for full power to the right (x axis=255)...

I believe that the OI for the Joysticks generate around 255 when pressed to the left, not right. A simple print statement or assigning the user_byte to the p1_x value should confirm this quite quickly.

If the wiring is done such that the motors spin the opposite way from what we want with the Joystick centered left to right, we change the motor wiring. Keeping 254 meaning forward on both sides just makes more sense when debugging.

In looking through this thread it appears to me that in inverted's posts there are signs wrong on the p1_x term. One of the choices presented by Keith Watson in his second post should be the correct solution. It matches what we've done for years.

[Mark McLeod]

It sounds like your y-axis is correct (forward is forward, back is back), but your x-axis, which controls the turn, needs to be reversed.

Prior to the mixing equation you can use p1_x = 254 - p1_x to reverse the direction of your turn.

e.g.,
p1_x = 254 - p1_x;
pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);

[Inverted]

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.

Just tried it, and that works for me, too. Thanks a lot!

One more quick question. We have a motor on the bot that we don't need on all the time, just to save battery power. I wired a toggle switch so that when it's turned on, it shows up as the trigger button of a joystick being held on. Is there any way I can set a PWM to be equal to the y-axis of a joystick, ONLY when the switch is on, and then neutral when it's off? Here's the idea I had:

int my_y;

pwm02 = my_y;
if (p3_sw_trig==1){
my_y = p2_y;
}
else {
my_y == 127;
}

Chances are it's completely wrong, but...

[Keith Watson]

int my_y;

pwm02 = my_y;
if (p3_sw_trig==1){
my_y = p2_y;
}
else {
my_y = 127;
}

Chances are it's completely wrong, but...That is the right idea. Just change the red thing from comparison to assignment.

[Keith Watson]

...and I have taken your advice and plugged these numbers into the formula, and it seems like the formula creates the backward turning that we are experiencing...That is also what I got from looking at the default code. I cannot check why since it will be a few days before I see the bot again. Maybe our team simply switched the left and right motor wires?

To figure out why though, go through the debug process of checking front to back how things are used. Check the joystick direction as Mark indicated. When we calibrated our joysticks x was not backward. Check if the pwm outputs used in the code for left are really wired to the left motors. Etc.

[Mark Pierce]

I'd also move the pwm assignment to after the if statement. Otherwise, there will be an additional cycle delay in your response, since the pwm will reflect the old value from the if statement.

The my_y value could be defined as an unsigned character (8 bits) instead of int. It's not essential, but it is good practice to match variable types.


unsigned char my_y;

if (p3_sw_trig==1) {
my_y = p2_y;
}
else {
my_y = 127;
}
pwm02 = my_y;

[Keith Watson]

I believe that the OI for the Joysticks generate around 255 when pressed to the left, not right.We verified this yesterday during testing. Y forward is 255 and X left is 255.

[jrmarenda]

This shoudl fix your problem:
pwm13 = pwm14 = Limit_Mix(2000 - p1_y - p1_x + 381);
pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);

I had the same problem, and figured out the answer by simply setting up a table with actual and desired values using the dashboard viewer. I have tried this on our robot and it works. Le t me know if it doesn't work out for you.

[Matt Krass]

I'd also have to recommend moving to different PWMs if there is anyway possible, those are flaky, since they're generated in software rather than hardware, any code lag disrupts them, quite unreliable.