Hi everyone, in odometry the robot vibrates like that:
what should i do? can you give some advice? what is the problem? and here is the robot code:
by the way, while robot doing this, the power goes under 8v.
have a nice day.
Hi everyone, in odometry the robot vibrates like that:
what should i do? can you give some advice? what is the problem? and here is the robot code:
by the way, while robot doing this, the power goes under 8v.
have a nice day.
If my team’s robot does that, it needs a freshly charged battery.
This comment assumes the code is working - that the robot had been functioning correctly then suddenly stopped for no apparent reason.
If this is your first run of a trajectory, then maybe the trajectory isn’t correct. I did look at your only path in the path directory that I assume you are using and it seems okay.
If this is your first run of using odometry then there could be any sort of coding error. For example, you could be misusing clock-wise / counter-clock-wise in different parts of the code. The gyro could be turning one way and your left-right motors turning the opposite way and thus fighting the gyro.
A more complete description of what the circumstances are will always help get better answers from others - minimize the assumptions by providing facts needed to help solve the problem.
Agreed. The only other drivetrain stuttering problem I’ve really encountered with trajectory is the motor safety which is why setVoltage(double leftVolts,double rightVolts)
has m_drive.feed()
in it.
Which auto are you using here?
AutoStraightDrive
doesn’t set requirements. You can fix this by passing m_drive
as a fifth argument to the PIDCommand
constructor. Similarly for ZeroLeftEncoder
, and ZeroRightEncoder
. I don’t think this is causing your problem, because of the way requirements propagate in command groups. Also tankdrive
.
In DriveSubsystem
, I notice that you have a -1
in getRightEncoderDistance()
, whenever you call rightDriveEncoder.getRate()
, and also in tankDriveVolts
. This looks consistent to me, but it’s better practice to drive this down into motor/encoder inversion. A common problem with setting up Ramsete is to have an inconsistent idea of motor/encoder sense. For example, your arcade drive doesn’t use a -1 on the right side. Why is that?
Generally it’s a good idea to chart everything on ShuffleBoard. Chart all the values used by auto in teleop to see that they’re doing what you expect.
Sounds like your bot is oscillating from full fowrd to full reverse. Check currents… and PID tuning
I think it’s less likely to be PID tuning-- and actually just motors not spinning the way you expect them to.
@morphax try using whatever method you’re using to set motor voltage (or percent output), just from a joystick or a constant value, and make sure that a positive output translates into a “positive” movement.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.