We are having some issues with a couple of our motors running. One is a 775 powered by a TalonSRX and the other is a Neo 550 powered by a SparkMax. I will address each problem individually.
The SparkMax’s issue is that it will only move the motor in one direction. We are using it on a simple elevator which does three tasks, lift up, stop and bring itself down. The motor, no matter what I do, will not reverse. Firmware is fully updated on it too. The controller will not even flash that it is wanting to move down when called upon by a button press on a controller. This code can be found here: https://github.com/FullMetalFalcons/2020-Robot-Code/blob/master/fmf2020v2/src/main/java/frc/robot/subsystems/Climber.java
The second issue is the other TalonSRX. We are using it for a secondary intake wheel so nothing too special at the moment. This one will not move no matter what and is not flashing the propper colors to show that it is being told to spin either direction. In the code, all I do is tell the motor to spin one direction and that’s basically it, so nothing too complicated. The code can be found here (it is named “wheel thing” because when I programmed it, I was told very little about what it was for lol): https://github.com/FullMetalFalcons/2020-Robot-Code/blob/master/fmf2020v2/src/main/java/frc/robot/subsystems/Indexer.java
I have run through just about everything I know from reupdating the firmware on each to make sure that they both show up.
For the SparkMax, what is the LED doing? Can you record a short video of it driving one way, stopping, then driving the other way? I suspect the limit switch pin may be shorted, which would prevent it from driving in that direction.
If the controller does turn green and red, then it’s likely a wiring issue between the controller and the motor or an issue with the motor itself. You could try a multimeter on the controller’s output. It could also be an issue with the controller but it’s less likely.
Yup, just found out from our electrical that a cable was not fully connected and the controller now lights up appropriately when called upon. The motor is still not spinning but we have now deduced that it is not a programming issue. Thank you for the help!
On a cursory check, the subsystems look set up correctly, but you basically aren’t taking advantage of Commands - all your button bindings are tied directly to subsystem methods in Robot.Java and I think much of your Weird Behavior is tied to that.
Normally, the command scheduler uses requires() values to make sure that a command that uses a subsystem isn’t conflicting with another command.
However, when you have a bunch of parallel IFs that reference the same motor - the last IF is the one that will take priorty.
Consider a mechanism with states “this”, “that”, and “other” controlled by a subroutine that does this:
void robot{
if (buttonA) this else that
if (buttonB) other else that
}
you will never achieve state “this”, because before the “this” state can act for a reasonable / human-visible amount of time, the state of the system will be over-written to either “other” or “that”
Do you have a mentor or local team you can work with to go back to command-based programming?
You can achieve what you’re trying to do with nested IF statements instead, if you just need it to work for week 1, but the ceiling of performance will be significantly higher if you can start using the Command Scheduler to help prevent this type of conflict.
Uploading the video to YouTube right now. The video would not upload to CD for some reason. The lights do blink the proper colors when going up but when coming down, the light shows that there is not moving. https://youtu.be/ROPZ2ikT6_w
