A breakpoint is a location in your program that you want to watch. The first important concept in remote debugging is the setting of “breakpoints” in your program. Visual Studio Code will also switch into debug mode (as indicated by the Debug icon in the activity bar on the left edge of the window). This command will build and deploy code in debug mode which will configure the RIO to communicate back to your debugger.
Execute the “debug” command instead of “deploy”:
Starting the debugger is almost the same action as deploying code with GradleRIO. You’ll be watching the action as if it’s happening on your screen, but the action is actually occurring remotely on your robot. Your robot program is executing on the RIO, but it will be controlled and monitored by the development environment on your laptop. We call this technique “remote” debugging because it involves a network connection between your programming laptop and the roboRIO.
You can even use the debugger to alter variable values, so novel scenarios can be tested. Since the the debugger can let you see the actual execution, you can also verify that conditionals and loops really execute the way you expect. Remote debugging lets us answer questions like “Did my code even get executed?” or “Did the initialization code really get executed before the periodic code?” or “What were the variable values?”. This technique, called Remote Debugging, is available to you from most modern Java development environments. You could examine the variables and then watch the lines of code execute, one at at time. Imagine a better system that doesn’t require added code, where you could stop time, crack the roboRIO open and see what was going on inside. Monitoring the robot with ShuffleBoard is similar you add output statements to your code. So far you’ve probably been debugging Java code by adding print statements you add code that gives you a peek into the robot’s internal state.
0 kommentar(er)
