I am trying to get our pathweaver and RamseteCommand running better. The issue we are having is it is calling for too much voltage in our turns for the robot to keep up. I know when we followed the WPIlib documentation for creating trajectories there was a voltage constraint, but when we transitioned to pathweaver there does not seem to be the same voltage constraint.
We are currently having to slow one of our autos way down. Slowing the acceloration down seems to really help, but it is slowing it down to the point of not having enought time.
Our current speeds are 2.0m/s max speed and 1.2m/s2 acceleration. We can make one path work well with 2.0 and 2.0, but it has less turning.
The numbers the SYIDs tool output are as follows.
public static final double ks_volts = 0.69097;
public static final double kv_volts_seconds_per_meter = 2.4064;
public static final double ka_volts_seconds_squared_per_meter = 0.436445;
public static final double kp_drive_velocity = 3.45555;
public static final double k_track_width_meters = 0.6731; //26.5 inches
public static final DifferentialDriveKinematics k_drive_kinematics = new
DifferentialDriveKinematics(k_track_width_meters);
public static final double k_max_speed_meters_per_second = 2;
public static final double k_max_acceleration_meters_per_second_squared = 2;
public static final double k_ramesete_b = 2; // originally 2
public static final double k_ramesete_zeta = 0.7; //originally 0.7
public static final int dt_gearbox_ratio = 7;
public static final double dt_wheel_dia_meters = .09906;
public static final double dt_wheel_circumference_meters = dt_wheel_dia_meters * Math.PI;
Just trying to figure out if something seems way off or not and what to maybe try from here.
The solution my team is using is just putting in the values of the waypoints manually. It isn’t the most elegant solution, but it does allow us to use the trajectory constraints.
Based on it being a nice round number, I’m assuming you’re using the theoretical track width rather than the empirically measured one. I would try measuring it using the process in the link and seeing what you get.
I would also validate that your robot is able to follow a long straight path of a set distance with your desired acceleration and max speed. This will help you figure out if the issue is truly in your turn dynamics or if your some of your characterization variables are off.
I’d also be curious to see what your paths look like. I’m mostly wondering how aggressive your turns are. We’ve had back luck doing aggressive turns.
Thanks… Yes it is a measured with tape measure turning wheel distance. I had forgoten about the calculated one you gave. I am also planning to revisit our characterization values tonight and make sure we didnt miss something there. Thanks very much… I really dont think we are making any crazy aggressive turns in our paths… if anything they are not aggressive enough… I will check the things you suggested and let you know tonight.
Falcon 500’s with 7:1 gearboxes and 4" traction wheels… we do have a 2 motors for each side and I do not remember putting anything in about a follower either…
If you didn’t put all your motors into the tool then kS and kA will be greatly inflated (as will kP). You also should adjust the filtering settings on your velocity measurements down to the minimum possible (1ms) through the CTRE API.
@Oblarg We did put both motors into the controller on the first step. What I meant was I dont remember telling it one of them which one was follower vs master, but we did put all 4 motors and their ports in
Is adjusting the filtering on them making it report ticks per 1 ms instead of ticks per 100ms like default? Am I understanding that correctly?
And is the filtering settings something we should leave that way permanently or just for Running SYID tool? If so should we hard code that into our Java to make sure it is that way?
The filtering won’t change the reported units; only the period of time over which the velocity is actually measured.
The SysId algorithm is robust to sensor delay by virtue of the specific driving signal chosen (we could also modify it to remove the delay post-hoc in the future), so it’s less of an issue there. Feedback control itself, though, is extremely sensitive to sensor delay. You can see this for yourself if you play with the measurement delay parameter in the feedback analysis pane.
These are the off the cuff wisdom drops I obsessively read CD for…
What would you recommend for a Rolling Average Window Size for a drivetrain? My intuition says you want it to be slightly longer than the poling interval of 20ms to keep the noise down.
Follow up question. What would you recommend for setting for a flywheel. My guess would be 1ms interval and a window size of 4 or 8.
Use the smallest window size you can get away with without introducing unacceptable amounts of discretization noise. The easiest way to detect discretization noise is to visually inspect the velocity signal.
For a high-resolution encoder like the one on the Falcon, I doubt it’s an issue even at the low low end of the filter periods.
Not quite. The update rate for the velocity measurement onboard the motor controller is 1khz, so that value updates every 1ms regardless of the other settings. However, that value is itself a rolling average of differenced position measurements; the CTRE API allows you to control both how long ago the position is sampled for the calculation, and the number of taps in the rolling average. You should set the former to 1ms, and the latter to 1.
Per my post above, SysId is robust to measurement delay so it shouldn’t matter much. You can run the test with matching filtering settings as a way to inspect sensor discretization error, though.
Max controller output is determined by the API of your motor controller. If you pick the appropriate preset it should be set correctly for you, and you should not have to change it.