レビュー1

[sititou70]

abstract

概要の役割は，読み手に研究の提案（そしてその面白さ）をできるだけ早く・簡単に理解してもらうことです．そのような文章を書く上で，次のようなことが大切です

1. 必要な情報だけをシンプルに書く
2. 適切な抽象度で説明する
3. わかりやすい文章を書く

現状の概要では，本研究の面白さが読み手にうまく伝わりません．そのため，全体的に書き直す必要があると思います．

近年，様々な分野においてロボットの活用が拡がっている．このロボットを制御するシステムの開発において，ソフトウェアフレームワークの一種である ROS を用いる機会が増加している．ROS では，ノードと呼ばれる機能モジュールを複数組み合わせることでシステムの構築を行う．ロボット制御システムの開発に ROS を用いることで，OSS ノードのような第三者が実装したノードをシステムに導入することが容易になり，開発効率の向上が期待できる．

• 背景としては長すぎます．もっと必要な情報のみを抽象的に伝えるべきです．
• 主張の量が多すぎるので，あまり関係のない話題で読者を振り回している印象があります．
  • たとえば…
  • あなた「ロボットの活用が広がっている」
    • 読者「（なぜ広がっているのかな）」「（どんな活用例があるのかな）」
  • あなた「このロボットを制御するシステムの開発において…」
    • 読者「（システム開発の話かよ）」
  • この場合，はじめからシステム開発の話をすれば良いのではないでしょうか？例えば「OSS ノードを組み合わせることによるロボットアプリケーションの開発が一般化している」というような…
• 開発効率が向上した理由について，「ROS によって OSS ノードを簡単に導入できる」からだと主張していますが，この主張は正しいですか？個人的には，「たくさんの OSS ノードが提供されているから」だと思います．言い換えれば，ROS のおかげというよりは ROS コミュニティのおかげというか…

しかし，OSS ノードがシステム内に混在することで，組み込みシステムの限られた計算資源(CPU,メモリ,ネットワーク帯域等)の消費量に関する見積もりが困難になる．

なぜですか？説明が足りません

本研究では，OSS ノードによるシステムへの想定外の負荷を防ぐことを目的として，ノードを対象としたサンドボックスの実現を提案する．

提案して終わりではなく，その提案によって「〇〇が可能になる」とか「〇〇が △％減少した」とか，もっと本研究をアピールする必要があります．

背景

近年，様々な分野においてロボットの活用が拡がっている\cite{Pepper}\cite{RoBoHoN}．このロボットのシステム開発において，Robot Operating System(ROS)を用いる機会が増えている．

ROS とは，ロボット開発を効率化するアプリケーションフレームワークのことであり，ノードと呼ばれる機能モジュールを複数組み合わせることでシステムを構築する．機能モジュールとは，独立した機能を持つ部品のようなもののことを指す．

ノードを機能モジュールだと説明し，さらに機能モジュールの説明をするのは冗長だと思います．最初からノードの説明をすれば良いのでは？

この説明だけでは，ノードがなんなのかいまいちわかりません．「ノード」という概念が本研究にとってとても重要なものなら，例示等を使ってより具体的に説明する必要があるでしょう

ノードは Linux におけるプロセスに相当し，その多くはオープンソースソフトウェア(OSS)として公開されている．

プロセスに「相当する」という表現は曖昧です．ノードはプロセスなのですか？それとも，説明のためにプロセスに例えただけですか？また，なぜ急に Linux の話が出てきたのですか．話の流れが悪い気もします．

「ノードが OSS として公開されている」とはどういうことですか．説明が足りなすぎると思います．おそらく「様々なロボットに必要な共通の機能（ここでも例があるといいですね）は，OSS のノードとして ROS コミュニティから提供されている」と言いたいのだと思いますが，だとしたらそのように書くべきです．

そのため，フルスクラッチで機能を実装していた従来のロボット開発に比べて，OSS ノードを用いた開発は高速かつ革新的であることから，現在のロボット開発には不可欠なフレームワークとなっている．

「革新的」は少し主観的すぎませんか？

「不可欠」は言い過ぎな気もします．ROS を用いないロボット開発も普通にあるので．

ROS には ROS 1 と ROS 2 が存在しており，ROS 2 は単に ROS 1 の最新版として開発されているものではなく，あくまで別物として開発されている．

この主張は必要ですか？

表現がわかりづらい気がします．「ROS2 は ROS1 の最新版ではない」や「ROS1 と ROS2 は別物」とありますが，そりゃ別の名前がついているんだから別物だろうという風にもとれます

ROS 2 では，ROS 1 で抱えていた問題点や ROS 1 で出来なかったことを可能にするために，通信プロトコル等アーキテクチャが大きく変更されている．

