My team is doing swerve this year, and we have a turret for our ball shooter. We are looking to be able to shoot while traveling left or right. While the turret is constantly updating its rotation with a limelight to be exactly centered on the target, it still lags behind while moving side to side and causes it to miss. Is there a way to compensate for this movement? I was thinking of trying to have it calculate the rate of change in angle and using that to calculate the compensation but I’m not 100% sure how to do that programmatically.
This sounds like PID tuning. Are you using PID or a custom correction method? Can you share it?
Basically what I’m hearing is that the turret aiming algorithm is assuming the robot is at rest and not taking into account the initial momentum of the ball given to it by the drive train.
I think you’d have to know the robot’s direction and velocity, then solve some kinematic equations for where the ball will end up and offset your target point by the error.
If you ignore the component towards/away from the goal and only account for lateral movement then you should be able to get the distance error by multiplying the tangential velocity of the robot by the time of flight for your shot (a factor of shooter velocity and angle, or just distance will probably be close enough).
This is assuming that the position and speed of the robot aren’t changed between when the turret is aimed and when the ball is fired, which I think is valid.
1 Like
Seems like the OP already has some control methodology defined and implemented…
But I agree with @Timebomb. If you use the WPI kinematics libraries for odometry, you should be able to get the robot’s velocity in two dimensional space to do the kinematics math.
Although I have no idea how to implement it, I recall 254 doing similar math with their turret last year (accounting for base’s velocity as an “arbitrary feedforward” as they travel around the goal if I understand correctly).
Pre post edit: 254 is typing, they can give a better explanation than I can.
1 Like
This isn’t a PID tuning issue but a controller design one. The D term in PID assumes that you’re trying to get to zero derivative (zero velocity). In this case, a non-zero derivative is desired.
To handle this case, one would need to determine desired turret angular velocity setpoint (based on the geometry of how the robot is moving relative to the target). Then the PID controller would need to be redesigned to adjust for that angular velocity setpoint.
1 Like
The problem is that your PID controller is trying to achieve the current turret position setpoint at zero velocity. When your robot is translating around the field, though, precisely tracking the position setpoint requires non-zero velocity because of the ongoing “disturbance” of the robot’s movement.
If you can predict what turret velocity would be necessary to keep an already on-target turret tracking accurately as the robot drives, you can feed this forward to the turret motor to counteract the disturbance. You can do this by taking the current measured (or predicted) robot velocity and doing some trigonometry. This is what 254 has done for the past two years, and it works really well with some tuning.
Now, intentionally leading or lagging the target to account for the effect of robot velocity on ball velocity is a bit of a different animal, and also doable, but I’d focus on getting the feedforward working well first.
11 Likes
While I agree with much of what has been said by others, I think the real issue is that you are not leading the target with your shot.
If you are travelling at 5 ft/sec laterally to the goal then the ball is given that same 5 ft/sec lateral velocity when it leaves the robot. Suppose that you are at a distance from the goal where the time of flight of the ball to the goal is 1 second, then the ball will travel 5 feet to the side during its 1 second flight. You need to compensate for that lateral velocity and actually aim 5 feet to the side of the goal (behind the goal relative to your direction of motion).
It is the same idea as trying to hit a moving target. A good example is a quarterback throwing to a wide receiver that is running a crossing route. The quarterback will aim the ball ahead of the receiver so that the ball and the receiver get to the same spot on the field at the same time.
In this case, it is the robot and not the goal that is moving, but since the math depends on the relative motion of the two end points, it doesn’t matter which one is moving.
2 Likes
How do you account for the error induced by the transmission time from the camera to the robot. Time stamps?
Yes, we use timestamps plus an estimate of image capture latency.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.