Use a button to make a motor move a certain number of rotations

[Levansic]

Originally Posted by RoboBucs

How do they have no way of understanding encoders if the encoders are built in?

Encoders, built in or otherwise, have to plug into something that can understand their signals. The Victors have no such facility. They are not "intelligent", meaning they don't take any external feedback.

The motors themselves don't have any intelligence. Their inputs are only the voltage applied to the wires. The encoders are not linked in any way to the windings in the motor.

You have setup some DIO channels to take the A and B data from the encoders. This information goes straight into the roboRio, which has to do something with it, to control the input to the victors. The roboRio is the brain in this case.

The new Talon SRX's are intelligent, and can do the work onboard with no involvement of the roboRio. The older Jaguars had promise of this, but in practice, they rarely worked as designed for encoder-driven closed loop feedback. I have trouble finding the right words to describe how much I LOVE the Talon SRX's closed loop modes.

[RoboBucs]

Originally Posted by Levansic

Encoders, built in or otherwise, have to plug into something that can understand their signals. The Victors have no such facility. They are not "intelligent", meaning they don't take any external feedback.

The motors themselves don't have any intelligence. Their inputs are only the voltage applied to the wires. The encoders are not linked in any way to the windings in the motor.

You have setup some DIO channels to take the A and B data from the encoders. This information goes straight into the roboRio, which has to do something with it, to control the input to the victors. The roboRio is the brain in this case.

The new Talon SRX's are intelligent, and can do the work onboard with no involvement of the roboRio. The older Jaguars had promise of this, but in practice, they rarely worked as designed for encoder-driven closed loop feedback. I have trouble finding the right words to describe how much I LOVE the Talon SRX's closed loop modes.

Man this stuff is so beyond my level of experience with this stuff. I may just have to work this with the joystick like we have been so far, unless you have some way around this:/

[RoboBucs]

Originally Posted by RoboBucs

Man this stuff is so beyond my level of experience with this stuff. I may just have to work this with the joystick like we have been so far, unless you have some way around this:/

Ok, I think we're just gonna have it where when we press the button it will just run for however long we need it to run, will that work?

[RoboBucs]

Originally Posted by Levansic

Encoders, built in or otherwise, have to plug into something that can understand their signals. The Victors have no such facility. They are not "intelligent", meaning they don't take any external feedback.

The motors themselves don't have any intelligence. Their inputs are only the voltage applied to the wires. The encoders are not linked in any way to the windings in the motor.

You have setup some DIO channels to take the A and B data from the encoders. This information goes straight into the roboRio, which has to do something with it, to control the input to the victors. The roboRio is the brain in this case.

The new Talon SRX's are intelligent, and can do the work onboard with no involvement of the roboRio. The older Jaguars had promise of this, but in practice, they rarely worked as designed for encoder-driven closed loop feedback. I have trouble finding the right words to describe how much I LOVE the Talon SRX's closed loop modes.

Do you know any realistic way that I could make this work with the encoder? I honestly don't have the slightest clue about anything to do with PIDs. All I need it to do it run an exact amount of rotations each time, there has to be some way to do it, could I maybe use a case structure?

[Levansic]

OK, there are a few things that you can do to get it pretty close without doing a full PID. No matter what, you need to get your logic right, which means that pressing a button will toggle a persistent state. You need to flop between deployed and not deployed, and the state has to be retained from one pass through your code to the next. Feedback nodes (at the bottom of the structures palette) are helpful for this. After you get this worked out, this logic can switch your case structure (or selects) to start moving in the right direction.

Once you have that part figured out, you can use the PID vi's that are included in LabView. Since the output shaft is so slow relative to the count, you can probably get away with using only a well-chosen P gain, setting the I and D to zero.

If you don't want to use the PID function, you can implement the P part on your own. Basically, you calculate the difference between where you are (current encoder count) and where you want to be (final encoder count), and multiply this number by the P gain that you choose. This number is then fed to the motor set vi.

As you approach the desired final encoder count (called the setpoint), the resulting number will get smaller, and the motor will slow, eventually stopping.

If your P gain is set too low, it will never reach the setpoint as the commanded voltage will eventually not be enough to move the motor. If the P gain is too high, the motor will oscillate about the setpoint. Because of this, you could purposefully choose a P that is slightly too low, and bump up your setpoint to a number that lets your motor rest where you want it to end up.

This last paragraph is an adequate way to accomplish your goals, only because your design is essentially toggling between two points. You fudge the setpoint numbers for deploy and retract, until it acts the way you want it to. This may not be viewed as the correct way from a control system perspective, but it will be good enough.

[mshafer1]

Originally Posted by RoboBucs

How do they have no way of understanding encoders if the encoders are built in?

They do not correspond to each other, the drive expects values from -1 to 1 on each axis corresponding to a joystick, you could use a pid loop (use the target encoder value as the setpoint and the current reading as the processing variable (pid.vi) which would give you a fine control (if you do this, also set the range on the pid from -1 to 1).
Other option is to implement a proportional gain yourself. Take the current encoder value, subtract the current reading and multiply it by a constant (you'll have to play with the constant to get it where the robot gets close without oscillating)