8 volts over talons

[dipmeinaluminum]

Hi guys,
First, thank you to all of Long Island for having is this past weekend!

I'm having a weird issue, I'm using Talons to power CIM Motors for our shooter. When a button is assigned to them, the voltage reads 8Volts, when the joystick is applied I get the full volts, solid green and red lights.

After calibrations and such, I can't figure it out. Can we just not use assign buttons to talons?

We are using JAVA. Thank you in advance.
-Mike

[Patrick Chiang]

Can you post the relevant part of your code?

Something like this should work:

if (joystick.getRawButton(SHOOTER_BUTTON))
talon.set(1.0);

Sometimes a button on a joystick is read as an axis on the computer. For example, the xbox 360 controller finger triggers (bumpers or whatever they're called) actually count as axis and you'll get a variable value instead of a true/false.

[TFleig78]

It seems like a code issue. Could you post the code? Also, are you using the command based model or the simple template?

[JavaNoNothing14]

For the most part, when running a blank code it was essentially just a simple


if (js.getRawButton(11)){
shooter.set(1);
}


After testing, it would only run at what seems to be 66% speed.

[tStano]

Electrical resistance will make your voltage drop.

There is some resistance in a talon, but not that much. This particular talon could be a bad one though, with a greater resistance.

Wire has resistance as well. If you have long wire runs, the voltage could easily drop to 8v by the time it reaches the motor. This calculator shows you how severe that effect may be. http://www.calculator.net/voltage-drop-calculator.html

There could be a loose or badly terminated wire somewhere along the path. This would increase resistance, further lowering voltage.

Also, it is possible the value you get is what the current battery voltage is. These batteries don't always output 12v, but I'm sure you knew that.

It could also be that your voltmeter isn't great, or has poor connections.

If the lights on the talons are flashing as you press the button, I'd think it was code. if their not, its probably something else.

Your code looks correct, assuming it runs every loop.

[TFleig78]

You can debug by printing the values that the talons are set to.
You can do this by writing:

System.out.println(shooter.get());

Also, check the status lights on the talons.

[JavaNoNothing14]

Its set to two talons, but for the sake of this i'm just writing the program as it would be if i only have one. The wire length is closer than any other motor control set up that we have.

So when I revised the program to have it read as such


if (js.getY()> 0)
{
shooter.set(1);
}


so if i move my joystick forward my shooter will go forward. When i run this program i have no problem at all, robot works fine and it reads 12+ V.

I've even switched out these talons with other talons to eliminate as much as could be and for some strange reason, being set to a button doesn't give it full speed.

[Jon Stratis]

if (js.getRawButton(11)){
shooter.set(1);
}


After testing, it would only run at what seems to be 66% speed.
First, I would personally supply "1.0" instead of "1" - I've had issues in the past (in other systems, not necessarily on an FRC system) with the conversion from int to double causing issues with stuff. This way you're supplying the double directly, instead of making the compiler convert it.

Try setting the speed to a variety of values (I would go 1.0, 0.9, 0.8, etc, all the way down to -1.0) and see what voltage you get out of the Talon for each value. Then do the same thing feeding in a joystick, printing out the joystick value as you go so you can get it at about the same values. This will let you plot two response curves, which may help us figure out what's wrong.

[Jon Stratis]

Its set to two talons, but for the sake of this i'm just writing the program as it would be if i only have one. The wire length is closer than any other motor control set up that we have.

So when I revised the program to have it read as such


if (js.getY()> 0)
{
shooter.set(1);
}


so if i move my joystick forward my shooter will go forward. When i run this program i have no problem at all, robot works fine and it reads 12+ V.

I've even switched out these talons with other talons to eliminate as much as could be and for some strange reason, being set to a button doesn't give it full speed.

Ahh... more information, makes more thoughts... What other code do you have around this motor? I assume somewhere you're telling it to stop and/or go in reverse?

[JavaNoNothing14]

I've stripped down the code, and removed it from all other variables, started a new file so all i have running is the button, and the js.getY(), (1 is being commented out when the other one is in use). And the results are still the same with the main program. It reads out 1.0 on the driver station, but shows a blinking light, and only reads ~8 volts on a voltmeter when done on a button.

[Jon Stratis]

So with the striped down code, the only way to stop the motor is to disable the robot?

Try getting rid of the "if" part all together - just set the motor to 1.0 and see what happens. I would also try 0.9, see if the output value changes.

[TFleig78]

Also, it would be helpful to post all of the code so we can see what else might be affecting the output

[JavaNoNothing14]

yea as i essentially just have the shooters set up to the drive train so its just the wheels running forward, rather than an arm just swinging around I didn't want to risk any other method of coding to be part of the issue. I'll try putting it on different speeds and seeing if the output values change

[Patrick Chiang]

Makes no sense that the axis is causing the Talon to give a different voltage than the button. If it were an electrical problem, you should see consistent and identical results for axis vs. button.

One problem I've frequently seen is:

if (js.getRawButton(SHOOTER_BUTTON))
shooter.set(1.0);
System.out.println(shooter.get());

... 200 lines of code later ...

shooter.set(0.7);

Prints 1.0 but sets to 0.7.

If you're multi-threading, maybe something else in another thread is modifying the shooter?

It just doesn't make sense that the problem is electrical related. If you don't want to post your code, it's fine, but we can at least help you eliminate the possibility of the problem being your code.

[JavaNoNothing14]

I tried opening a new project


public class WhyYouNoWork extends SimpleRobot{

Joystick js = new Joystick(1);
Talon shooter = new Talon(1);

public void robotInit(){

}

public void autonomous(){

}

public void operatorControl(){
while(isOperatorControl() && isEnabled()){
if (js.getRawButton(11)){
shooter.set(1.0);
}
}
}

[JavaNoNothing14]

I have never come across a problem that's baffled me as much as this has. Is it possible to calibrate the talons while applied on a button, or does it have to read Y-axis for it to work.

[TFleig78]

To calibrate the Talons, you should bring them through the full -1 to 0 to 1 range.

1. Press and hold the button labeled “CAL” with a paper clip. The
LED should begin to blink red/green.
2. Continue to keep the button pressed while moving the joystick
full forward and full reverse. You may do this as many times as
you like.
3. Center the joystick and then release the CAL button.
4. If calibration was successful, the LED will blink green several
times. If the LED blinks red several times, the calibration was
not valid. If this happens, the Talon will use the last valid
calibration values.

Did the new project with just the button code work?

[dipmeinaluminum]

To answer the electrical questions. The shooter is composed of two CIMs, brand new. Talons, out of the box, and PWMs from AndyMark. The solder-less terminals that connect the wiring are all solid. The raceway for ALL these wires are not ran in a configuration that runs against the chassis or may have been cut, all clean, short, out in the open runs. Instead of having the load on the motors, the multimeter replaced the terminals on the talons so when the actions are live, we have the 12V and the 8V read outs on the display and the Talon LED indicator light.
With this program are two limit switches that prevent the arm to destroy it's self when it fires, and when it returns back to loading position.

They work fine, we get zero volts when they are depressed.

[JavaNoNothing14]

Did the new project with just the button code work?

When last tried, no it didn't work. Gave an 8 volt reading. the difference in speed was noticeable

[BitTwiddler]

I'm not sure that reading the output of the Talon with a voltmeter is the correct approach to understanding what is happening. You see the output of a speed controller is a pulsed output that switches between 0 and 12 VDC.
It's the duty cycle (ratio of on to off time) that determines the speed of the motor. What you are probably seeing is the average voltage that the meter is reading over time. An oscilloscope is a better tool to use for this application.
Now having set that straight, I am also puzzled why you are reading a different average voltage output based on whether the joystick axis or the programmed button is providing the controlling input to the Talon's PWM input. If you have access to an oscilloscope can you see a difference in the pulse width of the PWM output to the Talon?

[Jon Stratis]

I'm not sure that reading the output of the Talon with a voltmeter is the correct approach to understanding what is happening. You see the output of a speed controller is a pulsed output that switches between 0 and 12 VDC.
It's the duty cycle (ratio of on to off time) that determines the speed of the motor. What you are probably seeing is the average voltage that the meter is reading over time. An oscilloscope is a better tool to use for this application.
Now having set that straight, I am also puzzled why you are reading a different average voltage output based on whether the joystick axis or the programmed button is providing the controlling input to the Talon's PWM input. If you have access to an oscilloscope can you see a difference in the pulse width of the PWM output to the Talon?

If you have a speed controller hooked up to a motor (which the OP said he does), you'll only read the average voltage, even with a scope - trust me, I've seen it. I was doing a demo for the team to show them how a speed controller output works, and was puzzled for about 5 mins when i just saw the average voltage... had to unplug the motor to actually be able to see the waveform.

[Zaque]

One problem I see with your code, although it shouldn't cause the problem you are seeing, is that the motor will not turn off if you release the button. You should probably change it to something like:


if(js.getRawButton(11)){
shooter.set(1.0)
}else{
shooter.set(0.0)
}

[Patrick Chiang]

When last tried, no it didn't work. Gave an 8 volt reading. the difference in speed was noticeable
But having shooter.set(1.0) with the getAxis() instead of the getRawButton() gives you 12V?

What happens if you bind it to another button?

[JavaNoNothing14]

One problem I see with your code, although it shouldn't cause the problem you are seeing, is that the motor will not turn off if you release the button. You should probably change it to something like:


if(js.getRawButton(11)){
shooter.set(1.0)
}else{
shooter.set(0.0)
}

right, i only had it set to the shooter.set(1.0) so that no other code could be the problem, even if its just to stop the shooter.

[JavaNoNothing14]

But having shooter.set(1.0) with the getAxis() instead of the getRawButton() gives you 12V?

What happens if you bind it to another button?

I understand that a voltmeter is not the best possible route to actually read what the talon's output is but when i have it set to getY(); the wheels move at nearly twice as fast. I have not tried testing it to another button, and won't get a chance to unfortunately until the regional.

I thank everyone for trying to get to the bottom of this problem..

[Patrick Chiang]

I understand that a voltmeter is not the best possible route to actually read what the talon's output is but when i have it set to getY(); the wheels move at nearly twice as fast. I have not tried testing it to another button, and won't get a chance to unfortunately until the regional.

I thank everyone for trying to get to the bottom of this problem..
Err... is it possible that set() is broken and you were setting it to a higher than 1.0 value (maybe because getY() returns more than 1.0)? Try setting it manually to something ridiculously high like 100.0.

Or maybe a limiter was implemented that lowered it if it went too high, and getY() would return values like 0.99583953 which would go through, but having it be 1.0 will get it artificially lowered in the program to say 0.7?

Just throwing ideas out there.

[BitTwiddler]

If you have a speed controller hooked up to a motor (which the OP said he does), you'll only read the average voltage, even with a scope - trust me, I've seen it. I was doing a demo for the team to show them how a speed controller output works, and was puzzled for about 5 mins when i just saw the average voltage... had to unplug the motor to actually be able to see the waveform.

Hmm. Sounds like I need to take a look for myself. I've never actually looked at a motor controller output. Make sense though since the motor inductance is probably distorting the pulse edges.

[BitTwiddler]

I understand that a voltmeter is not the best possible route to actually read what the talon's output is but when i have it set to getY(); the wheels move at nearly twice as fast. I have not tried testing it to another button, and won't get a chance to unfortunately until the regional.

I thank everyone for trying to get to the bottom of this problem..

Maybe the problem is more subtle than passing a numeric value to the robot from the DS. Is it possible that data packets are being dropped in the comms? Don't know why that would affect the discrete values versus the variable joystick output though. Do you have a motor timeout set in your initialization code?

Grasping at straws maybe but I really think the problem lies elsewhere.

[Kevin Sevcik]

Maybe the problem is more subtle than passing a numeric value to the robot from the DS. Is it possible that data packets are being dropped in the comms? Don't know why that would affect the discrete values versus the variable joystick output though. Do you have a motor timeout set in your initialization code?

Grasping at straws maybe but I really think the problem lies elsewhere.Ohhhhh, I just had a brainwave as I was typing this. You code looks fine, if you're always doing Set(1.0) and just switching from GetRawButton to GetAxis in your if condition, then it can't be an electrical issue. Clearly the problem must lie in GetRawButton. Can't be an issue in your code because your GetAxis works, and GetRawButton doesn't. Ergo, the problem has to be with the buttons themselves or GetRawButton.

Button state gets pulled directly from the control structure that gets set by the FRCComms library, so it's not like you can accidentally reset the state of the button in code. As far as I know, when you drop comms, the robot uses the last recieved values, so unless it's dropping long enough to fault things (which you'd notice driving), I don't think it's a comms problem. A comms problem that severe should affect things if you're using GetAxis anyways.

No, I'm betting it's a windows driver/joystick setup issue. I'm going to bet that (somehow) your joystick is setup to treat holding down that button like rapidly pressing the button. So you think you're holding it, but it's actually flickering off and on, and that's getting reflected in the data from the driverstation. So if you have code for turning the motor off when the button is released, you're actually constantly turning the motor on full speed, then off. Sort of an unintended PWM on top of the PWM.

Testing this theory:
Set up a variable to count edges on that button and check the value of that variable. Something like://In Robot class variable declarations
bool oldButton = false;
int edgeCount = 0;

//In your Teleop loop

if (oldButton != js.getRawButton(11))
edgeCount++;
oldButton = js.getRawButton(11);
//printf edgeCount here or write to the DSLCD, or however you want to monitor it.
If things are working properly, edgeCount should only increment once(ish) when you press the button, and once(ish) when you release it. It shouldn't increment while you're holding down the button. If it DOES, then the driverstation is sending bad data or windows is telling the driverstation that the button is flickering off/on.

Solution:
1. Figure out why the DS or windows thinks the button is flickering. I don't know the details of your joystick/laptop setup, so you get to have fun with that. Best solution because it actually fixes the problem.
2. Two separate buttons, one to turn on the shooter, on to turn it off. Worst solution because it complicates things for your drivers.
3. Debounce the OFF side of the button press. It's tricky, but you're basically looking for the button to be off for several loops in a row, to be sure it's actually off and not flickering. This solution should fix things even if the problem is comms dropout.
//In Robot class variable declarations
bool buttonState = false;
int offCount = 0;

//In Teleop initialization
buttonState = false;
offCount = 0;

//In Teleop Loop

if (buttonState)
{
if (!js.getRawButton(11))
offCount++;
else
offCount = 0;
if (offCount > 10) //10 is the number of loops we need to see
buttonState = false; //the button off to decide it's actually off
}
else
{
//will set buttonState true when first sees button pressed
buttonState = js.getRawButton(11);
offCount = 0;
}

if (buttonState)
{
shooter.set(1.0)
}
else
{
shooter.set(0.0)
}That will immediately turn the shooter on, then needs to see the button off for 10 loops before it actually turns the shooter off. Tweak the 10 loops to be as small as possible while still giving you consistent 12V output. I don't think you'd need to make it more than whatever's equivalent to 0.2 sec. I'd guess that 0.1 sec would work fine. You want it to be short, because the motor will keep running for that long after you let go of the button.

Note that if this is affecting this particular button, it could potentially affect ANY button where you're changing state based off whether the button is pressed or released. It won't affect things where you just set things if the button is pressed and do nothing if released.

[Kevin Sevcik]

Also, you really need to post back here with what the problem and solution is because I'm super curious and will PM you endlessly if you don't.