メリゲツトとメリプツト
Meridian計画。
前回のLITE版のリファクタリングの結果をTWIN版に移植したり、その時に気づいた点をLITE版にフィードバックしたりとまだまだゴニョゴニョが続いています。
そして、改修を重ねるうちにちょっとずつ複雑にもなってきています。
これは困りました。
Meridianの概念に立ち戻る
Meridianの概念自体は変わっておらず、シンプルなままです。
⓪ ロボット制御に必要な情報が全て入る配列であるMeridimを使う。
① デバイスは受け取ったMeridimの情報と命令をもとに処理を行う。
② 処理結果と最新の情報をMeridimに書き込み次のデバイスに渡す。
③ 複数のデバイス間で①②を繰り返し、サークル状に循環し続ける。
基本ルールは以上です。
イメージとしては、山手線を貨物列車が走る感じです。
列車が駅に到着すると、コンテナの箱が開かれ、中にある情報と指示書をもとに処理が行われます。処理が終わり次第、処理結果と次への指示書がコンテナに詰め直され、列車は次の駅へ向かう、ということを繰り返します。
ちょっと脱線 トークンリングの話
トークンリングという言葉をご存知でしょうか。
トークンリングの解説はリンク先にある通りで、トークンというデータをリング状に接続したデバイスの間で循環させるやや古めの通信方式です。イーサネットに取って代わられ、今ではほとんど使われていないようですが、基本的な原理はMeridianも同じです。
トークンリングのメリットはパケットの衝突が発生しないことや、通信量が安定している点です。一方、問題点は通信速度が違うデバイスが入ると全体がダウンするところや、トークンが回ってこないと通信ができない点です。Meridianは接続するデバイスがさほど多くなく、データ量もごく少量、トークンが回ってこない時の処理もデバイス側のコーディングで融通できますので、トークンリングの利点を最大限に生かしながら、弱点の影響もほとんど無効化できます。このようなデータ循環方式は、リアルのロボットとシミュレート空間のロボットをデジタルツイン化するにはもってこいの技術だと考えています。データサーキュレーション方式とでも呼んで、便利に使っていきたいと思います。
貨車に空気を乗せて運んでもよいのか
閑話休題。さて、Meridimではコンテナ車両の何両目にどの情報が入るか、ということが決まっています。たとえ空の車両が生じても、そのまま走らせた方が、人間から見ても分かりやすく、またデータ量が変動しないのでリアルタイム通信の設計もシンプルになると考えています。
これが実際の貨物列車であれば空の台車をコストをかけて輸送するのは無駄であるという評価になります。それがデータであっても、空の配列を転送するのは経済的ではないという評価にもなり得ます。
しかし学校のロッカーや下駄箱のように、空の箇所があっても毎回使う場所が決まっていた方が便利に感じるものもあります。少なくとも初期型であるMeridim90の段階では、配列の中身が直感的にわかりやすいことが優先度が高いと考えています。
シンプルな概念を表現できる関数にする
Meridim配列を貨物列車に見立てると、デバイスは駅になります。
その駅にはセンサやリモコンなど、その駅に隣接したサブデバイスからの新鮮な情報が山積みなって出荷を待っています。
駅では届いた情報を荷下ろしし、処理を行い、新しい情報を積み込みます。
概念はとてもシンプルですが、コードにするとちょっと複雑な印象を与えてしまうような気がします。
ここは今回のリファクタリングで少しでもわかりやすくしたいところです。
コーディングを行うデバイス側をから見ると、Meridimが来たら、とにかく情報を読み取り、必要に応じて処理を行い、そして手持ちの情報を載せてまた送り出す。という部分だけを行えばよいわけです。
とすると、その荷物の積み替え作業にフォーカスした概念の関数を用意すれば、データの流れがスッキリするかもしれません。
関数はデータの読み書きを行うだけのシンプルな機能となるので、名前さえしっかりしたものにしておけば見通し良くできそうです。
pack, unpack, load, mountなど、荷物の積み下ろしにふさわしい用語がいろいろありそうです。しかしこれらはすでに別の意味のコンピューター用語、概念として使われていますので避けた方がよさそうです。
Meridianの配列の操作は遺伝子のゲノムを切ったり貼ったりする作業にちょっと似ていると思いちょっと調べてみましたが、英語にすると聞きなれない単語ばかりで、伝わりにくそうでした。copyやpasteも遺伝子操作として使える単語のようで、こちらは日本人にも馴染みがあり候補にできそうです。
配列の一部のセグメントをブロックごとに読み書きするような概念を表す単語が見つかるとよいのですが、一単語でピッタリと来るものはなかなか見つかりません。（なるべく短くしておきたい）
メリゲットとメリプット
いろいろと悩んだ中で、コンピューターのデータの読み書きとして一般的なgetとputは使えそうな感じがしました。
Meridimを積み木の貨物列車とイメージしたとき、各デバイスやユーザーが荷物であるデータをgetしたりputしたりするというのは、無理のない表現に思えます。
ということで、自分で考えていてもやや拍子抜けな感じがありますが、
新しい関数名は meriget と meriput にしたいと思っています。
meriget90 ( <配列>, <開始INDEX>, <LENGTH> )というふうに配列の位置と長さを指定することで、ユーザーが自由に配列を読んだり書いたりすることができるというのが基本型です。
しかし、実際には、Meridim90の配列に対して、リモコンデータやセンサデータなど、意味のあるブロックを丸ごと読み書きすることがほどんどだと思います。そこで、
meriput90_pad ( <配列> )
meriput90_sensor ( <配列> )のように、作業の内容が明快な変数も準備しておこうと思います。
meriput90_padは文字通り、ジョイパッドのリモコンデータの書き込みで、meriput90_sensorは同様にセンサーデータの書き込みです。
実は、いままではいろんな関数が好き勝手にMeridianの読み書きを分散的に担っていました。これが混乱の原因の一つであることもちょっと自覚もありました。
追加のリファクタリングによって、Meridim配列の書き込みを行う時はかならずmeriputを行うように徹底できれば、コードを追うときもわかりやすくなるのではないかと考えています。
さらに健康にしたい
Meridianはロボットの気の巡り。
動脈と静脈がある情報の流れです。
これから機能の追加でどんどん複雑になると思いますが、そういった工夫で、データとコードの健康を保っていければと考えています。
次回記事；
前回記事：
目次：
いいなと思ったら応援しよう！
