Announcement

Collapse
No announcement yet.

NullPointerException DcMotor$RunMode.migrate

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • NullPointerException DcMotor$RunMode.migrate

    Hi,
    Our autonomous code that's worked well all season has suddenly showing some errors.. it's running on Neverest20 motors, and the encoder is set to RUN_WITH_ENCODER mode.

    code threw an uncaught exception: NullPointerException - Attempt to invoke virtual method 'com.qualcomm.robotcore.hardware.DcMotor$RunMode com.qualcomm.robotcore.hardware.DcMotor$RunMode.mi grate()' on a null object reference

    When the error occurs the robot abruptly stops at a random point in autonomous. "Robot is stopped" message flashes on Android driver station.This seems hardware related since no code changes related to encoders were made. Replacing the encoder cables hasn't worked, and may be replace the Modern Robotics DC motor controller could do the trick?

    What could be causing this issue? Especially since this a perfectly well working code over past 2 months??

    Please advice ASAP!

    Thank you
    --

  • #2
    Can you post your code? RunMode.migrate is only used with deprecated run modes. For whatever reason the motor object is null when this is called.

    Comment


    • #3
      Could it be due to a wiring issue? Or a motor controller with flaky connector? It seems to happen at random times.

      Comment


      • #4
        by the way - the migrate call is not in code. The setting is RUN_WITH_ENCODER.

        Comment


        • #5
          It shouldn't be a wiring issue, that would just not do anything, not throw an error. Please post your code.
          CoCaptain and Android Studio Troubleshooter for FTC Team 6566, Circuit Breakers.

          Website: http://www.aledoroboticsclub.com

          Comment


          • #6
            There is no RUN_WITH_ENCODER. In either case you're trying to use a motor that is null. That's not wiring but a coding problem.

            Can you post your code?

            Comment


            • #7
              Init:
              public void runOpMode() {
              telemetry.addData("First Init", true); //Begin initialization
              telemetry.update();
              robot.init(hardwareMap);
              ....


              after wait for start...

              robot.capServo.setPosition(0.5);
              robot.capRaiser.setPower(0);
              //range1Cache = RANGE1Reader.read(RANGE1_REG_START, RANGE1_READ_LENGTH);
              range2Cache = RANGE2Reader.read(RANGE2_REG_START, RANGE2_READ_LENGTH);
              robot.buttonServo.setPosition(0.05);
              robot.fl.setMode(DcMotor.RunMode.STOP_AND_RESET_EN CODER);
              robot.fl.setMode(DcMotor.RunMode.RUN_USING_ENCODER );

              robot.driveLimitless(0, 0, 0, 0);

              //shoot();

              while(robot.fl.getCurrentPosition() > -850 && opModeIsActive()) { // Move forward
              robot.driveLimitless(-0.4, 0.4, -0.4, 0.4);
              }
              stopRobot();


              ....

              private void stopRobot()
              {
              robot.driveLimitless(0, 0, 0, 0);
              sleep(50);
              robot.fl.setMode(DcMotor.RunMode.STOP_AND_RESET_EN CODER);
              robot.fl.setMode(DcMotor.RunMode.RUN_USING_ENCODER );
              }

              Comment


              • #8
                What version of the SDK are you using? There was a bug in 2.61 where ModernRoboticsUsbDcMotorController.finishModeSwitc hIfNecessary() would sometimes invoke ModernRoboticsUsbDcMotorController.modeToByte() with a null mode value, which would throw the NPE you're seeing when mode.migrate() was called. This was fixed in version 2.62.

                Comment


                • #9
                  Just want to post an update. We traced it down to a couple of screws falling off the DC Motor controller connecting to the said motor in use here, which resulted in vibrations, and intermittent loss of connectivity to that motor. Once the screws to DC motor controller have been replaced, the issue was resolved. It was a bit disconcerting a day before States, but it all turned out fine, and we won Inspire 1st place!

                  Comment


                  • #10
                    Originally posted by FTC6700 View Post
                    Just want to post an update. We traced it down to a couple of screws falling off the DC Motor controller connecting to the said motor in use here, which resulted in vibrations, and intermittent loss of connectivity to that motor. Once the screws to DC motor controller have been replaced, the issue was resolved. It was a bit disconcerting a day before States, but it all turned out fine, and we won Inspire 1st place!
                    That doesn't really make sense; the motor controller is not aware whether or not a motor is connected to it. It will happily create a voltage across the terminals even if no motor is plugged in. What seems more likely is that you simply didn't happen to observe the SDK bug in subsequent tests.

                    Comment


                    • #11
                      Originally posted by GearTicks View Post
                      That doesn't really make sense; the motor controller is not aware whether or not a motor is connected to it. It will happily create a voltage across the terminals even if no motor is plugged in. What seems more likely is that you simply didn't happen to observe the SDK bug in subsequent tests.
                      +1

                      Our code runs fine even if we lose an entire motor controller.

                      P.S. See you at supers

                      Comment

                      Working...
                      X