「ROS1 で出来なかったこと」とはなんですか？読者は，あなたの書いたあらゆるキーワードに興味を持つ可能性があり，それを説明しないままにしておくことは良くありません．

そのため，ROS 1 で開発したシステムを ROS 2 に移行する作業があるため，現在のロボット開発では ROS 1 を用いることが主流となっている．

この主張は正しいのでしょうか？そもそも，これまで ROS1 で作られたロボットを ROS2 に以降する必要があるんですか？

1 文で「ため」を 2 回使うのは気持ち悪いですね．主観ですが．

しかし，ROS 2 にはサポート OS の増加や開発に使用するプログラミング言語のバージョン更新等があるため，今後は ROS 2 の利用拡大が予想される．そのため，本研究では ROS の最新バージョンである ROS 2 を使用する．

「ROS 2 にはサポート OS の増加〜がある」や「ROS 2 には〜プログラミング言語のバージョン更新等がある」など，日本語として意味がわからない部分があります

また，そもそも ROS2 を研究対象とする理由は省略可能かもしれません．（ROS2 そのものの説明は必要だと思いますが）

課題

ロボットの高機能化に伴って，ロボット制御システムにおける脆弱性の報告が増えている．特に，多種多様な OSS ノードの開発が進められている\cite{AutoWare}ROS では深刻な問題となる．

「ともなって」は一般的にひらがなで書くような気がします．要確認ですが

「\cite{AutoWare}」を引用する意図がわかりません．多種多様な OSS ノードの開発が進められている根拠として引用したのですか？もしそうだとしても，この引用元は適切ではないと思いますが…

「ロボット制御システムにおける脆弱性の報告が増えている」の根拠となる引用がほしいです．

「ロボット制御システムにおける脆弱性の報告が増えている」から「ROS では深刻な問題となる」とは自明に言えない気もします．説明を追加する必要があるかもしれません．

ROS では，第三者が作成したノードの動作がシステム内の他のノードの動作に影響を与える可能性がある．

具体例がほしいです

特に，デバイス上で共有利用している計算資源である CPU，メモリ，ネットワーク帯域幅の消費量は，各ノードが必要とする計算資源消費量を事前に見積もることが難しい．

なぜ難しいのですか？理由がほしいです．

また，ここで「見積もりは難しい」と言っておきながら，提案手法では見積もりを行うんですよね？何が難しくて，それを本研究ではどのように乗り越えたのかが知りたいです．

そもそも，脆弱性の話はどこへ行ったのですか？話の流れが見えません

加えて，現在の ROS システムでは，ノード毎の計算資源の管理を行うための機構が備わっていないため，ROS の分散環境におけるノードの割り当てが不均衡になり，計算資源を効率的に利用できない\cite{ResourceManeger}．

「加えて」は今までの主張を補強することを述べるときに使います．ここでは不適切です．

図 1 は，実際に OSS ノードを取り入れたロボット制御システム(ドローン)のイメージであり，フルスクラッチで実装した移動制御ノード，位置情報取得ノードに加え，OSS である画像処理ノードを取り入れたシステムである．

図表の参照は TeX の機能で自動的に挿入できます．

この説明と，前の文章とのつながりがわかりません．読み手としては「いきなりなんの説明が始まったんだ？」というかんじです．話の流れを意識しましょう

図から，OSS 画像処理ノードがシステム内の計算資源を専有してしまい，その影響を受けた移動制御ノードは必要分の計算資源を与えられていないことがわかる．

主観ですが，「図から〜がわかる」は，実験結果等を指して何か考察を展開するときに使うのであって，ここでは不適当な気がします．そもそも，この図はあなたが「必要分の計算資源を与えられていないことがわかる」ように作ったものなので，わかるのは当然では？と感じました．

そのため，ロボット制御システム(ドローン)の動作が不安定になっている．このように，ロボット制御システムで利用可能な計算資源の量には上限があるため，ROS では，OSS ノードのような第三者が作成した計算資源消費量の予測できないノードが，システム内の他のノードの動作に影響を与える可能性がある．

一般的に全角のカッコを使うのではないでしょうか？確認して下さい

最後が「システム内の他のノードの動作に影響を与える可能性がある．」で終わっていますが，話が循環していないでしょうか？本段落の文章の構造をもう一度見直してみて下さい．

\begin{figure}[h]
\centering
\includegraphics[width=7cm]{img/図 1.pdf}
\end{figure}
\begin{center}図 1 ロボット制御システムの例\end{center}

