###### tags: `研究` # 2023/02/10 ## 質問対策 ### Ｑ１　今回の制作において最も工夫したところはどこか。どのように工夫したのか。 #### 岡村 - オンラインにおける話しやすさを支援する研究として、視線や頷き、表情を提示する研究がされている傾向にあります。そこで、頷き・首傾げの提示だけではなく、閲覧状況の提示もすることで、話しやすさを支援できると考え、導入した点です。 #### 上野 - 画像処理サーバーでの負荷を低減させたことです。画像処理サーバーでは、20人程度の顔画像を逐次的に並列で処理をする必要がありました。処理に時間がかかってしまうと、クライアントに結果を返却するのも遅れてしまいます。そのため、画像処理サーバーでの負荷を低減させるために、研究室のサーバーを増設したり、画像の逐次的に送信する頻度を変えて、レスポンスに遅れが生じないようにしました。 #### 内山 - 資料表示や閲覧人数の仕組みです。まず、スライドを表示するためにパワーポイントでは技術的に難しかったり、ファイルが重かったりと問題がありました。そこでPDFを表示することにした。この際ページ遷移を検出でき、システムでページ遷移を制御できなければならかった。その表示方法として最初に使用したライブラリで描画に時間がかかったりうまくページ遷移ができないと言った問題が発生、最終的にPDF.jsを使うことにして描画処理以外のページめくりなどのライブラリに依らず自力でコーディングすることで解決した。また、閲覧人数の数え方についてDBの構造でどのような構造だとうまく保存とカウントができるようになるかを工夫した。あと、ページめくりの操作に関しても経験があるような直感的わかりやすいUXを意識した ### Ｑ２　今回のプロジェクトにおいて最も困難だったところはどこか。どのように克服したのか。 #### 岡村 - バグ対応です。どういった状況で問題が生じるのか、再現性はあるのかを調査し、問題点を虱潰しで調査していきました。 #### 上野 - 頷きや首傾げの精度を上げること。個々人によって、頷きや首傾げの度合いは異なっている。画像の送信頻度を高めることや、pitchやRollの値を定期的に平均化して閾値を設定しなおす処理を加えたりして、反映に個人差が生まれないようにした。 #### 内山 - 期限内に正常に動かすこと。音声通話時に音声が通じない問題や、期待した動作しないバグが発生することが多くあった。研究室に夜までこもってデバッグしてました。例えば、ルーム入室と資料描画などで非同期処理をしてるために同期ずれが発生して通話や資料表示が正常に行われない事態があった。それぞれの処置が終わるまで待つ状態管理を徹底して解決した ### Ｑ３　今回のプロジェクトを通して得られた知見は端的に言うと何か #### 岡村 - アンケート結果から、聴衆の反応がわかることは、聞いてくれていると感じられ良かったという意見が多かったです。そのため、やはり、カメラOFFの場合でも聴衆がそこにいると常に感じられる機能に価値があると実感しました。 #### 上野 - オンライン通話において、自身のリアクションを何らかの形で伝えることは大事 - アプリケーションを制作して、UIによる効果は凄ましいこと。UIデザインの開発は、開発者の視点だけでなく、利用するユーザーの視点でデザインしないといけない。 #### 内山 - 確実は聴衆の反応がわかる発表者は話しやすくなる - UIはただたくさんの情報を与えるのが最適なわけではない ### Ｑ４　プロジェクトの進捗は計画通りだったのか。あるいは、計画どおりにはいかなかったのか。計画通りに進まなかった事例を教えてください。その場合、計画どおりにいかなかった要因は何か。どのように修正したのか。 #### 岡村 - 計画通りにはいっていません。当初は、夏休み中に利用できるアプリケーションの開発を予定していましたが、バグが多く、その解消ができていなかった。原因としては、フルスクラッチで、０からの開発だったためです。テストの機会を予め増やして予定することで、開発を進めました。 #### 上野 - 計画通りにはいかなかった。 - 実験日にアプリケーションでバグが多発し、参加者が正常にアプリを動かすことが出来ず、実験が中止になることがあった。これは、実験前にアプリケーションの動作テストを入念に行っていなかったことが原因。改善のため、実験の2週間前から、アプリの動作テストを何度も行い、メンバー間でも情報共有も行いながら、バグを取り除くなどの修正をして改善していった。 #### 内山 - いかなかった。まず、夏休みに実験を行う予定だったが、アプリケーションにバグや不完全な点が多く発生して時間までに治しきれなった。後日に実験日を指定して余裕を持ち、具体的な計画を練り、動作テストを何度も行った。 - 二回目の実験も失敗した。処理が重くなり、多人数に対応しきれなった。次回は人数を減らして実施した ### Ｑ５　役割分担について説明してください。また、役割分担は、当初計画したどおりに進捗したのか、あるいは、当初計画どおりにはいかなかったのか。当初計画どおりでなかった場合は、どのようなことが起こったか、それをどのように修正したのか。 #### 岡村 - 岡村が先行論文の調査、実験方法、実験アンケート、実験結果のまとめ・考察等を担当しました。 #### 上野 - 上野がアプリケーションの部分的な設計・開発、顔認識・頷き・首傾げの検出処理 #### 内山 - 内山がアプリケーション全体の設計・開発、DBの設計、インフラ設計、資料閲覧閲覧に関する処理 ### Slide Q. ### Slide2 Q. オンライン授業でどれぐらいの生徒がカメラOFFなのか - 具体的な割合に関しましては分かりませんが、本学を始め、複数の大学でカメラOFFでの受講をルールとして決めていることがあります。 - また、大学生にカメラONとOFFどちらがいいかという旨の質問で、9割の人がカメラOFFを希望したという結果もありました。 ### Slide3 Q. ２Dアバターでどのように頷きを提示しているのか。 - この研究では、複数のタイミングで頷いた場合の調査をしており、実際の聴衆の頷きを反映しているのではなく、頷きのタイミングは先に決めております。一定間隔で頷く、話の区切りで頷くなどです。 ### Slide3 Q. 先行研究をもっと詳しく教えてください - 閲覧人数の提示している先行研究では、領域ごとに閲覧人数を提示し、発表者が見ている領域との離れ具合で遅れているかどうかを推測して、提示しています。 ### Slide4 Q. 頷き・首傾げ・ページ閲覧人数以外の機能は導入しないのですか - 聴衆の状態を顔認証と閲覧状況から推測し、提示する機能を導入し、オンラインプレゼンテーションを行ったのですが、利用に慣れていない上、見るべき場所が多すぎるため、満足に見ることができなかったと回答されました。そのため、本研究では、機能を頷き・首傾げと閲覧状況に絞り、提示することとしました。 ### Slide4 Q. 頷き・首傾げ・ページ閲覧人数を選んだ理由は何か - 第一は、話しやすさの支援となる要素として適していると考えたからです。先行研究でアイコンで表情や頷き、視線を提示するものがありまして、その中で、頷きは明確に話しやすさの支援となることがわかっていました。そのため、頷きと、それに付随して首傾げを提示することとしました。 - また、本研究の大きな特色として、ページ閲覧人数を提示することがあります。 ### Slide5 Q. 各機能のデザインについて、なぜそのデザインにしたのか - 発表者に認知負荷があまりかからないように、パッとみるだけでわかりやすいように言葉ではなく画像・色で表現するようにしました。 ### Slide6 Q. 管理者とは？ - 実験者がログインしてルームの制御を行います。発表者の指定やルームの削除などができます。被験者は選びません ### Slide7 Q. 視覚的に捉えやすい表示とは？ - ボタンにアイコンを置いて視覚的にわかりやすくした。色で区画分けを分かりやすくした。頷き首傾げの数値表示は見出しをアイコンにして数字のフォントを大きくした。閲覧数は目次に置くことで連動してスライド全体と連動してわかるようにした ### Slide8 Q. 技術選定の理由 - SkyWayは研究室に技術スタックがあったから - SFUも同様であり、実績がある。加えてクライアントの負荷が軽くなり、同時接続可能人数が多くなる ### Slide9 Q. なぜサーバーを分けたのか - 各サーバの枠割が違い、直接かかわることもないから - 画像処理に関しては負荷が重たいこともある ### Slide10 Q.　なぜページを分割表示の機能があるのか - 経験則から発表者とは別に自分で自由に資料を閲覧できた方がいいと考えた。ただし、常に2枚見る必要もないので表示を切り替えれるようにした ### Slide11 Q. 資料の描画処理はどのように行っているか - PDF.jsライブラリを利用している ### Slide12 Q. なぜ閲覧状況を直接送らないのか - 個人の閲覧状況だけでなく、全体の閲覧状況を取得する必要があるため ### Slide13 Q. なぜ聴衆には表示しないのか - 聴取に表示することで、聴衆に「同じ目ページを見なけらばならない」「他のページを見てはいけない」などの圧を与えないため ### Slide14 Q.処理結果の中身はなにか - 頷いているか、首傾げをしているか、顔が検出できたかの3つ ### Slide15 Q.顔の検出は何で行っているか - pythonのdlibというライブラリを利用している - 機能には，機械学習，数値計算がユーティリティとしてある。 - 今回はdlibのCNNによる顔検出の機能を使用した。 ### Slide16 Q.物体の位置座標はどのように取得したか - 鼻の頭を原点とした顔の(x,y)座標データを取得するプログラムを組み、鼻の頭から目の間あたりまでの距離を出して、自分の鼻の高さに当てて自力でz座標を算出した ### Slide17 Q.頷きの閾値はどのように設定したか - メンバー3人で、頷きが検知される丁度良い閾値を設定した。 ### Slide18 Q.首傾げは閾値を超えるだけで判定されるのか - 首傾げは左右のどちらかに傾げるだけで判定されるようにしている。頷きは下向き・正面の二段階の変化によって判定させている。 ### Slide19 Q.なぜこのようなアイコンの色にしたのか - 頷きは発表を聞いてくれているという意味でプラスな反応　→　一般的に安らぎや安心感のイメージを人に与える緑色、ゲームUIで良い反応を示す色として使われているなど。 - 首傾げは発表を理解できないという意味でマイナスな反応　→　一般的に不安や寂しさのイメージを人に与える青色、ゲームUIで悪い反応を示す色として使われているなど。 - 顔認識成功はベーシックな反応　→　一般的に中間色として使われやすい黄色にした。 - 顔認識失敗はマイナスな反応　→　注意や回避のイメージをヒトに与える赤色にした。 ### Slide20 Q. リアクションボタンとは？ - zoomや、terms,googlemeetなどに搭載された挙手機能と同じように、参加者が挙手することができるボタン ### Slide21 Q. 数値の更新頻度はどれほどか - 5秒間の頷き・首傾げを算出し、1秒毎更新します。 ### Slide22 Q. 岡村（おかむら）さんのアイコンが非表示になっているのはなぜか。 - 発表者の人は頷き・首傾げを聴衆に伝える必要がないため、アイコンを非表示にしている。 ### Slide23 Q. アプリの同時利用人数の限界は12名なのですか？ - 18名で実験しようとしたところ、バグが発生してしまい、顔認証に不具合が起こってしまいました。そのため、今回の実験では15名を上限とし、発表者6名と当日参加できる三年生と院生のみ参加という形となりました。 ### Slide24 Q. 有意差はありますか？ - 母数が6名と非常に少ないため、有意差は出ませんでした。 ### Slide25 Q. アイコンが聴衆の反応が把握できていないが話しやすくなったと回答している人がいる人が居ると思うが、それはなぜか - 聴衆の詳細な反応を把握できていないため、聴衆の反応が把握できなかったと回答したのではないかと思います。 ### Slide26 Q. なぜ数値だけ、アイコンや閲覧人数に比べて見た人が少ないのか - アイコンと数値はどちらも頷き・首傾げを提示しており、アイコンが個々のものを反映しており、数値は全体をまとめて反映している。しかし、今回は参加者全員をアイコンでまとめてみることができたため、アイコンをメインで見た人が多かったのではないかと思います。 ### Slide27 Q. 誤検知とはどのようなものですか - 聴衆が頷いていないと思っているのに、アイコンが変化することがありました。 - また、カメラと少し離れてしまうと検出できなくなってしまうため、その影響があったと思います。 ### Slide28 Q. 他に利点はありましたか - 発表資料を自由に操作できる点が良かったという意見を頂きました。 ### Slide29 Q. 今後の課題で検知精度を高めることを考えているが、どういう方法があると思いますか - 機械学習を利用した時系列認識手法を利用することで、精度が高まるのではないかと考えております。