iruka0913 @ ウィキ

メニュー

2012-12-20T21:11:57+09:00

**メニュー -[[参考論文その1]] -[[Memo システム実装その2]] -[[Memo 画像変換機能の実装]] -[[Memo 歩幅推定(WAA006)]] -[[Memo システム実装]] -[[Memo システム評価実験]] -[[Memo 修士研究の方向性]] -[[Memo 足圧センシング]] -[[Memo 関連学会/ジャーナル]] //-[[Memo EUC2012発表原稿]] //-[[Memo 英語プレゼンテーション]] //-[[Memo ESS2012発表原稿]] -[[トップページ]] //-[[Memo 合同研究発表会]] //-[[Memo プロポーザル構成]] //-[[Memo プロポーザル発表]] //-[[Memo 投稿論文概要]] //-[[Memo 中間審査会原稿]] //-[[プラグイン紹介>プラグイン]] //-[[まとめサイト作成支援ツール]] //-[[メニュー]] //-[[メニュー2]] ---- //**リンク //-[[@wiki>>http://atwiki.jp]] //-[[@wikiご利用ガイド>>http://atwiki.jp/guide/]] // リンクを張るには "[" 2つで文字列を括ります。 // ">" の左側に文字、右側にURLを記述するとリンクになります //**更新履歴 //#recent(20) &link_editmenu(text=ここを編集)

memo EUC2012発表原稿

2012-11-26T14:13:51+09:00

memo 英語プレゼンテーション

2012-11-17T14:59:31+09:00

* 英語プレゼンテーションの極意 ** スライドデザイン - ヘッダ（セクションタイトル，トピックタイトル） - メッセージ - 視覚資料 ---- ** 基本的な英文法 *** 代名詞と名詞 - 対象をはっきりと特定する - "this", "that", "it"の内容を明確にする -- This is... → This figure is... -- This tells us... → This chart tells us... *** 発表原稿の注意点 - 堅苦しい表現は避けるため，一人称（We）や二人称（You）を使う -- 直接聞き手に語りかけるようにする *** 文章の量 - スライド資料に英文を載せる場合，1文は7ワード以内 - 原稿では，17ワード以内 *** 時制 - 原則として，プレゼンテーションでは「現在形」「過去形」「未来形」しか使わない *** 態 - できる限り「能動態」を使うようにする． -- 受動態よりも能動態のほうがポイントをダイレクトに際立たせる -- ×Last year, many products were introduced by our company. -- ○Last year, our company introduced many products. *** 数字 - 基本的に1～9までの数字は文字で書く（スペースや視覚的に考えて数字のほうがいい場合もある） - 金額，パーセント，少数は数字で書く *** about ≠「約」「およそ」 - approximately - around ---- ** 構文作成テクニック *** 原稿とスライド作成にあたっての基礎 - 発表原稿：簡潔で自然な口語体を使う．センテンスを完結させる必要がある．We,Our,You,Yourという表現を頻繁に使う． - 発表スライド：ビジュアルで簡潔な英語を使う．センテンスとしては不完全であっても，ポイントが明確に表現されるように書く． *** 主語+動詞+目的語 - 日本語を直訳してはいけない．多すぎる情報は聞き手の理解を妨げる． -- まず，その文のキーワードを英語で考え，主語を決定する． -- 次に，どんな動詞を置いたら適切かを考える． -- 最後に，適切な目的語か修飾語を考える． -- 当たり前の情報は省く（文脈で十分理解できる単語部分） *** 発表スライドでの簡潔な表現 - 必ずしもセンテンスを成立させる必要はない -- 35% Sales Increase (簡潔な書き方) -- Sales increased by 35% (センテンス形式の簡潔な書き方) *** シソーラスの活用 - シソーラス＝類義語，反意語辞典 - 適切な表現を簡単にすばやく見つけることができる *** 構文や情報の一貫性を持つ - 複数の内容を箇条書きに指定並べる場合には，構文・時制・表現を統一する - New Networking Strategies:~ ___ *Adding more terminals ___ *Installing new security software ___ *Upgrading networking software *** 文章を作成する際の注意点 - 話し言葉と書き言葉を区別する -- 発表原稿は自然な話し言葉で書くことが大切． - 否定文は避ける -- 状況を最も適切に表す肯定表現に置き換える．肯定文の方が読みやすい． -- ×Profit didn't increase~ 〇Profit decrease. (was flat) -- ×The market campaign is no longer continued. 〇The market campaign is discontinued. (is over) -- ×The test results were not good. 〇The test results were poor. *** 絶対的な表現や曖昧な表現をあまり使わない - 絶対：absolutely, always, never, allなど - 曖昧：sort of, kind of, It seemsなど - almostをつけると避けられる：almost impossible, almost every timeなど *** 長い文や複雑な文を避ける - シンプルな発表原稿にするためには，関係詞を使わないのが一番早い． - 主語+動詞，主語+動詞+目的語． - 従属節(thoughなど)は後に持ってくる． *** 英語プレゼンテーションの構成 - 各セクションとトピックで全体的な概念（結論）のポイントを最初に述べてから細部へ移る． ---- ** 発表原稿の作成 *** 表現に変化をつける - 使用する英語表現を厳格に統一せず，表現に変化を持たせると参加者を飽きさせない -- 別表現や強弱をつける *** プレゼンテーションの導入 - 伝えるべきことは2つ：「あなたは誰」で「これから何を話そうとしているか」 -- ①プレゼンテーションの始まりを告げる --- Hello, every one. --- I would like to start the presentation. --- Let me begin the presentation. -- ②自己紹介する --- 名前/所属 -- ③アウトラインについて話す --- Today, we will talk about...(本日お話しすることは…) --- My point is...(お話しするポイントは…) --- Our goal of this study is...(この研究のゴールは…) --- In this presentation, I'd like to emphasize...(強調したい点は…) -- ④プレゼンテーションの構成について話す --- We will conduct the presentation in the following order: --- First/ First of all/ Firstly, we will talk about...(最初に…) --- Then/ Second/ Secondly, we will discuss...(次に/2番目に…) --- After that/ Third/ Thirdly, we will mention...(そのあとに/3番目に…) --- Lastly/ Finally/ Forth/ Fourthly, we are going to refer to...(最後に/4番目に…) *** セクションイントロのまとめかた - 各セクションの最初は導入に当てる -- In this section, I will talk about... *** 不要な接続詞は使わない - 英語文では，論理的に，順を追って，段落を書いている限り，接続詞はさほど必要ない - 接続詞の用法に注意 -- Then, Therefore, And, But, However, Thusなど -- 特に，Butから文章を始めないようにする．否定的なイメージを与えてしまう． -- その他：in addition to, as well as, not only, too, by the way, still more, further, furthermore, moreover, in the least, at allなど *** トピックポイントを伝える - My first/ Second/ Next/ Third/ Fourth/ Last Point is about...(～番目のポイントは…) - I will talk/ explain/ describe/ illustrate/ tell you/ speak about...(についてお話します) - I will begin with...(最初に～についてお話します) - We believe that...(～と思います) - We found that...(～ということが明らかになりました) - Our research concluded that...(～という研究結果が得られました) - Our research shows that... *** 資料を説明する - 具体例をご紹介しましょう -- Let me show you some example. -- For instance/ For example, ... - このデータをご覧ください -- Please take a look at these figures. - この部分をご覧ください -- Please look at this area. - この数値をご覧ください -- Can you see this figure? - このグラフによると，…ということが明らかです． -- This graph shows ... -- This graph indicates ... -- This graph tells us ... -- This graph explains ... -- This graph illustrates ... - このように，… -- As you can see from this chart, ... -- As the data indicate ... *** 結論としてポイントを繰り返す - このデータが明らかに示すことは，… -- These data clearly explain ... -- We believe that the data support our point, which is ... - その結果（数値，データ）が示すように，… -- As the figure indicates ... -- As the data shows ... *** 参加者の理解への確認をとる - このセクションを良く理解いただけたでしょうか． -- I hope you understand this section well. *** セクションをまとめる - つまり，… -- Overall, ... -- As a whole, ... - …のように結論いたします -- We conclude ... *** 話題の転換・つなぎ - いままでご説明してきたことは，… -- Up to here, we talked about ... -- So far, I explained ... - 次のポイント/セクション/トピックに移ります． -- Let us move to the next topic. -- Now, we are going to the next section. ---- ** 使えそうな表現 - 話す/説明する -- talk -- explain -- describe -- illustrate -- tell -- speak - 順序を表す -- To begin with -- For starters -- Fist of all - 考えを述べる -- We believe that... -- We understand that... -- We think that... -- Our under standing on this matter is... - 理由を述べる -- That's because... -- The reason for that is... -- The reason why ... is ～ - 言い直す -- In other words, -- Let me explain further about it. -- I will explain about it further. - 話題転換 -- Let me move to the next topic. (では，次のトピックに移ります)

