Swerve Drive Targeting

I the programmer from 3374. We are currently working on our first swerve Drive robot as an off-season project. We are using limelight and odometry for targeting. Our programming mentor suggested using a PID loop for our drivetrain (like we would do for a turret) which allowed us to target but the closed loop made us unable to actually drive the robot. We are wondering how other teams achieve targeting with a swerve Drive.

You’ll get a more specific response if you share your source code, but when you create your ChassicSpeeds object to pass to your Swerve Drive Kinematics, you could pull the vx and vy from the joystick (probably via DoubleSuppliers), and pull the omega from your targeting. Does that help?

We used a turret this year on our swerve drive so that the shooter could be aimed at the goal full time while and the driver could drive the robot any way he wanted to collect the balls.

But, in 2019, we used a vision system to provide a “driver assist” mode for final hatch / cargo placement. It was not active the entire time. The vision system would provide an indication when it had acquired a target (we used the rumble feature on the controller for this) and the driver would have to push a button to select this mode. Once the mode was selected, the vision system would steer the robot toward the target, but the driver was still in charge of the speed. So, essentially, the X-Y speed commands on the one joystick was turned into X only (moving the stick laterally would be ignored) and the rotation on the other joystick was disabled (any side to side input on this joystick would be ignored. After the driver moved in and the hatch was placed, the driver would move back out (with the driver assist still active to make sure that the robot backed straight out and did not knock the hatch off. The driver would push a button to turn the driver assist off and resume normal control.

In your case for the 2022 game, assuming that you can shoot from any distance, the targeting system only needs to aim the robot toward the hub. This can be done by only having the vision system provide the rotation command to the swerve code. This would allow you to still retain translational control of the robot, and would just disable the rotation inputs from your controller but leave the translation controls intact. You would only need to close loop on the rotation commands. The vision system would provide a rotation input that would look to the serve code just like a rotation input from the controller (in terms of how that rotation input was used in the swerve math to drive the wheels), but it would be coming from your vision system instead of the controller. You would want to be able to switch this on and off so that you could drive normally when you were collecting balls and then just have the vision system aim the robot when you were preparing to shoot.

If you can only shoot from one distance and you need to get to this distance, then the math gets a little harder, but in robot oriented operation, it would mean letting the vision system take control of X and rotation leaving only Y to be input by the driver (similar to our 2019 robot where only X was input by the driver). Again, this would be a mode that you would need to be able to turn on and off so that you would be able to drive normally the rest of the time.

1 Like

When our operator presses the “SHOOT” button on the controller, the x-y translation is disabled and the camera rotates the robot.

We have a manual override button, too, so the camera rotation is disabled and the operator has full robot control and it shoots…


A well written swerve drive function wouldn’t be inherently coupled to a joystick, it will take inputs of x, y, and rot values. Most of the time you will tell it that x, y, and rot are numbers based on the joystick, but when targeting you can substitute other values (a constant, camera distance, etc.) to be one or all of those values.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.