Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

FUTURE, blocked by #223: Combine eye tracking, EDA and EEG streams with flight data

オープン
  • 何か問題がありますか？
#238 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
1/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
rust
領域
data-engineering

調査の方向性

Do not start this work: the issue explicitly records future work blocked by #223 and says not to build or design it yet. Read docs/client_meeting_notes.md for the client context; the open decisions include aligning sensor streams, choosing a join key, and deciding how physiological features may be used. Work can begin only after the stated blocker is resolved and the client questions are answered.

索引モデルが issue の本文から書いたものです。

説明

area:ml enhancement needs-info

FUTURE WORK. DO NOT START. This is blocked until a good working real-time model exists (#223, which needs the batch model from #216, targets from #213 and the data from #228 and #229). Nothing here should be built, designed in detail or used to change the telemetry format before then. It exists only to record what the client said so it is not lost.

Blocked by: #223

Is your feature request related to a problem? Please describe.
The client wants flight data, physiological data and (eventually) demographics combined before clustering is automated. Today inference/ only knows the flight telemetry. The client records three physiological sensors in iMotions: eye tracking, electrodermal activity (EDA) and EEG. They are stored separately from the flight data and the demographics.

Describe the solution you'd like
Nothing to build yet. This issue records the future work and what blocks it, so the telemetry design does not rule it out.

  • Decide how streams recorded at different rates are aligned. As transcribed, the sample rates are: simulator about 90 Hz, EEG 256 Hz, EDA 128 Hz, eye tracking 51 Hz. These are unconfirmed, and the Prepar3D export we have is 1 Hz. iMotions synchronizes the timestamps; the client is not sure a common rate exists for clustering.
  • Decide the join key, probably the timestamp plus pilot_id and flight_id (#211).
  • Keep physiological features out of the first clustering (flight data alone is the starting point, per the client), and decide later whether they form groups or only interpret them (compare ADR 0001 for pilot metadata).

Describe alternatives you've considered
Run the clustering on the iMotions computer (#223), where all streams are already synchronized, and read the physiological data from there.

Additional context
Open questions for the client:

  • Will we ever see the physiological data? The client said raw data is large and sampled at separate rates, so it is hard to share. For now the answer is "for starting the work, no".
  • Can instruction timestamps (the standardized in-flight instructions logged in iMotions) be exported on their own? They would give targets (#213) and leg boundaries (#229) without the physiological data. That, and later a model that detects the instruction automatically, is the most valuable piece.

Notes in docs/client_meeting_notes.md.

主要言語
Python
スター
4
フォーク
8
平均マージ
3日 6時間
マージ済み PR（30日）
12

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

oss-slu/PilotDataSynchronization のほかの issue

oss-slu/PilotDataSynchronization の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。