Skip to content
This repository has been archived by the owner on Oct 27, 2020. It is now read-only.

Switching between READ_ONLY and WRITE_ONLY mode causes issues. #102

Closed
FTC6499 opened this issue Dec 5, 2015 · 3 comments
Closed

Switching between READ_ONLY and WRITE_ONLY mode causes issues. #102

FTC6499 opened this issue Dec 5, 2015 · 3 comments

Comments

@FTC6499
Copy link

FTC6499 commented Dec 5, 2015

It appears that the function getCurrentPosition() does not ever update inspite of the fact that motor moves and in spite of the fact that rotations are being recongized by the rotatry encoder. PID is working so the motor controller must be registering the rotations in some way. I know that PID is working because the motor ramps up it's power after moving.

Here are the related global variables.

    DcMotor[] arm;
    DcMotorController armzeroctl;
    int armzeroid;
    boolean whichArm=true;
    boolean quearmize;
    double speedArm=6.;
    double armzeropos;
    int lastarmzeropos;
    boolean armzerobusy;

Some of these variables are initalized in init() as so. I based my code off of the K9TeleOp class.

       arm=new DcMotor[2];

        arm[0] = hardwareMap.dcMotor.get("arm0");
        arm[0].setMode(DcMotorController.RunMode.RUN_USING_ENCODERS );

        armzeroctl=arm[0].getController();
        armzeroid=arm[0].getPortNumber();

In loop() I have the following code

           if(armzeroctl.getMotorControllerDeviceMode()==DcMotorController.DeviceMode.WRITE_ONLY) {
                if((!armzerobusy)&&quearm) {
                    int armposround=(int)armzeropos;
                    arm[0].setPower(.01);
                    arm[0].setTargetPosition((int) armzeropos);
                    quearm=false;
                    lastarmzeropos=(int)armzeropos;
                }
                arm[1].setPower(scaleInput(gamepad2.right_stick_y));
                armzeroctl.setMotorControllerDeviceMode(DcMotorController.DeviceMode.READ_ONLY);
            }else if(armzeroctl.getMotorControllerDeviceMode()==DcMotorController.DeviceMode.READ_ONLY){
                armzeropos -= (scaleInput(gamepad2.left_stick_y) / speedArm * 32.);
                if(((int)armzeropos)!=lastarmzeropos){
                    quearm=true;
                }
                armzerobusy=arm[0].isBusy();
                telemetry.addData("Arm", String.format("Position %d Target copy: %d Target: %d busy: %b", arm[0].getCurrentPosition(),arm[0].getTargetPosition(), (int) armzeropos,armzerobusy));
                armzeroctl.setMotorControllerDeviceMode(DcMotorController.DeviceMode.WRITE_ONLY);

            }

Upon viewing the telmetry data I noticed that getTargetPosition() is always zero and most likely because of this the motor never stops. I used the Netbeans decompiler and I am baffled by this issue because of the following:

    public int getMotorTargetPosition(int motor) {
        this.a(motor);
        this.b();
        byte[] var2 = new byte[4];

        try {
            this.c.lock();
            System.arraycopy(this.b, OFFSET_MAP_MOTOR_TARGET_ENCODER_VALUE[motor], var2, 0, var2.length);
        } finally {
            this.c.unlock();
        }

        return TypeConversion.byteArrayToInt(var2);
    }

    public int getMotorCurrentPosition(int motor) {
        this.a(motor);
        this.b();
        byte[] var2 = new byte[4];

        try {
            this.c.lock();
            System.arraycopy(this.b, OFFSET_MAP_MOTOR_CURRENT_ENCODER_VALUE[motor], var2, 0, var2.length);
        } finally {
            this.c.unlock();
        }

        return TypeConversion.byteArrayToInt(var2);
    }

This is from HiTechnicNxtDcMotorController.class and we can see that getMotorTargetPosition() is using reading from the array which is called b. Values returned by getMotorTargetPosition() are correct. However getMotorCurrentPosition() always returns zero. At this point I do not know how to percede futher. What could be causing this issue?

@gearsincorg
Copy link
Collaborator

It's very possible that your encoders are not connected correctly. And therefore not generating pulses to be counted. The code sample shows reading two sets of numbers from the motor controller hardware registers. This looks perfectly OK.

You say that "I know that PID is working because the motor ramps up it's power after moving."

But this in not conclusive. If you are requesting a constant slow speed, and the encoders are not connected properly, then the motor controller will start with low power, and then continue to ramp up the power in an attempt to generate encoder counts. Eventually it will max out the power. To me, this an indication of a disconnected encoder.

Please verify that the encoder is plugged into the correct motor channel (1 or 2) and that the encoder cable has been plugged in the correct way around (yellow wire near the outside edge of the motor controller).

I true indication that the encoders are being read correctly is that you can run the motors slow for several seconds and run them fast for several seconds.

@FTC6499
Copy link
Author

FTC6499 commented Dec 9, 2015

I just verified that it is not a hardware issue. Instead it is a software bug (either on my part or in compiled FTC provided code).

It seems to be a combination of two problems

  • Not reseting the encoders
  • Not waiting for pending writes before switching to READ_ONLY mode.

The reason I know that this is a software bug is because I wrote a test program in which I can see getCurrentPosition() correctly updating by adding a delay before switching to READ_ONLY mode. I verified that it works
The initalization is the same except I start with RESET_ENCODERS and later switch to RUN_TO_POSITION. I added a global variable called loopcnt which is of type int.
Here is my code for loop.

            if(loopcnt==24) {
                arm[0].setMode(DcMotorController.RunMode.RUN_TO_POSITION  );
            }else if(loopcnt==64) {
                telemetry.addData("Arm", "Set");
                arm[0].setTargetPosition(128);
                arm[0].setPower(.25);
            }else if(loopcnt==128){
                armzeroctl.setMotorControllerDeviceMode(DcMotorController.DeviceMode.READ_ONLY);
            }else if(loopcnt>128&&(armzeroctl.getMotorControllerDeviceMode()==DcMotorController.DeviceMode.READ_ONLY)){
                telemetry.addData("Arm", String.format("Position: %d Target: %d busy: %b", arm[0].getCurrentPosition(),arm[0].getTargetPosition(),arm[0].isBusy()));

            }
            if(loopcnt<Integer.MAX_VALUE)
                ++loopcnt;

If I use a very small delay the motor will not move at all because the writes were never done to the controller telling it to move the motor. The issue is most likely because any pending writes are not completed during SWITCHING_TO_READ_MODE..

If this is a feature and not a bug how do I wait for writes to be completed before switching to READ_ONLY mode? Could someone add a function such as pendingRW() which returns true if there are any pending reads or writes. Using a hardcoded value is not a good idea for a delay.

Are any pending writes supposed to be flushed while in SWITCHING_TO_READ_MODE? If so then this is a software bug in the FTC Application.

Leaving the encoder in WRITE_ONLY mode allows for correct behavior of the rotary encoder. Because of this new information I have changed the title of the issue.

@FTC6499 FTC6499 changed the title The function getCurrentPosition() always returns zero with the legacy motor controller. Switching between READ_ONLY and WRITE_ONLY mode causes issues. Dec 9, 2015
@cmacfarl
Copy link
Collaborator

All reads and writes to motor controllers are synchronous with this season's SDK. For this reason I believe your problem here is solved. If you are still having trouble please post a question over on the forums.

sahithi-thumuluri pushed a commit to 6150FTC/Main-19-20-FTC6150 that referenced this issue Apr 4, 2019
swap controls for mouth, grsbber, and rotator
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants