We use a TalonSRX with a 775 pro to control our turret. And we use the CTRE’s Mag encoder. Since the turret’s reduction is big, so it takes the encoder to rotate nearly 400 thousand unit to make the turret rotate one circle. However, when l was testing the encoder with Phoenix Tuner, l just let the turret to rotate to 90 degree and 180 degree for some times. But the encoder’s light suddenly doesn’t working, which makes my turret rotate in one direction very fast. And when l use Tuner to get the encoder’s value, l could get nothing. To debug this problem, we plug the wire to another mag encoder and it’s light is on and l can also get the encoder’s value. So, the problem is on the Talon’s mag encoder which is wired on the 775pro.
We have used the same encoder, motor and motor controller(Talon SRX) on our swerve, but it works very well. l don’t know whether other people also meet with this problem? Is that a problem of the encoder itself?
Below are some photos of the encoder we use on our turret.
You need to provide some information about how it is hooked up for starters. If the light isn’t on, it’s not likely to work. What the motor does in this state depends on your software though (if it’s connected to the RIO), or possibly on how you have the motor controller configured (if it’s connected directly to the TalonSRX). If it was working and then the LED went off, it’s likely to be a wiring problem.
I don’t deploy code to the robot. I just run tuner setup and use tuner to test it. I set the PID 0 slot to Pulsewidthencoded ( l can’t remember its accurate name). And I set the KP to 0.006. Besides these two things, every value is factory default.
It’s not the wiring problem since when the light of the encoder went off, l plug it into another magencoder and its light is on and l can get the encoder’s value.
Add one thing: The encoder works well and its light is on at first. After l use to tuner to test it for 3minutes. Its light suddenly goes off.
Integrated components work together so when the datasheet/specification says 6380 rpm that means all parts of the motor are good for that speed.
[There is also a good chance the encoder is required in order for the motor to work at all which just shows very tight integration forcing the speed spec for the motor and encoder to be the same.]
Thanks! Another small question about Falcon’s integrated sensor: that’s how to get the integrated sensor’s absolute position in code? It seems that integrated sensor has two kinds of position and l guess one of them is the relative position and the other is the absolute. Besides, why is the absolute position unsigned here? If so, it seems that it’s hard to use absolute position to control the turret.
I assume you are still asking about the turret and the steer motor on a swerve module has the same problem. My team doesn’t use the Falcon 500 absolute position because it doesn’t work the way we need and that may be a problem for you, too.
For ease of aiming a device at power-on you have to have an absolute position that is remembered throughout the powered-off period and directly or nearly directly mechanically connected to the device we want to know which way it is pointing.
There is too much “round-off” error or slop in the mechanics to accurately know the position of the slowly rotating device - the turret - based on the position of the fast moving device - the Falcon 500 rotating about 200 times faster. After a short period of time of going back and forth the fast moving encoder doesn’t reflect the actual position of the slow device.
But that is the least of your problem. If the encoder goes around 200 times for the turret’s one rotation then if the absolute encoder is at say 15 degrees then how would you know which of 200 positions of the turret is the turret at that the encoder can read 15 degrees? Because of this aliasing you have to use the relative position which will remember how many times you’ve gone around. But that effectively count of rotations in the relative encoder is forgotten by the Falcon500 when it is powered off (“On power cycle, sensor position resets to zero.”). The absolute encoder remembers its current position within one rotation even when powered off. The relative encoder accumulates position even as there are multiple rotations (add to the accumulation if rotating in one direction and subtract from the accumulation if rotating in the other direction) but that accumulation is reset to 0 at power on.
[Note that many but not all encoders work this way. For example, the Bosch seat motor encoder cannot tell you which direction it is rotating - you have to remember that in order to accumulate position correctly.)
The other question, the absolute encoder reads unsigned 0 to 2047 for a 360 degree rotation so each position is uniquely identified. If you want -180 to +180 degrees then you can calculate that with a simple linear transformation.
Based on what you are saying, you have a CTRE SRX Mag Encoder, with a CTRE Talon SRX. I’m assuming you are using a premade cable, such as CTRE SRX / Gadgeteer Data Cable. Then, there’s the question of how you have CAN connected (assuming it’s just to the RIO). All of these details are important – there are many different encoders used in FRC, and some of these have several ways of connecting them.
The part about working for three minutes and then the encoder LED going off is odd. Here’s what the manual says about the LED:
The points about how fast the encoder is spinning are valid – there isn’t enough information in your posts to know about this. If the encoder is connected to the turret, you should be fine here. And, this is not a situation in which you want to use an encoder built into the motor, for the given reasons. There is also a big difference between an encoder which can determine absolute position, and one which cannot. In the later case, you need some way of zeroing things. You likely also will want to use limit switches, to prevent the turret from over-rotating. In some cases, you can use soft limits to do this, but it very much depends on the motor controller and encoder you are using.
excellent addition to designing moving parts. I always want the students to use them because “What could go wrong? Everything!” We set the soft limits range inside the mechanical limit switches’ range. Twice the protection and you might be able to cut it a little closer with the mechanical limits. Hard stop blocks are also useful to prevent damage to nearby components just in case the limit switches aren’t exactly right for whatever reason and your device runs away.
Thanks! @SLAB-Mr.Thomas@nuttle I think we have solved this problem. We mounted the encoder below an epicyclic gearbox in the past, so it had a very big reduction ratio and the encoder was easy to burn out. Now, we mount the encoder above an epicyclic gearbox and it works well both in practice and in theory. Thanks!