memo システム評価実験

2012-11-05T00:18:31+09:00

** システム基礎機能評価実験 *** プロジェクタパラメータ計測実験 - ''実験目的'' -- 投影距離と投影スクリーンサイズの関係式を導出する -- 投影距離Dのときの原点W(0,0,0)としたスクリーン座標（位置/サイズ） --- 軸の入れ替え/移動と拡大率変更 - ''実験設備'' -- テーブル -- 壁 -- 水平検出器（テーブルが水平か確認する） - ''実験手順'' -- 距離を10段階程度に分割 -- 距離D(i)におけるスクリーンサイズを記録する：縦，横 -- スクリーンの位置ずれについても記録する：水平に置いたとき，スクリーンが上目に投影されるようになっている気がする - ''ポイント'' -- 光源から直線的に投影されるわけではなさそう --- 投影する画像：背景原色のグリッドライン入り *** Wearable Comfort Rating Scale(2012.10.26) - 6項目の質問から成る：0(low)～10(high) - ''① Emotion｜印象'' -- 印象，見た目，緊張，イライラ -- Emotions, concerns about appearance and relaxation -- I am worried about how I look when I'm wearing this device. I feel tense or on edge because of wearing the device. -- このデバイスを装着することで，周りにどう見えるか気になる．装着することで緊張したりイライラする． - ''② Attachment｜装着'' -- 身体に装着する際の物理感覚 -- Physical feel of the device on the body, attachment -- I can feel the device on my body. I can feel the device moving. -- 身体にデバイスが装着されていることが気になる(気付く)．デバイスが動くのを感じる． - ''③ Harm｜痛み'' -- 物理的な影響，身体への害 -- Physical effect, damage to the body -- The device is causing me some harm. The device is painful to wear. -- デバイスは身体に害をもたらす．装着することで痛みを伴う． - ''④ Perceived Change｜感覚の変化'' -- 物理的な感覚の違い，動揺 -- Feeling physically different, upset -- Wearing the device makes me feel physically different. I feel strange wearing the device. -- デバイスを装着すると物理的に異なる感覚になる．違和感を感じる． - ''⑤ Movement｜動き'' -- 物理的な動きへの影響 -- The device physically affects movement -- The device affects the way I move. The device inhibits or restricts my movements. -- デバイスが動き方に影響を与える．デバイスは動きを阻害，制限する． - ''⑥ Anxiety｜不安'' -- 心配，安全，信頼性 -- Worry about the device, safety, and reliability -- I do not feel secure wearing the device. -- デバイスを装着することに不安を感じる． ** ユーザ評価実験 *** 手順 *** 評価項目 - 定量データ分析 -- 提示歩幅通りに歩行できたか -- その他の歩行パラメータに影響があったか --- 左右の歩行周期 --- Step Regularity --- Step Symmetry - アンケート -- 投影画像に関するアンケート -- 装着感アンケート：Wearable Comfort Scale -- システム利用負荷アンケート：NASA-TLX

参考論文その1

2012-11-03T20:55:11+09:00

memo 歩幅推定(WAA006)

2012-10-28T17:38:40+09:00

