My team is looking to switch to Talon SRX’s this year and I was looking at using velocity control for our drivetrain to improve driving. I was looking through CTRE’s code examples on velocity control and I think I have a basic grasp at tuning the two sides to a velocity determined by the setpoint of the joystick. However, I’m a little confused about how to deal with turning the robot. Our control scheme is setup to be a split arcade drive on an xbox controller, with one stick moving the robot forward and backwards and the other stick doing the turning. How would I be able to determine velocity of the wheels when both joysticks are used, for example, when moving forward and turning at an angle?
Normally what you’d do is first, calculate the left and right speeds as a percentage (-1 to 1) then scale that to the maximum velocity and set it.
1 Like
Generally speaking, the simple way you do this is to measure your top speed, then just do it like regular arcade drive with an additional final step of multiplying your motor setpoints by your top speed.
For example, in most arcade drive implementations, assuming positive values drive both sides forward, an input of .75 on the left stick and .5 on the right stick would net you 1.25 on the left side motors and 0.25 on the right. After normalization to stay in the [-1,1] range, this becomes 1 and 0.2. You may already be familiar with all that. The next step is to simply multiply those final two numbers by your maximum setpoint (your measured top speed) in whatever units the Talons work in, and feed that as their setpoints.
2 Likes
Just keep in mind that the velocities that that talon works with are measured in distance/100 ms. Also remember that if you are saturating the outputs then the velocity control will not help.
Also, something to keep in mind when using velocity control in teleop; when you move the sticks from full speed to 0 your robot is going to try to get to that 0 as fast as possible. Some teams have added a ramp rate on their throttle velocity to avoid this.
3 Likes
A (slight) ramp rate on the throttle velocity is an absolute must for good closed-loop velo control during teleop. It’ll save your battery and make your robot control much more “smoothly,” but have basically no meaningful cost to responsiveness if you’ve tuned it right.
3 Likes
A (slight) ramp rate on the throttle velocity is an absolute must for good closed-loop velo control during teleop. It’ll save your battery and make your robot control much more “smoothly,” but have basically no meaningful cost to responsiveness if you’ve tuned it right.
How would I go about implementing a ramp rate? I"m still pretty new to all this.
1 Like
Just keep in mind that the velocities that that talon works with are measured in distance/100 ms. Also remember that if you are saturating the outputs then the velocity control will not help.
By saturating outputs what do you mean?
1 Like
Meaning you’re outputting 100% of the input voltage. Think of what happens in the speed control loop when below your target speed; if implemented properly, the Talons should apply some extra voltage. However, now think about what happens when you’re accelerating towards max speed; if that requires all the voltage you have, the Talons won’t be able to do anything other than simply apply max voltage and therefore the robot will not have any improved response or consistency than it would in an open loop (as that would also simply apply max voltage).
Notice I said input voltage and not 12V; you’ll find that your battery drops below 12V when accelerating (and even when cruising at max speed). Because of this, the problem I outlined above extends down to speeds below your max, and is a bigger problem the faster you want to be able to consistently accelerate.
There some measures you can take to combat this, such as limiting your highest setpoint to something below what the robot can actually achieve. Whether or not this is worth it depends on whether your team values consistent velocity and acceleration control over top speed (which, in this year’s game, may be a good idea). I believe @Oblarg is more well-versed in this stuff than I; he can probably comment more on this (and maybe correct a few things).
Notice I said input voltage and not 12V; you’ll find that your battery drops below 12V when accelerating (and even when cruising at max speed). Because of this, the problem I outlined above extends down to speeds below your max, and is a bigger problem the faster you want to be able to consistently accelerate.
There some measures you can take to combat this, such as limiting your highest setpoint to something below what the robot can actually achieve. Whether or not this is worth it depends on whether your team values consistent velocity and acceleration control over top speed (which, in this year’s game, may be a good idea). I believe @Oblarg is more well-versed in this stuff than I; he can probably comment more on this (and maybe correct a few things).
This is an accurate summary. In general, for teleop, it suffices to ensure that your max velocity setpoint requires a steady-state voltage that is some safety margin below that which corresponds to a 100% duty cycle. It’s impossible to give a good numerical estimate for this in a vacuum - but typically, it is enough to simply measure your maximum achievable robot speed, and take something around 80-90% of that as your maximum velocity setpoint.
2 Likes
There a couple reasons that teams like velocity control on their drivetrain in teleop.
First - when you let go of the controller to stop turning, the velocity loop will for the drivetrain speed to zero. This helps eliminate overturn due to momentum, and helps solves issues like fishtailing.
Second - Any mechnical differences between the sides will be negated and the robot will track straight if you are not saturating (sending the maximum input voltage to the output). This helps drive straight, especially when you have an ‘unstable’ drive train like 2 traction and 4 omni wheels. Think about that a little like the fly-by-wire systems in fighter jets. The more unstable a jet is, the more maneuverable it is, but the harder it is to control without a control system doing the heavy lifting.
Saturation occurs in motion profiling as well - it’s why one of your first steps is to determine your max velocity and then choose a value below it. Usually 10 or 15%. You need to do the same with your max acceleration. This all comes back to key tenet: you shouldn’t ask your robot to do something that is physically impossible for it to do.
Before you implement this type of system, make sure you have a graceful fall back plan when one of your encoders becomes damaged. For both teleop and auto.
Note that in the case of simultaneous velocity/acceleration control (i.e. motion profiling), it is not enough to do naive measurements of “maximum velocity” and “maximum acceleration” to ensure that the setpoint is achievable. For details on how to do this properly, see: paper: FRC Drivetrain Characterization
1 Like
Look for setVoltageRampRate in the CTRE docs.
I would advise against doing this, as this implements an output ramp, rather than a setpoint ramp. Output ramps tend to interact badly with the control loop dynamics. Setpoint ramps are much cleaner.
1 Like
Great idea I would love to see some designs to get a better idea.
Our team has a basic 4 inch drive train.