[Unity 2018.1.0f2] Android 向けにビルドしてはまったこと

メモ程度に. 詳細はリンクを参照. 

＜環境＞

・Unity 2018.1.0f2

・Android Studio 3.0.1

・タブレット lenovo TAB4 8 Plus

＜流れ＞

・このサイトを参考に進めるもbuildに失敗

→ ここ(上記リンクと同ページ)を見て解決.

・buildには成功するがbuild and run に失敗. 

→ ドライバの設定, デバッガモード有効化, API Level にまつわるトラブルシューティングをするも解決せず. 

→ ＜参考＞のwarningより, "You are trying to install X86 APK to ARMv7 and ARM64 device. Please select ARMv7 or ARM64 as device filter under Player Settings or connect X86 device". ということで, Edit -> Project Setting -> Player -> Target Architectures の Armv7 にチェックを入れて, x86 のチェックを外すと Build and Run に成功した. 

とりま Android の build には成功したので, 次はいよいよ oculus go 向けに build だ.

＜参考＞

・build and run時のメッセージ

UnityException: No compatible Android device found
No compatible Android device found. If you are sure that the device is attached then it might be USB driver issue, for details please check Android SDK Setup section in Unity manual.

Hardware of device Lenovo Lenovo TB 8704F (HGAG57X7) is not supported: Device: HGAG57X7 [Lenovo TB-8704F]
You are trying to install X86 APK to ARMv7 and ARM64 device. Please select ARMv7 or ARM64 as device filter under Player Settings or connect X86 device.
UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)

第２回 キノフィットkinofit

半年ぶり、2回目のキノフィット。

気づきをメモする。

以下、リフィッティング結果。
・両脚にスペーサ
・サドルを少し前に出して(高さも変えた)
・ハンドルを5mm下げた
・ステムを1cm伸ばした


前回よりも下半身の動きは良くなっている。踏む癖も見られない。
しかし、上半身が下半身とリンクしていない。
体幹が機能していない+姿勢が悪いから。

<姿勢>
バンザイして一直線になるような姿勢を心がける。
無理なく耳の後ろの方で手を組めるようにする。
この姿勢で乗れるようになると、より大きなフォームが取れる。
腹にも余裕ができ深い呼吸ができる

<体幹>
「えー」と発声すると腹圧がかかることを感じ取れる。
腹圧は常に意識する。横腹が膨らむ感じ。力をいれるわけではない。

<ペダリング>
左脚はかかとが上がりすぎ。気持ち下げて。

右脚は腿が上がってないため、上支点を綺麗に通過できていない。
腿があげにくいのは、腸腰筋の筋力や筋肉の柔軟性が足りないため。正しいフォームで乗り続けることで今後、解決していく。

右脚の膝が外側に上がっている。これはQファクターが自分の腰幅に対して狭いため。
今後、Qファクターの広いペダルに変えるかも。

<その他>
カイロプラクティック等で体の使い方を見直しても良いかも。
肩の上がり具合は普段から意識して。体の調子もよくわかるから。
腿が上がるようになればサドルは後ろへ、高くすることができるが、それは先の話。
まずは体の正しい使い方を知る。正しく使い続けることで体幹(基礎)ができてくる。
柔軟性はそれらが出来てから(長い期間を要する)。

富士山HC前(5月末)にRRA行っても良さげ。
その次のリフィッティングは赤城山HC前とか？

第１回 キノフィットkinofit

忘れないうちに指摘事項をメモ+所感

メモ
1) 腹筋が使えていない
     → かかとが下がっている(サドルが低い)
     → 意識して回さない、フィッティング後は意識せずとも回る状態になっている
     → おなかを出すようにする

2) 今後１か月は負荷をかけるよりも今日教わった体の動きを身に着けることに専念する
    → 負荷をかけると腹筋が使えなくなり骨盤の角度が変わり今のフォームでは回せない(フォームが身につかない)

3)  動画を使って動作を確認すること。

4) 肩を丸めない肩甲骨を中央に寄せて溝を作ってあげる

5) 交換したサドルは尿道部分が固いので圧迫されるかも

6) 2)を実行するとき、左右の音に気を配る（一定の音で回せているか)＋片足ペダリングでも同様に確認する
   負荷は軽くして、ケイデンスも低めでゆっくりとした動作で行うようにする
 


所感
1) 「とりあえず回してみましょう」から始まる、斬新
 ・ メジャーで測ることで得た結果が良いとは限らない
 ・ 過去にケガをした、体が硬いといった外因も考慮したフィッティング
 ・ 今回の結果がすべてでなく、その後も柔軟性や筋力が向上することで変化していく

2) フレーム、ホイール以外のパーツに金をかけたのは初めてかも
 ・ 今回はハンドルバーとサドルを交換した(420mm→440mmでアーチが深い)
 ・ ハンドルは狭い＋近いと感じたから
 ・ サドルは何でもよいが現サドルではこれ以上後ろに引くことができないのでやむなく交換した
 ・ ステムの交換は割と多いらしい
