HELP with TANK DRIVE PROGRAMMING

[dcarswell]

I am new with programming ,and I wanted to know how to turn down the motor speed if you are using the tank drive example in Labview ?

[Ether]

Originally Posted by dcarswell

I am new with programming ,and I wanted to know how to turn down the motor speed if you are using the tank drive example in Labview ?

Short answer: Move your joystick toward the neutral position.

If that's not what you are asking, please explain what you mean by "turn down the motor speed". Do you mean you want to limit the maximum speed? If so, just divide the output from each "joystick get axis" by 2 (or whatever factor you desire) before feeding them to the "tank drive" vi.

Note that this will not only limit your maximum speed, it will also limit the maximum force with which your robot can push.

Tell us what you are trying to accomplish and a better answer can be provided.

[dcarswell]

In the code the speed is being based off of how much you push the joystick forward,(of course) what I am asking is...is there a way to turn the motors speed down to say like 25% of its full power , so when you press the joysticks to the maximum position the motors will move 25% instead of the full 100%.

[Ether]

Originally Posted by dcarswell

In the code the speed is being based off of how much you push the joystick forward,(of course) what I am asking is...is there a way to turn the motors speed down to say like 25% of its full power , so when you press the joysticks to the maximum position the motors will move 25% instead of the full 100%.

Yes. See my previous post, as edited.

You will have to experiment with what factor to divide by to get your desired reduction to 25%

Again, please note that this severely limits the robot's maximum pushing force. So if you go uphill, or downhill, or the robot's friction changes, or you are pushing something, the max speed will change accordingly.

If you want to reduce maximum speed without affecting max pushing force, you will need to sense speed and create a controller to limit the speed. Are you interested in doing that?

[dcarswell]

The whole point of even limiting the speed was to take our last years robot and show the newbies how to drive it in tank drive mode...and we wanted to limit the damage that they might cause .

[JesseK]

Additionally, if the drive wheel base & wheel friction aren't designed properly, the drive train will have a very hard time turning at 25% power output. I'd recommend a slightly more advanced program that allows a bit more power output so long as sensor feedback doesn't exceed the desired straight-line speed (as Ether is eluding to). Another way to solve it would be to change the gearing on the sprockets to a much lower speed so you don't have to mess with the programming at all. If the robot will never see a competition field, parade, football game, or other long-distance movement ever again, I'd say that it's a safe move.

Or you could put the bumpers on and get into a more open area. You could also stipulate that intentional damage will result in immediate dismissal from the team ... that tactic works most of the time on our team.

[dcarswell]

Are than any steps you can give me or a help guide that is in labview that will show me how to divide functions?

[Chris is me]

Originally Posted by Ether

Note that this will not only limit your maximum speed, it will also limit the maximum force with which your robot can push.

At the risk of veering off topic, why is this the case?

[JesseK]

Originally Posted by Chris is me

At the risk of veering off topic, why is this the case?

The controllers limit the voltage (or current?), thereby limiting the torque outputs of the motors.

[Mark McLeod]

Stay on topic or start a new thread. This cocktail party isn't helping the original poster...

Originally Posted by dcarswell

Are than any steps you can give me or a help guide that is in labview that will show me how to divide functions?

Here's an example for a single motor of what Ether is suggesting.
The 0.25 constant is the percentage of max power.
For tank drive you'd multiply both speed inputs to the Tank Drive vi.

You can also replace that fixed constant with an input from the throttle to make your power adjustable, so you can change it on-the-fly until you get the value you feel is right.

P.S.
Not that you've said you have this issue, but if turning at low power is a problem with your robot you can also do something in software that doesn't require adding sensors, physically changing the gearing, or swapping out sticky wheels for slicks.
In your code you can avoid applying the power reduction to any turning component or make just turning a higher percentage. For example, if one of your joysticks is forward and the other is backward, then don't reduce the power to the joysticks. If they are both forward but to varying degrees, so you get a curved driving path, then leave the difference between the sticks alone and only reduce the straight component.

[Andrew Schreiber]

Originally Posted by JesseK

