Currently, PathPlanner publishes poses and the active trajectory to NetworkTables using double arrays. A key advantage of the WPILib struct format is that it communicates data type (pose/translation/etc) and units (radians/degrees). The 2025 version of AdvantageScope will take advantage of this metadata to make it easier to mix and match fields for visualization, such as allowing 2D and 3D poses to be used interchangeably without user input.
WPILib is planning to switch to struct publishing for Field2d, so we've agreed to deprecate the double array formats in AdvantageScope this year (it will display a warning when they are used, and you need to manually select the data type and units). While PP telemetry is primarily intended for use in the PathPlanner app, updating to struct would ensure maximum compatibility moving forward.
Switching the library code to publish as struct would be very simple since PP is already using the standard NT4 publisher API. Also, the PathPlanner client wouldn't need to handle full struct decoding since it only deals with a limited number of data types; double values just need to be read from a raw buffer at the correct offsets. In regard to dashboard compatibility, see https://github.com/Gold872/elastic-dashboard/issues/91.
Currently, PathPlanner publishes poses and the active trajectory to NetworkTables using double arrays. A key advantage of the WPILib struct format is that it communicates data type (pose/translation/etc) and units (radians/degrees). The 2025 version of AdvantageScope will take advantage of this metadata to make it easier to mix and match fields for visualization, such as allowing 2D and 3D poses to be used interchangeably without user input.
WPILib is planning to switch to struct publishing for
Field2d, so we've agreed to deprecate the double array formats in AdvantageScope this year (it will display a warning when they are used, and you need to manually select the data type and units). While PP telemetry is primarily intended for use in the PathPlanner app, updating to struct would ensure maximum compatibility moving forward.Switching the library code to publish as struct would be very simple since PP is already using the standard NT4 publisher API. Also, the PathPlanner client wouldn't need to handle full struct decoding since it only deals with a limited number of data types; double values just need to be read from a raw buffer at the correct offsets. In regard to dashboard compatibility, see https://github.com/Gold872/elastic-dashboard/issues/91.