With the new release of the hex bore Mag Encoder housing and the 221 Systems encoder, our team will likely use absolute encoders in positions we previously used quadrature encoders. In the past, we primarily used the Mag Encoders in the VersaPlanetary housing, but with how easy it will now be to put an encoder directly on a shaft, we will use the absolute mode of these encoders wherever possible. Since this will be our first time using absolute encoders, I have a couple of questions:
For teams that build 2 robots, how do you effectively zero your absolute encoders to the same position on both robots? The solution in my head right now is to have a text file keeping track of the zero positions of absolute encoders for the robot the file is on, but I don’t know if that’s the best/only solution.
We’re looking to use some of our NEOs and Spark MAXes from last year on some of these mechanisms. From what I’ve heard, the Spark MAX pinout for the sensor port is the same as the Talon SRX pinout, so theoretically, we should be able to use the Mag Encoders with these directly, I think. However, there are a couple of things that give me pause:
REV has, I believe, referred to not being able to use the standard encoder pins on the Spark MAX when in brushless mode. Does this mean that if we connect the Mag Encoder (which will, when the mechanism it’s connected to spins, raise the quadrature encoder pins high at various times), the function of the brushless motor will be impeded? If so, I think we could resolve this by modifying the cable somehow, but I really hope this isn’t the case.
Also, do the Spark MAX APIs allow for using an external analog sensor? I know that using an external encoder was just added, but I’m not positive about about using analog sensors as external encoders (including for the built-in control loops).
Are you saying that the software restricts the alternate encoder to be a quadrature encoder? If so, can the CANAnalog class in the Spark MAX API only be used with brushed motors?
It doesn’t seem to me that the brushless motor uses the analog pin, so I don’t think there is pin interference. I think the issue is if the functionality to use the CANAnalog class as the sensor for the CANPIDController is present as of now in the Spark MAX API.
There are 2 types of absolute encoders. Ones that output an analog signal, and ones that output a pwm duty cycle signal. Devices like the hex encoder only output a pwm signal. I don’t think the spark currently has support for that type of signal, but I might be wrong. For an analog signal, the spark could read it fine.
As more of a general answer to this “cal stays with robot hardware, same software works on all robots” problem:
We’ve used roboRIO MAC address in the past to change calibration values, depending on which robot you’re on. Similar end result with different tradeoffs (ex: what if you have to swap the RIO’s at competition?).
Storing the calibration text file on a USB drive that lives with the robot it’s calibrated for is another option.
A final idea: reserve a digital input or two to place jumper harnesses on - the jumper harness determines the calibration used (and presumably the jumpers are zip-tied to the robot). An analog input with a resistor in the jumper is slight alteration to this principle with the same effect.
The Alternate Encoder input on SPARK MAX is currently restricted to quadrature only. The Analog input is independent of both the default encoder and the alternate encoder and can be used with either motor type.
This was one of the design constraints for our Through Bore encoder; an easy way to keep the relative position the same across bots, but also keep the relative position if you ever need to take the sensor off and put it back on the mechanism or replace it. When 3005 uses absolute encoders we make sure to do the following:
Design the mechanism so there is only one orientation that the sensor itself can be placed. The unique case and mounting pattern of the Through Bore makes this easy.
Make sure the rotation part of the sensor has an absolute marking relative to the case. The small notch in the hex part of our sensor lines up with the case to mark 0.
Physically mark the mechanism for where the 0 point should line up.
If you do these three things, between two robots, or when servicing a component etc. as long as you re-assemble it correctly the 0 point will always be the same, and you won’t need any calibration routines or text files.
Agreed. As I’m reading it, there is no absolute digital sensor [PWM or otherwise] input to the SPARK MAX in any of its operating modes. The only ways to send an absolute position are through analog or index + A/B.
In addition to reading the pinout diagrams and there follow-up paragraphs, I searched for PWM and absolute. The only way PWM is used in the manual is to refer to the control input, and the only ways absolute is used are for the analog input and the “Absolute maximum supply voltage” of 30V.
3946 has used the first and third, and I definitely prefer the third. When keyed to the MAC address, you can’t move the RIO among the chassis, nor move mechanisms from chassis to chassis effectively without re-configuring/compiling/deploying the code, which is what we’re trying to avoid here.
Correct, the outputs for the Through Bore Encoder are Quadrature (A, B, Index) and Absolute PWM. It cannot currently be used with the SPARK MAX as an absolute encoder, but this feature is on our roadmap.