* Memo WAA006-010 *** モデル近似による歩行速度推定(2012.10.28) - ''方法'' -- 歩行特徴量を用いて1次回帰式によるモデル近似を行い歩幅(歩行速度)を推定する． -- リアルタイム処理では，一歩ごとの歩行特徴量から回帰式にフィッティングして算出する． - ''特徴量の候補'' -- 鉛直加速度成分の最大最小の差分値d(v) --- SL = d(v) * a + b -- 進行加速度成分の最大最小の差分値d(h) --- SL = d(h) * a + b -- 歩行周波数f（1sあたりの歩数） --- SL = f * a + b - ''収集すべきデータ'' -- 鉛直加速度データ -- 進行加速度データ -- 歩行周期(FSRによる着地イベントの間隔) -- 一歩ごとの鉛直加速度データの最大最小の差分値 -- 一歩ごとの進行加速度データの最大最小の差分値 -- 歩行周波数(歩行周期の逆数) -- 平均歩幅(歩数と距離から近似的に算出) - ''実験設備'' -- 直線で歩行してもらう -- 歩行開始と終了を記録する必要がある --- IRセンサで自動記録するシステムを作る --- 歩き出しと終わりはとる必要があるだろうか ⇒ 実際の実験では存在する -- センサの装着位置 --- 前腰部中央 --- 胸部中央(プロジェクタ姿勢推定用で代用可能かどうか検証) - ''データ収集システム構成'' -- 処理端末 --- Android or ノートPC -- センサ類 --- WAAセンサ2個 --- FSRセンサモジュール2個 --- IRセンサ2～4個(歩行開始/終了 + 一定速度になってから開始/終了) *** 加速度波形の積分による速度計測 - 波形：横軸が時間で縦軸が対象波形の場合 -- 加速度波形：歩行開始時にプラスの山ができる，中間では山なし，歩行終了時にマイナスの山ができる． -- 速度波形：歩行開始時にプラスの勾配ができ，中間ではそのまま持続，歩行終了時にマイナスの勾配ができる． -- 変位波形：歩行開始時にゆるやかなプラスの変化，中間では一定勾配でプラスされ続け，歩行終了時にゆるやかなプラス変化で一定変位に収束する． - 歩行時の加速度波形： -- 幾つも山ができる：着地時の振動によるものが多い気がする -- つまり，上記の加速度波形の形状に加えて，振動分の波形が合成されて出力される． -- 本来なら，体幹速度は開始時に上昇し，そのまま一定のはずだが，実際にやってみると常に増加する傾向にある：完全に誤差：着地時の加速度のせいではないかと予想． - 加速度の積分による速度・変位の算出方法 ++ 時間積分 ++ FFTによる周波数分布に基づく積分 - [[直接積分時のフィルタリング:http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1123848156]] - 相当難しいテーマのようだ． -- つま先の加速度で推定を行うという手法には少し理解が深まった． -- 一歩ごとに加速度のプラスの山，マイナスの山から速度・変位を求める． -- そのためには着地時の振動による加速度を除去する必要がある -- 着地時はやはり高周波成分であるはずなので，ローパスをかけてみる． *** WAA006へのコマンド送信手順 + ''センサのリセット：%%%"stop all\r\n"%%%'' -- %%%"\r\n"%%%は，javaでは，''System.getProperty("line.separator")'' or ''System.lineSeparator()'' で取得(後者はJDK1.7) -- Replyとして%%%"OK\r\n"%%%が返ってくる + ''センサの時刻同期：%%%"sett %02d%02d%02d%03d\r\n"%%%'' -- それぞれに，時/分/秒/ミリ秒，が指定桁分入る -- Replyとして%%%"OK\r\n"%%%が返ってくる + ''センサの計測開始：%%%" +000001000 10 5 0\r\n"%%%'' -- 指定センサを，秒後から，単位で，回平均化，回出力を開始する -- : %%%"sens"%%%(加速度)~ : [+]オプションで現在からn秒後を指定 (フォーマットはHHMMSSmmm)~ : サンプリング間隔[ms] (2～60000)~ : 平滑化回数 (1～127)~ : 出力回数 (1～999999，0の場合はSTOPされるまで出力) -- テキストモード出力の場合，*が4ms以上でなければならない：サンプリング周波数最大 = 250Hz + ''センサの計測結果：%%%"sens,,HHMMSSmmm,,,"%%%'' -- HHMMSSSmmm: 計測時刻~ : 加速度X軸の値[mG]~ : 加速度Y軸の値[mG]~ : 加速度Z軸の値[mG]~

memo システム実装その2

2012-10-24T16:40:16+09:00

* ''今後やるべきTODOリスト'' - 2012.10.20以降の修士研究におけるTODOリストをまとめる． - 11月の初めには実験を行う必要がある． *** ''TO DO List(2012.10.24)'' - ''① システム実装'' -- 基盤ソフトウェアフレーム実装 --- 姿勢推定モジュール：慣性センサとのBluetooth通信スレッド --- 画像変換パラメータ計算モジュール：OpenCVのメソッド利用 -- 歩幅提示アプリケーション実装 --- センサ通信モジュール：Bluetoothによる複数スレッド --- 歩行速度推定モジュール：WAA006からのデータを使って計算 --- 歩行周期検出モジュール：2つのArduinoからのイベントデータを管理 --- 歩幅位置計算モジュール：実世界座標系での話 --- 画像描画モジュール：SurfaceView上でOpenCVのメソッドで描画 -- 歩行リズム提示アプリケーション実装 --- - ''② システム予備実験'' -- 健常者でシステムを利用してもらう - ''③ ユーザ評価実験'' -- キャリブレーション歩行実験 -- 歩幅提示機能の短期効果検証実験 --- 通常歩行 --- 投影ありで歩行 -- 歩行リズム提示機能の短期効果検証実験 --- 通常歩行 --- 投影ありで歩行 --- 聴覚リズムありで歩行 -- データ分析 --- 平均歩幅の比較：歩幅提示機能の効果 --- 平均歩行周期/分散の比較：歩行リズム/歩幅提示機能の効果 --- 加速度データ分析による周期性/円滑性/対称性の比較：歩行リズム/歩幅提示機能の効果 --- Wearable Comfort Scaleのアンケート分析：システムの装着感の評価 --- NASA-TLXのアンケート分析：システム利用による負荷の評価 --- 提示情報に関するアンケート：見易さ，歩きやすさ，利用の簡単さ，利用したいと思うか，など --- インタビューの分析 - ''④ システム基礎評価実験'' -- 実世界投影精度の評価 --- 投影位置，サイズの誤差を計測 -- 歩行周期検出精度の評価 --- 直線を歩行してもらい，歩数をカウントしてオフラインで数を比較 -- 歩行速度推定精度の評価 --- トレッドミル -- 画像安定化精度の評価 --- - ''⑤ 修士論文執筆'' ** %%%''歩幅提示アプリケーションの実装''%%% *** ① アプリケーション統合：StrideLengthProjectionManager - 各モジュールを統合して，アプリケーションとして完成させる． - Managerが各モジュールを起動．モジュール間の通信にはハンドラを用いる． *** ② 歩幅推定モジュール：StepLengthEstimationManager - ユーザの歩行距離を推定して変数として保持しておく． - スレッドループ内で，センサ通信モジュールが保持する加速度データ変数にアクセス． - 歩幅（歩行距離｜歩行速度）を推定するメソッドを毎回読み込む． *** ③ 着地イベント検知モジュール： - 着地イベント発生時に歩幅画像の左右を切り替える：どちらの足が立脚・遊脚か， - ハンドラを介して着地イベントが通知されたら，ハンドラを介して支援情報生成モジュールに切り替えタイミングであることを通知． *** ④ センサ通信モジュール：SensorCommunicationManager - 各センサとのBluetooth通信の管理を行う． - Managerから3つのスレッドが生成される：3種類のデバイスと通信：加速度センサ｜足圧センシングモジュール×2 - 加速度センサ(WAA006) -- 3軸加速度データをSensorCommunicationManagerのフィールド変数に格納する． - 足圧センシングモジュール(BluetoothMate) -- 着地イベントが送信されてくる．イベント検知時にハンドラを介して着地イベント検知モジュールに通知する． *** ⑤ 画像描画モジュール - 画像を実際にビューに描画する． - 支援情報生成モジュールの計算した画像パラメータ（足の左右，描画位置・サイズ，ホモグラフィ行列）を使って，対象画像をサーフェイスビューに描画する． *** ⑥ 支援情報生成モジュール - 提示する歩幅画像のパラメータを計算する． - スレッドループ内で，現在の足（左or右）の画像を使って，現在の歩行速度に従って次に出す歩幅を位置を管理． - 次に出す歩幅の位置が決まったら，位置・大きさのパラメータを基盤フレームワークに渡す． - 返ってきた画像パラメータ（描画位置，大きさ，ホモグラフィ行列）をフィールド変数に保持する． ---- ** %%%''歩調提示アプリケーションの実装''%%% *** ① アプリケーション設計 - a *** ② アプリケーション統合 - a ---- ** %%%''基盤フレームワークの実装''%%% *** ① フレームワーク統合 - 各モジュールを統合して，フレームワークとして完成させる． - Managerが各モジュールを起動．モジュール間の通信にはハンドラを用いる． *** ② プロジェクタ姿勢計測モジュール：ProjectorPostureMeasurementManager - スレッドループ内で，サンプリング間隔に従ってSensorCommunicationManagerのセンサデータから姿勢を推定する． - 姿勢データ（ロール，ピッチ，ヨー）はフィールド変数に保持する． - 歩行時：ジャイロ積分による姿勢計算 - 静止時は加速度センサの傾斜利用法にする？ *** ③ センサ通信モジュール：SensorCommunicationManager - センサWAA010とのBluetooth通信の管理を行う． - Managerからスレッドが生成される -- 3軸加速度データをSensorCommunicationManagerのフィールド変数に格納する *** ④ 画像変換パラメータ計算モジュール - 引数で得た画像の実世界座標系での位置，大きさ+プロジェクタ姿勢をもとに補正処理を行い，デバイス座標を返却する． - 補正1) 位置・大きさの補正処理 - 補正2) 台形補正 - 補正3) 画像安定化 *** ⑤ 台形補正機能設計 - a *** ⑥ 位置・サイズ提示機能設計 - a *** ⑦ 画像安定化機能設計 - a ---- ** %%%''システム評価実験の実施''%%% *** ① 実験日時の設定 - a *** ② 実験内容の設計 - a *** ③ 実験結果分析の設計 - a

