ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
ロボット用ミドルウェアとは一般的にはロボットのソフトウェアをモジュールに分割し、ソフトウェアモジュールを組み合わせてシステムを開発するためのフレームワーク、通信ライブラリのことを指します。
あるいはロボットのソフトウェア開発に有用なライブラリ群を指すこともあります。
ロボット用ミドルウェアのようなものが出てきたのは90年代前半にSPACEが出てきたあたりだろうけど、そんな昔のことは詳しく知りません。ちなみにSPACEはONC RPCによるリモート呼び出しによりモジュール間の連携を行っていたのでほとんど現在のロボット用ミドルウェアと仕組みは同じです。
ロボット用ミドルウェアと名乗るものが出始めたのが2000年前後にMCA、SmartSoft、OROCOS、Orca、ORiN、Player、RTミドルウェア、MIRO等がどこからともなく湧いてきたごろだろうと思いますが、そんな昔のことは知りません。
ちなみにOpen Robot Controller Architectureの略のORCAとシャチの学名から付けられているOrcaは別物です。一般的に知られているのは後者の方です。
2000年代半ばになるとMRDS、ROS、ASEBA、YARP、RSNP、ERSP、MARIE等の怪しい実装がわらわら出てきました。
MRDSはVPLによるビジュアルプログラミングができ、解説書も出ていたのでそれなりに知名度があったと思います。
ROSはPR2ベータプログラム等で普及活動に重点を置いていたような印象です。
RTMはOMG標準規格を取ることに力を入れていた感じです。
それでどうなったかというとROS以外消えました。
MRDSはMicrosoftがやる気をなくしたのかどうか知りませんが、まあ.NETの言語やVPLでロボットを開発する人なんてほとんどいないだろうし、プログラミング教材として残るという道はあったかもしれないけどそれもありませんでした。
RTMについては標準規格を持っていて勝てるならCORBAは大人気のはずだし、PythonよりもRubyの方が人気があるはずです。RTMは次世代ロボット知能化技術開発プロジェクトでいろいろ作っていたのに全部捨てたのがちょっともったいなかった感じです。
ロボット用ミドルウェアを使いたくて使う人はほぼいません。Moveit!等のツールを使うために仕方なくROSを使うというのが普通です。
2010年以降もCCA、MIRA、ISCSP等の胡散臭い実装が登場してはROSに蹴散らされてるか、もしくはだれにも認識されずに消えています。ISCSPなんて数人しか知らないと思う。
ROS2もROSに蹴散らされる予定です。まあ小さい業界の話だし、普及しているといってもそれなりですが。
上記のロボット用ミドルウェア対応のモジュールは大抵オープンソースで公開されていますが、今後はクローズドソース、シェアウェアも利用する方向になるのか。でもROSの方針とは違うのでそうならないかもしれません。
これからもオープンソースだけでやっていくとなるとどうやって収益化するのかということですが、それは散々問題視されているから簡単ではないのでしょう。JR北海道を黒字化させる方が簡単な気がする。つまりほぼ不可能という事。
考えられる方法としては、顧客の要求しているシステムをオープンソースから構築するシステムインテグレートで儲けるという手はあるかもしれません。
そのオープンソースの品質をだれが保証するんだという問題もあるかもしれないので、「ROSに何かあったら俺が責任を取る」とか言ってサポート料金を取るという手はあるかもしれません。
もしくはROS等で制御するハードウェアを売って儲けるという手段はあり、実際そういう商売をしている人はいますが、オープンソースがどの程度収益に影響しているかは不明です。
というわけで、現在はロボット用ミドルウェア(主にROS)を使ってどう収益化するかという方向に向かっており、概ね失敗しています。
個人的にはオープンソースから脱却したほうがいいと思う。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
あるいはロボットのソフトウェア開発に有用なライブラリ群を指すこともあります。
ロボット用ミドルウェアのようなものが出てきたのは90年代前半にSPACEが出てきたあたりだろうけど、そんな昔のことは詳しく知りません。ちなみにSPACEはONC RPCによるリモート呼び出しによりモジュール間の連携を行っていたのでほとんど現在のロボット用ミドルウェアと仕組みは同じです。
ロボット用ミドルウェアと名乗るものが出始めたのが2000年前後にMCA、SmartSoft、OROCOS、Orca、ORiN、Player、RTミドルウェア、MIRO等がどこからともなく湧いてきたごろだろうと思いますが、そんな昔のことは知りません。
ちなみにOpen Robot Controller Architectureの略のORCAとシャチの学名から付けられているOrcaは別物です。一般的に知られているのは後者の方です。
2000年代半ばになるとMRDS、ROS、ASEBA、YARP、RSNP、ERSP、MARIE等の怪しい実装がわらわら出てきました。
MRDSはVPLによるビジュアルプログラミングができ、解説書も出ていたのでそれなりに知名度があったと思います。
ROSはPR2ベータプログラム等で普及活動に重点を置いていたような印象です。
RTMはOMG標準規格を取ることに力を入れていた感じです。
それでどうなったかというとROS以外消えました。
MRDSはMicrosoftがやる気をなくしたのかどうか知りませんが、まあ.NETの言語やVPLでロボットを開発する人なんてほとんどいないだろうし、プログラミング教材として残るという道はあったかもしれないけどそれもありませんでした。
RTMについては標準規格を持っていて勝てるならCORBAは大人気のはずだし、PythonよりもRubyの方が人気があるはずです。RTMは次世代ロボット知能化技術開発プロジェクトでいろいろ作っていたのに全部捨てたのがちょっともったいなかった感じです。
ロボット用ミドルウェアを使いたくて使う人はほぼいません。Moveit!等のツールを使うために仕方なくROSを使うというのが普通です。
2010年以降もCCA、MIRA、ISCSP等の胡散臭い実装が登場してはROSに蹴散らされてるか、もしくはだれにも認識されずに消えています。ISCSPなんて数人しか知らないと思う。
ROS2もROSに蹴散らされる予定です。まあ小さい業界の話だし、普及しているといってもそれなりですが。
上記のロボット用ミドルウェア対応のモジュールは大抵オープンソースで公開されていますが、今後はクローズドソース、シェアウェアも利用する方向になるのか。でもROSの方針とは違うのでそうならないかもしれません。
これからもオープンソースだけでやっていくとなるとどうやって収益化するのかということですが、それは散々問題視されているから簡単ではないのでしょう。JR北海道を黒字化させる方が簡単な気がする。つまりほぼ不可能という事。
考えられる方法としては、顧客の要求しているシステムをオープンソースから構築するシステムインテグレートで儲けるという手はあるかもしれません。
そのオープンソースの品質をだれが保証するんだという問題もあるかもしれないので、「ROSに何かあったら俺が責任を取る」とか言ってサポート料金を取るという手はあるかもしれません。
もしくはROS等で制御するハードウェアを売って儲けるという手段はあり、実際そういう商売をしている人はいますが、オープンソースがどの程度収益に影響しているかは不明です。
というわけで、現在はロボット用ミドルウェア(主にROS)を使ってどう収益化するかという方向に向かっており、概ね失敗しています。
個人的にはオープンソースから脱却したほうがいいと思う。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
プラットフォーム、フレームワーク、ミドルウェア、ライブラリについて用語の意味の違いが分かりづらいのでメモしておきます。間違っていたらコメントで指摘してください。
ロボット界隈では「プラットフォームロボット」という用語を使いますが、これは新規機能の開発、追加が可能な基盤となるロボットのことを指します。
具体的にはRuby on Rails、OpenRestyなどが該当します。
ただ、ソフトウェアフレームワークはユーザーの作成したアプリケーションの機能をフレームワーク側のメインループから呼び出す「制御の反転」の構造になっている必要があります。
論文などでROSはフレームワークであると書いてあるものがありますが、これは厳密には間違いという事になります。
OpenRTM-aistやChoreonoidはフレームワークに該当します。
Lua VMがプラットフォーム、OpenRestyがフレームワークという事です。多分。
.NET Frameworkはフレームワークで、その実行環境のCLRがプラットフォームという事になります。
というか、ほとんどの場合はアプリケーション、OS以外のソフトウェアのことを指します。
具体的にはOpenCV、OpenGLなどが該当します。
Java VMやLua VM等のプログラミング言語の実行環境も該当します。
ただし、ミドルウェアはその名の通りOSとアプリケーションの中間に位置するソフトウェアのため、OSが無い環境のライブラリはミドルウェアには該当しません。例えばArduino用のライブラリはミドルウェアではありません。
フレームワークの場合はフレームワークが主となりますが、ライブラリはアプリケーションに機能を提供するだけのため、アプリケーションが主になります。
適当にソフトウェアを分類すると以下のような感じだろう。
所々どこに分類すればいいのか分からないものもあります。
まずOpenRTM-aistはスタンドアロンRTCとして起動すればライブラリ、RTCDで起動すればフレームワークに該当しそうなので仕分けが難しいです。
これがLove2Dのようにアプリケーションのみの提供であればライブラリには該当しません。
QtはQt Creatorを使えばフォームに追加したウィジェットから直接スロット関数をいじることでフレームワーク的な使い方ができるので、フレームワークでもあると言えます。
Luaは単体で実行したらただのプラットフォーム、組み込んで実行すればミドルウェアでもあるということになります。組み込む側からすればライブラリのようにも見えます。
というわけでライブラリ、フレームワーク、プラットフォームを図で表すと以下のような感じになりますが、プラットフォームの定義がよく分からないので間違っているかもしれません。
- プラットフォーム
ロボット界隈では「プラットフォームロボット」という用語を使いますが、これは新規機能の開発、追加が可能な基盤となるロボットのことを指します。
- フレームワーク
具体的にはRuby on Rails、OpenRestyなどが該当します。
ただ、ソフトウェアフレームワークはユーザーの作成したアプリケーションの機能をフレームワーク側のメインループから呼び出す「制御の反転」の構造になっている必要があります。
論文などでROSはフレームワークであると書いてあるものがありますが、これは厳密には間違いという事になります。
OpenRTM-aistやChoreonoidはフレームワークに該当します。
Lua VMがプラットフォーム、OpenRestyがフレームワークという事です。多分。
.NET Frameworkはフレームワークで、その実行環境のCLRがプラットフォームという事になります。
- ミドルウェア
というか、ほとんどの場合はアプリケーション、OS以外のソフトウェアのことを指します。
具体的にはOpenCV、OpenGLなどが該当します。
Java VMやLua VM等のプログラミング言語の実行環境も該当します。
ただし、ミドルウェアはその名の通りOSとアプリケーションの中間に位置するソフトウェアのため、OSが無い環境のライブラリはミドルウェアには該当しません。例えばArduino用のライブラリはミドルウェアではありません。
- ライブラリ
フレームワークの場合はフレームワークが主となりますが、ライブラリはアプリケーションに機能を提供するだけのため、アプリケーションが主になります。
適当にソフトウェアを分類すると以下のような感じだろう。
| ソフトウェアの分類 | プラットフォーム | フレームワーク | ミドルウェア | ライブラリ |
| OpenRTM-aist | 〇 | 〇 | △ | |
| omniORB | 〇 | 〇 | ||
| Qt | △ | 〇 | 〇 | |
| ROS | 〇 | 〇 | ||
| Choreonoid | 〇 | |||
| ODE | 〇 | 〇 | ||
| OpenCV | 〇 | 〇 | ||
| Lua VM | 〇 | 〇 | △ | |
| VMWare | 〇 |
まずOpenRTM-aistはスタンドアロンRTCとして起動すればライブラリ、RTCDで起動すればフレームワークに該当しそうなので仕分けが難しいです。
これがLove2Dのようにアプリケーションのみの提供であればライブラリには該当しません。
QtはQt Creatorを使えばフォームに追加したウィジェットから直接スロット関数をいじることでフレームワーク的な使い方ができるので、フレームワークでもあると言えます。
Luaは単体で実行したらただのプラットフォーム、組み込んで実行すればミドルウェアでもあるということになります。組み込む側からすればライブラリのようにも見えます。
というわけでライブラリ、フレームワーク、プラットフォームを図で表すと以下のような感じになりますが、プラットフォームの定義がよく分からないので間違っているかもしれません。
とりあえずRTMコンテストの感想を書きます。
今年はロボットでプレゼンをするという前代未聞の発表があったわけですが、まさか本当にやるとは・・・。予想はしていたけど、マジでやるのかよと思いました。
今年の作品の中で出来のわりに評価が低ったのはこの作品ですかね。
審査員のほとんどはROSも分かるのでROSだからは関係ないと思いますが、スマホからロボットを操作する事例がよくなかったかもしれません。
rosbridgeを使ってWEBブラウザからROSノードを操作する事自体はそんなに難しくないだろうし、複数のマシン上のROSノードを管理できるというのが今一つピンとこない感じがします。
RSNPでは複数のロボットを管理するような事例がありますが、あんな感じのものを出したら多少変わっていたかもしれません。
後、表彰式のスライドでタイトルを間違えてすみませんでした。焦って作ったので間違えました。
この作品は発表でしくじったのがまずかったかもしれません。Macは発表で使うべきではありません。Appleは倒産したほうがいいです。
内容だけ見れば別にこれが最優秀賞でもよかったとは思いますが、なんだかこの作品は最優秀賞が合わない雰囲気なんだよなあ。新しいことが一つもないので面白みがない感じです。
ほかはこんなもんじゃないですかね。
今年は内容がひどい作品が受賞するという事は無かったと思います。
それにしてもMacがプレゼンでトラブルを頻発するのはちょっと考えたほうがいいよなあ、と思いました。
今年はロボットでプレゼンをするという前代未聞の発表があったわけですが、まさか本当にやるとは・・・。予想はしていたけど、マジでやるのかよと思いました。
今年の作品の中で出来のわりに評価が低ったのはこの作品ですかね。
審査員のほとんどはROSも分かるのでROSだからは関係ないと思いますが、スマホからロボットを操作する事例がよくなかったかもしれません。
rosbridgeを使ってWEBブラウザからROSノードを操作する事自体はそんなに難しくないだろうし、複数のマシン上のROSノードを管理できるというのが今一つピンとこない感じがします。
RSNPでは複数のロボットを管理するような事例がありますが、あんな感じのものを出したら多少変わっていたかもしれません。
後、表彰式のスライドでタイトルを間違えてすみませんでした。焦って作ったので間違えました。
この作品は発表でしくじったのがまずかったかもしれません。Macは発表で使うべきではありません。Appleは倒産したほうがいいです。
内容だけ見れば別にこれが最優秀賞でもよかったとは思いますが、なんだかこの作品は最優秀賞が合わない雰囲気なんだよなあ。新しいことが一つもないので面白みがない感じです。
ほかはこんなもんじゃないですかね。
今年は内容がひどい作品が受賞するという事は無かったと思います。
それにしてもMacがプレゼンでトラブルを頻発するのはちょっと考えたほうがいいよなあ、と思いました。
最近の投稿に毒が足りないというありがたいお言葉をいただいたので、残りの3作品はやや辛辣に行きます。
まずはこの作品の感想を書きます。
最初に一言いうと、rowmaの発音が分からないので教えてください。
この作品のコンセプトは「簡単に誰でも使えるシステム」ということですが、まずコマンドラインの操作ができない人がROSを使ってはいけません。これは一般常識です。
遠隔操作や監視ができるという事を挙げていますが、セキュリティに穴をあけているだけです。
WEBブラウザでの操作中にエラーになるとエラー発生個所を表示するのはやめてほしいなあとは思いました。というか、画面上に表示される円を動かしただけでにエラーが発生するのは問題だなあ。
このソフトウェアはマニュアル通りにrosrun rowma_ros rowmaを実行すると外部のサーバーに繋ぎに行くようなのですが、その辺の仕組みがマニュアルからは分かりづらいです。
ソースコードについては・・・、謎のprint文とか細かい点で気になるところはあるけど、今のところ別に言うことないなあ。どうてもいいけど、この作品ではrosbridgeが重要な要素になっている気がするけど、何故か使用技術でsocket.ioについてだけ触れているのが気になります。
まあデバッグを頑張ってください。
一言言っておくと、別のこの作品の評価は低くないです。まあでもマニュアルがなあ、という評価です。
次にこの作品の感想を書きます。
マニュアルはいったいどこなんでしょうね・・・。
仕様書らしきものがありますが、OdomViewerの概要説明が間違っているように見えます。
独自データ型の意味が不明です。そもそもPose3D型にロール・ピッチ・ヨーの回転角が入っているので、そこにクォータニオンの情報も入れる意味が分かりません。Point2D型でよかったのでは？
ソースコードを読んだ感じでは、コンフィギュレーションパラメータSensorNumberはどこでも使われていないため、仕様書に書いてあることは嘘ではないかと思います。
そしてやっぱりPose3D型の回転角には何も入れていません。
わざわざVisualOdometryクラスのInit関数で初期化失敗したときの処理も考えているのに、onActivate関数でエラーに遷移しないのは何故なのか。
よほど時間がぎりぎりだったのか、やっつけで作った部分が目立ちます。
まずはマニュアルを作ったほうがいいです。
最期にこの作品の感想を書きます。
評価不能です。終わり。
・・・まあ一応コメントをしておくと、MIND STORMとは何でしょうか？
LEGOのことだとすると、MINDSTORMSなのでタイトルがおかしいです。
いやでもLEGOだとすると意味が通らないような気がするので別物かもしれません。
これ以上語ることがないので終わります。
これで一応全作品の感想を書き終わりました。
実は一つ書いてないけど、まああれはいいか。
まずはこの作品の感想を書きます。
最初に一言いうと、rowmaの発音が分からないので教えてください。
この作品のコンセプトは「簡単に誰でも使えるシステム」ということですが、まずコマンドラインの操作ができない人がROSを使ってはいけません。これは一般常識です。
遠隔操作や監視ができるという事を挙げていますが、セキュリティに穴をあけているだけです。
WEBブラウザでの操作中にエラーになるとエラー発生個所を表示するのはやめてほしいなあとは思いました。というか、画面上に表示される円を動かしただけでにエラーが発生するのは問題だなあ。
このソフトウェアはマニュアル通りにrosrun rowma_ros rowmaを実行すると外部のサーバーに繋ぎに行くようなのですが、その辺の仕組みがマニュアルからは分かりづらいです。
ソースコードについては・・・、謎のprint文とか細かい点で気になるところはあるけど、今のところ別に言うことないなあ。どうてもいいけど、この作品ではrosbridgeが重要な要素になっている気がするけど、何故か使用技術でsocket.ioについてだけ触れているのが気になります。
まあデバッグを頑張ってください。
一言言っておくと、別のこの作品の評価は低くないです。まあでもマニュアルがなあ、という評価です。
次にこの作品の感想を書きます。
マニュアルはいったいどこなんでしょうね・・・。
仕様書らしきものがありますが、OdomViewerの概要説明が間違っているように見えます。
独自データ型の意味が不明です。そもそもPose3D型にロール・ピッチ・ヨーの回転角が入っているので、そこにクォータニオンの情報も入れる意味が分かりません。Point2D型でよかったのでは？
ソースコードを読んだ感じでは、コンフィギュレーションパラメータSensorNumberはどこでも使われていないため、仕様書に書いてあることは嘘ではないかと思います。
そしてやっぱりPose3D型の回転角には何も入れていません。
わざわざVisualOdometryクラスのInit関数で初期化失敗したときの処理も考えているのに、onActivate関数でエラーに遷移しないのは何故なのか。
よほど時間がぎりぎりだったのか、やっつけで作った部分が目立ちます。
まずはマニュアルを作ったほうがいいです。
最期にこの作品の感想を書きます。
評価不能です。終わり。
・・・まあ一応コメントをしておくと、MIND STORMとは何でしょうか？
LEGOのことだとすると、MINDSTORMSなのでタイトルがおかしいです。
いやでもLEGOだとすると意味が通らないような気がするので別物かもしれません。
これ以上語ることがないので終わります。
これで一応全作品の感想を書き終わりました。
実は一つ書いてないけど、まああれはいいか。
今年はSI2019でRTM講習会があるのですが、参加登録数はかなり不調です。
四国開催なのに四国からの参加者0は笑えないのですが。
なんでも同じ日にROS勉強会を開催するという動きがあるらしいですが、そっちの方が人が集まったらやだなあ、と思っているところです。僕も参加申し込みをしようと思ったのですが、その後何の情報もないです。
それはさておき、まずはこの作品の感想を書きます。
教材は今までのコンテストに腐るほどあったのであまり気が進まないのですが、これは最初から教材を作成するつもりでやっているように感じるのでいいのかもしれません。
あまり突っ込む点はないなあ。I2Cはフィリップじゃなくてフィリップスだろとか、3日目と4日目のタイトルが微妙に違うけど何か意味あるのかとか、細かい話くらいですかね。
ソースコードについてはコンフィグレーションパラメータを使ってほしいとかありますけど、作成例なのでこれでもいいかもしれません。
ただPython3に対応していないのは残念です。
何か新しい発想があるわけではないので、他の人がどういう評価にするかは気になります。
次にこの作品の感想を書きます。
さて上の作品は最初から教材を作成しているのでいいと言いましたが、この作品は教材を取って付けた感があるので印象がよくないです。
教材といっていますが学習する手順が示されていないので、頑張った割には評価は厳しくなるかもしれません。必要なハードウェアについても具体的に必要な製品のページのリンクを貼るなりした方がいいです。
後は動画があったほうが分かりやすいと思いました。
その辺を改善出来たら最優秀賞もありそうなのになあ。
最後にこの作品の感想を書きます。
まずプロジェクトページの画像を見て思ったのが、SysMLで設計したとか強調する必要ある？という点です。まあそれはいいか。
ソースコードを見て思ったのは、マジックナンバーが気になります。今年の作品はマジックナンバーが問題になるケースが多い気がする。
PresentationManageSystem.pyで変数を1や2と比較しているのですが、意味が不明です。
あとサービスインターフェースをいくつか定義していますが、説明不足であり動作が分かりません。
ちょっとonExecute関数に書きすぎだと思う。onExecute関数内でSleepしている箇所がありますが、意味がよく分かりません。
見たところSpeechManageSystem.pyのStartFlag==1の時の処理は1回しか実行しないようですが、なぜonActivated関数で処理しないのか。全体的に処理の流れが分かりづらいです。
まあでも上の作品が改善しないようであればこの作品のほうが評価が高いように思います。
今日はこのぐらいにしておきます。
四国開催なのに四国からの参加者0は笑えないのですが。
なんでも同じ日にROS勉強会を開催するという動きがあるらしいですが、そっちの方が人が集まったらやだなあ、と思っているところです。僕も参加申し込みをしようと思ったのですが、その後何の情報もないです。
それはさておき、まずはこの作品の感想を書きます。
教材は今までのコンテストに腐るほどあったのであまり気が進まないのですが、これは最初から教材を作成するつもりでやっているように感じるのでいいのかもしれません。
あまり突っ込む点はないなあ。I2Cはフィリップじゃなくてフィリップスだろとか、3日目と4日目のタイトルが微妙に違うけど何か意味あるのかとか、細かい話くらいですかね。
ソースコードについてはコンフィグレーションパラメータを使ってほしいとかありますけど、作成例なのでこれでもいいかもしれません。
ただPython3に対応していないのは残念です。
何か新しい発想があるわけではないので、他の人がどういう評価にするかは気になります。
次にこの作品の感想を書きます。
さて上の作品は最初から教材を作成しているのでいいと言いましたが、この作品は教材を取って付けた感があるので印象がよくないです。
教材といっていますが学習する手順が示されていないので、頑張った割には評価は厳しくなるかもしれません。必要なハードウェアについても具体的に必要な製品のページのリンクを貼るなりした方がいいです。
後は動画があったほうが分かりやすいと思いました。
その辺を改善出来たら最優秀賞もありそうなのになあ。
最後にこの作品の感想を書きます。
まずプロジェクトページの画像を見て思ったのが、SysMLで設計したとか強調する必要ある？という点です。まあそれはいいか。
ソースコードを見て思ったのは、マジックナンバーが気になります。今年の作品はマジックナンバーが問題になるケースが多い気がする。
PresentationManageSystem.pyで変数を1や2と比較しているのですが、意味が不明です。
あとサービスインターフェースをいくつか定義していますが、説明不足であり動作が分かりません。
ちょっとonExecute関数に書きすぎだと思う。onExecute関数内でSleepしている箇所がありますが、意味がよく分かりません。
見たところSpeechManageSystem.pyのStartFlag==1の時の処理は1回しか実行しないようですが、なぜonActivated関数で処理しないのか。全体的に処理の流れが分かりづらいです。
まあでも上の作品が改善しないようであればこの作品のほうが評価が高いように思います。
今日はこのぐらいにしておきます。
次のページ
>>
