Shooting while moving

[SammyPants]

I have seen several people asking about how to shoot while moving and over the past day I’ve been thinking about it too. From what I’ve seen, most solutions appear to be predicting where the robot will be in the amount of time that it will take to shoot. I think the easier solution is to use vectors to calculate the necessary trajectory to shoot at. First, I’m making a few assumptions,

1. no friction.
2. the robot will be moving at a constant velocity.
3. the shooter is capable of achieving any angle and speed and the note comes out of the same place no matter what angle the shooter is at.
4. the robot is a swerve robot or has a turret

For all images I use, assume that the robot (specifically, the shooter) is the origin.

If the robot is not moving at all, shooting into the speaker is simple. rotate to the speaker and shoot at the right speed like this:

however, if the robot is moving, the robot velocity and the shooter’s velocity will add together to cause the note to land in the wrong spot like this:

If we think in vectors, you can fix this is to simply subtract the robot velocity from the simple calculated velocity and use that as the actual shooter velocity, like this:

Actually calculating the theoretical shooter velocity is fairly easy as long as you have the distance that the robot is from the speaker.
constants:
height difference between the shooter and speaker: heightDiff
diameter of the shooter wheels: wheelDiameter

If anyone has better math than this please post it. This is somewhat modified code from our cube shooting robot in 2023 so its def not perfect (+ I’m not sure if its even correct)

[Dave1998]

Not many teams are capable of choosing the projectile velocity.

[SammyPants]

what do you mean? If you’re using a shooter, you’re probably using a motor (unless your robot is casey jones) and that motor is capable of varying its speed. Thus you can choose the velocity of the projectile (the note)

[Dave1998]

The tangent velocity of the shooter wheels is usually not the exit velocity of the projectile. Play with the numbers here and see what I mean:

[SammyPants]

Thing is, with all this, I’m assuming the physical hardware is capable of doing whatever I command it to do. In the real world I suspect that you can compensate for that as well.

[Dave1998]

There’s an easier approach for this, laid out here. It assumes a constant projectile velocity from all poses, which is fair, but according to my napkin math can be adjusted to incorporate a distance to time function.

Shooting while driving / good shooting code

I have some untested code that should do the same thing as the desmos program, although I optimized it by removing all the terms that are multiplied by 0 (ie the robots position since it will always be at the origin) import java.util.Optional; import com.spartronics4915.frc2024.Constants.AutoAimConstants; import edu.wpi.first.math.geometry.Translation2d; public class AutoAimFunctions { private static double pow(double a){return Math.pow(a, 2);} private static boolean check(double a…

[SammyPants]

tbh I just included the math there to go a bit further than theory. If that’s what you’re worried about, yeah same. That math isn’t great. I think the theory part is still going to be easier.