Robots don't quit error message prevents robot from driving

[joelg236]

Hey CD, I have a little bit of a problem.
We have just finished doing most of our code (excluding extra things and autonomous (we haven't finished building so we can't test)) and we are getting an error when running our program on the robot. First of all, our disabled method DOES work. We have it println "disabled". So we know for a fact that it compiles somewhat correctly.

What we do not know is what is actually going wrong. It returns this error message :

java.lang.NullPointerException
[cRIO] at edu.wpi.first.wpilibj.templates.OperatorControl.driving(OperatorControl.java:15)
[cRIO] at edu.wpi.first.wpilibj.templates.MainRobotFunctions.operatorControl(MainRobotFunctions.java:138)
[cRIO] at edu.wpi.first.wpilibj.SimpleRobot.startCompetition(SimpleRobot.java:118)
[cRIO] at edu.wpi.first.wpilibj.RobotBase.startApp(RobotBase.java:156)
[cRIO] in virtual method #10 of javax.microedition.midlet.MIDlet(bci=17)
[cRIO] at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(64)
[cRIO] at com.sun.squawk.imp.MIDletMainWrapper.main(110)
[cRIO] in virtual method #95 of com.sun.squawk.Klass(bci=25)
[cRIO] at com.sun.squawk.Isolate.run(1506)
[cRIO] at java.lang.Thread.run(231)
[cRIO] in virtual method #47 of com.sun.squawk.VMThread(bci=42)
[cRIO] in static method #3 of com.sun.squawk.VM(bci=6)
[cRIO] WARNING: Robots don't quit!
[cRIO] ---> The startCompetition() method (or methods called by it) should have handled the exception above.
[cRIO] Robot Drive... Output not updated often enough.
[cRIO] Robot Drive... Output not updated often enough.

Our actual code is available at here and here. (Yes, we messed with DriverStationLCD as an experiment, maybe that's the problem but we've tried it without it.)

I've been looking around on CD and some others, and all I've concluded from them is that it either has to do with one of our initialized classes (which is most likely - but which one?) or it has to do with the startCompetition() method in SimpleRobot. I've also gathered from looking into operatorControl() that it implements a few methods from robotBase(), might that be the source of the problem(Not the actual methods but missing libraries? We use subversion to transfer code)?

Also, if there is any other errors we are making in the code, suggestions are greatly appreciated. This is our first year doing FRC, and I just started learning Java in the middle of the season (Our programming team was almost down the drain before I came to save the day ) Well anyways, thanks in advance for the help, its greatly appreciated. We just want to get onto bigger and better things than just driving!

Joelg236
Team 4334

[therealman1]

you should do your final code in inerive robot (i know i spelled it wrong dont judge) if that is any help
i say when robot goes "pshyco social" power cycle EVERYTHING (just make sure its saved) that is just restarting, do this for even the robot
P.S. i cant see your code it would help to upload it

[joelg236]

Sure thing.

[NotInControl]

From the first line of your error it seems that you have a null pointer error. Somewhere in your constructors you are not instantiating an object.

Look for any object that you don't first instantiate.

[derekwhite]

The immediate problem is that "joystickAndXbox" is null at line 15 in OperatorControl.java, just like the stack trace says.

This seems impossible, because you definitely initialize it in robotInit(), which does get called.

EXCEPT, you have at least 3 joystickAndXbox fields as part of at least 3 instances of MainRobotFunctions:

1. The one created by WPILib - your actual robot.
2. In robotInit() another one is created.
3. OperatorControl extends MainRobotFunctions, so it IS a kind of MainRobotFunctions too.

I think you just want access to the robot state in MainRobotFunctions from your other classes. Some ways to do that are:

1. Pass a reference to the MainRobotFunctions to the constructors of your other classes, and store a copy in the class.
2. Create a singleton MainRobotFunctions object in MainRobotFunctions, and have a public static getInstance() method that you csn call from anywhere to access it.

[joelg236]

Thanks for your help

I haven't been able to test it out yet, but I am thinking that I fixed it. (Which of course means that it won't work ) What I did was just instead of creating all of the objects in init with new ClassName(); , I made static methods in each called getInstance(); That checks if it has already been initialized or not and if it hasn't, returns the object.

Figuring as I have not tested this out, I am curious about this :

EXCEPT, you have at least 3 joystickAndXbox fields as part of at least 3 instances of MainRobotFunctions:
The one created by WPILib - your actual robot.

Maybe I'm just brain-dead, but I don't quite understand why that is true. I was not aware that WPILib created all of the objects. It seems to me that if that were at all true, EVERY object would be initialized twice (because of the robotInit() method)

And on your third point, I actually thought about that last night on how to call the methods or objects from our main program by just storing a reference in any class that will need to access it. Not difficult

Well since I have not tested, I just have a question of how this error actually occurs (even if the error is because of the nullpointerror I was curious)

    protected final void startApp() throws MIDletStateChangeException {
        boolean errorOnExit = false;

        Watchdog.getInstance().setExpiration(0.1);
        Watchdog.getInstance().setEnabled(false);
        FRCControl.observeUserProgramStarting();
        UsageReporting.report(UsageReporting.kResourceType_Language, UsageReporting.kLanguage_Java);

        try {
            this.startCompetition();
        } catch (Throwable t) {
            t.printStackTrace();
            errorOnExit = true;
        } finally {
            // startCompetition never returns unless exception occurs....
            System.err.println("WARNING: Robots don't quit!");
            if (errorOnExit) {
                System.err.println("---> The startCompetition() method (or methods called by it) should have handled the exception above.");
            } else {
                System.err.println("---> Unexpected return from startCompetition() method.");
            }
        }
    }

That is the error I was encountering, in the RobotBase class. I assume it tries to run startCompetition() (which should loop forever) and if that gets interrupted goes into my error. Something must have been interrupting it, but are you sure it's a nullPointerException? That means somewhat unrelated. At least to me it does.

I'm curious, for all of you guys who have been doing this for a while now, is it normal to try and operate from the ground up, to increase efficiency ? Or maybe even just for the challenge. I was looking into the build scripts too, and since I am .xml illiterate, I really had no idea what kind of dependencies are going on between the build script and the FRC libraries. Yeah, well I just curious what the norm is out there, if you guys just take what's given to you or if you really go down to the deeper stuff. Even though I'm new to all of this, I love a good challenge. Maybe a next year thing.

[derekwhite]

I'll just handle this part:

Originally Posted by joelg236

Figuring as I have not tested this out, I am curious about this :
Maybe I'm just brain-dead, but I don't quite understand why that is true. I was not aware that WPILib created all of the objects. It seems to me that if that were at all true, EVERY object would be initialized twice (because of the robotInit() method)

I was wrong here. WPILib doesn't create the objects automatically. Java ME creates a MIDlet object to start your application - this is different than in desktop Java, which calls the "main()" method of your application class.

The MIDLet created for your robot is is your MainRobotFunctions class (because MainRobotFunctions is a SimpleRobot is a RobotBase is a MIDlet).

Java ME knows to create "MainRobotFunctions" becuase the class name is stored in your manifest.mf file.