Needing help with programming

I am a new programmer this year, and I have been watching a lot of youtube videos about programming tutorials for drivetrain and shooter. However, my code did not seem to work even though it says build successfully. I’m overwhelmed because I am the only programmer on the team, and if the robot is not running, we might not be able to compete. If any programmer can give me a hand I would be much appreciated it.

There are a lot of people that are willing to help. However, you need to make it easy to help you.

Some advice:
“It doesn’t work” or “It doesn’t seem to work” is not enough information to help you.

A better approach would be:
“My code builds and deploys successfully to the robot, but when I enable it and try to drive with the controller the robot doesn’t move”.

It would also be more helpful if you could post your code to something like Github where people can take a look at the whole project.

If you’re using Java, and command-based, my first inclination of “robot code not working” is that I’d like to see your default command for your Drivetrain subsystem. The more information you provide, it is much easier to help you.

1 Like

+1 for code in Github. Seeing your code will help us diagnose the issue. Think of it like the vet. If you go to their office and say “My cat doesn’t work!” without bringing your cat or explaining the issue, then you most likely wouldn’t fix said cat.

1 Like

This is a pretty good guide for asking good questions.

As you already have determined, while build successful implies the computer understands your instructions, it doesn’t mean the instructions you gave will accomplish your intent.

The most relevant thing to start with: What is it that you are intending to do. That is to say, if everything works out correctly, what do you expect to happen?

This question, in the context of “program a drivetrain and shooter”, is a pretty broad one. The first step is to break down that large problem into many smaller ones. Continue to break them down smaller and smaller until each individual problem is trivial.

And, yes, as others have mentioned, posting code is extremely relevant. If you only have a single Robot.java file you’re modifying, posting it’s contents here with Fenced code block markers around it is a quick and dirty way to inform folks of where you are currently at. If you have many files, Git/Github is a good technology to use for sharing source code.


here’s my code for the robot I have so far. Is there anything that I can chage?
1 Like

I can’t be sure, but I am guessing: the file “DriveTrain.java” in the top directory is not being used. You did not check in the whole project (you should), but the standard WPILib build uses the code under src/main/java/frc/robot.

fwiw there’s another DriveTrain.java inside the subsystems folder, which looks quite similar. Still, OP will want to be careful which one is being edited.

This isn’t the complete project, can you zip it up and share that?

As others have said, there are two DriveTrain.java’s in the project. You probably should get rid of the one in the base directory, and use/keep the one in the subsystems directory.

What I think you might need to do is have the DriveWithJoysticks command accept 2 DoubleSuppliers, then do something like this in your robot container. It’s been a minute since I’ve programmed our robot, but here is what we do:

The drivetrain snippet inside RobotContainer.java:

m_Drivebase.setDefaultCommand(
          new SetDrivetrainSpeedCommand(
            () -> joy0.getY(Hand.kLeft),
            () -> joy0.getY(Hand.kRight),
            () -> P0_rightBumper.get(),
            m_Drivebase));

The constructor of SetDrivetrainSpeedCommand.java:

public SetDrivetrainSpeedCommand(DoubleSupplier leftAxis, DoubleSupplier rightAxis, BooleanSupplier turbo, Drivebase drivebase) {
    m_Drivebase = drivebase;
    m_leftAxis = leftAxis;
    m_rightAxis = rightAxis;
    m_turbo = turbo;
    addRequirements(drivebase);
  }

The Execute function inside SetDrivetrainSpeedCommand.java:

 @Override
  public void execute() {
    // Default speed multiplier = 70%
    double speedMultiplier = .7;

    // If the turbo button is pressed, change the speed multipier to 100%
    if(m_turbo.getAsBoolean()) {
      speedMultiplier = 1.0;
    }

    m_Drivebase.manualControl(-m_leftAxis.getAsDouble() * speedMultiplier, -m_rightAxis.getAsDouble() * speedMultiplier);
  }

We have a turbo button since our drivetrain is geared up, so that’s what that is

Here’s our github:

FWIW, I was able to do the following:

  1. Clone your repo
  2. Make a brand new command-based project
  3. Copied your posted files in
  4. Built and ran in simulation
  5. Ran a quick test sweep in both teleop and autonomous

Here’s my results:

You can see PWM values changing and moving around in a manner that seems like it could be reasonable.

So, I’m continuing to push for a better description from you. What, precisely, does “did not seem to work” mean? What actions did you take, what was your expected behavior, and what actually happened?