The controllers limit the voltage (or current?), thereby limiting the torque outputs of the motors.

Neither... the controllers pulse a voltage (12v in our case). http://homepages.which.net/~paul.hil...llersBody.html Has a little more info.

Edit: Thinking more on it. JesseK is "correct" as far as I can tell. Because of the pulsing of the output you are limiting the amount of current which limits the amount of torque. He is correct but I wanted to make sure there was no confusion about how an ESC worked.

[Jon236]

You may need a multiplier of 0.35-0.4 at a minimum in order to get the drive motors working well.

[JesseK]

Originally Posted by Andrew Schreiber

Neither... the controllers pulse a voltage (12v in our case). http://homepages.which.net/~paul.hil...llersBody.html Has a little more info.

Edit: Thinking more on it. JesseK is "correct" as far as I can tell. Because of the pulsing of the output you are limiting the amount of current which limits the amount of torque. He is correct but I wanted to make sure there was no confusion about how an ESC worked.

Hmm

The second paragraph under "Theory of a Speed Controller" states that it's an 'averaged' effect of lowering the voltage by switching the full-voltage signal on and off. Later on the page, a figure shows the effect of the PWM switching on current as if the signal 'pulses' the current, thereby averaging it to a lower value as well. Rather than neither I'm inclined so say 'both' ... but really I'm just getting confused.

I'll look at it more later. Thanks for the link.

[Andrew Schreiber]

Originally Posted by JesseK

Hmm

The second paragraph under "Theory of a Speed Controller" states that it's an 'averaged' effect of lowering the voltage by switching the full-voltage signal on and off. Later on the page, a figure shows the effect of the PWM switching on current as if the signal 'pulses' the current, thereby averaging it to a lower value as well. Rather than neither I'm inclined so say 'both' ... but really I'm just getting confused.

I'll look at it more later. Thanks for the link.

Yeah, I'm talking with an EE who has a better understanding than and he is saying that the Jags also have the capability of being operated in a Voltage or Current mode over CAN.

I have a few other links regarding ESC design and construction if you are interested. It has been a couple years since I read them and I admit they move way beyond my understanding pretty quickly.

[Ether]

If you are using a Victor, or a Jaguar with servo input (not CAN), then your command to the Victor (or Jaguar) results in an output voltage to the motor being controlled.

The motor then draws current (at that voltage) according to how heavily it is loaded. As you load the motor, the motor slows down and draws more current (according to the motor's current vs torque curve for that particular voltage).

This is variously referred to as open-loop control or voltage control.

If you limit the inputs to the tank drive vi, what you are doing is limiting the available maximum voltage supplied to the motors.

Limiting the maximum voltage to the motors limits the maximum speed of the motors, but it also limits the amount of current that can flow when the motors are trying to push something. It is current that provides torque, so this limits the motor torque and thus the robot's pushing force.

The output voltage from the Vic or Jag is modulated by a technique called Pulse Width Modulation (PWM). The voltage is alternately turned ON and OFF at a high rate of speed (15,000 times per second for the Jag and 150 times per second for the Vic). The motor sees this as if it were a steady DC voltage equal to the percent of the time the voltage is ON. For example, if the voltage is ON 75% of the time and OFF 25% of the time, the motor would think it is getting 9 volts DC (75% of 12).


Now, having said all that, there are ways to operate the motor other than voltage control. One such way is speed control. This requires that you have a sensor to sense the motor's (or the wheel's) speed.

What you can do is to feed the speed signal to the cRIO. Your software looks at the speed and says "hey, it's going slower (or faster) than what I wanted". Your software then increases (or decreases) the command until the motor is doing what you want. This is called a closed-loop control. There are many ways to do this. One very popular way is called PID. LabVIEW provides a PID vi to do this.

Another option, available on the Jag only, and only if using CAN, is to connect the speed sensor directly to the Jag instead of the cRIO. The Jag has a microcontroller inside it, with a built-in PID algorithm, and the Jag can "close the loop" for you so you don't have to do it in the cRIO. The Jag provides options for controlling speed, position, or current.