Using WPILibJ (Java) Swerve Example - DIOJNI Error

We are working on getting our(basic) swerve to work - we tried working with 2910’s swerve program, and found it to be way over our heads, so we opted for a more “basic” swerve, trying to get our feet wet. We are using Swerve Drive Specialties Mk3 with Neos for both turn and drive motors, and have added SRX Mag encoders to each of the modules to look at angular position. Right now, we are just trying to get the thing to move - even in a straight line - but we keep getting the same error out of the compiler - even if we just compile and push the base example without any modification - here is the error stack:

  • Unhandled exception instantiating robot edu.wpi.first.hal.DIOJNI edu.wpi.first.hal.util.UncleanStatusException: Code: -1029. HAL: Resource already allocated

    • Error at frc.robot.SwerveModule.(SwerveModule.java:75): Unhandled exception instantiating robot edu.wpi.first.hal.DIOJNI edu.wpi.first.hal.util.UncleanStatusException: Code: -1029. HAL: Resource already allocated

    • at edu.wpi.first.hal.DIOJNI.initializeDIOPort(Native Method)

    • at edu.wpi.first.wpilibj.DigitalInput.(DigitalInput.java:33)

    • at edu.wpi.first.wpilibj.Encoder.(Encoder.java:134)

    • at edu.wpi.first.wpilibj.Encoder.(Encoder.java:94)

    • Robots should not quit, but yours did!

    • at frc.robot.SwerveModule.(SwerveModule.java:75)

    • at frc.robot.Drivetrain.(Drivetrain.java:33)

    • at frc.robot.Robot.(Robot.java:14)

    • at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:289)

    • at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:407)

    • at frc.robot.Main.main(Main.java:23)

Our code can all be found here:

The Resource already allocated error usually means you have made two objects that use the same port, ie PWM, DIO, Analog, ect. Looking at your Drivetrain class, it looks like you accidentally used the Constants.REAR_LEFT_ANGLE in your m_frontLeft SwerveModule object as well as your m_backLeft object. So you’d be creating two motors in that port.

  private final SwerveModule m_frontLeft = new SwerveModule(Constants.FRONT_LEFT_DRIVE, Constants.REAR_LEFT_ANGLE, Constants.FRONT_LEFT_ENCODER_A, Constants.FRONT_LEFT_ENCODER_B, Constants.FRONT_LEFT_DRIVE);
  private final SwerveModule m_frontRight = new SwerveModule(Constants.FRONT_RIGHT_DRIVE, Constants.FRONT_RIGHT_ANGLE, Constants.FRONT_RIGHT_ENCODER_A, Constants.FRONT_RIGHT_ENCODER_B, Constants.FRONT_RIGHT_DRIVE);
  private final SwerveModule m_backLeft = new SwerveModule(Constants.REAR_LEFT_DRIVE, Constants.REAR_LEFT_ANGLE, Constants.REAR_LEFT_ENCODER_A, Constants.REAR_LEFT_ENCODER_B,Constants.REAR_LEFT_DRIVE);
  private final SwerveModule m_backRight = new SwerveModule(Constants.REAR_RIGHT_DRIVE, Constants.REAR_RIGHT_ANGLE, Constants.REAR_RIGHT_ENCODER_A, Constants.REAR_RIGHT_ENCODER_B,Constants.REAR_RIGHT_DRIVE);
1 Like

Nice catch, I updated that, but still getting the same errors.

In your SwerveModule Constructor, you’ve hard coded the ports for your m_driveEncoder so you’d be trying to re-use those same ports at least 4 times.

m_driveEncoder = new Encoder(9,10, false);