For example, a typical debug session could involve the following:

  1. Powered on the robot
  2. Connected to it via Wifi
  3. Deployed the code to the robot
  4. Opened the driver station
  5. Plugged in an XBOX controller
  6. Confirmed the controller is recognized in slot 0 by the driver station
  7. Confirmed the driver station has connection to the Robot
  8. Selected “Teleop” and then “Enabled” in the driver station
  9. Pushed the left-hand joystick around on the xbox controller
  10. Observed signs of motor controllers getting control signals (different LED color/blink patterns)
  11. Observed signs motors are getting voltage (noise, heat, motion)

WPI documentation has these steps and more troubleshooting as well: Here as well as Here. Similar question related to those - which steps have you taken, and what were the results?

With my code currently, I am expecting the robot to simply move forward and backward. I also try the stimulation and see the PMW values change, but the robot did not move. I checked the status of the communication on the Robio and everything looks fine. I just don’t really know what the problem is

Ok. So go through the list I posted. In particular, what about item 10? Do motor controllers indicate they are getting the expected signals from the roboRIO?

Fair enough. Some related bits of knowledge to help orient your mindset:

  1. I don’t know what the problem is either :slight_smile:
  2. Finding root cause of the problem is what we’re working toward now
  3. Symtoms are important and point us toward root cause, but in and of themselves are not root cause
  4. It’s rarely possible to trace a symptom back to a single root cause - multiple pieces of evidence are usually needed.

Yes there is blinking light on the SparkMax

Ok. “A blinking light” is not detailed enough yet. Not all blink patterns imply “Getting expected data from the RoboRIO”.

Please click here and read up some on Spark and Spark Max motor controller status lights (they are different): Status Light Quick Reference — FIRST Robotics Competition documentation

Something I’m noticing… your code says you are using Spark motor controllers, which look like this:

image

However, you reference A Spark Max motor controller, which looks like this:

image

Is your code consistent with the electrical components on the robot, and how they are wired?

We wire the robot as a CAN daisy chain starting from the Roborio to 4 of the SparkMax and ends at the PDP.

Alrighty, sounds like one thing to start with. The code does not match with the electrical system on the robot. You’ll need to change your Spark controllers in code to be Spark Max’s.

Here’s the spark max main product page: SPARK MAX Motor Controller - REV Robotics

From that page, they link to their software resources: REV Software Resources

Take a look at the getting started docs if you haven’t yet, there are critical details there about configuring unique CAN bus ID’s, and testing out motor controller functionality before software comes into play.

From there, since you are using Java, you’ll want to take a look at the Java-specific software writing resources: SPARK MAX API Information - SPARK MAX

Finally, REV does produce some sample projects you can reference. This tank drive in particular might be relevant: SPARK-MAX-Examples/Java/Tank Drive With CAN at master · REVrobotics/SPARK-MAX-Examples · GitHub

Another bit of background, again just to help orient your mindset:

Right now, you’re doing two tasks simultaneously:

  1. Learning how to diagnose and fix issues.
  2. Fixing the actual problems on the robot.

This is a tall task for sure, but doing them together is (IMO) the best way to learn!

Keep this in mind once you get to the end: I suspect the final “solution” will involve just tweaking a few lines of code, maybe running a command or two, maybe moving a wire or two around. It will likely seem very simple.

Don’t be discouraged by the simplicity! That’s to be expected. It’s the software equivalent to this classic story:

The huge printing presses of a major Chicago newspaper began malfunctioning on the Saturday before Christmas, putting all the revenue for advertising that was to appear in the Sunday paper in jeopardy. None of the technicians could track down the problem. Finally, a frantic call was made to the retired printer who had worked with these presses for over 40 years. “We’ll pay anything; just come in and fix them,” he was told.

When he arrived, he walked around for a few minutes, surveying the presses; then he approached one of the control panels and opened it. He removed a dime from his pocket, turned a screw 1/4 of a turn, and said, “The presses will now work correctly.” After being profusely thanked, he was told to submit a bill for his work.

The bill arrived a few days later, for $10,000.00! Not wanting to pay such a huge amount for so little work, the printer was told to please itemize his charges, with the hope that he would reduce the amount once he had to identify his services. The revised bill arrived: $1.00 for turning the screw; $9,999.00 for knowing which screw to turn.

The punchline: The difficult part (and therefor the more valuable part) is figuring out what fix to execute, not necessarily how to execute the fix. This “what” is what most mentors will seek to teach to their students.

1 Like