We have our turn to an angle working just fine, it’s just that a large spike of wheel turn happens, a pause, quick wheel turn, etc… We do have a kP and I assume it’s a pid issue. Are there any resources you could point me to or a solution? Thanks!
Sometimes a large kD value causes this (and I assume you aren’t using the I term). Or, depending on your situation, you might be experiencing a brownout which is when the battery voltage drops too low so the robot shuts off the motors for a brief moment. A brownout is easily visible on the driver station since the voltage value flashes while it’s happening. Another possibility is that you could have two parts of your code running, one using a PID loop to set the value and other in the background trying to set the motor value to 0 or a joystick value. It’s hard to tell what’s going on without video and code.
Probably just down to tuning. Honestly there is no right answer to this. kP will overshoot if it’s too high. Try lowering it to get it closer to hitting the target without overshooting. Do some research on PID tuning for adding in kI and kD. kI will make the steady state error (the difference between the position where the robot stops after running PID and the goal position) lower, and kD will reduce oscillating (generally).
Here is a good guide: https://frc-pdr.readthedocs.io/en/latest/control/pid_control.html
Had the exact same issue last year, turns out the gyro output was rapidly switching between 0 and the actual angle because we were pulling values from it too fast.
Hope this helps.
We only have kP. The default for drive sub-system is the input xbox controller value. We are running the turning straight from another system but calling the arcade drive from the drive sub-system
Could you elaborate? Would this be as simple as printing the gyro value?
I assume your rotate to angle code turns your drive wheels in opposite direction. Can you rotate your robot with a joystick at low and high speeds? This should support there isn’t anything mechanically wrong.
You need to post your code.
If you are calling turning straight from another system (I hope you mean Command). If you are turning from another command that is not the default, have you properly told the scheduler that you require the drivetrain.
You may be stuttering because your PID controller is trying to drive, and your default command is trying to drive to 0, which would be a rapid start stop.
It’s not a command. If we copy paste our subsystem into a command the scheduler should know not to run the default command and the turn command at the same time?
Our team had this problem in 2018, and the cause was that we had too much scrub on our wheels.
I believe out problem is that the only command scheduled is our driving sticks. This would cause it to keep interjecting our running code for turning. we could slap this turn code as the default to see if that’s really the case (hopefully because that’s pretty easy to solve). If not, which I doubt, we’ll set our constants higher
The Default Command of a subsystem is the command that is run when nothing else requiring the subsystem is required to run.
So, yes, that should work.
As a general design principle it is my opinion that the Subsystem should own all the sensors and actuators of the subsystem, but it in and of itself, should not be actuating anything. If you want the subsystem to do something, you should have a command that does that thing.
In the case of driving the robot, you should have a default command that likely does nothing more than drive the robot with joysticks. Then, any other more complicated driving such as driving a set distance or turning to a set angle with PIDs should all be in their own commands that also require the subsystem.
If you do things that way, you eliminate this type of contention.
Also, if you use Shuffleboard, you don’t have to guess.
After you instantiate your subsystem you can just add to SmartDashboard SmartDashboard.putData(my_subsystem);
and you’ll see what is scheduled and running for the given subsystem.
If you are using a four wheel drive or have not done something like a dropped center wheel, this could be normal action when turning. High friction on the drive train during turns can cause the drive motors to go into a near stall condition, which may trip the breakers or cause brownout in the RoboRio. Be sure that the robot does not exhibit the same issue with the wheels off the floor to be sure friction is not the problem.
seems to be it, thanks.
Btw, on a side not(although you might already have this, I haven’t seen any mentions to it and I have seen several teams doing this before), make sure that you are using kF. PID controller should be there to fix minor differences in your target and actual, not 0 to target.
we’re not using the controller, just the simplified equation. will transfer it later to the controller; we’re all new to programming so we’re going at baby steps.
technically… your equation should also have the “minimum power”… or kF
would that be constant force?
We are using the chameleon Vision example. it has kp times error and then subtracts .05 from that adjusted value