Struggling with Armsystem Code for REV Robotics 2024 Starter Bot

We are a relatively new team with a beginning level of programmers so we decided to build out the 2024 Rev Robotics starter bot. All went well with the build but we are now struggling with the code for the Arm subsytem. We’ve used the example code provided on the REV site but can not get the kIntakePosition and kScoringPosition to work. Using the current number for softlimitRevers -1.15 and kIntakePosition -1.17 does not work for us. We’ve tried changing these using different values but have mixed results. We don’t get consistency and the range of motion always changes. The math is tripping us up…

We can get the arm to work prefectly using the REV Hardware Client and using the limit values for forward and reverse. We can’t seem to get it within the code.

We are hoping a team that is also using th ecode or someone from REV (Orion) might respond with some suggestions for us to try. With a week to go b4 regional we r stressing:-/

Ok… after many more hours of trial n error we seem to have fixed the main issue.
It has only taken 4 broken arm supports because of seemingly random movement going to far in the rotation. :face_with_spiral_eyes:

Hi, my team is also using this robot kit. Could you tell me what you did to fix this issue? Im using the rev code for the arm. Thank you.

Our solution steps worked but they are not ideal. First, make sure the arm is in the upright (home or scoring position) as this is zero. Then, power up the robot and that locks the arm into the zero position. The intakeposition will vary but you adjust this in the CONSTANTS file. We added another 4:1 gear on to the motor so that the arm does not fall down and had to change the intake position value to where it best took in the note. After every match we checked and reset the intakeposition as necessary. We found that with use there is some play that creeps in to the arm movement. Always power up/down with the arm in the scoring or home position. We also found it Important to set the soft limit value to be the same as our intake and scoring positions. Hope that helps!

Thank you so much for your input. I am also curious on how you have your gears? So far for my arm it has the motor then 5:1 gear then another 5:1 gear. Did you do motor then 4:1, 5:1, 5:1? And did you modify the code for kArmGearRatio to fit the gears? Thank you again.

Sorry, Kevin for the delay we are full on trying to repair/prepare for shipping to Championship.

We have Motor-5:1,5:1,4:1 setup We did not modify the kArmGearRatio. We tried to adjust the kArmFreespeed in the hopes of increasing the uo/down speed of the arm but had not success. If you have any suggestions do let us know.

Our 2 programmers are very new and focussed on trying to understand the Rev supplied starter code. We tried a few things to speed up the arm movement but had no success.

How is your team’s autonomous? Are you using path planning? We are struggling to run run consecutive movements. We can spin up the shooter, then the intake…and then we want to move but this is not happening for us. We can move if we disable the shooter/intake, but not all 3 sequentially. Any suggestions from your programmers would be appreciative.

Hi Mike, I’m the programmer for my team and also very new to programming but for the arm we tried it without the 4:1 gear ratio and it does work fine for us so far. The arm does move up and down pretty fast. But if you’re sticking with the 4:1 ratio, you might need to mess with the PID maybe to get the arm moving faster. We haven’t gotten to autonomous yet. I’ll be messing with autonomous sometime. I’ll let you know if i run into your issue and if I could help

Thx Kelvin. Riley has just sorted our automous and we have pre-spin, then intake, then stop and move. So we have a basic 7 point auto. Next year we are going to dig into Path Planning that the more experienced teams seem to use.

Alll the best.

TIP for your Fabrication crew. We had screws come loose and subsequently shear into our through bore encoder on the swerve drive, twice. Turning was then inoperable. The screws are awkward to tighten when building the swerve. It is the screw holding down the small gear. We’ve now locktited them in. This is not in the REV documentation.

1 Like

Hey Mike. We recently got our arm working pretty well, we changed the P value in the PIDGAINS in the constants file to 1.0 . We noticed the arm moved slower but was hovering over the ground so we changed our kIntakePosition to -1.30 (this might be different or you robot). Maybe try taking out the 4:1 because you said it was moving slower? This might help move the arm faster. I would suggest elevating the robot so the arm doesn’t slam into the ground, again this might help or not help because we your team is using a neo and we are using a vortex. Hopefully this helps. We are currently running a vortex motor, 5:1, 5:1 configuration for the arm. I just got to working on autonomous do you have any tips?

Hi Mike, I’m trying to figure out the autonomous in the rev code but I’m a bit confused with it. Do you think you could share the code so I can see how it works.
Thanks again.

I can try to find my teams auto that shot and went backwards if you need however it only gained the 7 points from middle otherwise it stayed in zone on source side and on amp needs to be e-stopped to prevent hittting the amp

By any chance are you using the rev 2024 starter bot? If not anything helps.
Thank you.

