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.
**
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?
**
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 .
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.
Are than any steps you can give me or a help guide that is in labview that will show me how to divide functions?
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.
Stay on topic or start a new thread. This cocktail party isn’t helping the original poster…:rolleyes:
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.
Neither… the controllers pulse a voltage (12v in our case). http://homepages.which.net/~paul.hills/SpeedControl/SpeedControllersBody.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.
You may need a multiplier of 0.35-0.4 at a minimum in order to get the drive motors working well.
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.
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.
**
Ether is correct, PID-based speed control is your best option. Know that you must test and tune this until you can trust it to work how you want.
Now, about how Jaguars control motors: This is my understanding; please correct me if I’m wrong.
Say you have a DC brushed motor that draws 6A at 12V DC under normal load. That’s 72W.
Now say you’re driving it at 50% duty cycle, at 15khz. (I think that’s the chop rate of a Jaguar). That motor coils have enough impedance that the motor effectively gets the RMS voltage - the average voltage. At 50% duty cycle, that would be 6v. Using ohm’s law, we say that the motor would draw 3A. That makes 18W; a quarter of full power.
Now let’s compare that to a 2 ohm resistor, with no significant impedance. The 50% duty cycle is still 12v, but only half the time. That means we take 60W / 2 = 30W. In this case, the Jaguar is better described as controlling current, as opposed to the voltage control in the previous example.
Victor 884’s have a chop rate of 150hz, if I remember correctly. I know it’s very poor control, and very audible at low speeds. It’s clear that the motor impedance is not enough to make up for the low chop rate, and so the Victor effectively controls current. (I’ve looked at the waveform of a Victor 884 controlling a Globe motor. At 50% duty cycle, the inductive ring almost fades completely before the MOSFETs switch.)
Could this be why the control resembles a square root function? The Victor has a square root function internally because P=RI^2, when (because of the low chop rate) the equation is actually P=VI? (The only manipulated variable here is I; V and R are constants.)
There are two fundamental errors in the above analysis:
I)
The RMS* of a 12V 50% duty cycle square wave is ~8.5 volts, not 6 volts. If the motor inductance is high enough, or the PWM period is short enough, then the motor inductance filters the square wave so that for purposes of computation the motor effectively sees the algebraic average, which is 6 volts, not the RMS.
II)
The only time motors obey Ohm’s law is when they are not moving. Since you mentioned “normal load” I will infer that the motor is spinning with a speed well above 50% of no-load speed. Since the motor is moving, Ohm’s law does not apply, and your analysis is incorrect.
If you have a motor that is drawing 6 amps at 12 volts and producing torque T, and then you reduce the applied voltage to 6 volts, what happens depends on whether you maintain the same torque load on the motor and allow the motor speed to drop, or some other combination of torque and reduced speed.
Say you maintain the same torque load on the motor and allow the speed to drop. Since the torque remains the same, the current will remain 6 amps. The motor will be drawing 6amps times 6volts = 36 watts.
Now let’s compare that to a 2 ohm resistor, with no significant impedance. The 50% duty cycle is still 12v, but only half the time. That means we take 60W / 2 = 30W. In this case, the Jaguar is better described as controlling current, as opposed to the voltage control in the previous example.
If you put a 12V 50% duty cycle square voltage waveform across a 2 ohm pure resistance, the power consumed by the resistor will be the square of the RMS voltage of the waveform divided by 2 ohms, or (8.485^2)/2 = 36 watts, not 30 watts.
It’s clear that the motor impedance is not enough to make up for the low chop rate, and so the Victor effectively controls current.
No it doesn’t. Again, Ohm’s Law is not applicable to a spinning motor. For a given output PWM duty cycle percent, the average voltage that the motor sees remains constant, but the average current that the motor draws increases (or decreases) as the torque load on the motor increases (or decreases). Also, for a given motor torque load, changing the output PWM duty cycle percent just changes the motor’s speed, not its current… unless of course you drop the percent until the speed is zero, in which case further reduction of the percent causes current to drop.
The effect of low motor inductance, or long PWM period, is to cause ripples in the current. The ripples cause increased motor heating (Irms^2*R) for a given average motor torque (which varies with Iave, not Irms^2).
RMS means “root mean square”: take the square root of the average of the squares. So, for a 12V 50% duty-cycle square wave: ** 1)* multiply the wave by itself (ie square it). You now have a 144V 50% duty-cycle square wave. * *** 2)** take the average: 144/2=72 (because it’s 50% OFF). ** 3)** Take the square root: the square root of 72 is ~8.5 volts
**
Here’s one possible implementation of what Mark has suggested:
Let Y1 be the left joystick command and Y2 be the right joystick command.
Then compute these modified joystick commands:
Y1’ = (a+1)*Y1 + (a-1)*Y2]/2
Y2’ = (a-1)*Y1 + (a+1)*Y2]/2
where “a” is your speed adjustment factor, e.g. 0.25
Then send the modified Y1’ and Y2’ commands to the tank drive vi.
This transformation yields Y1’ and Y2’ values which are always in the range -1 to +1 (assuming that Y1 and Y2 were in that range).
It also handles cases where (Y1>0) and (Y2<0)] or (Y1<0) and (Y2>0)], so no conditional logic is required.
**
Now, I do not know about your robot at all, but rather than doing this with the programming, why don’t you just change the gear ratio of the DT? This will probably save a lot of headache (If your DT is anything like ours). It will, in turn, give you more power, but in most robot destruction cases I have seen in the past 4 years, it has been because of the speed of the bot.
If this is not what you are looking for, then please just disregard this! Hope this helps! 
i.e. , if you gear it down further, it will reduce the top speed, and increase the pushing force.
**