図表のマークアップが適切でないように見えます．これでは，テンプレートのスタイルファイルが意図する体裁にならないのではないですか？また，図番号を手打ちしているのも非効率です．もう一度 TeX の仕様を確認して下さい．

提案する理論

本研究では「理論」ではなく「手法」のほうが無難でしょう

前章までで述べたとおり，ROS を用いたロボット制御システムの開発において OSS ノードを用いることは，計算資源消費量を予測できないが故にシステム内の他のノードの動作に影響を与える可能性があるという課題がある．

「OSS ノードを用いることは〜課題がある」は，主語と述語が対応していません．

「計算資源消費量」とは，どの計算資源消費量ですか？システムですか？ノードですか？OSS ノードですか？

「他のノード」とは，「どれの他」ですか？曖昧です．OSS ノード以外のこと？

本研究では，OSS ノードによるシステムへの想定外の負荷を防ぐことを目的として，システム内の各ノードを対象としたサンドボックスを作成し，計算資源消費量を実行時に制御することを提案する．ここでのサンドボックスとは，計算資源の最大消費可能量に制限をかける機構のことを指す．

サンドボックス設定のフロー

まず，サンドボックスの設定前に，シミュレータを用いてシステム内に存在する各ノードが使用する計算資源量の見積もりを行う．

細かいのですが，「システム内に存在する」は冗長です．なぜなら，システム内に存在しないノードはないからです．細かい部分に気を使い，読みやすい文章を心がけましょう

次に，見積もりの結果を踏まえて，サンドボックスで制限する計算資源の設定を行い，各ノードに対して設定が反映されたサンドボックスを導入する．

「計算資源の設定」とはどういうことでしょうか？「計算資源量の設定」とか「資源量の上限を設定」なら意味がわかりますが…

サンドボックスは「導入する」のでしょうか？細かいですが，表現が気になります

冗長な表現が多いと思います．

これにより，図 2 のように OSS 画像処理ノードの使用可能な計算資源量の上限がコントロールされ，移動制御ノードは必要とする分の計算資源を使用できる．そのため，不安定であったロボット制御システム(ドローン)の動作が安定するようになる．

これは，例を説明しているのですか？それとも，本提案手法はドローンのためのものなのですか？

\begin{figure}[h]
\centering
\includegraphics[width=7cm]{img/図 2.pdf}��
\end{figure}
\begin{center}図 2 サンドボックス導入後のロボット制御システムの例\end{center}

↑なんだか変な文字が入っています

ノードの計算資源消費量見積もり手法

ノードの計算資源消費量の見積もりは，ノード動作中の各計算資源消費量を一定間隔で記録する機能を ROS フレームワークに組み込み，Gazebo を用いてシミュレーションを行うことで実現する．

言いたいことが順序よく表現できていない感じです．

• ロボットを実環境で動作させる前に，各ノードが消費するおおよその計算資源量を見積もる必要がある
• そのために，Gazeboによってロボットを仮想環境で動作させる
• これにより，各ノードを擬似的に動作させ，その動作中の各計算資源量を計測することで，計算資源量を見積もる

という流れを参考にしてみて下さい（無論，これは箇条書きなので，これをそのまま本文に使用することはしないで下さい）

Gazebo とは，ROS で一般的に用いられるシミュレーションツールのことであり，これを用いることでシステムを模擬的に動かすことができる．

Gazebo の説明が不十分です．

「模擬的」はこの分野ではあまり使わない言葉かもしれませんね

この計算資源消費量の記録には，Linux の procfs と，帯域幅監視ツールの一つである NetHogs を使用する．procfs とは，プロセス情報の擬似ファイルシステムであり，ここでは CPU とメモリの使用率の表示に使用する．

「表示」とありますが，どこに表示するのですか？「計測」とか「取得」ではダメですか？

また，NetHogs は，プロセス毎のトラフィックを表示するものであり，ここではネットワーク帯域幅の表示に使用する．

「トラフィック」というよりは「トラフィック量」ではありませんか？

これらの出力結果の必要な部分のみを取りまとめたファイルを作成・保存し，一定間隔でデータの更新を行い，このファイルの内容を基に見積もりを行う．

「ファイルを作成・保存し，一定間隔でデータの更新を行い，このファイルの内容を基に見積もりを行う．」は，複雑かつ冗長な表現だと思います

「基に」は，「元に」や「本に」との表記ゆれを防ぐために，ひらがなのほうが良いかもしれません．

サンドボックスの作成

本研究におけるサンドボックス機構は，cgroup と tc コマンドを用いて，ノード毎の計算資源における最大消費量に対して制限を課すことで実現する．

「毎」は一般的にひらがなで表記すると思います．確認して下さい