Fixed that too, Here is the error:

  • ********** Robot program starting **********

  • Unhandled exception instantiating robot edu.wpi.first.hal.DIOJNI edu.wpi.first.hal.util.UncleanStatusException: Code: -1029. HAL: Resource already allocated

  • Error at frc.robot.SwerveModule.(SwerveModule.java:76): Unhandled exception instantiating robot edu.wpi.first.hal.DIOJNI edu.wpi.first.hal.util.UncleanStatusException: Code: -1029. HAL: Resource already allocated

  • at edu.wpi.first.hal.DIOJNI.initializeDIOPort(Native Method)

  • at edu.wpi.first.wpilibj.DigitalInput.(DigitalInput.java:33)

  • at edu.wpi.first.wpilibj.Encoder.(Encoder.java:134)

  • Robots should not quit, but yours did!

  • at edu.wpi.first.wpilibj.Encoder.(Encoder.java:94)

  • at frc.robot.SwerveModule.(SwerveModule.java:76)

  • at frc.robot.Drivetrain.(Drivetrain.java:32)

  • at frc.robot.Robot.(Robot.java:14)

  • at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:289)

  • at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:407)

  • at frc.robot.Main.main(Main.java:23)

  • Warning at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:303): Robots should not quit, but yours did!

Thank you!

Like I said, it does it in the base version of the code before we even modify it at all, we just opened it and tried to send it - it compiles, but the same issues - is it possible it is an issue with the WPI Example?

What did you change it to? The error is still pointing to the Encoder Object instantiation.

Error at frc.robot.SwerveModule.(SwerveModule.java:76)...
at edu.wpi.first.wpilibj.Encoder.(Encoder.java:134)

m_driveEncoder = new Encoder(driveEncoderChannelA,driveEncoderChannelB, false);

I’m fairly certain the example is fine, though not 100% because I’m not actually a Java Developer, and don’t use it outside Robotics, but in the example, while the Encoder Objects in the SwerveModule Class use Hard-Coded values, because they are initialized outside any methods, all instances of SwerveModule actually share a single Encoder object, not a separate one. Kinda like static, except the “pointer” space is separate so you could later make separate encoder objects for each SwerveModule instance if you wanted, provided you removed the final declaration from the encoder variables.

The original error where you hard coded the encoder ports, broke because you moved the instantiation (the part with the new) to inside the constructor where each instance of SwerveModule could get a fully separate Encoder object instead of sharing a reference to the same one.

Ok, So I assume then you modified the Constructor for SwerveModule to also have those parameters, and your SwerveModule Instantiations in DriveTrain and your Constants, ect.

You’re certain the namings are all right and no numbers are being reused between your sets of encoders or anything?

If you could update your Google Colaboratory page it would be helpful in continued diagnosis.

I am really out of my element, here - we have never had a lead programming mentor, and my students really only have me, and they are trying to push what we are doing - we are planning on using the integrated encoder on the Neo for drive wheels and an external SRX mag for the position of the wheel angle.

Thank you so much for your help!

I have to be honest - I have no idea - but I am updating the Colab now.

Yeah… trying to impliment something as software complicated as swerve without anyone very familiar with programming is definitely a challenge.

Ah, SO you are using NEO’s encoders for the “driveEncoder” so you actually need/want to switch those to using the CANEncoder class, and retrieve the encoder objects from your motors.

You should be able to see kinda how this works in our Launcher/Flywheels code from 2020/2021 InfiniteRecharge/Launcher.java at master · frc3468/InfiniteRecharge · GitHub

We used NEOs and their integrated encoders to control the speed of our flywheels.

mainly

    leftLaunchMotor = new CANSparkMax(LauncherConstants.leftLaunchMotor, MotorType.kBrushless);
    rightLaunchMotor = new CANSparkMax(LauncherConstants.rightLaunchMotor, MotorType.kBrushless);

    leftMotorEncoder = leftLaunchMotor.getEncoder();
    rightMotorEncoder = rightLaunchMotor.getEncoder();

Yes. SwerveBot example crashes on encoder pin overallocation · Issue #3089 · wpilibsuite/allwpilib · GitHub

1 Like

Ah, there goes my theory on that. Thanks!

So what does this mean?

Nothing of serious consequence, just that yeah, the way the encoders were setup by default is incorrect. Though you already began to take steps to correct that moving the initialization of the encoders to the Constructor.

Our team did create a pretty basic example for swerve drive in our offseason last year. The drive motors don’t have any encoders on them but it should be a start for you guys if you can’t get it driving. Github link

Thank you! I will look into this!

Alright, so I got rid of the error - now it is just a function of stopping the wheels from panicking - as soon as we enable, the wheels start spinning all over the place - I would imagine we aren’t reading the proper encoder, but that is something I will make the kids dive into.

Thank you for your help!