Hello all, I was just wondering if anyone was aware of the math to convert the WheelSeeds values spit out by WPILib’s DifferentialDrive class back into arcade drive style X and Z percent values? We need this because we are trying to add heading correction to our diff drive class. Anyways, thanks in advance for your help!
Hmm, I believe I’ve done a similar system to what you’re looking for, a “heading hold” system, using gyro yaw angle as input to PID.
You can take a look here GitHub - lasarobotics/PH2023: 2023 Purple Haze FRC
However, more clearly explaining what exactly you’re looking for would help.
1 Like
I’m trying to support it across tank, arcade, and curvature inputs, the inverse kinematics for which all output a duty cycle for the left and right drive. The system we use for heading correction (per driver feedback) uses trigger thresholds for linear and rotational commanded velocity before it takes effect. So I’m trying to convert those tank drive outputs, into arcade drive style values in order to check the trigger thresholds for heading correction. plus it just makes adding the PID values to the output easier.
1 Like
Do you have any code written already and posted on GitHub for us to look at? That would also be helpful. A thought I had was you could threshold the driver’s input before putting it through your algorithm so you know if you need to do correction or not.
Also, is there a reason why you want to use all three types of inputs (tank, arcade, curvature)?
IMO its best to just standardise your team to one, and go from there. Also, with a system like this, you don’t want to do curvature, you don’t want to have correction on top of whatever system you’re doing.
Its simple enough to do with arcade and tank though. With arcade, you can directly get the driver’s turn input, and with tank, you can infer the “turn input” is the difference in value between the two sticks. Then you can use that turn input variable in PID and do some thresholding and heading correction.
The main reason we are supporting all three is because we are refactoring the Differential drive classes for a library we maintain. The same conversion solution should work for all three since WPILib’s Differential Drive inverse kinematics methods all spit out WheelSpeeds objects (a percentage {1.0 to -1.0} for your left and right drive). I basically just need a way of reversing WPILibs Arcade Drive inverse kinematics equations. The WIP code is located here: Plop_2023/src/main/java/frc/robot/BreakerLib/subsystem/cores/drivetrain/differential/BreakerDiffDriveBase.java at main · BreakerBots/Plop_2023 (github.com)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.