I've been struggling to understand the TrajectoryCommand

I have spent around a couple of weeks trying to write a FRC command for following a Trajectory in Java. The one issue I have is that the Trajectory Config always gets ignored. No matter how low I set the max voltage, or the max speed, it always goes up to 30, 40, or 50 volts.

Below are links to my DriveTrain subsystem and my Auto Command. If anyone is able to help, that would be great. My guess is that it is something wrong with the constructor for the Ramsete Command, but I am not 100% sure.

1 Like

What steps have you taken (lets us know the results) on the trajectory troubleshooting guide?

My guess for the fix would actually be centered around the units you are using to set things up.

1 Like

My issue isn’t similar to any of the ones on the troubleshooting guide. While there may be some issues relating to units, the main one is that my max speed, max velocity, and max voltage simply don’t do anything.

1 Like

That is not what I think is happening. If the units to your robot are wrong then even if you set the max speed and that speed is being obeyed by the ramsete controller if the calculations done by the robot to achieve the correct speed may make it ask for a significantly higher speed.

Under getWheelSpeeds why are you dividing that by 42? I believe getVelocity outputs in RPM. DifferentialDriveWheelSpeeds needs the inputs in meters/second. I don’t know the properties of your robot but dividing by 42 seems like you think that this is encoder counts and doesn’t seem to factor in wheel size.

4 Likes

Sorry it has taken a bit to reply. The results from getWheelSpeeds have been measured to make sure they are in meters per second. Basically what happened was that we measured the wheel circumference to make the distance per pulse, but then only accounted for the amount of pulses per rotation in the function itself. Probably should have that as part of distance per pulse though. But I do know that units are not the issue, as we have tested for it.

1 Like

To be fair everyone says this, but a very large amount of the time it is units. So please do not dismiss my advice.

I think you are saying you believe your units to be correct as coded and I am not sure how that can be possible. You say the results have been “measured” by who? How? I have an extremely hard time believing the wheel circumference is exactly 42.0. Can you please list in detail how you came to this conclusion? What size are your wheels?

1 Like

I should have been more specific, we measured by having the robot drive a long distance, timing it, and checking it’s velocity in mps to make sure it is correct. Our distance per pulse was based on the wheel circumference, then we divided it by 42 for the encoder ticks per revolution. We will probably include the encoder ticks in dps to keep it cleaner though.

The math for Distance per pulse took the diameter of the wheels: 0.15 meters, and got the circumference by multiplying by pi. Then we divided by 10.24 for our gear ratio to get 0.4675. We realized later we forgot to divide by 42 for the number of ticks per revolution, so we tacked that on in the function.

1 Like

I see in your code in tankdrivevolts you are multiplying by 3/20, why?

What are the voltage values you see graphed there on a simple drive 2m forward? A graph of the wheel speeds for that run would be helpful too. Where does your odometry say your robot is during this process?

What happens when p values are reduced to 0? I know I am mostly repeating the steps in the troubleshooting guide, but we really need those to know where to dig deeper.

1 Like

What specific encoder are you using? If you are using the packaged encoder inside the NEO you do not need to divide by its CPR. The API already handles that for you.

2 Likes