Java lang null pointer exception when using a button bound to a command

The current WPILIB simply does not support calling cancel within initialize (although it looks likely that a future version will), because the next command scheduled for that subsystem will crash, so you have to get rid of that line.

When you do that, you not only need to make sure that your isFinished method will pick up on the same condition, but also that execute won’t do anything dangerous if called once on that condition.

I note that you already have problems with race conditions in this code (because the condition could occur between initialize and execute), but I assume you’re most concerned about the case where the last target information from the LimeLight is very stale when the command starts.

1 Like

I think they meant the project directory, where your build.gradle file is. The JVM log file may be named hs_err_pid<pid>.log (where <pid> is the process id). Alternatively, you might find it somewhere like C:\Users\AppData\Local\Temp.

Been searching for a while now, In the build gradle file it just lists stuff like dependencies and plugins with no mention of a log file. For the latter suggestion i couldnt find “Temp” or anything of the sorts in appdata local for this user.

Sorry, not in the build.gradle file itself, I meant in the project directory that contains that file.

Now that I think about it, I’m not quite sure whether @Starlight220 is looking for a JVM log file on your build laptop or on the roboRIO, so I’ll let them clarify.

Yeah you’re right on the dot with the last sentence, and I wasn’t aware that WPIlib didn’t support that function. As for the race conditions, is the conditions that would have happened between initialize and execute the only things that conflict? Looking back at it there are a lot of troublesome coding habits that I employed.

The cancel method does work in most cases, just not inside initialize. (For all I know, there may be some other places it doesn’t work.) I don’t think the WPILIB team anticipated anyone wanting to do that, so they had no test to ensure it worked.

It’s not common practice for commands to cancel themselves, because that sort of decision-making fits neatly into the remit of isFinished. It would be more common for one command to cancel another, but even in that case I would probably just set an AtomicBoolean somewhere (e.g. in the subsystem) for the command’s isFinished method to test. (It’s more robust to handling the case where the command is rescheduled.)

Your tests in initialize and isFinished rely on hasValidTarget, which checks tv (Whether the limelight has any valid targets), but execute uses only tx (Horizontal Offset From Crosshair To Target). I recommend that you move the check of hasValidTarget from initialize to execute.

Unfortunately there’s a race condition here, because no matter in which order you fetch the two values, tx might have been read while there is no valid target. In this specific scenario, it probably doesn’t matter much, so long as you avoid using a very stale value. (Hopefully the limelight updates tx before switching tv from 0 to 1, but I suspect that NetworkTable updates can be re-ordered.)

Nobody expects perfection. The important thing is to keep learning and keep improving. Never stop asking questions.

1 Like

That file would probably be on the RIO and not on the DS, so nvm.

As for the cancel-from-initialize issue, I have a PR open to fix it.

Then the file will likely be in /home/lvuser/hs_err_pid*.log on the roboRIO. Sorry for the misleading advice above.

how do you acess files from the rio?

Personally I use scp, but many people like to install FileZilla. See roboRIO FTP and roboRIO User Accounts and SSH.