「機構は〜実現する」は，個人的に少し違和感があり，冗長な表現だと思います．「本研究におけるサンドボックスとは，cgroup と tc コマンドを用いて，ノード毎の計算資源における最大消費量に対して制限を課す機構である」ではダメですか

cgroup とは，ROS の動作プラットフォームである Linux 上で動作するコンテナ型仮想化機構の一つであり，プロセスグループの計算資源の利用を制限・隔離する Linux カーネルの機能のことを指す．

cgroup とはコンテナ型仮想化機構でしょうか？もういちど確認して下さい．

「プロセスグループ」は未定義かもしれません

「計算資源の利用を隔離する」とはどういうことでしょうか？正しくない説明の可能性があります

また，tc コマンドは，Linux カーネル内の通信を制御するものであり，ネットワークインターフェースに対してネットワーク帯域制限を設定する機能を指す．

個人的に，「（機能）を指す」という表現はここでは適切でない気がします．「機能である」ではダメでしょうか？

「カーネル内の通信を制御する」は，曖昧な表現です．どのように制御するのかを説明するか，この説明自体が必要ないなら削除しましょう．

cgroup については，cgroup v1 の改良版である cgroup v2 を主に使用する．しかし，cgroup v2 は徐々に実装を進めている段階であるため，v1 で使用されていた機能全てを使えるわけではない．

「実装を進めている段階であるため」という表現は曖昧です．「実装を進めている」のは誰ですか？「比較的新しい機能」とか「実験段階の機能」，「不完全な機能」など，ふさわしい表現を考えてみて下さい

そもそも，なぜ cgroup v2 を使うのですか？すべて v1 を対象に開発すれば良いのでは？

そのため，cgroup v1 と v2 を共存させる形で使用する．cgroup の操作には，基本的に cgroupfs という擬似ファイルシステムを用いる．新たに cgroup を作成する際も，通常のファイルシステムを扱うように mkdir コマンドを用いることが可能である．また，制限を行う際には，cgroup のサブシステムを用いる．サブシステムとは，linux のプロセスに作用するリソースコントローラーのことを指す．

リソースコントローラーとは何ですか

具体的に cgroup を用いてノードの計算資源消費量の制限を行うには，まず cgroup を作成し，ノードの PID を cgroup.procs に登録する．その後，計算資源消費量の上限値を cpu.max 等のサブシステムに書き込むことで，CPU 使用率とメモリ使用率の制限を完了できる．また，ネットワーク帯域幅の制限についても，cgroup の net_cls サブシステムを用いて，パラメータとネットワークインタフェースを設定することで，制限を完了できる．これらの設定を行うことで，本研究におけるサンドボックスの作成とする．

「サンドボックスの作成とする」は論文的な表現ではない気がします．「サンドボックスを作成する」でいいのでは？

関連技術

本研究の関連技術として，一般にコンテナと呼ばれる，アプリケーションコンテナがある．このアプリケーションコンテナの一例として，Docker\cite{Docker}が存在する．

この説明だと，Docker は一般的に「コンテナ」と呼ばれていることになりますが，本当ですか？Docker は一般的にコンテナ型（仮想化）技術と呼ばれているのでは？

Docker は，Linux カーネルの機能である cgroup と namespace を用いて計算資源の制限と分離が可能であることに加え，コンテナの実行に必要なパッケージの共有が容易であるなど，高い機能性を持つ．

「機能性」はかなり曖昧で一般的ではない言葉です．「たくさんの機能を持つ」ということを言いたいのなら，そのように書きましょう

しかし，Docker では，本研究において求めている以上に機能があるため，オーバーヘッドがかかる．そのため，本研究では，コンテナ型仮想化機構の一つである cgroup と linux の tc コマンドを用いて，ノードの計算資源消費量の制限に特化したサンドボックスを作成する．

「オーバーヘッドがかかる」とありますが，理由がよくわかりません．Docker のどのような部分がオーバーヘッドとなるのですか．「機能が多いから」というのは理由として曖昧すぎます．また，前の文章から，「パッケージの共有が容易である」機能がオーバーヘッドの一要因のようにも読めますが，そんなことはないと思います．

Fukutomi らは，ROS 分散環境においてノードを動作させるホストマシン上の計算資源を効率的に利用するための計算資源管理機構を提案した\cite{ResourceManeger}．この研究では，計算資源使用率が一定に達したノードを動的に他のホストマシンに移行することで，分散環境上でも効率的にノードを動作させることを可能としている．このことから，ROS 分散環境における計算資源管理機構の運用には，計算資源の利用状況を逐一管理する必要があることがわかる．

