One Joystick Drive

[mattsavela]

Hey. My team is interested in one joystick drive. We have the code loaded into our robot, but it needs some tweaking. For example, when we turn right, we want the left motor to go slower than the right motor. How would we add this into our program? Any help is greatly appreciated.

[Mark McLeod]

The IFI default code does the axis mixing for you with this section of code in user_routines.c depending on how your motors are hooked up (both forward or one forward, the other reverse).

/*---------- 1 Joystick Drive ----------------------------------------------
*--------------------------------------------------------------------------
* This code mixes the Y and X axis on Port 1 to allow one joystick drive.
* Joystick forward = Robot forward
* Joystick backward = Robot backward
* Joystick right = Robot rotates right
* Joystick left = Robot rotates left
* Connect the right drive motors to PWM13 and/or PWM14 on the RC.
* Connect the left drive motors to PWM15 and/or PWM16 on the RC.
*/
pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);



However, I might not quite comprehend what you are asking, since if you make the left motor go slower than the right motor, the robot will only turn to the right by rotating counter-clockwise (what I'd normally consider turning to the left). If this is the case you could invert the x axis of the joystick prior to mixing, e.g., p1_x=254-p1_x;

[mattsavela]

We are using our IFI Controller for an underwater robotics competition. We want to use one joystick drive for many reasons. I loaded the code in at our meeting today and it seemed to work fine. We haven't tested it in the pool yet. One of the students on the team were saying something about how our left motor seems to move faster than our right motor. What I think I need to know is how to make our motors adjust to this, (For example: When we turn left, the right motor spins a bit faster than the left motor, and when we turn right, the left motor spins a bit faster than the right motor, which I may have worded incorrectly in the original post). Do you guys have any idea about what I could do with the code to help? BTW, I am new to programming.

Thanks a lot

[mattsavela]

Yeah, sorry about that, I worded the example wrong in the original post.

[Alan Anderson]

(For example: When we turn left, the right motor spins a bit faster than the left motor, and when we turn right, the left motor spins a bit faster than the right motor, which I may have worded incorrectly in the original post)
What you're describing sounds like it's working properly. If you think it's a problem, there's obviously something you're not getting across to us.

[Mark McLeod]

One of the students on the team were saying something about how our left motor seems to move faster than our right motor. What I think I need to know is how to make our motors adjust to this...
You can rescale the power output of the faster motor to more closely match the slower motor using something proportional like:

#define LEFT_MOTOR_CORRECTION 42; // example value at full pwm (254)

signed int LeftPwm;
...
//Proportional drop in power

LeftPwm = (int)pwm15; //assume pwm15 has already been set by the joystick mixing code
LeftPwm -= 127; //Just because math is clearer if we make 0 neutral (-127 reverse, 127 forward)

if (LeftPwm > 0)
{
LeftPwm = LeftPwm - (LeftPwm / 127 * LEFT_MOTOR_CORRECTION);
}
else if (LeftPwm < 0)
{
LeftPwm = LeftPwm + (LeftPwm / 127 * LEFT_MOTOR_CORRECTION);
}

pwm15 = (unsigned char)(LeftPwm + 127); // restore the normal 0-254 range

This reduces the Left Motor pwm by an amount proportional to the “speed” requested by the joystick.

You’ll have to discover through measurement or trial & error what pwm value (e.g., 220 instead of 254) for the left motor matches the max pwm value on the right motor at full speed.

Also, be aware that reverse on your machine might require a completely different offset value, i.e., the right motor might be faster than the left motor in reverse. So measure in both directions and correct for them separately.
If that’s the case then something like the following might help:

#define LEFT_MOTOR_CORRECTION 42; // Correction value at full forward pwm (254)
#define RIGHT_MOTOR_CORRECTION 22; // Correction value at full reverse pwm (254)
// Assumes pwm15 is the Left motor, pwm13 is the Right motor
…
if (pwm15 > 127) // Forward, slow the Left motor
{
pwm15 -= (pwm15-127) / 127 * LEFT_MOTOR_CORRECTION;
}

if (pwm13 < 127) // Reverse, slow the Right motor
{
pwm13 += (127 - pwm13) / 127 * RIGHT_MOTOR_CORRECTION;
}

[mattsavela]

What you're describing sounds like it's working properly. If you think it's a problem, there's obviously something you're not getting across to us.
Thats what we want the motors to do. At the moment, it looks like they are both moving at the same speed when we turn

[Alan Anderson]

At the moment, it looks like [the motors] are both moving at the same speed when we turn
Sorry, I'm still not getting it. What makes you think the motors are at the same speed? Unless you're doing something you haven't mentioned, it wouldn't be turning if the motors aren't running at different speeds.

[mattsavela]

Im not positive about that. I'll let you guys know more on Thursday when I get a chance to test it in the pool with new code you guys helped with.

Also, the first code the Mark posted, when I put it in MPLab, it won't compile. I think I may be doing something wrong considering that I am new to programming, but when I take it out, it compiles fine. Any ideas?

[Mark McLeod]

Also, the first code the Mark posted, when I put it in MPLab, it won't compile. I think I may be doing something wrong considering that I am new to programming, but when I take it out, it compiles fine. Any ideas?
Let's narrow the problem down.

What "baseline" code are you starting with? The IFI 2005 v2.2 default code (http://www.ifirobotics.com/docs/frc-code-1-12-2005v2.2.zip) or something else, such as your team's 2005 modified code?

The code in my first post was quoted verbatim from the v2.2 default code and wouldn't have to be added. The default code already does what you want. The MPLAB problem you're encountering can be caused by lots of simple mistakes, especially if you've never used it before. It might be misplaced code, or if you aren't starting with the default code then the function Limit_Mix might be missing. Whenever you get an error you want to ask the forum about, post (copy and paste) the actual error message. That usually tells us all we need to know to solve the problem.

As an aside, you'll need to be sure the correct motor pwms are being used.

If you are starting with your team's customized 2005 code then post a zip of the user_routines.c file, so we can see what's been modified and how. Then we'll be able to describe the easiest may to add the one joystick lines if they aren't already there.

[mattsavela]

I attached my userroutines.c file

[Mark McLeod]

A couple of simple issues.

The code for joystick control is in the Default_Routine() a few lines below the Process_Data_From_Master_uP routine(). The 1-Joystick code starts there on line 226 (in the version I attached). (In MPLAB look under Edit -> Properties and check "line numbers" if you don't already see them.)
There was a ". . ." in my example above that isn't code and needs to be removed (sorry about that).
Set both the MOTOR_CORRECTION's to zero to begin with. You'll only need to adjust those values if the operator cannot manually correct for the robot pulling to one side or the other. I don't know how hard it will be for your operator to see the robot underwater.
Make sure your drive motor pwms are connected to pwm 13 (right motor) and pwm 15 (left motor).
I've attached a modified version, so you can see what I meant.
the new code is at lines 204-205 and 239-255.
What you wrote originally will actually work, but would be confusing to anyone reading the code, because it does all the joystick work in Default_Routine() then overrides it all in Process_Data_From_Master_uP().

Anyone else have comments to add?

[mattsavela]

We have cameras attached to our robot, so we can't actually see our robot, but we can see from certain perspectives.

Thank you guys so much for helping me with this.

[Mark McLeod]

We'd like to see photos and hear about your progress, so don't forget about us here on the ChiefDelphi forums.

Good Luck!

[mattsavela]

We have an online album of pictures. I'll check with our coach to make sure that I can give the link out.

[mattsavela]

http://photobucket.com/albums/v660/lhsrobotics/
http://photobucket.com/albums/y205/lhsrobotics1/


Those are the two links to our photo albums.

[N7UJJ]

I assume you are going to the MATE championship in Houston.
If so be sure to look for us. We also use the FRIST controller equipment on our ROV except we put the robot controller and the battery on the ROV. It allows us to use a small diameter tether which really helps the maneuverability.

Looking forward to meeting y'all

Allan

[mattsavela]

Yeah. We are going to the MATE competition in Houston. Our team saw some pictures of your team's robot (not sure what year), but it was in one of your past tech reports. It looked excellent.

[mattsavela]

We finally got a chance to test our robot in the pool. The robot worked fine going forwards, and turning. However, when we pull our joystick backwards, the robot goes forward, and when we push the joystick forward, our robot goes backwards. Is there a way you guys can help me fix that? Also, our robot does not goes very fast when it is moving backwards, but moves at a good speed when it goes forwards. Is there a way to make it so that when we go backwards, it goes the same speed as it goes when going forwards?

Thanks

[N7UJJ]

We finally got a chance to test our robot in the pool. The robot worked fine going forwards, and turning. However, when we pull our joystick backwards, the robot goes forward, and when we push the joystick forward, our robot goes backwards. Is there a way you guys can help me fix that? Also, our robot does not goes very fast when it is moving backwards, but moves at a good speed when it goes forwards. Is there a way to make it so that when we go backwards, it goes the same speed as it goes when going forwards?

Thanks
There are two solutions to the forward/backward problem:

1. transpose the wires from the motor speed controller that go to the motor by switching the M+ and M- wires. (I think this is the best solution)
OR
2. in the code, add pwm01 = 255 - pwm01;
pwm02 = 255 - pwm02; // put after any other assignments to pwm01. (I used PWM01 Ind 02, but of course, use the pwm## that the motors use

As for the different speeds, there can be three solutions:
1. calibrate the motor speed controllers
2. in the code,use a lookup table or a function so that the p1_y goes from 0 - 255
3, It may be the motors, They just may go faster in one direction or its the water flowing more efficiently in one direction that the other. Not much you could do about that.

Fix the direction problem first and test in the water. Maybe the speed problem will go away or not be so noticeable.

Let me know what happens

Allan

[mattsavela]

Thanks a lot. We gonna test our robot again in the pool tomorrow. I'll try changing the cords. Also, do you think that someone could add the part Allan suggested into our user routines.c file (I uploaded it). I would really appreciate it because I am new to programming. I'm going to add everyone who helped to our acknowledgements section of our teams tech report.

Thanks a lot