本のしおりをIoTにしてみた (SHIWORI)
開発概要
組み込みマイスター2018-2019で制作した作品です。
開発期間は半年弱、高専の4年生4名で開発しました。
（内2名アプリ開発、2名サーバーサイド兼ハードウェア開発)
目次
作品概要
本のしおりをIoTにしてみました。
作品名は "SHIWORI" です。
電子書籍には便利な機能が沢山あります。
例えばこんな感じ
- 読書量の管理（読書時間やページ数、読了率等）
- 読書量の可視化（グラフ表示など）
- おすすめの本の表示
- 書籍検索
- 他人のレビューが見れる
- SNSシェア
同じようなことを紙の本でできたらいいよね！と考えました。
読書記録用デバイスを作成し、スマホアプリを使ってデータを可視化しようと考え、実装しました。
自分は主にスマートフォンアプリケーション開発をしました。
実際に開発したものについては後述します。
当初予定
最初やりたかったことの中で、最終的に実装できなかった機能や別の方法で実装した機能・加えた機能が複数あります。
まずは、中間発表までに考えていたことについて書いていきます。
調べた限り、栞をIoTにしている製品やプロジェクトは見つからなかったので、実装時に苦労したことや、考えていたことをできるだけ詳しく書いています。
ハードウェアについて
マイコンは主にESP32を使いました。小型化を目指しました。
読書量の管理
最初の壁は、「紙の本の読書量の管理をどうするか」というものでした。
読書量の管理、つまり読んだページ数が欲しい。 時間はソフトウェアで簡単に計測できるので、ページ数が分かれば - 分速ページ数 - 読了率 - 特定の時間内に読んだページ数 - 今まで読んだ本のページ数
などなど、色々算出できます。
ただし、本を〇ページまで読んだことをどこかに入力するような、ユーザの直打ちは面倒 なので、どうにかして直打ち以外の策をとりたいと考えました。
ページ数測定案 1（物理的に測定）
まず考えたのは物理的なもの。 「紙の厚さを測ろう」というものです。
測り方にも、リアルタイム計測と読書終了時に計測する方法の2つが考えられました。
リアルタイム計測
読んでる途中に「次のページに行った・前のページに戻った」とかを認識する方法。
下図のようなものを考えていました。
しかし、「一気に10ページとか、50ページとか、めくられたらめくられたページ数を認識できない。精度が十分に出ない。」という問題で実装を断念しました。
読書終了時に計測する方法
読書が終わったら、ユーザからの直接入力以外の形で、ページ数を取得させる方法です。
後者はそのままです。2通り案が出ました。
読書が終わったときに読んだ分の紙の厚さを測る方法
1枚の紙の厚さが分かれば、測定した厚みから今のページ数が算出できるので、厚みを測ろうという案。
厚みのセンサは、主に印刷機等で使われているようです。
ただし、紙一枚の精度を出すためにはセンサが大きいため、断念しました。
今読んでいる本のページまでの距離を測定する方法
透過型光電センサで検出体までの距離測定 >> ページ数算出 という案です。
透過型センサは、検出位置精度が比較的高いですが、本の紙ぐらいまでの測定となると、センサが20万円以上する（予算が足りない）という問題があり断念しました。
読書終了時に計測する方法でも、精度が十分に出ないため、実装不可という結論に至りました。
ページ数測定案 2（ソフトウェアで測定）
ハードで厳しいならソフトで処理しよう。
ページ数を画像認識させよう、というものです。
これなら予算がかからず、精度は学習量でカバーができるのでいいのではないでしょうか。
実装するページ数測定方法
ページ数計測に関しては、上記のような検討過程から、SHIWORIにカメラを付けてページ数を画像認識させることで読書量を取得しようと考えました。
ソフトウェアについて
スマホアプリの機能
SHIWORIデバイスで取得したページ数と時間等のデータを利用して、スマホアプリと連携しようと考えました。
具体的なアプリの機能は以下の通りです。
ブックマーク機能とは、ページ数とメモをアプリに保存することができる、という機能です。
また、アプリはIOS/Android両方で動かしたいと考え、クロスプラットフォーム開発が可能なReactNativeという言語で開発しようと考えました。 他にもKotlinやUnity、Xamarinなどの言語もありますが、自分を含めアプリ開発者がJavaScriptおよびWeb開発の知識を持っていたのも選択した理由の一つです。
本の情報の取得先
本の情報の取得先は幾つかありましたが、GoogleBooksAPIを使用しました。 url : https://developers.google.com/books/
サーバー
最初はAWSのLamba、DynamoDB等を使用する予定でしたが、最終的にConoHaのサーバーをレンタルし、MySQLとNode.js,Expressでデータベースやサーバーを設計しました。
通信部
SHIWORIデバイスと、アプリのデータ共有はどのように行おうか考えた結果、bluetooth通信を使うことになりました。
また、アプリからサーバーへのアクセスはhttp通信、ReactNativeのFetchAPIを使うことになりました。
最終的に実現した作品について
実現できなかった機能について
画像認識
正確にはカメラの問題です。撮影ができないバグがあり、画像認識までたどりつくことができませんでした。
よって、ページ数を画像認識で取得するという方法が使えなくなってしまいました。
代わりにHTTP通信でSHIWORI APIを経由してデータを共有する方法に変更しました。
bluetooth通信・push通知
アプリ側については、bluetooth通信が実装できませんでした。
ネイティブコード周りは難しかったです。開発環境等にも問題があったのかもしれないです。
同様にpush通知も実装しようとしていましたが断念しました。
上記の機能を補うべく、アプリの機能を増加したり、SHIWORIに電子ペーパーを設置して、指定の本の表示機能を追加したりしました。
ユーザ登録・ログイン・ログアウト処理
完全に時間が足りなかったので実装しませんでした。 デモでは、テストユーザが一人あれば大丈夫なので。
ただし、一度画面設計やDB登録等の内部システムは実装できました。
実現した機能 (Hardware)
- 読書開始ボタン・終了ボタンを押すことで、押した時間がhttp通信でチームが管理しているサーバーに送信。
- 現在読んでいる本にセットした本（SHIWORIの使い方を参照）を電子ペーパーに表示。
実現した機能(Software)
- サーバーでは、ユーザ毎に感想やブックマーク、読書履歴等を管理させました。
AppはiOS/Android両方で動作します。アプリのスクリーンショット等はSHIWORIの使い方に貼っています。
- プロフィール設定
- 現在読んでいる本の設定・読書履歴の表示・編集
- 最近チェックした本の表示
- 読書量のグラフ表示機能
- 今読んでいる本の表示機能
- 本のキーワード検索機能・検索履歴の表示や削除もできます。
- 著者検索の実装
- ブックマークの表示・登録・変更・削除機能
- レビューの登録・他ユーザーの評価の表示
- アプリ内でCryptoJSのハッシュ関数(SHA256)を用いてパスワードを暗号化しました。
SHIWORIとアプリの通信はbluetoothの予定でしたが、SHIWORI APIを通じてhttp通信で共有することになりました。(詳細は全体構成を参照)
全体構成
全体構成は下図のようになっています。
SHIWORIデバイス
ESP32を使用しています。
サーバー
- Shiworiサーバーからのデータや、アプリケーションから指定したデータを全てConoHaを用いたサーバー（以後SHIWORIサーバー）が管理するデータベース（DB）に保存。
- DBは次のようなデータを管理している
- ユーザデータ（email,pass,プロフィール情報等）
- ブックマーク
- 感想（レビュー）や評価値(0.0~5.0)
- SHIWORIデバイスからの情報
- 本の情報取得にはGoogleBooksAPIを使用しました。
通信部
- SHIWORI本体とスマホアプリのデータ共有のためにSHIWORI APIを経由します。
- 他にも、AppからDBで管理されている情報を取得するとき（ブックマーク等）もSHIWORI APIを仕様します。
スマホアプリケーション
- ReactNativeで書きました。
- アプリ内に情報を保存する機構を、Reduxを用いて実装しました。これでタスクキルしてもデータが消えません。それ以外にも開発上のメリットは沢山ありますが、ここでは割愛します。
- アプリ内保存データには次のようなものがあります。
- ユーザーデータ
- 検索履歴
- 最近チェックした本
- 今読んでいる本のリスト
- サーバーに指定した本のid等
SHIWORI・SHIWORI-Appの使い方
画像は開発時のスクリーンショットを集めたものなので、表示されている内容が本来と違う部分があります。
本の登録から、ページ数入力まで。
1．下のタブから「Search」を選んで、本の名前等を検索
2． 検索結果から一つ選び、「今読んでいる本」に登録する。
3．下のタブから「Home」を選び、ホーム画面へ
4．購読中の本の変更ボタンを押すと、登録画面に飛びます。
5．今読んでいる本から一つ本を選ぶ。（これは今実際に読んでいる本を指定してください。）
6．すると、SHIWORIについている電子ペーパに登録した本が表示されます。（開発中の画像なので、選んでいる本とは違う本が表示されています。）
7． SHIWORIには、ボタンが3つついていますが、その中の「読書開始ボタン」「読書終了ボタン」を読書に応じて押します。
8．押した結果が、読書履歴としてセットされ、アプリに表示されます。「現在読んでいる本」についての読書履歴が登録されます。
9．読書履歴はそれぞれ詳細を見ることができ、内容を変更することもできます。
10．ボタンを押しただけでは、読書時間しか計測されないので、読んだページ数を入力してください。
11．以上で読書量がセットされました。
ブックマークの管理
1．先ほど示した検索結果の詳細画面から、ブックマークを登録できます。
ページ数とメモをそれぞれ入力します。登録ボタンを押すと登録されます。
2． 登録したブックマークは、マイページから見ることができます。
3．マイページには下のタブから選ぶことで移動できます。
4．「ブックマークを読む」ボタンを押すと、ブックマーク一覧にジャンプします。
5．ブックマーク一覧画面では、それぞれを左スライドすることで、内容の変更・削除ができます。ブックマーク詳細ではブックマークの内容が全文見れたり、本の詳細ページにとぶこともできます。
レビューの登録
本の詳細ページから感想（レビュー）を登録することができます。
同時に評価値(0.0~5.0)を付けることができ、レビューした人全ての評価値の平均が本の詳細ページで表示されます。
また、登録した感想は本の詳細から見ることができます。
他人のレビュー等も観ることができます。（画像は割愛）
自分の担当箇所
主にアプリ開発です。 アプリ開発の中でも、Reduxを用いたデータ処理や、ほぼすべての画面のシステムの開発とUIのベースを開発しました。 ここでの、「システム開発」とは、具体的に次のようなものです。
- Http通信を用いたShiworiServerやGoogleBooksAPIに対するデータのpost/get/delete
- 特定の動作をする（例：ボタンを押す）と画面遷移する
- 特定の動作後に何かする（Http通信とか）
- ReduxStore（アプリ内保存データ保管庫）に対する情報の取得・変更などの処理
どちらかというとアプリの中でもバックエンド側でした。
UIについては、ベースとなるレイアウトを自分が作成し、もう一人のアプリ担当に綺麗にしてもらいました。
UI改善前と改善後の比較画像
UIのベース
改善後
自分の思ってた10倍ぐらいUIがユーザに与える印象が違うので、かなり衝撃的でした。UI大事、すごい。
感想
組み込みマイスター2年目。今年は、「しおりをIoTにする」という明確な目標が初期からあったので、開発が凄くやり易かったです。
4人でのチーム開発でしたが、毎週の会議や、週報などを実施したのでお互いの進捗についてのコミュニケーションもよく取れてよかったと思っています。
調べた限り、本のしおりのIoT化は、まだ誰もやっていませんでした。
その分難しかったですが、とても楽しかったです。
作品審査員やサポーターからのフィードバックには、次のようなものがありました。
- 目新しい・面白い・着眼点が良い
- 実用性が高い
- プロダクトデザインの良さ
- ユーザビリティ―のテストの実行
- 可視化した読書量はデータ、他への応用について
- ハードの小型化について
これらを活かしてまた来年に繋げるか、全く違うものにチャレンジするか分かりませんが、来年も組み込みマイスターには参加したいです。
自分が担当したReactNativeは、ゲーム以外のアプリならだいたい作れるみたいで、Instagram,Twitter等にも使われているようです。実際に身近で使われている言語での開発、かつアプリ開発は初めてだったので、とても楽しかったです。良い経験になりました。
個人的には、UIの大切さと、バックエンド（例：検索・ユーザログイン）のフローの多さに驚きました。 UIは上記の比較画像を見ればわかると思います。
キーワード検索 >> 結果が表示のような処理や、ユーザ登録やユーザログイン等で自分が想像していた以上に裏でシステムが動いていることを知りました。最近バックエンドに興味を持ったきっかけでもあります。
自分が担当したReactNative開発の詳細はまた記事にすると思います。
最後に
同じ開発メンバーだったyryr君が電子ペーパー周りのことを書いてくれたので参考に。
