Go to Post Adversity should be seen as a challenge and not as an obstacle. :D - waialua359 [more]
Home
Go Back   Chief Delphi > Technical > Programming > Java
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rating: Thread Rating: 2 votes, 5.00 average. Display Modes
  #1   Spotlight this post!  
Unread 14-02-2012, 20:15
joelg236 joelg236 is offline
4334 Retired Mentor & Alumni
AKA: Joel Gallant
no team
Team Role: Mentor
 
Join Date: Dec 2011
Rookie Year: 2012
Location: Calgary
Posts: 733
joelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond repute
Exclamation Robots don't quit error message prevents robot from driving

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 :
Code:
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
Reply With Quote
  #2   Spotlight this post!  
Unread 14-02-2012, 20:20
therealman1's Avatar
therealman1 therealman1 is offline
Registered User
FRC #3044
Team Role: Programmer
 
Join Date: Oct 2011
Rookie Year: 2011
Location: ballston spa
Posts: 14
therealman1 can only hope to improve
Re: Robots don't quit error message prevents robot from driving

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

Last edited by therealman1 : 14-02-2012 at 20:22.
Reply With Quote
  #3   Spotlight this post!  
Unread 14-02-2012, 20:29
joelg236 joelg236 is offline
4334 Retired Mentor & Alumni
AKA: Joel Gallant
no team
Team Role: Mentor
 
Join Date: Dec 2011
Rookie Year: 2012
Location: Calgary
Posts: 733
joelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond repute
Re: Robots don't quit error message prevents robot from driving

Sure thing.

Last edited by joelg236 : 30-10-2012 at 00:07.
Reply With Quote
  #4   Spotlight this post!  
Unread 15-02-2012, 03:37
NotInControl NotInControl is offline
Controls Engineer
AKA: Kevin
FRC #2168 (Aluminum Falcons)
Team Role: Engineer
 
Join Date: Oct 2011
Rookie Year: 2004
Location: Groton, CT
Posts: 261
NotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond reputeNotInControl has a reputation beyond repute
Re: Robots don't quit error message prevents robot from driving

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.
Reply With Quote
  #5   Spotlight this post!  
Unread 15-02-2012, 08:27
derekwhite's Avatar
derekwhite derekwhite is offline
Java Virtual Machine Hacker
no team (FIRST@Oracle)
Team Role: Programmer
 
Join Date: May 2009
Rookie Year: 2009
Location: Burlington, MA
Posts: 127
derekwhite is on a distinguished road
Re: Robots don't quit error message prevents robot from driving

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.
Reply With Quote
  #6   Spotlight this post!  
Unread 15-02-2012, 15:59
joelg236 joelg236 is offline
4334 Retired Mentor & Alumni
AKA: Joel Gallant
no team
Team Role: Mentor
 
Join Date: Dec 2011
Rookie Year: 2012
Location: Calgary
Posts: 733
joelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond reputejoelg236 has a reputation beyond repute
Question Re: Robots don't quit error message prevents robot from driving

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 :
Quote:
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)
Code:
    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.
Reply With Quote
  #7   Spotlight this post!  
Unread 16-02-2012, 12:46
derekwhite's Avatar
derekwhite derekwhite is offline
Java Virtual Machine Hacker
no team (FIRST@Oracle)
Team Role: Programmer
 
Join Date: May 2009
Rookie Year: 2009
Location: Burlington, MA
Posts: 127
derekwhite is on a distinguished road
Re: Robots don't quit error message prevents robot from driving

I'll just handle this part:

Quote:
Originally Posted by joelg236 View Post
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.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 13:04.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi