-
Notifications
You must be signed in to change notification settings - Fork 22
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
Generate log files (cockpit standard and video subtitles) #582
Generate log files (cockpit standard and video subtitles) #582
Conversation
2b83c6c
to
b15506e
Compare
30bb006
to
f7718a7
Compare
src/libs/logging.ts
Outdated
const roll = Number(logPoint.data['roll']).toFixed(2) | ||
const pitch = Number(logPoint.data['pitch']).toFixed(2) | ||
const heading = Number(logPoint.data['heading']).toFixed(2) | ||
const depth = Number(logPoint.data['depth']).toFixed(2) | ||
const mode = logPoint.data['mode'] | ||
const batteryVoltage = Number(logPoint.data['batteryVoltage']).toFixed(2) | ||
const batteryCurrent = Number(logPoint.data['batteryCurrent']).toFixed(2) | ||
const gpsVisibleSatellites = logPoint.data['gpsVisibleSatellites'] | ||
const gpsFixType = logPoint.data['gpsFixType'] | ||
const latitude = Number(logPoint.data['latitude']).toFixed(6) | ||
const longitude = Number(logPoint.data['longitude']).toFixed(6) | ||
const secondsStart = logPoint.seconds.toFixed(0) | ||
const secondsFinish = (logPoint.seconds + 1).toFixed(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we include units for these somehow? The indicators already include units, so that seems like it should be doable, hopefully :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will try the discussed approach. If it fits, I will change the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the new approach, each widget register which variables it uses, and this information is used for automatic variable selection (if no user custom selection is made).
6ceca2e
to
f8c3559
Compare
549093b
to
0cdf9c2
Compare
/** | ||
* Variables data can be datalogged | ||
*/ | ||
export enum DatalogVariable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cant we use registerUsage to do this kind of definition for us dynamically ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do that, we lose the ability to add to the logs variables that are not being used by widgets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So.. why not having the log being done by the abstract vehicle class over registerUsage being used over widgets if the idea is to log everything ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logs should be independent from video subtitles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logs should be independent from video subtitles.
They are. It's the other way around. The subtitles are dependent on the logs.
So.. why not having the log being done by the abstract vehicle class over registerUsage being used over widgets if the idea is to log everything ?
The registerUsage approach is just to deliver a good default to users. If they never configured which variables to show in the subtitle overlays, the default ones will be the ones they are using.
0cdf9c2
to
e32773c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was imagining that all the widgets would provide their data, and a class would record them when registered.
With the current design, I don't understand how, for example, arbitrary data would be recorded, like from a custom sensor received as a float value, or anything from a generic indicator.
We indeed do not support the use-case you mentioned in this first patch. The problem with having the widgets registering what to record as a solo approach is that we wouldn't be able to record things that no widget is registering. Remember the widgets are lazy-loaded, so if the widget is not in any view, the variable will not be registered and them the user won't be able to use it. What we could do is to actually do both: have the pre-registered variables and allow widgets to also provide their own, in a custom way. |
e32773c
to
e3a1dec
Compare
@joaoantoniocardoso I'm testing the approach I mentioned and the place where it fit's more is indeed the As I still need to finish the joystick pipeline for this week, do you think it's reasonable if we go with this PR as is and open a an issue and follow with a PR next week adding support for the generic from-wiget registering? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested :)
For the docs, we should mention that the browser will ask the user for permission to download multiple files at once.
Video of the final working version: Screen.Recording.2023-11-27.at.20.05.32.mp4 |
Docs key points:
|
@ES-Alexander I'd advocate to include something like:
|
To be merged after #573.Fix #546
Fix #450