「ROS 分散環境における計算資源管理機構の運用には，計算資源の利用状況を逐一管理する必要がある」ことの根拠が弱いです．この文章だと，「Fukutomi らがやっているから私の研究でも真似します」というように読めますが，そうではなくて根本的な理由を明確に述べる必要があります．

Fukutomi らの手法と本手法との違いを明確にする必要があります．このままでは「Fukutomi らの手法があれば，提案手法は必要ない」と思われるかもしれません．

まとめ

本研究では，OSS ノードがシステムに与える影響を最小限に抑えることを目的とする．この目的を達成するために，各ノードの計算資源消費量を実行時に制限するサンドボックス機構を実装する．具体的には，Gazebo シミュレータ上でノードを動作させ，Linux の procfs と帯域幅監視ツールの一つである NetHogs を用いて計算資源消費量を記録し，これを基に計算資源消費量の見積もりを行う．見積もり結果より，コンテナ型仮想化機構の一つである cgroups と tc コマンドを用いて，ノード毎の CPU，メモリ，ネットワーク帯域の各計算資源における最大消費量に対して制限を課すことでサンドボックス機構を実現する．

今後の課題として，ノードの計算資源消費量の見積り手法がある．シミュレータ上でノードにどのような動作をさせるか，ノードを動かす期間をどうするかについて，基準を設ける必要がある．

「ノードを動かす期間」とは？

ここで設けた基準が正確でなければ，サンドボックスを用いてシステムの計算資源消費量に上限を設けていても，本研究が期待する効果は得ることができないため，最も重要な部分である．

• 「基準が正確」とはどういうことですか？何をもって「正確」なのですか？
  • 基準が「各ノードの真の計算資源量」に正確だということかもしれませんが，そもそもサンドボックスの基準は各ノードの計算資源量と同じ（ギリギリ）で良いのでしょうか？
  • 見積もり結果をもとに，どのようにして基準を定めるのか，本研究が期待する効果を得るための基準とは何なのか，よりしっかりと考察する必要があるかもしれません．（その考察次第では，見積もりの正確性が必要なくなる可能性もあります）

また，計算資源消費量の記録を更新する間隔についても検討が必要である．

「記録を更新する」というのは，すこし不思議な表現です．記録とは変わらないものですよね？「記録する間隔」で良いでしょう．

知能システムコースにおける本研究の位置づけ

知能システムコースでは，知能に関する課題および人と人工物の新たな関係性を構成論的な手法で追究する観点から、人の知的能力や機能の解明、数理モデル化、実世界への実装に関する具体的な課題に取り組み、その結果の評価を通じて、新しい方法論や、学問領域を切り拓く能力を育むことをカリキュラムポリシーとして掲げている．\本研究では，ROS という実世界への実装を補助する技術における課題を構成論的な手法で追究している．今後は実装を行い，サンドボックス導入前と導入後で各ノードの計算資源消費量がどう変化したか，またシステムの動作パフォーマンスがどう変化するかを評価する．

\begin{thebibliography}{99}
\bibitem{Pepper}
SoftBank：特集 \textbar ロボット\textbar ソフトバンク，\入手先\textless https://www.softbank.jp/\\robot/special/\textgreater(参照2020-10-30)．
\bibitem{RoBoHoN}
SHARP CORPORATION：ロボホン，\入手先\textless https://robohon.com/co/\\introduction.php\textgreater(参照2020-10-30)．
\bibitem{RobotSecure}
齋藤慶太，森達哉：コンシュマー向けロボットの安全な運用に向けたセキュリティポリシー，コンピュータセキュリティシンポジウム 2017 論文集，Vol.2017，No.2，pp.1426-1433(2017)．
\bibitem{AutoWare}
Computing Platforms Federated \Laboratory：CPFL/Autoware_Toolbox，\入手先\textless https://github.com/CPFL/\\Autoware\_Toolbox\textgreater(参照2020-10-30)．
\bibitem{ResourceManeger}
Fukutomi,D.，Azumi,T.，Kato,S.，et al.：Resource Manager for Scalable \Performance in ROS Distributed \Environments，Proc.DATE 2019，pp.1088-1093，IEEE(2019)．
\bibitem{LinuxMan}
Michael Kerrisk:cgroups(7)-Linux manual page，man7.org，入手先\\textless https://man7.org/linux/man-pages/\\man7/cgroups.7.html\textgreater(参照2020-10-30)．
\bibitem{Docker}
Docker Documentation\textbar Docker \Documentation, 入手先\\textless https://docs.docker.com/\textgreater\\(参照2020-11-01)．
\end{thebibliography}
\end{document}

文献リストの作成にはbibtex 等を使うと楽です．