This year we’ve switched to Java. We decided to go nuts and try out the new command based template. I depoloyed our first crack at drive code onto last year’s robot with cRio has been re-imaged to the latest. The driver station indicates it has code but the joysticks are unresponsive. Can someone take a look to see if there are any obvious problems?
The last few lines in Netbeans output window show this:
[cRIO] Default IterativeRobot.disabledInit() method… Overload me!
[cRIO] Default IterativeRobot.disabledContinuous() method… Overload me!
[cRIO] Default IterativeRobot.disabledPeriodic() method… Overload me!
[cRIO] java.lang.NullPointerException
[cRIO] at edu.wpi.first.wpilibj.templates.pleasework.teleopInit(pleasework.java:55)
[cRIO] at edu.wpi.first.wpilibj.IterativeRobot.startCompetition(IterativeRobot.java:137)
[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.
I haven’t looked at the code, but whenever you have a null pointer exception, it usually means you’re trying to use something that you, like david said, haven’t initialized yet.
Looking through your code, you don’t have any getInstance() methods in Sweeper, which means you may not everything you need to have a “singleton class.”
A singleton is a class that ensure that only one instance of it is ever created. The getInstance() method should check to see if a Sweeper has already been created. If it has, return that instance, if not, create a new one.
There are examples of how to make a getInstance() method to ensure your subsystems classes are all singletons. These examples can be found in the WPILib Cookbook.
Still no luck, how exactly do you initalize a command? the cookbook says it’s supposed to happen automatically when the joystick is pressed…
David, I have this in Sweeper.java. is this not “constructed” as you say:
public class Sweeper extends Subsystem {
Victor sweep;
public void initDefaultCommand() {
setDefaultCommand(new SweepStop());
}
public Sweeper(){
sweep = new Victor(RobotMap.sweeperMotor);
}
}
Since my last post I added a getInstance method to the DriveTrain subsystem as Mr Lim’s suggested. I also got rid of all subsystems except for the DriveSystem and the commands pertaining to that just to rule out any conflicts. This includes the Sweeper subsystem and commands.
line 55 in pleasework.java is this, doesn’t that need to be there?
public void teleopInit() {
autonomousCommand.cancel();
}
i commented it out to just to give it a try and it gets rid of the null pointer but still no movement in the robot.
Now, the last few lines in Netbeans’ output window show:
[cRIO] Default IterativeRobot.disabledInit() method… Overload me!
[cRIO] Default IterativeRobot.disabledContinuous() method… Overload me!
[cRIO] Default IterativeRobot.disabledPeriodic() method… Overload me!
[cRIO] teleopInit
[cRIO] edu.wpi.first.wpilibj.util.AllocationException: PWM channel 2 on module 1 is already allocated
[cRIO] at edu.wpi.first.wpilibj.PWM.initPWM(PWM.java:t edu.wpi.first.wpilibj.RobotDrive.<init>(RobotDrive.java:110)
[cRIO] at edu.wpi.first.wpilibj.templates.subsystems.DriveTrain.<init>(DriveTrain.java:41)
[cRIO] at edu.wpi.first.wpilibj.templates.subsystems.DriveTrain.getInstance(DriveTrain.java:30)
[cRIO] at edu.wpi.first.wpilibj.templates.commands.DriveWithJoy.<init>(DriveWithJoy.java:27)
[cRIO] at edu.wpi.first.wpilibj.templates.subsystems.DriveTrain.initDeat edu.wpi.first.wpilibj.templates.pleasework.teleopPeriodic(pleasework.java:70)
[cRIO] at edu.wpi.first.wpilibj.IterativeRobot.startCompetition(IterativeRobot.java:145)
[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.
That error suggests that you are trying to initialize two things to the same PWM port. If all you have left are the drive system and sweeper subsystems, I would hazard a guess that either they are both trying to access PWM channel 2, or that somehow one of them (the one that uses PWM channel 2) is being initialized twice (the sort of scenario the singleton class is meant to prevent). Look through your getInstances to make sure they can only run the constructor once, make sure your constructors are private, and make sure there aren’t any accidental calls to constructors outside of the subsystem classes.
Also it’s possible you are trying to create more than one instance of your Sweeper.
Check your code to ensure you are NEVER trying to create an instance of the Sweeper OUTSIDE of your getInstance() method.
If you have:
Sweeper sweep = new Sweeper();
anywhere else in your code, you need to replace it with:
Sweeper sweep = Sweeper.getInstance();
If you try and create multiple Sweepers by running new Sweeper() more than once, you will get the error error you described. The getInstance() method should prevent that from ever happening.
Just an update: I found a new version of the cookbook and followed the examples again and it worked this time. Our robot drives now!
The difference was that the previous version of the cookbook was telling us to declare another object (m_drive) in the command file. in the new cookbook that’s not there. i took it out of my code and it worked. that would explain why i was getting an error from it trying to access the same PWM port twice…