Does the phoenix swerve project generator configure the x, y and theta controllers as well?
I think you’ll need to be more specific.
Are you asking if the generated project configures a joystick/xbox controller to control x, y, and theta? It does.
Are you asking if it configured PID controllers for use with PathPlanner? It does not (but their example project does)
Or something else?
For path planner and holonomic drive controller. Sorry I should have clarified. I suppose I have another question now. For trajectory tracking it looks like the x and y co trollers are position controllers which react based on positional error. Link to what I’m talking about: https://github.com/wpilibsuite/allwpilib/blob/main/wpilibjExamples/src/main/java/edu/wpi/first/wpilibj/examples/swervecontrollercommand/RobotContainer.java
Whereas the holonomic controller requires an x and y velocity based controller.
Although both are trying to achieve the same thing. Shouldn’t both of these use the same type of controller?
Sorry, I don’t understand your question. Are you talking about the parameters to SwerveControllerCommand? The X, Y, and theta PID controllers passed to the constructor are position controllers. The only difference between the three is that theta is a ProfiledPIDController, using motion profiling.
If you’re talking about how the end result is an array of SwerveModuleStates, which have wheel velocity and azimuth position, this is because we need to convert the ChassisSpeeds (x, y, and theta velocity) that come out of the controllers into states for the swerve modules. See Swerve Drive Kinematics
Sorry about that. I was asking if the x and y pid controllers in the swervecontrollercommand were positional controllers which you’ve answered. What is the best way to go about tuning these controllers? For the x and y controllers I am assuming you can lock the wheels in the x or y direction and run sysid or tune the constants manually. What about the theta controller?
The SwerveControllerCommand is about following a trajectory, so the X, Y, and theta are in relation to the field, and the desired pose at a given time in the trajectory. You cannot tune them on blocks. You need to run a trajectory and track the error from where the robot is supposed to be on the field, and where the robot thinks it is on the field.
PathPlanner makes this really easier with the way it shows a visualization in realtime. I recommend checking it out instead of WPILib trajectories.
Could you please link resources on how path planner can do this? Thanks
Sure. Check out the Telemetry page in the 2024 version of PathPlanner.
The 2023 version could connect to your robot and show a visualization of where your robot should be and where it thought it was, but it’s improved even more for 2024.
Thank you. Is there a way to use this with a simulated drivetrain instead. The settings tab on the wiki says you can use it with a simulated drivetrain. But I’m unsure how that works exactly.
Yes, you just have to tell PathPlanner the PPLib Telemetry Host is localhost. But, it’s not useful for tuning PID, you need to do that with your real robot.
Yes I do know that you’d have to tune pid on the actual robot. I was asking about the simulation because we don’t have the motors for swerve yet. It’s so that I know how to use it when I have access to the actual robot.
Also coming back to the x, y and theta controllers I think I don’t have a good understanding of what they do exactly. I think I understand that with the theta controller you are correcting for heading error by generating velocity set points. But I don’t understand what the x and y controllers do. Obviously they’re correcting for error the robot has in the x and y direction. But what does their output signify exactly? From my understanding assuming that there is some error in the x direction and some error in y direction and the robot is already at the correct heading, the best way to get to the setpoint is to take a straight diagonal path. And you can use a pid controller to achieve this. So my question I guess is how do the x and y controllers factor into doing this exactly.
I must clarify I am not a physics expert as all the control theory and physics I know I have taught myself so there may be gaps in my understanding. So the questions I could be asking may seem a bit silly.
They are all position control, not velocity control. Someone might have to correct me on how it actually works versus my understanding of how it logically works, but here goes:
- PathPlanner samples the trajectory for the next time slice. Based on the planned path, the desired pose of the robot is calculated (X, Y, and theta) .
- Each PID controller has its setpoint set to the desired value from the pose, and the robot’s estimated pose from odometry is used to calculate the output.
- The output from the controllers will calculate field relative chassis speeds.
- Using the robot’s estimated theta (from odometry,) the field relative chassis speeds are transformed to robot relative chassis speeds.
- Finally, reverse kinematics is performed to calculate the swerve module states (speed and rotation of each module.)
Don’t all trapezoidal motion profiles work by creating velocity set points that such that your mechanism can smoothly track to the position setpoint? That is what I meant by velocity set points I should have been more clear. Also I think I understand the programming sequence it’s mostly just the control theory I don’t understand. I don’t know how the output from the x and y controllers can be used to calculate chassis speeds. From the holonomic drive controller documentation which if I’m not mistaken is what the swerve drive command is using behind the scenes, it says the x and y controllers are outputting velocities in the x and y direction based on positional error. Is how I interpret it right?
Yes, trapezoidal motion profiled controllers output velocity for the next time slice. We’re mixing two different solutions in our discussion; PathPlanner and WPILib trajectories. They’re similar, but not the same:
- PathPlanner doesn’t use any
ProfiledPIDController, but it is still creating a motion profile within the trajectory (you set the constraints in the PathPlanner UI). - Similarly, WPILib trajectories are profiled for X and Y, but the theta for a swerve robot is only a start and end point. Due to this limitation with WPILib trajectories,
SwerveControllerCommanduses aProfiledPIDControllerfor theta to get smooth, planned motion for theta.
PID controllers output a control signal in whatever measure your system accepts. If you are driving a system with duty cycle, your output is duty cycle percentage. If you’re driving a system with voltage, your output is voltage. These measures and their units set the units for your PID coefficients. A robot on the field is driven by chassis speeds, so the control signal is velocity.
Ah that makes a lot of sense thank you. I will have to look into path planner and it’s trajectory following methods further. One last question I should be able to use the same pid controllers I configured for either path planner or wpilib trajectories to also follow on the fly generated trajectories right? For example if I want to move the robot right x meters and or x degrees to align with a target.
No, you can’t use the same PID controllers for both. PathPlanner 2024 creates the PID controllers internally, you pass it PIDConstanst objects. You might be able to use the same PID coefficient values. In theory, they’re based only on the dynamics of your robot. However, in my experience you may want to adjust them slightly to get the best performance.