We are planning to use falcon for power motor and neo for turning motor as well as we have cancoder as abselute encoder in system do we need to add extra encoder for neo or is it all enough ?
You donāt āneedā an absolute encoder, but it would be highly recommended.
The Neos built in encoder is relative to itself, but not the overall position of the wheel on the ground through a gearbox or even if it was directly mounted to the output of the neo. You would need to move all of the wheels to a āhomeā position and then power the robot on without nudging them to make sure they start off aligned properly. This is problematic for lots of reasons, mostly itās too much to expect humans to get perfect over and over again.
It also has a semi-low count per revolution of 42. Again directly mounted (which no swerve does) this would not be enough to control precise degrees for rotation.
The cancoder will always report the same position no matter when power is applied. It is tied directly to the rotation of the wheel assembly and itās degrees are accurate to what direction the wheel is currently facing (which way itās steering)
The Cancoder acts as the encoder for the turning motor. It would not have much use on the drive motor, as you do not need to have the drive motor position.
Relative encoder (built into the Kraken in this case) is used to get how fast the robot is theoretically traveling linearly, assuming perfect friction and no variation in wheel diameter, drag, etc
You donāt need to know the original home position, instead you measure how far the counts changed over a certain period of time. This change in distance (based on diameter not changing and perfect friction again) over time is your robots linear speed. The amount of time measured varies but itās incredibly small in the ms range or less to make sure counts are not missed, or over lapped more than one full rotation between checks. Higher frequency will result in more accurate speed measurements.
In some cases outside of FRC you would use encoders that trigger an interrupt pin (Arduino) or use a device to hold a buffer when the frequency is faster than the main control board can handle. All counts are picked up by this Encoder Buffer (hard to find any nowā¦) and then you poll it at a rate you can handle and then do the math yourself.
You already have an absolute encoder - thatās your cancoder.
You can recalibrate NEO encoder based on the cancoder values (we essentially did that in our 2023 code, though we used Falcons in that fashion) to use hardware PID for angle motors.
If you can use hardware PID, your angle motors will perform faster and will be more precise. But you can use hardware PID only for encoders directly connected to the corresponding motor (you cannot directly connect CANCoder to Spark) or if the underlying technology allows it (e.g. CANCoder can talk to the Falcon or Kraken directly and FAST via CAN). Software PID for turn motors technically will work as well, but it will have bigger potential to āmisbehaveā if your PID is not calibrated quite well (hardware PID is much more forgiving due to the higher sampling/measuring rate).
The low count per revolution in NEO may also be a factor if you have low gear ratio between the motor and the wheel (cancoder has very high resolution of I think 2048 ticks per revolution, which is 0.18 degree; NEO with 42 ticks and, say, 8:1 total steering gear ratio has 1.07 degree resolution, so about 6 times less precise)