Auton Motor Stutters

Technical
1

During auton the motor is supposed to run continuously but it stutters, it runs barely stops runs barely, ect.

2

It sounds like two commands are fighting for control. Make sure your default and auto commands declare their subsystem requirements correctly.

We can help more if you can post a link to your code, say on GitHub.

3

I dont really think they should be fighting but maybe im not the greatest at coding heres the git

4

See Jerky wheels with DifferentialDrive in autonomous

You need to ‘feed’ the differential drive when you directly set motor speeds in auto

5

… but it looks like you’re always going through your drivetrain’s arcadeDrive(), not trying to directly set the left/right motor, so that’s not it, unless maybe you do see “motor safety” warnings?

If it’s not that, then you’re likely running multiple commands at the same time.

6

You’re calling arcadeDrive with joystick values from the periodic of your drive subsystem. You should be doing this using a default command instead.

2 Likes
7

Sorry it’s not the driveTrain it’s the SparkMax aka liftSpark if you look into 2BallAuton that’s what I’m working on

9

If the setpoint is higher than the position, then the MoveToPosition command will alternately set the power and stop the motor. This will make the motion jerky, but only in one direction.

10

So remove the greater than?

11

Maybe like this:

  // Check encoder value
  if(liftEncoder.getPosition() >= setpoint)
      // If the encoder is going to pass the setpoint, stop the motor
      liftSpark.stopMotor();
  else
      liftSpark.set(power);

So either move or stop, but don’t move & stop at the same time

12

But then you would not be able to move “back” once you hit the limit.
So maybe something like this:

 // Check encoder value when moving 'up' to prevent running too high
  if (power > 0 && liftEncoder.getPosition() >= setpoint)
      // If the encoder is going to pass the setpoint, stop the motor
      liftSpark.stopMotor();
  else
     // always OK to move 'down' or 'up' while below limit
      liftSpark.set(power);
13

I think that if you’re already moving to commands to make your robot work, it would be worth the investment to just have your teleop be command-based as well.

I think it will greatly reduce the amount of guessing and troubleshooting you have to do to make your robot work.

The only real issue I saw in a brief look at your 2 ball Auto sequence command is that your moveToSetpoint command never finishes. So your sequence will actually never run all the way through because your first command will block it from continuing on.

14

How would i fix that. I don’t know much about commands.

15

Probably not a good idea to try and do it before you’re done competing this year, but the core of it is to break your robot’s functionality into Subsystems, and Subsystems are driven to do things through commands.

The nice thing about this paradigm is that it allows a more novice programmer to do perform more complicated actions.

You can take a look at our school’s code, we keep it open source.

Here for example is a single command defined as a shooting sequence that interacts with a couple different subsystems.

The nice thing about this setup, is if you look at the RobotContainer.java file, specifically the configureButtonBindings() method, you’ll see that we bind three different button presses (A, B, Y) on the controller to perform that same shooting sequence from three different spots on the field.

I’m not saying our code is the best way to code, or that there aren’t other ways to do the same thing. The point I’m making about Command-based things simplifying complex robot interactions is that once we got that command to work well for shooting the ball one time, it became next-to-zero effort to give our drivers multiple control options that performed similar actions (like shoot reliably from multiple places on the field).

16

I’ve got like half the controls based off commands it’s just at the beginning of coding this I’d only ever done timed so I was learning as I was doing.

17

The most important piece of good Command-Based code is understanding the scheduler.

Key parts there are:

  1. The Subsystem default command is the command scheduled to run, when no other command is scheduled to run for that subsystem."
  2. Commands are typically instantiated, just one time. There is only one instance of a given command, (e.g. when you bind it to a controller button). That command is going to be scheduled to run multiple times. Pay attention to the state of things you need to do in the initialize method to set things up, the execute->isFinished loop, and terminate your command safely by doing stuff in the end() methods of your commands.
  3. You can view what commands are scheduled and running by using shuffleboard, smartdashboard, or glass.

After that, it’s just getting your commands scheduled to the proper triggers (like button presses).

18

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