Open vatbrain opened 3 years ago
Thanks for running with the example, can you provide a summary of how you have the sensor wired?
One of the cables that was included with the encoder is plugged into the encoder on one end and an Alternate Encoder Adapter on the other end. The Alternate Encoder Adapter is plugged into the Spark Max such that the zip tie slots on the adapter and the Spark Max line up. I am running the code on a VMX-pi, not a Roborio, but I would not expect that to make a difference.
Here is the latest code I was running to watch the behavior of the alternate encoder: `/----------------------------------------------------------------------------/ / Copyright (c) 2017-2018 FIRST. All Rights Reserved. / / Open Source Software - may be modified and shared by FRC teams. The code / / must be accompanied by the FIRST BSD license file in the root directory of / / the project. / /----------------------------------------------------------------------------/
class Robot : public frc::TimedRobot { /**
Change these parameters to match your setup */ static constexpr int kCanID = 1; static constexpr auto kMotorType = rev::CANSparkMax::MotorType::kBrushless; static constexpr auto kAltEncType = rev::CANEncoder::AlternateEncoderType::kQuadrature; static constexpr int kCPR = 8192; //orig 8192;
// initialize SPARK MAX with CAN ID rev::CANSparkMax m_motor{kCanID, kMotorType};
/**
revolution set to 8192 */ rev::CANEncoder m_alternateEncoder = m_motor.GetAlternateEncoder(kAltEncType, kCPR); double y = 0.0; double echo_y = 0.0;
public: void RobotInit() { /**
frc::SmartDashboard::PutNumber("Input Y", y);
frc::SmartDashboard::PutNumber("Echo Y", echo_y);
frc::SmartDashboard::PutNumber("AltEncdr Position", m_alternateEncoder.GetPosition());
frc::SmartDashboard::PutNumber("AltEncdr Velocity", m_alternateEncoder.GetVelocity());
frc::SmartDashboard::PutNumber("Applied Output", m_motor.GetAppliedOutput());
}
void TeleopInit() override { frc::SmartDashboard::PutNumber("Input Y", y); }
void TeleopPeriodic() override { rev::CANSparkMaxLowLevel::SetEnable(true); // Periodically ensure motor controller outputs are enabled
double in_y = frc::SmartDashboard::GetNumber("Input Y", 0); if((in_y != y)) { m_motor.Set(in_y); y = in_y; echo_y = y; } //m_motor.Set(y);
frc::SmartDashboard::PutNumber("Echo Y", echo_y);
frc::SmartDashboard::PutNumber("AltEncdr Position", m_alternateEncoder.GetPosition());
frc::SmartDashboard::PutNumber("AltEncdr Velocity", m_alternateEncoder.GetVelocity());
frc::SmartDashboard::PutNumber("Applied Output", m_motor.GetAppliedOutput());
} };
int main() { return frc::StartRobot
Note that the above code sets the position conversion factor of the alternate encoder to 0.5, which gives me one revolution reported per one actual revolution. When I do not make that call, I get two revolutions reported per one actual revolution.
@willtoth Has anyone at Rev had a chance to look at this? I am really interested in whether this can be confirmed or denied on another set of hardware using a robo-rio (I am using a VMX-pi in place of a robo-rio).
When running the Alternate Encoder example using the Rev Through Bore Encoder, the shaft with the Through Bore Encoder moves half the number of revolutions specified by the setpoint. This appears to be because m_alternateEncoder.GetPosition() returns twice the number of revolutions that the encoder rotates. Strangely enough, changing kCPR from 8192 counts per revolution to 4096 counts per revolution does not seem to have any effect on this.