Thanks for your advice! We have simliar solution to yours, but since our oscilliation is a little big, which is around 20 rpm, so l need to set the tolerance to be big enough to let the indexer to run. l think this isn’t accurate.
Thanks, but l think the falcon needs a time to get to the desired speed, so if your operator wrongly press the indexer button, the ball won’t be shooted to the hub accurately. So, l think a more accurate condition should be added. If you have other wise solutions which are not mentioned, please introduce them, thanks!
We are in the similar situations to yours! Can you share a link to the related code of 6328?
It was only about a second and a half from zero, so for auto we just waited 2 seconds before shooting our auto balls. During teleop, the shooter was always running so getting up to speed only mattered when we were shooting 2 balls at a time, so we just slowed the feeder speed down until shots were consistent. It was still pretty quick. An ‘up to speed’ condition would work too, but this is one way to set it up without one and still shoot consistently.
l find that they do control the blocker’s speed in every point on the field, that’s really smarting! That equals to control the time the shooter needs to get to the desired speed l think. So, is this thought still available with an interpolation table? Has anyone tested it? Besides, can a too low speed still be able to pass the ball to the shooter?
// Called every time the scheduler runs while the command is scheduled.
@Override
public void execute() {
m_shooter.setTargetVelocity(m_targetRPM);
if (m_shooter.getRPM() - ShooterConstants.kShooterRPMTolerance <= m_targetRPM
&& m_shooter.getRPM() + ShooterConstants.kShooterRPMTolerance >= m_targetRPM) {
m_shooter.shooterState = ShooterState.VELOCITY_CONTROL_SPUN_UP;
}
if (m_targetRPM != 0 && m_shooter.shooterState != ShooterState.VELOCITY_CONTROL_SPUN_UP) {
m_shooter.shooterState = ShooterState.VELOCITY_CONTROL_SPINNING_UP;
}
}
// Called once the command ends or is interrupted.
@Override
public void end(boolean interrupted) {
if (m_shouldStop) {
m_shooter.setShooterVolts(0);
m_shooter.shooterState = ShooterState.SLOWING_DOWN;
}
}
What we’ve used last year is checking the RPM to decide what state you should set the shooter subsystem as. We also had similar thing for our hood mechanism and turret, then if all mechanisms were in the required state the robot would shoot.
I believe the code @AllenGregoryIV is referenceing relates specifically to calculating the robot’s pose based on vision data (including distance to the target). We used a circle fitting algorithm that feeds into our odometry system. I’ve included some links below where I talk about how it works in our build thread.
This is useful specifically if you care about full field localization, since the pose will be accurate even if the target is at an angle. If you just need the distance to the target when you’re already aimed at it, using the angle or size of the target is much simpler.
Correct we used the circle finder to find a much more accurate distance from goal calculation. We then made a linear relationship between launcher speed and distance to get accurate shots.
Thanks for sharing! l have had a look to your code, but l still can’t find where the circle finder is? Can you give a more specific link? Thanks? Besides, l want to make sure that once your robot is stop at a point on the field, will the distance you get from limelight oscilliating? Besides, l see that your swerve’s max angular speed is 3 * Math.PI, will this make the driver harder to control the swerve since l think this angular speed is too big?
We have a timer that starts when the PID controller reaches the setpoint and when it can sustain the desired speed ±15% for 0.5 seconds, our conveyor system then brings the cargo to the shooter wheels.
We also have another timer that starts when the microswitch which is right in between said conveyor system and shooter wheels reports as “not pressed”. It tells the motors to maintain their velocities for 1 second after the fact.
We use robotpy and we haven’t touched it in a while so it’s quite messy but i believe you could do the same in java/c++.
The feedforward controller actually calculates the voltage, The PID is just there because feedforward does not have .atSetpoint() method. And as per the ±15% tolerance (which is really just 5 rpm because we don’t spin it faster than 30-50 rpm most of the time ) the feedforward works just great so we haven’t bothered to lower it.
Nope, the front which the encoder is connected to is 2 redlines with a 3.25:1 speed gearbox that uses 3 inch plastic wheels; and the back one is a single 775pro with I believe 2 inch compliant wheels. It doesn’t have much mass and we aren’t exactly rich so we didn’t use an encoder for those.
We have created a method that sets the rpm based on the distance calculated using our limelight. The ‘rpm’ variable is the desired rpm that is returned by that method. We have an if statement similar to yours that checks if the desired rpm is reached. If not, the Xbox controller doesn’t rumble. Here is the code:
) the feedforward works just great so we haven’t bothered to lower it.
l guess your repo is private.