My team has been looking into purchasing a set of MK4 modules from SDS to practice with in the offseason and possibly use during the 2023 FRC season. I noticed that there is a spot on the modules to include a CANCoder for feedback. However, is there a compelling reason to use the CANCoder seeing as there is already encoders on the Falcon 500/NEO motors?
The camcorders are the to locate the absolute position of the modules. The internal encoders are relative (they will zero in startup independent of the direction the wheel is pointed).
So unless you want to align your wheels manually at startup you will need some sort of absolute encoder or limit switch to get the initial orientation.
4 Likes
Your conclusions are right, but the reasoning is slightly off. The integrated motors do have an absolute reading that they can be set to boot to. However, the steering motor on the MK4 goes through a 12.8:1 reduction. That means for a given orientation of the motor shaft, there are 12-13 corresponding orientations of the module. This is why you can’t use the integrated encoder alone to be sure of your position on boot-up even though it’s absolute.
The CANcoder magnet is mounted so that it’s 1:1 with the module (in fact, starting with the MK3 it turns directly with the module, no gear proxy or anything), so every value of the CANcoder has precisely one possible orientation of the module.
The template code 2910 provides actually only uses the CANcoders on boot-up to seed the integrated encoder value, then uses a position closed loop on the motor controller with the integrated motor encoder. I presume this is for latency reasons, but I have heard of teams successfully using the CANcoders for their feedback loops.
Edit: Sorry @chadr03, seems I did that thing where I confidently corrected someone who was already correct - at least on the NEO side. NEOs only have relative encoders available through the API. Internally it’s technically an absolute encoder, but one that goes through its full range every 1/7th of a rotation which isn’t very useful to the end user; therefore, it’s not exposed through the API. However, the Falcon 500 encoder is absolute for the entire shaft rotation and is exposed to the API.
We use the cancoders and directly pid off them. I know it’s not ideal because the can bus communication latency, but it’s the point we were at in our development when it was time to compete. It worked quite well.
5940 used the CANCoder configured as a Remote Sensor to the steering Falcon500. As others have mentioned, this introduces extra latency in the steering feedback loop, but theoretically is more accurate because the control loop is closed on actual module position and is not effected by any backlash in the gearing. This was what we tried first and it worked and we did not do an in-depth comparison between robot path tracking performance in this mode versus seed-on-boot as is done in the example code.
Both methods clearly work, but it would be interesting to look at the error introduced by closing the loop on Falcon500 angle. Would be pretty easy to do by just plotting the estimated module angle from the Falcon500 encoder vs. reading the value directly off the CANCoder. Maybe I will suggest this as a project to our team, though would be curious to know if anyone already did this.
I didn’t quite do that, but I did compare both setups with a module on a bench looking at the difference in response times. IIRC they were pretty comparable. We decided to go with the integrated encoder since it gave us one more CAN status frame to safely turn down (four for the whole robot), but in the end I don’t think it mattered much.
1 Like
Highly suggest using an srx mag encoder. It fits the same slot, and doesn’t utilize can.
Many teams would rather not bother with the gadgeteer port.
CAN is strange in that it’s convenient if you’re not running into the bandwidth limit but essentially a nonstarter if you are (though that’s starting to change with the introduction of socket CAN to FRC). For some teams, CANcoders will make it harder to reign in an overloaded bus, while others will have no trouble ramping them up to a 5ms status frame period.
TL;DR CAN is a trade-off, not a straight negative. Because of this, some see it as a positive.
1 Like
I’m pretty curious to try this for swerve encoders:
https://www.thethriftybot.com/bearings/Thrifty-Absolute-Magnetic-Encoder-p421607500
Seems like a 3 pin PWM pin would be easier to deal with than those tiny plugs. Especially because generally there is no SRX nearby to plug it in to.
2 Likes
You don’t need to mess with the gadgeteer port, you can wire the encoder directly to your PWM/DIO (I forget which one)
I think the problem they were referring to was the funky connectors to get there.
The mag encoder has a gadgeteer port on it, so you have to use a tiny ribbon cable to connect to it. From there, you (generally) would use one of the CTRE conversion boards to convert that to a 3 pin wire, which would then plug in to your Rio. By no means impossible to do, but it does require some funky connections, and some skill to make those wires reliably.
The CANCoder is generally regarded to be simpler to wire. You can either solder your own pigtails, or have the pigtails soldered on for you from CTRE. Then you just wire it in to your CANbus, and you are good to go. This simplified the wiring for us at least.
I’m curious about the ttb encoders because it simplifies that wiring. You can plug them straight into the analog port on the Rio. I also think it may be possible to plug them in to the Spark MAX. (this assumes they do work at 3.3V, and/or you use the REV breakout board)
1 Like
We use a neo550 for out azimuth so we were planning on running whatever encoder directly back to the spark max because that simplifies wiring more than the cancoder and less stuff on can. But from my understanding the spark max does not currently support a PWM encoder.
1 Like
I believe that is correct.
Reading the datasheet though, the Spark does support an 0-3.3V analog signal, which the TTB encoders can (potentially) provide by shorting 2 pins together.
Alternatively, the Rev breakout board (like above) converts the 0-3.3V signal to 0-5V input, which is what the TTB encoders is advertised to do.
I’ve not tested that particular encoder yet. I’ve been considering doing so as a summer project, be because wiring something directly into the Spark Max is pretty appealing to be able to simplify wiring. It’s also significantly cheaper than other solutions, which is a plus.
We’re probably gonna try these encoders for our summer (or early fall) swerve project since they’re less expensive, easy to wire, and use our always unused analog inputs.
1 Like
For some reason I was thinking it’s PWM output. Sound like it might be a solution to on of our problems.
Have any teams successfully used SDS MK4 - NEOs with the Thrifty Absolute Mag Encoder instead of the CANcoder?
2 Likes
We used the Thrifty Absolute encoders for our Swerve X modules this season and they worked great, a lot less noise than when we were using the mag encoders and its a lot easier to connect to the roboRIO.
6 Likes
I wonder. The thrifty encoders would be more deterministic than cancoders because you don’t have to deal with can timing. The resolution appears to be the same as a cancoder.
How much will noise on the analog channel degrade the actual resolution?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.