Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions source/docs/software/vscode-overview/debugging-robot-program.rst
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,42 @@ Another way to debug your program is to use print statements in your code and vi

:doc:`NetworkTables </docs/software/networktables/networktables-intro>` can be used to share robot information with your debugging computer. :term:`NetworkTables` can be viewed with your favorite Dashboard or :ref:`OutlineViewer <docs/software/wpilib-tools/outlineviewer/index:OutlineViewer>`. One advantage of NetworkTables is that tools like :doc:`Shuffleboard </docs/software/dashboards/shuffleboard/getting-started/shuffleboard-tour>` can be used to graphically analyze the data. These same tools can then be used with same data to later provide an operator interface for your drivers.

## Common Causes of Loop Overruns

Loop overruns occur when the robot's periodic methods (``robotPeriodic()``, ``teleopPeriodic()``, etc.) take longer than 20ms to complete. When this happens, the Driver Station will display a warning and the robot code may behave unpredictably. Here are common causes:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be an example of the warning so that people searching will find it.


### Blocking Operations

- **Thread.sleep() or wait()**: Never use blocking sleep or wait calls in periodic methods
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Thread.sleep() or wait()**: Never use blocking sleep or wait calls in periodic methods
- **``Thread.sleep()`` or ``wait()``**: Never use blocking sleep or wait calls in periodic methods

- **Synchronous I/O**: Reading files, network operations, or other blocking I/O operations
- **Busy-wait loops**: Loops that repeatedly check a condition without yielding (e.g., ``while(!sensor.isReady()) {}``)

### Excessive Computation

- **Complex calculations in periodic methods**: Move expensive calculations to separate threads or spread them across multiple loop iterations
- **Large data structure operations**: Sorting, searching, or iterating over large arrays or lists
- **Unoptimized algorithms**: O(n²) or worse algorithms running on large datasets

### Excessive Logging or Print Statements

- **System.out.println() in loops**: Console output is slow, especially when called frequently
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **System.out.println() in loops**: Console output is slow, especially when called frequently
- **Print statements (e.g. ``System.out.println``) in loops**: Console output is slow, especially when called frequently

- **Verbose NetworkTables updates**: Updating many NetworkTables entries every loop iteration
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Network tables updates should be fast. What might be slow is getting whatever data that is being put to NT

- **Excessive Shuffleboard updates**: Sending large amounts of data to the dashboard
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Excessive Shuffleboard updates**: Sending large amounts of data to the dashboard
- **Excessive dashboard updates**: Sending large amounts of data to the dashboard (Shuffleboard, Elastic, etc.)


### Hardware/Sensor Issues

- **Synchronous CAN calls**: Some motor controller methods may block waiting for a response
- **I2C or SPI timeouts**: Faulty sensors or loose connections can cause communication timeouts
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **I2C or SPI timeouts**: Faulty sensors or loose connections can cause communication timeouts
- **I²C or SPI timeouts**: Faulty sensors or loose connections can cause communication timeouts

- **USB device enumeration**: Plugging/unplugging USB devices during operation

### Tips to Avoid Loop Overruns

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Use ``Trigger``s to check conditions without a loop.

- Use :doc:`Notifier </docs/software/convenience-features/scheduling-functions>` for operations that need precise timing independent of the main loop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps addPeriodic() is simpler?

- Profile your code to identify slow sections (see :ref:`docs/software/advanced-gradlerio/profiling-with-visualvm:profiling with visualvm`)
- Remove or reduce print statements, especially in frequently-called code
- Cache values that are expensive to compute rather than recalculating every loop
- Use the Driver Station log to identify which periodic method is causing overruns
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommend going one level deeper on how to interpret the log in this case.


## Learn More

- To learn more about debugging with VS Code see this [link](https://code.visualstudio.com/docs/editor/debugging).
Expand Down