Null Gamepad References

[Varun Singh]

Hi,

I just downloaded and ran the latest version of the SDK from GitHub today and I had a weird issue where when I tried to run an opmode that used a gamepad, for example it used the button x, then it would give me an error saying that gamepad1.x is a null reference. I fixed this by adding gamepad1 = new Gamepad() and gamepad2 = new Gamepad() in all of my opmode constructors, but I was wondering if all of this is intentional, or accidental. I used the built-in decompiler and saw that in the OpMode class, the gamepads were set to null, whereas in the previous version of the SDK, the gamepads were set to new Gampad() 's.

[GearTicks]

I have noticed this too. They seem to be null during init() and the first time through init_loop(). Here is the test code we have been using:

public class GamepadReferenceTest extends OpMode {
	private Gamepad lastGamepad1;
	private int differenceCount;


	public void init() {
		this.lastGamepad1 = this.gamepad1;
		this.logDifferencesAndHashCode("init");
	}
	public void init_loop() {
		this.checkDifferences();
		this.logDifferencesAndHashCode("init_loop");
	}
	public void start() {
		this.checkDifferences();
		this.logDifferencesAndHashCode("start");
	}
	public void loop() {
		this.checkDifferences();
		this.logDifferencesAndHashCode("loop");
	}
	private void checkDifferences() {
		if (this.gamepad1 != this.lastGamepad1) this.differenceCount++;
		this.lastGamepad1 = this.gamepad1;
	}
	private void logDifferencesAndHashCode(String method) {
		if (this.differenceCount != 0) {
			DbgLog.msg("Changed in " + method);
			this.differenceCount--;
		}
		DbgLog.msg(method + ": " + ((this.lastGamepad1 == null) ? "null" : ((Object)this.lastGamepad1).hashCode()));
	}
}

[Cheer4FTC]

Hi,

I just downloaded and ran the latest version of the SDK from GitHub today and I had a weird issue where when I tried to run an opmode that used a gamepad, for example it used the button x, then it would give me an error saying that gamepad1.x is a null reference. I fixed this by adding gamepad1 = new Gamepad() and gamepad2 = new Gamepad() in all of my opmode constructors, but I was wondering if all of this is intentional, or accidental. I used the built-in decompiler and saw that in the OpMode class, the gamepads were set to null, whereas in the previous version of the SDK, the gamepads were set to new Gampad() 's.

And if you add the initialization in the constructors, do they work properly in init_loop (i.e., do they return the correct values of the gamepad button states, etc.)?

[Varun Singh]

And if you add the initialization in the constructors, do they work properly in init_loop (i.e., do they return the correct values of the gamepad button states, etc.)?

Yes. They work perfectly normal when I add those in the constructor. I don't even have to press Start-A and Start-B if I had already done it earlier when the app opened. The code in the constructor to create a new Gamepad() does nothing except ensure that I don't get a null gamepad reference. If I already had gamepads defined, then I do not need to press Start-A and Start-B, and if I didn't have them defined before, it is not necessary for me to define them if I am going to use them. (By defined, I mean that they are registered in the driver station and the little white gamepad icon is showing at the top).

[Cheer4FTC]

Thanks very much for reporting this bug and the temporary fix!!

[FTC6389]

Thanks for figuring this out Varun. We are also experiencing this issue.

- The Lazybotts

[mlwilliams]

What I noticed is that the gamepad might be null the first time through the loop but later has a value. Explicitly testing for null solved it without having to create your own gamepad objects. Presumably they start out null but are overwritten soon after:

@Override
public void init_loop() {
  super.init_loop();

  if (gamepad1 == null) {
    telemetry.addData("gamepad1", "null");
  } else {
    if (gamepad1.y) { // Want more delay
      if (!ydown) {
        CurrentDelay += 1.0;
      }
      ydown = true;
  } else ydown = false;      
...
}

[dlevy]

That should be fixed in the beta. Plus you'll also have "USB Reconnect" support.

see: http://ftcforum.usfirst.org/showthre...tor-to-follow)

[mlwilliams]

Yes, and the USB disconnect support is huge. I'm anxious to try out the beta later today with the students. I'll get them to start the robot and yank/replace one USB cable at a time just to see what happens. I believe that many past failures were a result of a USB cable jiggling slightly for just an instant. I suspect it was mainly the OTG cable from the phone to the CPDM but I think when that happened the immediate error was that it couldn't find whatever controller it was trying to access next making it seem like it was a motor controller cable issue.

Another big improvement is the real-time robot battery voltage. I want to put the robot on a stand and run full speed to see how the voltage level is affected.

[dlevy]

In theory the robot will also be able to reconnect after an ESD although I don't think that has been verified.