Skip to content

Allow downloading raw sensor logs#2512

Draft
rafaellehmkuhl wants to merge 1 commit intobluerobotics:masterfrom
rafaellehmkuhl:allow-downloading-raw-telemetry-logs
Draft

Allow downloading raw sensor logs#2512
rafaellehmkuhl wants to merge 1 commit intobluerobotics:masterfrom
rafaellehmkuhl:allow-downloading-raw-telemetry-logs

Conversation

@rafaellehmkuhl
Copy link
Copy Markdown
Member

@rafaellehmkuhl rafaellehmkuhl commented Mar 12, 2026

I'm opening this so we make the binary available for users that need to try it (we had some in both the Discord and forum).

It allows users to download the sensor logs that are stored in Cockpit (the same ones that are used to generate the .ass video overlay file) in both CSV and JSON format.

We probably want to allow users to download it in ASS format as well (maybe allowing them to specify the video resolution to do that).

image

Should be used with care.

Fixes #2238

@rafaellehmkuhl rafaellehmkuhl force-pushed the allow-downloading-raw-telemetry-logs branch from a74e355 to 65c4ecb Compare March 12, 2026 20:09
@ES-Alexander
Copy link
Copy Markdown
Contributor

I'd be more inclined to include this as a tab in the existing telemetry configuration page.

Fragmentation (e.g. "configure telemetry logging over here, but access it in these other places") is hard to document and often confusing/frustrating for users. Would be good if we can revisit more generally how we want the menu to be laid out, so we can try to reduce the steps required to do things, and improve the interface consistency :-)

@rafaellehmkuhl
Copy link
Copy Markdown
Member Author

rafaellehmkuhl commented Mar 17, 2026

I'd be more inclined to include this as a tab in the existing telemetry configuration page.

Fragmentation (e.g. "configure telemetry logging over here, but access it in these other places") is hard to document and often confusing/frustrating for users. Would be good if we can revisit more generally how we want the menu to be laid out, so we can try to reduce the steps required to do things, and improve the interface consistency :-)

I agree on consistency but would say in this case this is indeed a tool, not a configuration, and so would be important to live under tools. There are certainly cases that can be questioned (e.g.: Actions), but this don't seem like one.

@ES-Alexander
Copy link
Copy Markdown
Contributor

I'm less concerned with our current categories than with the usage experience - if you configure your telemetry logging and then want to see the results, you have to go somewhere else, which seems unintuitive.

Actions configuration/monitoring/usage is definitely worse (e.g. make a data-lake variable, copy the ID, go somewhere else to make an Action, repeat if using multiple variables, and then go somewhere else again to view sent MAVLink messages, etc), but it does seem like a similar fragmentation problem (to me at least).

If we want to keep this kind of separation between settings and tools then I think it's important that each one has a button that takes you straight to the other one, so at least you don't have to go looking for other related/important parts of the feature.

@rafaellehmkuhl
Copy link
Copy Markdown
Member Author

I'm less concerned with our current categories than with the usage experience - if you configure your telemetry logging and then want to see the results, you have to go somewhere else, which seems unintuitive.

Actions configuration/monitoring/usage is definitely worse (e.g. make a data-lake variable, copy the ID, go somewhere else to make an Action, repeat if using multiple variables, and then go somewhere else again to view sent MAVLink messages, etc), but it does seem like a similar fragmentation problem (to me at least).

If we want to keep this kind of separation between settings and tools then I think it's important that each one has a button that takes you straight to the other one, so at least you don't have to go looking for other related/important parts of the feature.

Yeah, agree. At the very least a button.

Maybe we should think if keeping the two categories (Settings vs Tools) makes sense at all. Maybe those categories are too broad? Maybe we should categorize by something else? Not sure.

We can make so it lives under /menu/settings/telemetry in the meantime.

@ES-Alexander
Copy link
Copy Markdown
Contributor

Maybe we should think if keeping the two categories (Settings vs Tools) makes sense at all. Maybe those categories are too broad? Maybe we should categorize by something else?

We've discussed this a little in the past, but not reached a conclusion on what they should be. I think at the moment the categories are conceptually understandable (if somewhat haphazardly applied), but aren't actually well-suited to making a streamlined interface, so even if it's possible to figure out where a thing is likely to be found, it's still annoying to actually go to it / between related things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

We should allow users to download the raw telemetry files

2 participants