Memo 画像変換機能の実装

2012-10-23T21:08:40+09:00

**画像変換についてのメモ - ''OpenCvによる画像変換の流れ(2012.10.23)'' -- ''基本的な処理方針'' --- サーフェイスビューでViewを作成 --- 画像はBitmapで読み込み --- BitmapをMat型に変換 --- Mat型の画像データをOpenCVのメソッドで処理 --- Mat型のデータをBitmapに再変換 --- canvasのメソッドでViewに描画 -- ''OpenCVメモ'' +++ 使用しているのはAndroid OpenCV2.4.0 +++ プロジェクトとライブラリのリンクはProperty->Android->Libraryから．Build-Pathからだと上手くいかないらしい~ [[Eclipseでのプロジェクト生成の解説:http://dokumaru.wordpress.com/2012/05/02/how_to_build_face_detection_sample_with_opencv_2_4_for_android/]] +++ Bitmap<-->Matの変換は注意が必要：[[BitmapToMat & MatToBitmapを使う際の注意点 OpenCV Java API for Android:http://micchysdiary.blogspot.jp/2011/10/bitmaptomat-mattobitmap-opencv-java-api.html]] +++ ホモグラフィを見つけるメソッドはfindHomography(src, dst)メソッド．~ MatOfPoint2f::src :入力画像の座標群~ MatOfPoint2f::dst :出力画像の座標群~ 帰り値 :ホモグラフィ行列 +++ 変換を適用するには別のメソッドが必要： - ''ハードウェアアクセラレーションの検討(2012.10.23)'' -- [[ハードウェアアクセラレーションを使用する(1):http://techbooster.org/android/application/7054/]] - ''画像変換の流れ'' ++ プロジェクタの姿勢P(r,p,y)を計測し，回転行列Rを求める ++ プロジェクタの設置高Hと姿勢Pから，投影距離Dを求める ++ プロジェクタ設置位置を世界座標系原点W(0,0,0)として，X方向に距離Dの位置A(D,0,0)に投影したと仮定する ++ そのときのプロジェクタ座標系における画像Aのある頂点r0i(xi,yi)を世界座標系の位置Aに投影した際の座標qwi(D,Yqi,Zqi)を，事前に求めておいた行列αにより求める ++ 行列Rを用いて座標qwiを回転変換し，座標q`wiを求める ++ 原点Wと座標q`wiを結んだ直線l0iを求め，平面Z=-H（地面）との交点である座標q``wiを求める ++ 座標q``wiを行列Rの逆行列R^-1を用いて回転変換し，座標q```wiを求める ++ 座標q```wiを，位置Aでの投影面上での2次元座標系に変換し，座標q```2dwi(Y```wi,Z```wi)を求める ++ 座標q```2dwiを行列αを用いて(ココ曖昧)デバイス座標系に変換し，座標r`0i(x`i,y`i)を求める ++ この処理を4頂点について適用し，座標r`01, r`02, r`03, r`04を求める ++ 画像Aの元の4頂点の座標r0iおよび画像Aの床上に投影されている4頂点の座標r`0iの合計4組の座標（8つ）から，8元一次方程式を解き，ホモグラフィ行列における変換係数a～hを求める ++ 変換係数a～hから，ホモグラフィ行列Hmatを生成する ++ ホモグラフィ行列Hmatの逆行列H^-1matを求める ++ 画像Aの元の座標r0iを行列H^-1matで変換すると，台形補正済みの座標t0iが得られる - ホモグラフィ行列の求め方 -- [[OpenCVのホモグラフィ行列の求め方のページ:http://tessy.org/wiki/index.php?%A5%DB%A5%E2%A5%B0%A5%E9%A5%D5%A5%A3%A4%CE%B7%D7%BB%BB]]：9個目はスケーリングの固定のため1にしているらしい． > 射影変換とかホモグラフィと呼ばれる方法で座標変換できます。~ 変換前の座標を(X,Y)とし、変換後の座標を(x,y)とおくと~ 　~ 　(x,y) = ( (A*X+B*Y+C)/(G*X+H*Y+1) , (D*X+E*Y+F)/(G*X+H*Y+1) )~ 　~ という変換式です。文字A～Hは「画像の平面内の四頂点の座標」から決まる定数です。~ 　~ A～Hの求め方は、少々面倒ですが8次元連立一次方程式を解いて求めます。~ 変換前の４点の座標を(X1,Y1)(X2,Y2)(X3,Y3)(X4,Y4)とし、変換後の４点の座標を(x1,y1)(x2,y2)(x3,y3)(x4,y4)とすると、連立方程式は次のようになります。~ 　~ X1*A + Y1*B + C - x1*X1*G - x1*Y1*H = x1~ X1*D + Y1*E + F - y1*X1*G - y1*Y1*H = y1~ X2*A + Y2*B + C - x2*X2*G - x2*Y2*H = x2~ X2*D + Y2*E + F - y2*X2*G - y2*Y2*H = y2~ X3*A + Y3*B + C - x3*X3*G - x3*Y3*H = x3~ X3*D + Y3*E + F - y3*X3*G - y3*Y3*H = y3~ X4*A + Y4*B + C - x4*X4*G - x4*Y4*H = x4~ X4*D + Y4*E + F - y4*X4*G - y4*Y4*H = y4~ 　~ 手計算するのは大変なので、この方程式を行列で書き直してエクセルに計算させれば簡単に定数A～Hが求まります。<

Memo システム実装

2012-10-20T20:38:28+09:00

** システムの実装に関するメモ - 足圧センシングモジュール第1号完成(2012.10.12) -- Arduino-Pro-miniで感圧センサを制御，BluetoothMateで通信 -- はんだ付け完了．リチウムポリマー電池で動作確認．PCで動作確認．Androidで動作確認． -- 電源は入っているのにデータが送られてこなくて焦る．通信速度変更が反映されていなかったぽい．~ CMDモードで通信速度の設定をしたら，RESETかもう一度プログラムを入れ直さないといけない?? -- ケースはTALESEA的なものを作る．もう少し柔らかい素材はないだろうか． -- どうやって靴に取り付けるか考える．個人靴に装着する場合を考えて，中敷きにくっつけられないか -> ダイソーで中敷き購入． - 画像の描画 -- 候補：OpenCV, OpenGL ES -- 最初からOpenGLは利用可能なようなので，そちらにするか．高速描画もできるようだし． - 画像描画に要求される項目 ++ 画像が描画できる ++ 画像を移動させることができる ++ 画像を変形させることができる（射影変換） - 画像をどうやって台形補正するか -- CanvasのdrawBitmapMesh関数を使う：[[Android(Java)を始める – 画像の自由変形:http://sakef.jp/blog/2011/02/android04_image_translation/]] -- OpenGL ESで視点を変える：[[iPhone上でOpenGL ESを使って台形補正に挑戦（その2）:http://studio.tgl.jp/blog/?p=828]]~ 端末姿勢(r,p,y)に対して，逆変換(-r,-p,-y)をかけると台形補正画像が完成する - 画像変換のコンセプトメモ(2012.09.21) -- ある画像Aを大きさS(Sx,Sy)cmで位置L(Lx,Ly)cmに投影したい -- そのためには，現在のプロジェクタの高さHcm，姿勢(R,P,Y)degを把握する必要がある -- サイズを決める｜位置を決める｜画像を回転させる：どの順番で行えば良いか？ +++ サイズを決める：実世界での投影スクリーンサイズ(垂直投影面)から決定される（H + (R,P,Y)） +++ 位置を決める：床に投影され歪み，それが台形補正されて変形することを考慮しなければならない +++ 回転させる：あるサイズのものを回転させ台形補正し，それを投影した時に（投影スクリーン内での比が）同じサイズになるのか⇒恐らくなる - OpenGL ES参考サイト3(2012.09.21) -- [[OpenGL ESで2D描画やるでー:http://d.hatena.ne.jp/fkm/20110917]] -- [[OpenGL ESで2D描画やるでー2:http://d.hatena.ne.jp/fkm/20110918]] -- [[OpenGL ESで2D描画やるでー3:http://d.hatena.ne.jp/fkm/20110926/p2]] - 歩行周期センシングモジュールのプロトタイプテスト(2012.09.21) -- 靴にUNOをくくりつけてUSB電源でテスト．感圧センサと足の間に中敷き入れずに試す． -- きつめの靴で試したのでどうかと思っていたが，上手くいった． -- あとは基板に回路を作ってArduino Pro-miniとはんだでくっつけて完成． - 外部電池によるArduino Pro-miniの稼働(2012.09.21) -- 配線は，&color(red){赤：VCC}，''黒：GND'' -- ボックスを使ったボタン電池*2：6V出力．無事に稼働を確認．接続し，Android-BluetoothChatにセンサ値（今回はセンサなし）を送信した -- リチウムポリマー電池(400mAh)：3.7V出力．接続端子が悪くて一瞬焦る．無事に動作確認． -- リチウムポリマー電池(110mAh)：3.7V出力．無事に動作確認． - 足圧センシングモジュール部品購入(2012.09.21) -- 単3電池2本で5V出力する電池ボックス（昇圧回路込み） -- リチウムイオンポリマー電池400mAh (SFE-PRT-10718) -- リチウムイオンポリマー電池110mAh (SFE-PRT-00731) -- 2032型コイン*2個直列電池ホルダー6V出力スイッチ付き -- 小型のリチウムイオン電池充電器（マイクロUSBタイプ） - OpenGL ESはTexture表示が遅い?? -- [[OpenGL/ESによる2D描画の高速化 (update-6):http://suzukiplan.blogspot.jp/2012/07/opengles.html]] - OpenGL参考サイト -- [[その1_Android で OpenGL を利用する方法:http://android.keicode.com/basics/opengl-overview.php]] -- [[その2_OpenGL を利用して立方体を描こう:http://android.keicode.com/basics/opengl-drawing-basic-shapes.php]] -- [[その3_OpenGL で図形を回転させてみよう:http://android.keicode.com/basics/opengl-drawing-basic-shapes-2.php]] -- [[その4_OpenGL での光源と質感 (ライティングとマテリアル) の設定:http://android.keicode.com/basics/opengl-lighting.php]] -- [[OpenGLを使ってみる。(1.1):http://andante.in/i/opengl/opengl%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B%E3%80%82/]] -- [[Android OpenGL 最初の一歩用Tips(1.1):http://andante.in/i/opengl/android-opengl-%E6%9C%80%E5%88%9D%E3%81%AE%E4%B8%80%E6%AD%A9%E7%94%A8tips1-1/]] - OpenGL参考サイト-2 -- [[Part1 ポリゴンを描画しよう:http://itpro.nikkeibp.co.jp/article/COLUMN/20120731/412953/]] - ''2Dテクスチャの表示'' -- 動作確認．以下のページのソースをコピペした．2つ目のサイトと併せて家でこのソースを良く確認しておく． -- [[OpenGL ES2.0 最初の一歩【OpenGL ES 2.0 for Android】:http://shimoigi.net/archives/854]] -- [[2Dの描画 OpenGL ES 2.0:https://sites.google.com/a/gclue.jp/android-docs-2009/2dno-miao-hua-opengl-es-2-0]] - glVertexPointer @OpenGL ES > 第1引数には、一つの頂点が持っている要素数を指定します。今回の場合ですと、一つの頂点はXYZ座標の3要素を持っていますので、3を指定します。ほとんどの場合3を指定すれば事足りますが、「とにかくメモリーを節約したい！」「2Dっぽく描画するからZの要素は必要ない！」という場合はXY座標の2要素で事足りますので、2を指定すれば良いでしょう。 - 画像変換のイメージ ++ 今表示すべき画像の種類，大きさ，場所を決定する ++ 今のプロジェクタの姿勢からその画像がどのように投影されているか推定する ++ どんな形か分かったので，それを正しい形に変換する - センシングモジュールプロトタイプ -- Arduino Pro-mini + BluetoothMate + 0.5inch-FSR --- USBバスパワーで動作確認：AndroidのBluetoothChatにセンサ値を飛ばす． --- 3Vボタン電池で試したところ，Bluetooth接続でBluetoothMateがリセットされる．恐らく電圧か電流が足りていない模様：ボタン電池*2の電池ボックスを注文，リチウムポリマ電池を注文．届き次第そちらで試す． --- 次の課題：UNOで良いのでFSRを靴に仕込んでセンサ値を確認する --- 消費電力抑制のため，センサ値を全てAndroidで処理するのではなく，Arduino側でセンサ値を監視し，着地イベントのみをAndroidに送信する． - Bluetooth通信 -- まず，接続して赤点滅時に端末側からペアリングする -- [[Arduino-Processing　BlueTooth通信+曲げセンサ:http://kousaku-kousaku.blogspot.jp/2008/10/arduino-processingbluetooth.html]] -- [[Arduino + Bluetooth + Androidで遊ぶ:http://www.swingingblue.net/mt/archives/003319.html]] -- [[BluetoothでAndroid-Arduino通信:http://umikappa.main.jp/20110708-148]] -- [[BluetoothChatでシリアル接続（SPP）を行う:http://dietposter.b.sourceforge.jp/2011/02/17/bluetoothchat%E3%81%A7%E3%82%B7%E3%83%AA%E3%82%A2%E3%83%AB%E6%8E%A5%E7%B6%9A%EF%BC%88spp%EF%BC%89%E3%82%92%E8%A1%8C%E3%81%86/]] -- [[BluetoothChatとPCのターミナルソフトでテスト通信:http://dietposter.b.sourceforge.jp/2011/02/19/arduino-uno%E3%81%A7bluetooth%E3%81%99%E3%82%8B/]] -- ペアリングは完了⇒しかし文字列が送られてこない：シリアルモニタでは出現 -- もう一度参考サイトの回路図の説明を見てプログラムエラーでないか確認 - Arduino + BluetoothMate + RC2032 -- ペアリング中にリセットされる：電流が足りないのかもしれない -- リチウムポリマー電池を購入 -- 単3電池*2用の電池ボックスを購入 -- ボタン電池*2用の電池ボックスを購入 -- 商品が到着し次第，試す - BluetoothMate -- [[ATコマンド入力／通信速度の設定変更:http://kousaku-kousaku.blogspot.jp/2008/10/arduino-processingbluetooth.html]]

memo ESS2012発表原稿

2012-10-16T22:45:28+09:00

** ESS2012発表原稿 *** タイトルページ - P.1 - ''(speak)'' それでは，東京農工大学の村田が発表させていただきます．~ タイトルは，「センサの帯同場所を考慮した個人参加型センシングのための環境センサモジュールと基盤ソフトウェア」です．~ よろしくお願いいたします． *** 見出し: 【本研究の背景と目的】 - P.2 - ''(speak)'' まず，本研究の背景と目的について説明します．~ *** 背景1: 【スマートフォンを利用したヒューマンプローブの増加】(P.1) - P.3 - ''(speak)'' 近年のセンサ技術やMEMSの発達によって小型で持ち運べるセンサデバイスが多く登場してきました．~ これによって，たくさんの参加者で色々な情報を大量に蓄積して共有する「ヒューマンプローブ」というセンシングパラダイムの研究が盛んに行われるようになりました．~ 特に，近年では，スマートフォンを使ってヒューマンプローブをする研究が増えてきています．~ 例えば，スマートフォン内蔵のマイクロフォンを使って，街の騒音マップを生成するシステムや，USB接続したセンサを使って，細粒度の大気汚染マップを作るシステムなどが提案されています．~ スマートフォンを使う大きな理由は，センシングへの参加の敷居を大きく下げることができることです．~ スマートフォン内蔵のセンサ，もしくは直接接続されたセンサを使えば，新しく別のセンサを持ち運ぶ必要がなくなります．~ そして，ユーザは意識せずに日常生活で環境計測を行なえるようになります．~ また，計測結果をインターネットに簡単にアップロードできることも利点の1つです．~ このような理由から，日常生活で大量の環境データをより細かく得るためには，スマートフォンを用いることが望ましいと考えられます．~ *** 背景2: 【スマートフォンを利用した環境計測の問題点】(P.2) - P.4 - ''(speak)'' しかし，この方法には問題点があります．~ それは，帯同場所の自由度の高さです．~ 首から下げたり，胸ポケットに入れたり，ズボンのポケットにしまうなど，人によっても，また，状況によっても身につける場所は異なります．~ この帯同場所の自由度の高さは，センサで計測された環境情報に大きな影響を与えます．~ 例えば，加速度や音量，温度・湿度といった情報は，ユーザが端末をどこに身につけているかによって計測値の傾向が変わってきてしまいます．~ このデータ特性の変化は，参加者から集められたデータでどんどん蓄積していき，計測精度や結果の信頼性を低下させてしまいます．~ 特に，熱中症やインフルエンザと言った環境リスク計測のシステムにとっては，大きな問題になります．~ 例えば，実際には危険度が高いのに身に付けている場所の影響で危険度が低いと判断されてしまうという状況が起こりえます．~ *** 背景3: 【センサ格納場所による温度湿度の差異】(P.3) - P.5 - ''(speak)'' 一例として，温度湿度センサを，異なる場所に身につけて夏に屋外を歩いたときの計測データの分布を，この図に示します．~ 上の段は，横軸を首，縦軸を胸ポケットにした場合の，温度と湿度の計測データの分布です．~ 下の段は，首とズボン前ポケットを比較したものです．~ この結果から，センサをしまう場所によって，実際に計測値の傾向が異なっていることが分かります．~ *** 目的1: 【本研究の目的と意義】(P.4) - P.6 - ''(speak)'' 本研究では，そのような問題点に対して，センサが帯同されている場所を考慮したうえで環境計測を行う新しいヒューマンプローブシステムを提案します．~ この方式の実現によって，より高精度・高信頼なヒューマンプローブの実現が期待されます．~ 本研究では，特に，先ほど述べた熱中症やインフルエンザと言った環境リスクに対する個人参加型計測アプリケーションの実現を目標とします．~ そして，本発表では，それらを実現するために必要な基盤ソフトウェア機能とスマートフォン向けの直接接続型の環境計測モジュールについてお話したいと思います． *** 基盤1: 【センサ帯同場所適応型ヒューマンプローブの提案】(P.5) - P.7 - ''(speak)'' 提案システムのコンセプトを，この図を使って簡単に説明します．~ システムは，大きく分けて3つの要素で構成されます．~ ユーザの持つスマートフォンと，インターネット上にあるセンサデータ共有プラットホームと，情報共有プラットホームです．~ スマートフォン上では，環境情報の計測処理が行われます．~ また，それとは独立した処理として端末の帯同場所の識別が行われます．~ 計測データには，識別された帯同場所メタ情報が付加され，特定の処理が施されます．~ 例えば，ある特定の場所のみのデータをアップロードしたり，場所ごとに計測値を自動で補正したりすることが考えられます．~ アップロードされたデータはセンサデータ共有プラットホームに蓄積されていき，情報共有プラットホームを介して他の参加者に情報共有されます． *** 見出し: 【スマートフォン端末の帯同場所識別】 - P.8 - ''(speak)'' では，次に，帯同場所の識別方法について説明します．~ *** 基盤2-1: 【スマートフォン端末の帯同場所を識別する】(P.6) - P.9 - ''(speak)'' 識別には，端末に内蔵されている加速度センサを使います．~ ユーザが歩いている時の加速度データから29種類の特徴量でニューラルネットワークの学習を行い，リアルタイムで判定を行います．~ 現在対象としているのは，首，胸ポケット，ジャケットポケット，ズボンの前後ポケットの5か所です． *** 基盤2-2: 【スマートフォン端末の帯同場所を識別する】(P.7) - P.10 - ''(speak)'' 識別精度ですが，10分割交差法で評価したところ，歩行者本人のデータで学習・分類を行った場合には約91%の精度で識別できます．~ また，本人を含まない歩行者グループのデータで学習・分類を行った場合には約72%の識別精度が出ることが分かっています． *** 見出し: 【Android端末向け環境計測モジュールTALESEAの開発】 - P.11 - ''(speak)'' それでは，次に，Android端末向けの環境計測モジュールTALESEAについてお話します．~ *** 基盤3-1: 【Android端末向け環境計測モジュールTALESEA】(P.8) - P.12 - ''(speak)'' まず，このモジュールを開発した目的について説明します．~ 発表の冒頭で，スマートフォンを環境計測用のセンサとして用いることで，ユーザは日常生活で意識せずにセンシングに参加できるようになると述べました．~ スマートフォンの近年の進化は目覚ましいものがあり，今後も搭載されるセンサは増えていくと予想されます．~ しかし，現状では，まだスマートフォンに搭載されているセンサには限りがあります．~ そこで，スマートフォンに直接接続する形式のセンサモジュールを作り，今回目標とする環境リスク計測システムに利用することにしました．~ 本モジュールは，マイコンと計測用センサから構成され，Android端末とUSB接続で通信を行います．~ 今回は熱中症やインフルエンザなどの環境リスク計測システムの実現に向けて，温度・湿度センサを搭載することにしました．~ モジュールの外観はこのようになっており，重さは20g弱です．~ また，このモジュールの制御機能を，先ほど述べた帯同場所識別とともにライブラリとしてまとめて，センサ帯同場所適応型ヒューマンプローブのアプリ開発者の支援環境として提供します．~ 詳しくは，後ほど説明します． *** 基盤3-2: 【TALESEAの内部構成】(P.9) - P.13 - ''(speak)'' では，次に，TALESEAの内部構成について簡単に説明します．~ マイクロコントローラにはArduino Pro-miniを使っており，FT232RLのUSBシリアルアダプタと接続してあります．~ また，温度湿度センサには，今回Sensirion社のSHT-71を採用しました．~ Android端末とマイコンの通信には，Android OS3.1以降で提供されているUSBホストモードを利用しています．~ この図に示すように，計測制御サービスはFT232用のデバイスドライバを介してマイコンとシリアル通信をして，定期的に計測要求を送信します．~ マイコン側ではSHT用ライブラリを介してセンサへアクセスし，計測を行います．~ 計測されたデータは，計測制御サービスがデータベースに書き込み，常に最新の値が保持されます．~ *** 基盤4: 【基盤ソフトウェアとユーザアプリケーションの関係】(P.10) - P.14 - ''(speak)'' 次に，今回開発した基盤ソフトウェア機能とアプリケーションの関係を，この図に示します．~ 基盤ソフトウェアは，ユーザアプリケーションに対して2種類のAPIを提供しています．~ 1つは，TALESEAモジュールの計測結果を保持しているデータベースへのアクセスAPIです．~ もう1つは，端末の帯同場所識別結果を受け取るためのAPIです．~ アプリケーションは，取得したこれらの情報から計測データに特定の処理を施し，インターネット上のサーバにアップロードを行います． *** 見出し: 【基盤ソフトウェア機能の消費電力計測実験】 - P.15 - ''(speak)'' それでは，次に，基盤ソフトウェア機能の消費電力計測実験について説明します． *** 基盤5-1: 【提供する基盤機能の消費電力計測実験】(P.11) - P.16 - ''(speak)'' 今回開発した基盤ソフトウェア部分の消費電力がどの程度のものなのか，日常生活で利用できるのかを確認するために，計測実験を行いました．~ 具体的には，基盤ソフトウェアの機能をすべて稼働させた状態と，基盤ソフトウェアの各処理を独立して稼働させた状態で計測を行いました．~ 基盤ソフトウェアの各処理というのは，この5種類のことを指しています．~ 計測時間は1時間で，バッテリ減少率を比較しました．~ また，Android端末としてはGalaxy Nexusを使いました． *** 基盤5-2: 【提供する基盤機能の消費電力計測実験】(P.12) - P.16 - ''(speak)'' 実験結果についてまとめると，この図のようになります．~ まず，全機能を稼働させた場合には，1時間あたり37%，647mAhのバッテリを消費しました．~ これは，概算で3時間弱でバッテリを使いきることになります．~ ということで，現状の消費電力では，日常利用においてバッテリが持たなくなる可能性があることが分かりました．~ *** 基盤5-3: 【提供する基盤機能の消費電力計測実験】 (P.13) - P.17 - ''(speak)'' 次に，その内訳について見てみると，最も消費電力が大きいのはモジュールへの電源供給であることが分かりました．~ また，次いで帯同場所識別とWebへのアップロード処理がそれぞれ消費電力の約1/4を占めていました．~ 今後の課題として，今回分かったボトルネックとなる処理機能の消費電力を抑えることを検討していきます．~ 詳しい方針については，後ほど説明します． *** 見出し: 【個人参加型熱中症警告マップアプリケーション】 - P.18 - ''(speak)'' 最後に，提案コンセプトの応用例の1つとして，熱中症を対象にした個人参加型の共有マップシステムについて説明します．~ *** アプリ1: 【個人参加型熱中症警告マップアプリケーション】(P.14) - P.19 - ''(speak)'' このシステムでは，TALESEAモジュールで計測した温度湿度データから，「WBGT」とよばれる5段階の熱中症警告レベルを算出します．~ そして，端末の帯同場所情報をもとに，警告レベルを加工してWeb上にアップロードします．~ アップロードされた警告レベルは地図上で可視化され，参加者間で共有されます．~ 今回は，センサデータの共有プラットホームとしてパッチべイを，情報共有プラットホームとしてGoogle Mapを利用しました． *** アプリ2: 【センサ帯同場所情報の利用】(P.15) - P.20 - ''(speak)'' さきほど，端末の帯同場所情報を使って熱中症警告レベルを加工すると言いましたが，例えばこのような利用方法が考えられます．~ 1つ目は，場所に応じて警告レベルを自動で補正する方法です．~ この方法は，本当は高い警告レベルだけれども帯同場所の影響で警告レベルが低く推定されてしまうといった問題を解決することができるので，最も理想的です．~ しかし，各場所における補正式を求めることが必要で，大量のキャリブレーションデータが必要になります．~ 2つ目は，首にかけた状態で計測されたデータのみをアップロードするという方法です．~ 首は，他の場所に比べて外気に触れる量が多く真の値に近くなるので，正確なマップをつくることができます．~ しかし，計測データ数が極端に減ってしまう可能性が大きいです．~ その他にも，このような2つの方法が考えられます．~ 今後，これらの方法を実装して，ユーザにとってどのような影響があるか比較実験をしたいと考えています．~ しかし，現状ではまだ集めたデータ数が少なく，個人差や衣服の影響についても分かっていない部分があるので，今回はより簡易的に帯同場所情報を利用することを目的として，3つ目の方法を実装することにしました．~ この方法は，算出した警告レベルと一緒に，帯同されていた場所も可視化するというものです．~ この場合，直接的に熱中症警告マップの高精度化には繋がっていませんが，計測データに対してユーザがそれを信用するかどうか判断するための材料を提供しています．~ これは，帯同場所情報がなければ実現できない仕組みの1つであり，警告マップの信頼度向上に繋がっていると考えています． *** アプリ3: 【熱中症警告レベルの可視化】(P.16) - P.21 - ''(speak)'' 熱中症警告レベルと共に帯同場所情報を可視化した様子をこの図に示します．~ アイコンの枠の色がその地点で計測された警告レベルをあらわしています．~ また，書かれたイラストがそのとき端末を身に着けていた場所を示しています．~ 今後は，更に多くのデータを収集して，先ほど述べた他の3種類の利用方法を実装することを目指します．~ そして，今回実装した方法と共にユーザ評価実験を行う予定です． *** 見出し: 【今後の課題と展望】 - P.22 - ''(speak)'' では，今後の課題と展望について説明します．~ *** 課題1: 【今後の課題と展望】(P.17) - P.23 - ''(speak)'' まず，実験から分かった基盤機能の消費電力のボトルネックについて改善を図ります．~ 方針としては，現在これら4種類の方法を考えています．~ 1つ目は，計測の合間にマイコンを定期的にスリープモードで動かすことで，マイコンへの給電を抑制する方法です．~ 特に，温度湿度センサなどはそこまで頻繁な計測が必要ないので，効果があると考えています．~ 2つ目は，コンテクストアウェア技術との併用です．~ アプリケーションによっては，ユーザの位置やしている行動によって，計測したデータが利用できないケースがあると考えています．~ そこで，そのような状況ではマイコンをスリープモードにしたり，帯同場所判定を行わないといった仕組みを導入しようと思っています．~ また，既存研究において，計測データのアップロード時の電力抑制や，参加者間で分担し協調しながらセンシングを行う手法などが提案されています．~ 本研究でも，それらの手法を取り入れることを検討します．~ 最終的には，15時間程度のバッテリ維持を目標にして，日常生活で環境リスク計測を行えるようにすることを目指します．~ また，今回プロトタイプの実装を行った熱中症警告マップシステムのユーザ評価実験を行って，帯同場所適応型ヒューマンプローブの有効性について検証していく予定です． *** まとめ: 【本発表のまとめ】(P.18) - P.24 - ''(speak)'' 本発表のまとめはこのようになっています．~ 以上で終わります．~ ありがとうございました． ---- *** 見出し: 【補足資料】 - P.25 *** 補足1-1: 【TALESEAの消費電流/電力】 - P.26 *** 補足1-2: 【TALESEAの構成回路図】 - P.27 *** 補足2-1: 【「鞄」を考慮した帯同場所識別】 - P.28 *** 補足2-2: 【静止中の端末格納動作による帯同場所識別】 - P.29 *** 補足4: 【】 - P.26 -