Yes we use the starter bot

I believe this was our auto if u want to try it out

return new RunCommand(() → m_launcher.runLauncher(), m_launcher).withTimeout(2).andThen(m_intake.feedLauncher(m_launcher));//.andThen(swerveControllerCommand.andThen(()-> m_robotDrive.drive(.25,.25,0,false,false)))

Hello Kelvin. I am the one who worked on team 8338’s autonomous code. We are using a Time-based robot. Ive heard that autonomous for time-based is different from command-based, so if you are using command-based, there may be a bit of a barrier

//snippet from robot.java

import edu.wpi.first.wpilibj.Timer;

public Timer timer = new Timer();
private RobotContainer m_robotContainer;

public void autonomousPeriodic() {
    // code here
    double metersDist = 0.2;
    double rotDist = 0.4;

    double delayTime = 1;

    System.out.println(timer);

    // This resets everything to assure the robot is movng the currect direction.
    if (timer.get() <= 0) {
      m_robotContainer.m_robotDrive.drive(0, 0, 0, false, false);
      m_robotContainer.m_intake.setPower(0);
    }

    // prefires the launcher
    if (timer.get() >= delayTime && timer.get() <= 2 + delayTime) {
      m_robotContainer.m_launcher.runLauncher(true);
    }

    // runs the intake so we can fire the preloaded ring
    if (timer.get() >= 2 + delayTime && timer.get() <= 3 + delayTime) {
      m_robotContainer.m_launcher.runLauncher(true);
      m_robotContainer.m_intake.setPower(Constants.Intake.kIntakePower);
    }

    // moves the arm downwards and drives forward
    if (timer.get() >= 3 + delayTime && timer.get() <= 4 + delayTime) {
      m_robotContainer.m_intake.setPower(0);
      m_robotContainer.m_arm.setTargetPosition(Constants.Arm.kIntakePosition);
      while (timer.get() >= 3 + delayTime && timer.get() <= 4 + delayTime) {
        m_robotContainer.m_robotDrive.drive(metersDist, 0, 0, false, false);
      }
    }


Here is a direct snippet of our old TESTED autonomous code that worked fine for us. We are using a timer that runs the autonomous based on the the current time. It is a little messy as this was rushed but allow me to explain what it does.

We first imported the timer from the wpi library which allowed us to make moves based on time. Then a variable that defines the Timer.
We then created a variable “private RobotContainer m_robotContainer” that grabs the script “RobotContainer” sso we can call functions from there.
we also set a delayy variable thats just delays the entire autonomous code in the scenario where we have a teammate that may be in the way.

in the first if statement.

    if (timer.get() <= 0) {
      m_robotContainer.m_robotDrive.drive(0, 0, 0, false, false);
      m_robotContainer.m_intake.setPower(0);
    }

this is the start and just initializes the wheels and the intake power to default to assure theres no running launcher or missaligned wheels on startup.

    if (timer.get() >= delayTime && timer.get() <= 2 + delayTime) {
      m_robotContainer.m_launcher.runLauncher(true);
    }

this runs the launcher if the time is between 0 and 2 seconds (assuming we have no delaytime)

    if (timer.get() >= 2 + delayTime && timer.get() <= 3 + delayTime) {
      m_robotContainer.m_launcher.runLauncher(true);
      m_robotContainer.m_intake.setPower(Constants.Intake.kIntakePower);
    }

Between 2 and 3 seconds, it runs the launcher, and the intake so it shoots the ring up. (the prior launcher run was to prefire)

if (timer.get() >= 3 + delayTime && timer.get() <= 4 + delayTime) {
      m_robotContainer.m_intake.setPower(0);
      m_robotContainer.m_arm.setTargetPosition(Constants.Arm.kIntakePosition);
      while (timer.get() >= 3 + delayTime && timer.get() <= 4 + delayTime) {
        m_robotContainer.m_robotDrive.drive(metersDist, 0, 0, false, false);
      }
    }

This final one runs between times 3 and 4 seconds. Setting the intake to 0 (off) and moving the arm to the intake position where it can pick up another ring. it calls m_robotContainer (the script) then looks for the function “setTargetArmPosition” then moves the arm to the preset location we have up.

in the while loop, it runs the wheels forward so it can drive away from the wall. its in a while loop because it would only run once on call. this was a huge issue for us cause we didnt understand why it was running the other commands fine but not the wheels constantly.

I hope this helps you with your autonomous code, and i hope you can understand my broken english as im in a rush. If you have any additional questions, feel free to ask.

thank you for the example. I am using command base but I will try my best to convert it. Thanks for the help