　 → ハンドルを交換したことで両手が縦と横に遠くなり結果、ちょうどよい長さになったのでステム交換は不要だった

 3) メカニコのフレームに興味持ってくれてうれしい...
 ・ 「フレームホイールいいもの買ったって基本がなってないと性能を活かせないよ」だそう(エンジンが大事)

 4) 体の使い方は良いと褒められて素直にうれしい...
 ・ ポジションがあってないことでフォーム・ペダリングがおかしくなっている
 ・ ずばっとはっきり話してくれるので頭にすっと入ってくる

 5) 根拠を交えて話してくれるので説明に納得がいくし、内容も実に興味深い(1.5hあっという間)


とりあえず今回はこんなところでしょうか。

カーボンフレーム納車

メカニコさんにカーボンフレームを注文して、先月到着ー。
パーツ類はwiggleでまとめて購入。
以下、構成。

• コンポ: アルテグラDi2
• ホイール: レーシング4
• ステム: Deda zero100
• ハンドル: Deda zero100
• シートポスト: Deda zero100
• 他…

重量はおそらく7.2kgくらい。

手持ちのホイールとサドルを付け替えたら6.8kgを下回る。

最終調整は高知の城北サイクルさんに依頼した(¥2000)。

お安く済んで満足＾＾

下ハンドルが握りにくいので角度をつけてブラケットの位置を再調整しなくては。

フレームアグリゲーション有効/無効時におけるiwlwifiの挙動

送信処理

• DMA転送は１フレームごとに行われるため，フレームアグリゲーションの有無で処理は変わらない

送信完了処理

• フレームアグリゲーション無効時
• ACKフレームの結果を通知し，当該フレームをiwlwifiの送信キューから破棄する．
• 必ず，１フレームごとに処理が行われる（１フレーム破棄/1回の送信完了処理）
• フレームアグリゲーション有効時
• デバイスから３種類の通知情報を受信する
• フレームアグリゲーションの結果（※送信結果ではない）
• アグリゲーションされたフレーム（確認した限りでは最大で５フレーム）のそれぞれの，転送結果，再送回数（転送回数？），etc...
• デバイスへ転送時，つまりACKフレームの到着前に通知されるため，この段階では送信結果はわからない（コード中のコメントより）
• Block-ACKの結果（送信結果）
• 結果をもとに破棄可能なフレームを決定する
• TCPと同じように宛先へ到達の確認が取れているフレームまでを破棄することが可能
• 例：1,2,3,4を送信→3のみロス→1,2を破棄→3を次回の送信機会で最初に送信（再送）する
• TCP+Sackみたいな感じ...
• 無効時と同様にアグリゲーションされたフレームの再送にも上限回数があるっぽい
• ACKフレームの結果（送信結果）
• フレームアグリゲーション有効時でも単発のACKが帰ってきた場合は上記と処理が異なる
• 単発か否かの判定はここ
• フレームアグリゲーション無効時の場合は常にtx_resp->frame_countが1で，有効はおそらく1〜5
• 破棄するフレームは，ACKフレームに該当するフレームとそれ以降連続して確認が取れているフレームまで
• 例：1,2,3,4,5送信→3のみロス→1,2を破棄し3を再送→3をACK→3,4,5を破棄
• アグリゲーションしたフレームの再送に上限回数があるのはヘッドラインオブブロッキングを防ぐため
• 呼ばれる関数は無効時と同じであるが，1回の処理で複数のフレームを破棄するため処理が異なる

オフロードの設定変更

//現在の設定 # ethtool -k dev //変更 # ethtool -K dev gso off gro off

fedora24 caps ctrl 入替え

参考：https://www.kdel.org/wp/?p=367

dconf write /org/gnome/desktop/input-sources/xkb-options "['ctrl:swapcaps']"

reboot

iwlwifi の設定・デバッグ

自分用なので冗長なことが多いわりに中身がない．
リンクを踏んで適時補完...

1. iwlwifi の設定
 こことかここを参考に．

• 無線関連のパラメータ一覧の表示
• # modinfo iwlwifi 
• 現在のパラメータの表示
• # cat /sys/module/iwlwifi/parameters/11n_disable
• 上は，フレームアグリゲーションの有無
• parameters以下は，必要に応じて変更する
• パラメータの変更
  例：フレームアグリゲーションの無効化
• # echo "options iwlwifi 11n_disable=1" > /etc/modprobe.d/iwlwifi.conf
• # reboot
• 必要に応じて iwlwifi.conf を編集，再起動する
• フレームアグリゲーションについて 

2. iwlwifi のデバッグ
ここを参考に．

