Neos fight eachother sometimes?

Petrie_4610 · February 19, 2020, 4:41am

So on our shooter we have 2 neos. Sometimes they fight eachother, then without changing code, just cycling power on the robot, it is fixed and works as expected. We have 2 robots with the same setup. Issue only happens on one of them. Both have the same code. Anyone else have this issue? Any soulutions?

plusparth · February 19, 2020, 4:49am

We have seen a similar issue where our feeder would sometimes reverse itself, seemingly at random.

It turns out that if the SPARK MAX loses power, such as when its associated PDP breaker trips, it resets its configuration to whatever it has stored in flash memory. This includes its inversion settings.

To fix, call burnFlash() on each SPARK MAX in your constructor/wherever you initialize your motors once you set all of your configuration stuff. This will save that configuration to flash memory and will ensure that it remembers all of its configuration, including inversion, correctly.

gdefender · February 19, 2020, 4:57am

An alternative is to call resetFactoryDefaults() and put all of your configuration in you code.

I prefer this method because it’s portable if you swap out a SPARK MAX during competition. You wouldn’t have to worry about reproducing the configuration with the SPARK MAX Client or by calling burnFlash()

plusparth · February 19, 2020, 5:02am

I would do both – call resetFactoryDefaults() at the beginning of the constructor, make your configuration changes in code, then call burnFlash().

Also, to be clear, just setting configuration in code won’t solve the issue if it’s the same one we saw. When the breaker for the motor controller trips, the code doesn’t go back to the initialization for each subsystem, so when the configuration resets, it will stay reset until that initialization is called.

gdefender · February 19, 2020, 5:04am

Oh man, your right. If the breaker pops and restarts the controller during a match the settings will revert if you didn’t call burnFlash(). Doing both is a good idea.

Petrie_4610 · February 19, 2020, 2:42pm

Thank yall. We will for sure try this

Gunmanhammer · February 19, 2020, 2:52pm

Hmm interesting, thanks for the heads up on the sparks. That’s probably going to save me hours down the line as this is our first year using some neos as well.

JesseK · February 19, 2020, 4:33pm

On that note, I wonder if either CTRE, WPILib, or a team could make some code to detect that a breaker was actually tripped, for use with the PowerDistributionPanel object . Not sure if the existing sensors / physics makes that easy though.

codeman73 · February 19, 2020, 5:04pm

I saw that resetFactoryDefaults() in their sample code and it kinda scared me off. I was worried it would reset the CAN IDs as well. What kind of configuration are you doing?

This is our first year using NEOs. We’ll be using them for our shooter, and now our intake. I think on the shooter, we’ll just be setting a setpoint and using PID to maintain that. Not sure of the intake usage because that’s a recent change.

We’ve had a LOT of trouble with the Spark Max client used to config the NEOs. All we’ve done so far with it was to set the CAN IDs and set it to Brushless motor. But it kept resetting the CAN IDs, at random, it appeared. Very flaky.

Will_Toth · February 19, 2020, 5:29pm

This will not reset CAN IDs, running the example code is a good way to get started with the SPARK MAX, and you will see that this is the case.

Can you make sure that

You are on the latest firmware (v1.5.2)
You have a unique CAN ID for each SPARK MAX
You save the parameters after configuring

gdefender · February 19, 2020, 6:36pm

It resets pretty much everything except the CAN IDs. You can get a good idea by looking in the SPARK MAX Client. The stuff that you can change and save to a configuration would get reset. I like doing all of the configuration in the code because it’s repeatable.

The idea here is that you could, for example, not configure your PID values in your code but instead set them in the persistent configuration (either with the Client or using the API and burnFlash()). I don’t like this because you don’t get revision history with source control, and you have to do a manual step if you change the config or swap out controllers.

The configuration we are doing is PID values, coast mode, and followers. Much like you, this is our first year using NEOs and we are using them on our shooter.

Here’s a link to our configuration code, if you’re interested:

github.com

STMARobotics/frc-7028-2020/blob/master/src/main/java/frc/robot/subsystems/ShooterSubsystem.java#L36




private final CANPIDController shooterPIDController = shooterMaster.getPIDController();
private final CANEncoder shooterEncoder = shooterMaster.getEncoder();


private double targetSpeed;


private final SimpleMotorFeedforward motorFeedForward = 
    new SimpleMotorFeedforward(ShooterConstants.kS, ShooterConstants.kV, ShooterConstants.kA);


public ShooterSubsystem() {
  shooterMaster.restoreFactoryDefaults();
  shooterSlave.restoreFactoryDefaults();


  shooterPIDController.setP(ShooterConstants.kP);
  shooterPIDController.setIZone(400);
  shooterPIDController.setOutputRange(-1.0, 1.0);


  shooterMaster.setIdleMode(IdleMode.kCoast);


  shooterSlave.setIdleMode(IdleMode.kCoast);
  shooterSlave.follow(shooterMaster, true);

codeman73 · February 19, 2020, 7:40pm

Yes to all 3. We had done all of that. The client was still reading a different value for the CAN ID, if we simply disconnected the USB, restarted the client, reconnected. It was extremely frustrating, and to be honest, makes me seriously doubt the quality of the software, and makes me very nervous going into the season depending on these.

codeman73 · February 19, 2020, 7:45pm

Thanks. How did you determine your kP constant?
We’ve tried PID tuning before, for cases like turning to a target angle, or aiming/centering on a Limelight target, and it’s has never worked out.

Will_Toth · February 19, 2020, 8:03pm

Have you looked at our example code? The examples provide a nice starting point for various gains as well as code to allow adjusting on the fly from shuffleboard.

gdefender · February 19, 2020, 8:27pm

If you see in our code, we are using SimpleFeedForward, this was key to our success. We used the Robot Characterization tool to get a near-perfect feedforward. We then set P, I, and D to 0 and adjusted our kV until the flywheel was almost perfectly achieving the setpoint RPM with only feed-forward.

Once we had excellent feed-forward we started with a P term that was about 1/10th of what the characterization tool suggested and then doubled it until we got oscillation (overshoot then rebound). We then reduced the P value until the oscillation went away. Finally we shot some balls and made final adjustments to P to get the flywheel to recover as fast as possible without overshooting.

Here’s a link to our shooter characterization project, if that helps at all:
https://github.com/STMARobotics/characterization-2020/tree/master/Shooter

codeman73 · February 19, 2020, 10:26pm

I’ve gone through the Robot characterization tool once. I thought it was focused on the drive train. How did you use this to get constants for a shooter?

gdefender · February 19, 2020, 11:08pm

You can use the simple-motor profile, and then choose the SPARK MAX Project Type. Use the command frc-characterization simple-motor new to start the project, and then select the project type at the top. The rest is pretty much the same as the drivetrain.

system · February 18, 2021, 11:08pm

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.