-
Notifications
You must be signed in to change notification settings - Fork 188
add a struct interface + support to send telemetry packets using binary data encoded in struct format #196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
… serializable struct descriptor
…dering logic in TelemetryView
This reverts commit 7a215b1.
…ve encoding logic in TelemetryView
…on in Telemetry view
|
What do you see as the value proposition for dash here? Is the hope to save communication bandwidth for dash or turn telemetry packets into a universal API for third-party FTC telemetry?
I suppose this is what I don't understand in particular. Why should dash care/know about AdvantageScope? |
More of the second one.
AdvantageScope is currently able to accept telemetry packets from FTC Dashboard/its webserver; right now a telemetry packet is just a string key + string value, but this PR also allows packets to include a struct schema and a list of byte arrays encoded according to the schema. AdvantageScope is able to parse that and use published pose data to draw on the field, for example. |
|
My main reason for adding FTC Dashboard support to AdvantageScope was so it could be used as a drop in frontend for existing code bases with the minimum of library and robot code changes. I don't know that it totally makes sense for Dash to support it's own binary struct format? That seems like something better served by dedicated libraries on existing standards, like PsiKit. The current parsing telemetry option does also already allow for struct publishing and parsing, if inefficiently. |
|
The binary struct format here is the same format that WPILib and AdvantageKit and PsiKit already use. |
|
@rbrott bump |
The struct format follows wpilib's struct format.
To be used effectively, we would need to add struct implementations for most of RoadRunner's geometry classes (which I'd be willing to do, especially because they mostly have equivalents in WPIMath already).
The point of this PR is mostly to allow for sending data using structs to AdvantageScope, but I also added support to decode the structured data on the front end. On the frontend it just looks like somebody invoked the
toStringmethod of a Kotlin dataclass (obivously except using the struct schema instead the constructor arguments).