• 使用するツール：trace-cmd
• # yum install trace-cmd
•  使用例
1. # trace-cmd record -e iwlwifi_msg ping google.com -c 1
• ping 開始から終了時までのデバッグログを出力
• カレントディレクトリにtrace.dat が形成される
2. # trace-cmd report trace.dat| less
• たくさんログが吐き出されるため，必要なものだけ抽出する
• trace-cmd report | grep "LONG\|SUCCESS\|retries" | less
•  送信完了処理で破棄するフレームの送信結果とMACヘッダのシーケンス番号を出力する
• FW，HW，ドライバのみデバッグするならば，trace-cmd で事が足りると思う．
  →パケットの情報を見るならデフォルトのままでは不十分...
• 送信時，送信完了時には，処理中のパケットのMACのシーケンス番号のみ出力される
• MACだけの情報だとSrc, Dst の端末でWiresharkを使ったときにパケットの対応付けが難しい（上位レイヤの情報が欲しい）
• Wireshark はEthernet以上の情報しか見れないため
• monitor mode とかOSXの診断ツール使えばIEEE802.11フレームもキャプチャ可
• モジュールに手を加えて必要な情報を取得する
  →具体的には，ドライバの送信バッファ内のsk_buff 構造体からヘッダやデータなどの値を取得する
• (準備) カーネルモジュールのコンパイル
• (準備) 全体をコンパイルする場合はこっち(Fedora 23)
  →config を iwlwifi と mac80211のデバッグのために変更するならば以下の方法
1. # su -  
2. # wget http://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.5.5.tar.gz
3. # cat <<"EOF">> /etc/dnf/dnf.conf
4. # exclude=kernel*
5. EOF
6. sudo cp /boot/config-4.5.5-300.fc23.x86_64 linux-4.5.5/.config
7. dnf install -y openssl-devel ncurses-devel
8. cd linux-4.5.5
9. make menuconfig
10. make
11. make modules_install
12. make install
• モジュールのコードを書き換える
• vi linux-4.5.5/driver/net/wireless/intel/iwlwifi/mvm/tx.c
•  ここを書き換えるもしくは，マクロを新たに追加する
1.  水平タブ(\t)の影響でノートPCだとログが改行して表示されるため\tを消す
2. ほかにも出力される情報の中で冗長なものは，排除する
• retries ：フレームのMAC層における再送回数(実際にはackが返ってくるまでに再送した回数？(15回でリセット？))
3. TCPに関する情報を出力する
• シーケンス番号：ntohl(tcp_hdr(skb)->seq)
• ポート番号：忘れた
• パケット長：skb->len
• ヘッダ長：skb_headlen(skb)
• データ長：skb->data_len
• コンパイル・アンロード・ロード   
• # make M=driver/net/wireless/intel/iwlwifi/
• # rmmod iwlmvm
• # insmod linux-4.5.5/driver/net/wireless/intel/iwlwifi/mvm/iwlmvm.ko
• 書き換えてから trace-cmd を再度実行

今回は，送信完了処理で呼ばれるデバッグ用の関数をヘッダ情報も出力させるように変更した．
毎回コンパイルが面倒ならばSystemTapとか使えば多少楽になるかも...

iwlwifi 各種パラメータの設定

iwlwifi 各種パラメータの設定

カーネル：linux 4.5.5
ディストリビューション：Fedora 24

・データフレームの再送回数
driver/net/wireless/intel/iwlwifi/fx-api-tx.h

#define IWL_DEFAULT_TX_RETRY                    15

大津CC2周

1周目は，流して，2周目はメディオ走．
複数人で走ると楽しいコースなのね．

信楽1周

たんたんと回った．50km．

信楽1周+α

人数が多かったので市街を迂回するコース．
計70km

鈴鹿スカイライン

鈴鹿峠を越えて，三重側から鈴鹿スカイラインを越えた．
菰野ヒルクライムと同じコース．

大津CC2周

1周目でたれた．
2周目は，脚が止まった．
その時飲んだコーラがおいしかった（小並感）．
大津CCは，アスファルトがボッコボコでストレス溜まる．
交通量とキツさは，いいんやけどなあ．

信楽1周

ケイデンス低め（70〜90）で下ハンドル，ダンシング多用した走りを心がけた．
1ヶ月前よりかは確実に走りがよくなった．
上りはやっぱり落ちるけど．

信楽1周（林道経由)

登って下りのとっても良いコース( ･ิϖ･ิ)

信楽1周

山が、坂がきつい。重い。
漕ぎ始めにふらつく。
ダンシングふらふら。

感覚取り戻さなければ！

信楽1周（林道経由)

約半年ぶりにまともに自転車に乗った．
いろいろ落ち着いて乗れる機会も増えるし，早く元のパフォーマンスが出せるように頑張ろう．

サイクルロードレースのスタンプを買ってみた．自転車乗りとの会話に使えそう．