Control Problems
 

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

Re: Control Problems
 

Isn't that supposed to be a - not underscore

2000 - p1_y

Re: Control Problems
 

It sounds like the left and right sides are swapped.

Re: Control Problems
 

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

Re: Control Problems
 

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?

Re: Control Problems
 

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:then either swap the pwm vars between formulas or change just the way the x and y values are mixed like this:

Re: Control Problems
 

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.

Re: Control Problems
 

I wouldn't expect 2000 - p1_y to work. ;)

Re: Control Problems
 

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?

Re: Control Problems
 

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

Re: Control Problems
 

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:

Good luck to all,
Robinson

Re: Control Problems
 

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.

Re: Control Problems
 

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.

Re: Control Problems
 

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.

Re: Control Problems
 

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

Re: Control Problems
 

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?

Re: Control Problems
 

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.

Re: Control Problems
 

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

Re: Control Problems
 

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:
Chances are it's completely wrong, but...

Re: Control Problems
 

That is the right idea. Just change the red thing from comparison to assignment.

Re: Control Problems
 

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.

Re: Control Problems
 

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.

Re: Control Problems
 

We verified this yesterday during testing. Y forward is 255 and X left is 255.

Re: Control Problems
 

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.

Re: Control Problems
 

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.