リパーティション、REPARTITION♪
久々にスマホのリパーティションしたのですが、以前やったのにすっかりやり方忘れてましたので、メモです。
ご注意:やり方にもよりますが、基本的に、データが吹っ飛びます。パーティションを再構成するのだから当然ですよね?ということで、何が起きるのか、何をしたいのか分からない人は、真似しないでくださいね(リンク先やダンロード先の安全性も自己責任でお願いします)。
1. パーティション書き換えツール "parted"
旧型AndroidではARM(32bit)のバイナリが必要です。自分でクロスコンパイルしてもいいけど、ここから落としました。
2. 潰し方と作り方
ココが参考になります。
基本的には、fdiskとpartedで確認しながら潰し、確認しながら作って、お名前つけていきます。
・パーティション一覧の見方
# fdisk -l /dev/block/mmcblk0
・パーティションの潰し方
# ./parted /dev/block/mmcblk0 rm <パーティション番号>
・パーティションの作り方
# ./parted /dev/block/mmcblk0 mkpart primary <開始セクタ>s <終了セクタ>s
・パーティションへの名前付け
# ./parted /dev/block/mmcblk0 name <パーティション番号> <名前>
3.気をつけること
- 必ず変更前にfdiskやpartedでパーティション情報を取得しておくこと。
- 使用中のパーティションは潰せないから他のパーティションから作業すること。
今回は、/cacheで作業した。 - 作業に影響なくてマウントされているパーティションは umountすること。
- パーティション番号が変わるとマウントの設定を書き換えないといけない
(fstabの編集が必要になる)
ま、これをやりたいのはsystem(factoryfs)パーティションが足りないとき。よく隣にuserdataパーティションがあるので境目をずらす感じですね。
== END ==
AndroidにErlang/OTPとElixirを仕込んでみた
忘れないうちに作業メモ。
Erlang/OTPのビルドと配置
基本的にはこの手順が正だとは思う。
otp/INSTALL-ANDROID.md at master · erlang/otp · GitHub
一番参考になったのは、この手順。
あとでこの2つの手順をベースに書き直すつもり。ソースのバージョンは20.2.2を使用した。
Elixirのビルドと配置
2つ目の手順で概ね問題なかったが、Elixirの導入でハマる。原因は、ソースをビルドしないまま配置していた!elixir.beamがなかったので、elixirやiexを使っても、呼ばれたerl(Erlang/OTP)が中でcrashしていた。
Elixirのソースはここから。
手順はほとんどなく、git cloneした後、チェックアウト(v1.5のHEAD。v1.6はまだRC1だったので)。
で、make clean test をする。これをしてなかった。
あとはAndroidに突っ込んでパス通すくらい。スクリプトの先頭行(#!/bin/sh)がAndroidでは微妙に違う。
LPC1768からHelloを打ち込んでみた
明けました。特に何もないです。何がめでたいのかもよくわからない。
で、人とは楽な方へと流れるもので(笑)最初に手を付けたのはLPC1768(以下mbed)。といっても昨日、珍しくハンダ付けが調子よく(決め手は老眼鏡!)、転がっていたmbed用のEthernetパーツを作り上げて接続。
しかし、シリアルをつないでないので、つながったかどうかがわからない。それならと、つないだついでにHTTPサーバーにPOSTを投げるところまでやってみた。途中、諸々、省略(笑)最後の方に参考にしたサイトをメモっておく。
mbedのコード。
// main.cpp #include "mbed.h" #include "EthernetInterface.h" EthernetInterface net; int main() { net.set_dhcp(false); net.set_network("192.168.1.101","255.255.255.0","192.168.10.1"); net.connect(); TCPSocket socket; socket.open(&net); socket.connect("192.168.1.100", 80); char sbuffer[] = "POST /cgi-bin/hello.py HTTP/1.1\r\nHost: 192.168.1.100\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 19\r\n\r\nurname=Mbed_LPC1768\r\n\r\n"; int scount = socket.send(sbuffer, sizeof sbuffer); socket.close(); net.disconnect(); }
結果(mbedをリセットすると接続→POSTリクエスト送信となる)。
ま、これであとはセンサでも付けて情報をPOSTすればいいのかな、と。たぶん、Mbed Device Connectorのような、コントロール用のホストを中に立てた方が良さそう。手許には可視光の光センサがある(何故あるのかが不明。)のだが、いかんせんこの子、Wiredなので何処にも連れていけない。いまそこで引っかかっている。なんかWiFiっぽい部品も転がってるんだけど・・・めんどうい。
参考にさせていただいたサイト:
- Mbed OS Documentation | Docs for IoT
- 21.2. cgi — Common Gateway Interface support — Python 3.6.4 documentation
- フォームデータを送信する - ウェブ開発を学ぶ | MDN
- Pythonで現在の日時を取得して指定のフォーマットの文字列に変換する
- Pythonでのファイル操作 - Qiita
まだ、Hello! の世界。いつもこればっかり(笑)
やっとフォントを変えることができた(2018/1/7更新)
Elephone C1max の中華フォントを国産フォントにやっと置き換えられました。
自分のメモですので、以下のリンクで再実行可能。
2018/1/7更新:
別筐体で試したら、SuperSUの導入で「空振り」があったので、その部分を再確認、以下の記述も更新。
以下、十分ご理解いただいた方以外は、絶対に真似しないでください。けっこうザックリ書いてますので、立ち往生すると端末が使えなくなります。また順調に行ったとしても既存のデータは全て消えてしまいます。
Stock ROMの用意:
以下がElephoneの公式サイトとなる。Support → Downloadsで、いくつかの機種が表示される中に、C1maxもある。焼き込みのツール(FlashTool)とVCOMのドライバーもある(なんて親切)。試行錯誤で失敗してもこれでリカバリ可能。カスタムRecoveryの修正にも必要。
ImageKitchenの準備:
カスタムのTWRPイメージをそのまま焼いても簡単にはTWRPが立ち上がらない。このため、ImageKitchenというツールでrecovery.imgをunpack, 修正, repackする。
TWRPの準備:
公式のTWRPサイトからはC1max用のイメージは提供されていない。C1MaxはMediatekのMT6737TというSoCで動作している。また、C1maxは初期の出荷時からNougatであり、上述のStock ROMもNougatのため、TWRPはバージョン3.1が必要(とWEBのどっかに書いてあった)。このため「TWRP MT6737T 3.1」で検索。今回は以下を利用している(他も試したらロシア語のTWRPが出来てしまい、操作に苦労した)。
C1max用のrecovery.imgの作成:
上記のTWRP3.1はそのままfastbootで焼いても起動しない。以下の手順にて、Stock ROMの中にあるrecovery.imgの一部分をTWRPのrecovery.imgに取り込む(双方のrecovery.imgをunpackして、TWRP側を修正してrepack)。unpackするとMT6735とかあるが、Stock側も6735とあるので、気にしないで進める。
FastbootでのTWRP焼き込み:
C1maxの設定で開発者モードの中にOEM UnlockをEnableにするトグルがあるのでこれをEnabledにしておく。また、ファームウェアの自動更新も一応オフにしておく。fastbootモードには、adb reboot bootloaderでもいいし、電源オフ状態から電源ボタン+Volume UPで選択モードに入る(V-Upで選択肢変更、V-Downで選択可能)でもよい。oem unlock → flash recovery → oem lock で、reboot。
注意点:flashした後、必ずlockし直すこと。unlockのままではブートループとなる。
TWRPでのSuperSU焼き込み:
chainfire氏謹製の、SuperSUを焼き込む(直近では2.82がstableで2.85がbeta。SuperSU焼き込みは大きく2段階の処理。もし1段階のみだと「空振り」。2.82の方が確実な様子)。
また、焼き込む前に dataパーティションをext4でフォーマットしておく。焼き込んだ後にcache, Dalvik cacheもクリアする。SuperSUの処理が2段階通ったようなら、Reboot → Reboot Systemで再起動。
フォントの変更:
起動後にSuperSUのアイコンがあるのを確認して、adb shell , suを行いシェルでrootで作業できることを確認する。Recoveryモードに戻り、/systemをrwでマウントして(TWRPでマウントするだけ)、以下のサイトの手順で、自分が使いたいフォントの配置と、fonts.xmlの書き換えを行う。Recoveryモードだと、/systemをRWでマウントできるから作業は楽。グループとパーミッションの変更を行う。
TWRPからReboot Systemで、完了!
Stockが提供されたので、やっと気合い入れて調査、変更することができました。
== END ==
Open JTalk .htsvoiceへの形式変換(htsvconv)
補足、というかこのブログは自分のためのメモ帳なので。
初音ミクのボイスがあるけど、変換はWindowsで、とありましたが、Linux Mint 18.2(Sonya, Ubuntu16.04LTS xenialに相当)でも変換を行えました。
まずソースコードをいただきます。
neu101.seesaa.net上記の中の「htsvconv002.zip」へのリンクをクリックでダウンロード、てきとに解凍。
実行に必要なもの。
- コンパイル:mcsコマンド(apt install mono-mcsでインストール可能)
- 実行:monoコマンド
私はmonoコマンドは入ってましたのでmonoコマンド自体はどうやってインストールするか調べてませんが、mono-runtimeというパッケージがあるので、もしかしたらそれかも?インストール、コンパイル〜ミクボイスの変換は以下が参考になります。
karaage.hatenadiary.jpMacと同じようにできます。非常にラフな言い方をしますと、brew → apt に置き換えただけです(笑)
しかし、世の中、欲しいものはまぁほとんど誰かがすでに作ってくれているのですね。
何事も、あらまほしきは先達なり。ありがたや、ありがたや〜、です。
RaspberryPiで音声認識→ESP-WROOM-02操作 (後編)
長くなるのでやったことだけ、メモ。
1.プリコマンドによる誤操作防止
直接指示を与えるのではなく、事前に「これからコマンドを送るよ」という前置詞的なコマンドを用意。プリコマンドを発声すると、ready_state → ON となる。各コマンドは ready_state == ON の場合のみ実行され、実行後に ready_state → OFF とする。
2.ロック(アンロック)コマンドによる誤操作防止
長時間不在時のために、もう1段、明示的にロックをかけられるようにする。lock_state == OFF の時だけプリコマンドが成功し、ready_state → ON に変更できる。ロックコマンドで lock_state → ON、アンロックコマンドで lock_state → OFFとする。
3.Open JTalkによるコマンドエコーバックメッセージ
音声操作の場合、モニタなどのディスプレイ装置を観ていないことが多い。このため、エコーバックを音声(WAVファイル)で行うこととし、テキスト文言からWAVファイル作成には Open JTalkを使用した。
女性ボイスデータ:meiちゃん(mmdagent.jp)
ちなみに、私のパラメータ設定は以下の通り。割とキビキビした明るい女の子。ちなみに、アクセントの制御は難しいが、「、」や空白を入れて読み上げを区切るとアクセントが変わる(かなりの違和感をこの方法で解決できた)。
open_jtalk -m /usr/share/hts-voice/mei/mei_happy.htsvoice -x /var/lib/mecab/dic/open-jtalk/naist-jdic -a 0.55 -fm 4.0 -r 1.0 -jf 1.2 -ow test.wav voice.txt
4.マイクレベル・音声認識の調整
マイクレベルが高いと常に入力信号を拾い、音声認識(Julius)のバッファあふれや頻繁なエラーが起きる。マイクレベルは使用機器により異なると思うが家にあったマイクでは30%程度で適正であった。
また、音声認識のカットオフを800msec(結局はインストール時の初期値)に変更した。
5.TODO
- 音楽再生の仕組み導入
- 玄関の照明のコントロール追加
- Pythonコードの整理(コピペで悲惨なことになっている)
- ESP-WROOM-02でHTMLを表示しているのをRasPiに持ってくる。
- rospeexによる、さらなる萌えボイスの追求(笑)
rospeex ― Speech communication toolkit for robots
RaspberryPiで音声認識→ESP-WROOM-02操作 (前編)
先週末の、ESP-WROOM-02 (以下ESP)らくちんリモコンの続編。
自宅に眠っていたRaspberry Pi2 B+ (以下、RasPi) にWiFiドングルを挿して、RasPiで音声認識、ESPに指示を送る形で、音声のみでの照明・エアコン操作をしてみました。
RasPiのセットアップやWiFiドングル(IO-DATA WN-G150UMK)の設定は検索すれば多く見つかりますし、RasPiではこのドングルはすぐ認識されましたので特別なことはないです。
音声認識は以下のサイトの通りやっただけ(ありがたや)。ただ後半は自分のリモコンへの接続をしているので、もちろん違ってきます。
raspibb2.blogspot.jp後半の差分部分は、とりあえずESPのWEBサーバーにPOSTで(前回のWEB画面でボタンを押した時にサブミットされる文字列を入れた)JSONを送る。上記サイトで使っているPythonプログラムにPOST送信のコードを埋めただけ。なので、コードも省略。
ひとつわかったことは、上のサイトではJuliusの音声認識の時間を800msecから400msecに短縮しているが、辞書を絞った上に認識時間を短縮すると、些細な言葉(例えば「ねむい」)も誤変換されて、コマンドが発行され、うっかりすると照明もエアコンもぐちゃぐちゃに動き出すのです。
とりあえずの対策は、逆に認識の時間を1500msecと長く設定して、辞書の単語も1ワードを長くする(例:「しょうめいあかるく」とか)して、命令以外の言葉を引っかかりにくくしてみました。が、辞書を絞っているので、長い言葉を掴むと無理やりコマンドに変換してしまいます・・。
なので根本的には、「事前にこの後、命令を発することをRasPiに教える」必要がありそうです。というわけで、「OK, Google」の意味がわかりました。これが前置詞で、これで待機状態に入ったところで、命令を発行するわけですね。
ならばもちろん「Nope, Google!」としたいところですが(笑)せっかくなので、このコンシェルジュにお名前を付けてあげて、その名前で呼んであげることにしたいと思います。
== TO BE CONTINUED ==