here’s what we have right now. This code gives us no errors when we build it, and whenever we put print statements anywhere, it prints when it is supposed to. Does anyone know why the arm motor is not spinning when I press button 5?
Define not working. Your “RollerEject.java” probably isn’t doing anything because the motor calls in the “rollerEject()” method are commented out…
Could you explain what you mean by “working” and why it isn’t doing that?
Right now, all we are using is the arm motor (named armMotor in IntakeSubsystem). It is supposed to spin when you press LB on the controller (line 80 in RobotContainer.java). When I press LB on the controller, it prints that the command has started, but it never spins the motor. When I put print statements in the execute method, they repeatedly print as they should. The problem is, the arm motor is not turning.
Thanks for the help!
I dont recommend using magic numbers like 5
and 3
to refer to buttons. You can either use enumerated values (like the kA
a couple lines above), or switch to the CommandXboxController class (new this year) and use the leftBumper()
methods to get a Trigger object for binding your commands (docs found here)
Where in the subsystem is the motor actually being set to your demand?
Line 50 is what should be doing it.
@Hunter_McDougall, where did you get your PID constants from? I would leave I
at 0 and configure feedforward properly (currently itll always be 0 since your ArmFeedForward constants are all 0). Your P of 0.025 might be too small to actually move the motor (I havent done all the math, but a position error of 10 (setpoint = initialPos+10) looks like it would result in a voltage of 0.25), which would explain why youre not seeing anything. What do the motors say theyre doing (check LEDs and/or REV Hardware Client)?
The arm motor is set up on line 19 of IntakeSubsystem.java. I call setgoal on the intakesubsystem in lines 21 and 24. I enable the PID control of the subsystem in lines 22 and 25.
I see that you are updating the goal of the PID controller, but I don’t see you actually using the output of the PID controller. Where are you calling the useOutput() method?
It’s a ProfiledPIDSubsystem. That part is abstracted away in the parent class
Oh, I didn’t catch that, my bad. I’m used to using the ProfiledPIDController object, so I just skimmed the name and assumed it was that. You’re probably on the money about the PID gains then.
The PID constants come from when we tried tuning the PID constants using a robotpy example (before we decided to switch to java). We tried switching the P value to 0.25 and then 1, but both times the same thing happened. When teleop is disabled, the light on the spark max blinks magenta. When teleop is enabled, the light is solid magenta.
Thanks again for the help!
Line 80 of RobotContainer binds to the IntakeToggleCmd. In the IntakeToggleCmd.execute, both branches of the if statement to the same thing. My guess is that one of those is suppose to be a minus sign rather than a plus. The result is that you are always setting the same goal. At least, after the first time.
I am not completely clear on what is happening across the command and subsystem, but you may also want to consider if
initialPos = intakeSubsystem.getMeasurement();
belongs in the constructor (called once when the command is created) or in the command’s initialize method (called each time the command is scheduled.
Even if we are setting the same goal every time after the first time, shouldn’t the arm at least move the first time? Right now, the arm isn’t moving at all.
I believe we are creating a new instance of the command each time it is scheduled, so it shouldn’t matter if we are getting the measurement each time it is scheduled or when it is created.
Thank you for the help!
After some testing, we have realized that it will fight against you if you try to push it one way, but won’t if you push it the other way. Additionally, turning the setpoint to 10000 makes the arm correct for you pushing it a lot more violently than if the setpoint is 2.
You are only creating the command once when RobotContainer.configureButtonBindings runs at the start of the match.
I also noticed that several days ago you lowered your intake kp value by a few orders of magnitude. This could have something to do with it not moving.