View Full Version : Encoder Wiring Help Needed
This is our team's first time using encoders and we are encountering issues as to where on the robot/cRio we should be connecting the encoder wires. If anyone can please help and show what part of the robot we should wire our encoders to (electrically) and more specifically how.
Please Note: we are using the kit of parts E4p encoders for our shooter.
Thanks in advance!
The encoders in the KOP have 4 wires. +5, GND, A and B. You can connect the encoders either to the Jaguars directly (if you are using the Jaguars as your motor controllers) or to the digital input channels on the digital sidecar.
For connecting to the Jaguar, crimp a 5-pin header connector with the 4 wires ("+" goes to +5, "-" goes to GND, "A" goes to A and "B" goes to B, "I" has no connection).
If connecting to the cRIO, each encoder needs two digital channels. On the first digital channel, "+" goes to +5 (red), "Gnd" goes to "GND" (black) and "A" goes to signal (white). For the second digital channel, "B" goes to signal (white).
nitneylion452
03-02-2012, 18:58
The encoders in the KOP have 4 wires. +5, GND, A and B. You can connect the encoders either to the Jaguars directly (if you are using the Jaguars as your motor controllers) or to the digital input channels on the digital sidecar.
For connecting to the Jaguar, crimp a 5-pin header connector with the 4 wires ("+" goes to +5, "-" goes to GND, "A" goes to A and "B" goes to B, "I" has no connection).
If connecting to the cRIO, each encoder needs two digital channels. On the first digital channel, "+" goes to +5 (red), "Gnd" goes to "GND" (black) and "A" goes to signal (white). For the second digital channel, "B" goes to signal (white).
Is there any advantage to wiring the encoders one way over the other? I only ask because we used encoders last year and had no idea they could go to the jags.
If you wire the encoders to the Jags, you must use CAN or you can't access them. The benefits are pretty much the CAN versus PWM arguments such as: cleaner wiring, not taking 2 digital channels per encoder, can optionally use the Jag's built-in PID control etc.
its da PAT!!!
03-02-2012, 19:22
Is there a point to access both channels?
Is there a point to access both channels?
Don't understand your question. What channels? Are you talking about the two digital input channels? If so, you need two channels per encoder in order to determine the position/speed as well as the direction of the rotation. the FPGA will handle the two channels and give you the resulting count and direction.
its da PAT!!!
03-02-2012, 19:27
Yes that's what I mean. But if you use PWM and use either A or B channel is it less accurate?
Yes that's what I mean. But if you use PWM and use either A or B channel is it less accurate?
What are you going to use it for?
its da PAT!!!
03-02-2012, 19:33
If connecting to the cRIO, each encoder needs two digital channels. On the first digital channel, "+" goes to +5 (red), "Gnd" goes to "GND" (black) and "A" goes to signal (white). For the second digital channel, "B" goes to signal (white).
Just as a general question. But I may have miss read he post. Do A and B both go to white or is it one or the other?
Yes that's what I mean. But if you use PWM and use either A or B channel is it less accurate?
It's not a matter of accuracy, without two channels, it won't know the direction of rotation. Besides, unless you are writing code to "count" the pulses from the one digital channel yourself, the Encoder module provided by the WPI library expects both A and B channels.
Encoder(UINT32 aChannel, UINT32 bChannel, bool reverseDirection=false, EncodingType encodingType = k4X);
Just as a general question. But I may have miss read he post. Do A and B both go to white or is it one or the other?
A and B goes to the white of a different digital input channel.
unless you are writing code to "count" the pulses from the one digital channel yourself, the Encoder module provided by the WPI library expects both A and B channels.
Are you saying the FPGA running the FRC firmware cannot be configured to count pulses on one channel and make that count available to the CPU? Or just that the high-level encoder class is not designed to do that?
its da PAT!!!
03-02-2012, 19:40
Makes sense to me. My team since i've been involved, never really used anything more than just a limit switch. So I just figured I ask for future.
Are you saying the FPGA running the FRC firmware cannot be configured to count pulses on one channel and make that count available to the CPU? Or just that the high-level encoder class is not designed to do that?
I am not sure if it can or cannot. After all, the FPGA is programmable, the firmware can configure it anyway it could. My understanding is that the FPGA implements the counter for the encoders and the Encoder module in the WPI library is expecting both channel A and B. There is no method in the Encoder module that accepts only one channel. So I am making a speculation that it does not support one channel. However, it is probably possible to implement a software counter. But I don't know the innards of the FPGA enough to be able to do that.
Makes sense to me.
You linked your response to my two-question post#12. Was that intentional? If so, not sure what part made sense to you.
its da PAT!!!
03-02-2012, 19:47
I dont recall doing that, but no it wasn't to your two part question.
Wait...
I just found a different class module (GearTooth class). This one accepts one channel. So it does support counting one channel. I suppose you can connect the A channel to one digital input and use the GearTooth class to access the count.
its da PAT!!!
03-02-2012, 19:51
To honest with you I know nothing about code. The most i know is that we use Java lol. I'm more of a mechanical/ electrical guy.:rolleyes:
Interesting...
From reading the source code of the GearTooth class, it seems the GearTooth sensor can even tell the direction. It supports different pulse widths on different directions. I wonder how does that work? But I am sure it is only specific to the GearTooth sensor. If you use one channel of the optical encoder, since the pulse width doesn't change in both direction (except for changing speed), it cannot decode the direction from the pulse width.
I am not sure if it can or cannot. After all, the FPGA is programmable, the firmware can configure it anyway it could. My understanding is that the FPGA implements the counter for the encoders and the Encoder module in the WPI library is expecting both channel A and B. There is no method in the Encoder module that accepts only one channel. So I am making a speculation that it does not support one channel. However, it is probably possible to implement a software counter. But I don't know the innards of the FPGA enough to be able to do that.
Just found this thread:
http://www.chiefdelphi.com/forums/showthread.php?t=101587
Just found this thread:
http://www.chiefdelphi.com/forums/showthread.php?t=101587
Yep, there is also a counter class that can be used for this purpose.
Yep, there is also a counter class that can be used for this purpose.
I am assuming that the counting is being done by the FPGA hardware. Otherwise you'd swamp the cRIO with interrupts.
I am assuming that the counting is being done by the FPGA hardware. Otherwise you'd swamp the cRIO with interrupts.
Yep, the counting is done by the FPGA.
Yep, the counting is done by the FPGA.
Does it say that explicitly in one of the documents you've just been reading?
Does it say that explicitly in one of the documents you've just been reading?
It's in the source code of counter.cpp. It's accessing the FPGA all over.
jmailhot
04-02-2012, 11:26
Another issue with encoders to keep in mind is the "sense" of forward and backwards. Especially if using the encoders with jaguar PID loops, but even with cRIO PID loops, the encoders need to be increasing when the motor is going forward, and the control input sense of forward needs to match the encoder. And the jaguar's sense of positive voltage needs to match also. You may need to reverse the A and B lines of the encoder, or the polarity of the motor, to get these things all having the same definition of "forward". If you add limit switches to the mix, the forward and reverse limit switches must also correspond.
BitTwiddler
04-02-2012, 13:53
Yep, there is also a counter class that can be used for this purpose.
Very timely discussion. I am going to make the assumption the LabView VIs associated with the counter implement this class for us to use to count shooter revolutions.
Thanks guys.:D
gnichols
04-02-2012, 16:14
Not sure where to go. I have wired these encoders using the 2 channels on the sidecar. When I do, the robot goes nuts. It spins one side drive backwards and the second side does nothing and never works. Have wired +5, gnd, signal A to first channel and signal b to second channel on both sides. Anyone have an explanation as to what is going on.
BitTwiddler
04-02-2012, 18:12
Very timely discussion. I am going to make the assumption the LabView VIs associated with the counter implement this class for us to use to count shooter revolutions.
Thanks guys.:D
An Update:
For you Labview programmers only interested in looking at one input to count pulses to determine the rate of rotation, the WPI counter library works great. Just make sure you take the time to read the help file on the counter VIs thoroughly.
When I got to the shop earlier today the team programmer complained that the software based counter he had built couldn't keep up at high motor speeds. I explained how the FPGA offloaded this work to the hardware and the counter VIs in the WPI library took advantage of this capability. We tried them and they worked all the way up to the 4000 RPM speed with no problem. We found it helpful to use one of the low-pass filters from the PID library.
Alan Anderson
04-02-2012, 20:31
Not sure where to go. I have wired these encoders using the 2 channels on the sidecar. When I do, the robot goes nuts. It spins one side drive backwards and the second side does nothing and never works. Have wired +5, gnd, signal A to first channel and signal b to second channel on both sides. Anyone have an explanation as to what is going on.
What is your program doing to control the drive motors? Are the encoder readings used to compute the commanded motor power?
Not sure where to go. I have wired these encoders using the 2 channels on the sidecar.Which 2 channels? Which type of channel? They should be digital I/Os.
When I do, the robot goes nuts. It spins one side drive backwards and the second side does nothing and never works.
What do your encoders have to do with your driving? Have you implemented some form of control loop already?
Have wired +5, gnd, signal A to first channel and signal b to second channel on both sides. That's one way to wire them, provided you are using the digital I/Os.
BurkeHalderman
04-02-2012, 23:04
Are you supposed to wire the encoders to the sidecar or the Analog Breakout?
Are you supposed to wire the encoders to the sidecar or the Analog Breakout?
The encoders provide quadrature outputs (i.e. two square waveforms), so they need to be wired to the digital I/O pins on the sidecar.
I'm on the same team as gnichols.
The encoder is wired into 2 digital I/O ports on the digital sidecar, with careful attention made to plugging in gnd and signal to one port and 5v and signal to other port. The hardware connection is correct.
With the encoder wired, when the code is enabled, and in teleop mode, the motors start to run, with no joystick input.
With the encoder unplugged, everything works as expected, with no movement until the joystick is moved.
We are using C++ and this happens even when deploying the FRC Default Program (current with imaging tool), which when loaded into workbench is titled BuiltinDefaultCode.
That code does not explicitly reference digital input ports or the encoder classes at all, neither does the custom code we have created when first discovering this problem.
One other problem we are having is that the signal light we have connected to the digital sidecar is not lighting, though the small led on the sidecar next to the DSL port is lighting. What voltage should we see there?
Brian Selle
05-02-2012, 13:21
We are also having encoder issues. We have the E4P wired as described in the previous posts (2 digital IO ports using PWM cables - one has signal A, +5, GND and the other signal B). I've checked the output with a multimeter - the +5 and GND are good (the red light on the encoder is on) and when I slightly move the wheel I can see the A and B channels vary from 0 to 5v. When the motor is moving the voltage of the A and B channels is 2.5-2.6v. In the software, we create an Encoder - assign the ports in the constructor, but when we output distance, rate, or raw when motor is moving we get 0 for all. I triple checked the port numbers (tried 1,2 and 7,8) but no joy.
One thing I wonder about... is that the our motor shaft is slightly less than 1/4" so we had to crimp the encoder wheel slightly. I wobbles ever so slightly when the motor turns. Could this be it?
Alan Anderson
05-02-2012, 18:08
One other problem we are having is that the signal light we have connected to the digital sidecar is not lighting, though the small led on the sidecar next to the DSL port is lighting. What voltage should we see there?
You should see 12 volts when the light is supposed to be on.
Are the BAT, 5V, and 6V LEDs lit?
nitneylion452
05-02-2012, 18:11
We are also having encoder issues. We have the E4P wired as described in the previous posts (2 digital IO ports using PWM cables - one has signal A, +5, GND and the other signal B). I've checked the output with a multimeter - the +5 and GND are good (the red light on the encoder is on) and when I slightly move the wheel I can see the A and B channels vary from 0 to 5v. When the motor is moving the voltage of the A and B channels is 2.5-2.6v. In the software, we create an Encoder - assign the ports in the constructor, but when we output distance, rate, or raw when motor is moving we get 0 for all. I triple checked the port numbers (tried 1,2 and 7,8) but no joy.
One thing I wonder about... is that the our motor shaft is slightly less than 1/4" so we had to crimp the encoder wheel slightly. I wobbles ever so slightly when the motor turns. Could this be it?
It could very well be the issue. Rather than crimp the encoder wheel (which is highly inadvisable) try taking a small piece of paper or thin plastic (like from a plastic bag) and putting it over the motor shaft, then putting the encoder wheel over the plastic or paper covered motor shaft.
I'm going out on a limb here, but have you guys (gnichols, alb4h) checked your DB37 cable assembly as per FIRST's directions (http://www.usfirst.org/sites/default/files/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2012_Assets/DB37%20Ribbon%20Cable%20Assembly%20-%20Rework%20Instructions.pdf)?
If the problem persists, I would suggest posting copies of your code and pictures of the relevant connections so it's easier to isolate the problem.
hello all,
my team (1325) is still unsure as to the wiring of our E4p encoders if anyone could supply a diagram that would be great!
Thank You
Alan Anderson
07-02-2012, 22:11
my team (1325) is still unsure as to the wiring of our E4p encoders if anyone could supply a diagram that would be great!
You will find just such a diagram in both the Encoder Example and Motor with Encoder LabVIEW example projects.
In short, connect encoder common, power, and output A to (-), +5, and signal of one DIO on the Digital Sidecar. Connect encoder output B to the signal of another DIO.
Brian Selle
08-02-2012, 22:23
We are also having encoder issues. We have the E4P wired as described in the previous posts (2 digital IO ports using PWM cables - one has signal A, +5, GND and the other signal B). I've checked the output with a multimeter - the +5 and GND are good (the red light on the encoder is on) and when I slightly move the wheel I can see the A and B channels vary from 0 to 5v. When the motor is moving the voltage of the A and B channels is 2.5-2.6v. In the software, we create an Encoder - assign the ports in the constructor, but when we output distance, rate, or raw when motor is moving we get 0 for all. I triple checked the port numbers (tried 1,2 and 7,8) but no joy.
One thing I wonder about... is that the our motor shaft is slightly less than 1/4" so we had to crimp the encoder wheel slightly. I wobbles ever so slightly when the motor turns. Could this be it?
Fixed the problem... you need to call encoder.start() before you get any readings. Also, the disk does wobble slightly but it's well within the tolerance of the optical reader. Another poster did suggest a better idea of using paper or plastic shims, but crimping the wheel (ever so slightly) was actually on the manufacturers instructions. We are reading motor turns - yeah!
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.