うめぞーコラム

思ったことを書き綴るだけの内容。IT業界ネタ中心。

ブラーバ jet m6 その後

動かなくなったブラーバm6。何度も米国のサポートに連絡しても、なんの返信もなく。サポートレベルとしては最低でした。International Support の意味がわかりません。

 

いろいろ試してみたものの、やっぱり動かず。

致し方ないので、下記のようになりました...

 

f:id:mumeno:20200622214624j:plain

 

(笑)

はい。日本でサポートしてもらえるやつです。だって便利なんだもん。水拭きロボット。

 

米国バージョンと日本バージョン、見た目は全く同じですが動きがかなり違います。

電源を入れたあとの光り方。米国バージョンは蓋(グレーのところ)の周りがクルクル光るだけでしたが、日本バージョンはクルクル光ったあとに、「Clean」ボタンがブリンクしたりします。

レーニングさせてみましたが、米国バージョンはいきなり全部屋をめぐり 、マップを作成しましたが、日本バージョンは行動範囲が徐々に大きくなり、3回目にしてマップを作成しました。マップを作るのに時間がかかっているのですが、日本バージョンは部屋の区切りを自動で作成していました。米国バージョンは自分でパーティションを作って上げる必要がありました。

 

洗面所に5mmの段差があり、それを吸収するために幅5cmのスロープを作っていたのですが、米国バージョンは何をやっても乗り越えず、洗面所からホームステーションに戻ることはありませんでしたが、日本バージョンは洗面所が終わるとホームステーションに軽々と戻っていきます。

 

ブラーバm6は声で教えてくれる機能もついているのですが、同じ日本語でも声の感じが米国バージョンと日本バージョンで違いました。

 

米国バージョンは部品取りとして保存しておくことにします。

 

もしこれでまた壊れて買い直すことになったら、ブラーバの名前は「レイ」とつけることにします。

「私はたぶん3人目だと思うから。」

って言いそう。w

 

Red Hat Decision Manager を売っていてよく聞かれる質問解答集

いわゆる「製品部門が展開するFAQ」ではなく、私が実際にお客様とお会いして経験したこととして、先日赤帽エンジニアブログにて公開した、Red Hat Decision Managerを売っていてよく聞かれる質問回答集をこちらにも転載しておきます。4日間連続で投稿しました。

 

中には「回答しづらい」質問もあるわけですが、そのあたりは理屈をこねくり回すのではなく、素直に回答しているつもりです。ご参考まで!

 

rheb.hatenablog.com

 

rheb.hatenablog.com

 

rheb.hatenablog.com

 

rheb.hatenablog.com

 

 

 

AIを支える仕組み

AIを支える仕組みについて

今日はArtificial Intelligence, AI 支える仕組みについて、あまり語られていない視点で語ってみます。

 

IBMが誇るWatsonは、誰もがAIと認識していると思います。クイズに勝ったりチェスに勝ったりと、人知を超えるアクションを起こして「すげぇ!」と言われています。確かに凄いです。だって、人の知識量を遥かに超える情報から、応答すべき答えを、限られた時間内で返すんですから。

でも、ちょっと待って。これってWatsonという、なんだかわからない巨大なブラックボックスでしかできないものなのでしょうか?普通の技術でできないのでしょうか?

クイズの回答を例にとって要素技術を見てみましょう。クイズのプロセスは、1. 質問者からの問いかけがあり、2. 回答者が考えて、3. 回答する。これだけです。素人考えですが、コンピュータ側で行うべき技術要素は下記のようなものでしょう。

 

1. 音声認識により発音された内容を忠実に文字に起こす

2. 起こされた文字情報から、何について回答すべきかを判断する(人名なのか物質名なのか、形容詞なのか... 等)

3. 起こされた文字情報から、予め持っておいたデータから関連性を検索し、スコアリングする

4. スコアリングと情報の関係性を判断し、より的確なものを回答候補とする

5. 複数の回答の候補と2.で判断した回答すべき内容とのマッチングをとり、回答候補を絞り込む

6. スコアリングなどで回答に序列をつけ、最も得点の高いものを回答とする

 

もっとも、上記の操作を予め何度も繰り返して、その結果自体をデータとして持っておくことも必要でしょう。

 

この一連の動作を、もうちょっと技術よりに抽象的に考えてみます。今までのコンピュータの世界で何が難しかったかというと、

A. 大量のデータを保存しておくこと

B. 大量のデータから情報(データ)を超高速に検索すること

C. データとデータの関連性をマッチングしてアクションを起こすこと

D. 超高速で処理をすること

かなと思います。この4つについて解決方法を考えてみます。

 

A. 大量のデータの保存

 データの保存 というと、ファイルとかデータベースとかになりますが、通常の使い方であればそれで良いです。AIの世界になると情報量がとんでもなく必要になります。ギガとかテラとかではなく、ペタ(千兆)とかエクサ(100京)という、私が産まれた後に国際単位系にて制定(!) された単位を持つ量です。単一のファイルシステムとかデータベースでは容量が少なすぎて使い物になりません。そのため、複数のファイルシステム、複数のデータベースを連結して使うことになります。

 

B. 大量のデータから情報(データ)を超高速に検索すること

 「データを単に入れておくだけ」であれば、入れ物さえデカくすれば目的は達成ですが、使われないデータを貯めていても、それはゴミ屋敷と同じです。データがどのような目的で使われるかを意識してデータを貯める必要があります。それはデータの保存形態をどうするかに直結します。1件1件バラバラに、名刺を箱の中に入れておくようなデータとするのか、データを正規化して複数のテーブルに関係性(Relational)を持っておくようなデータとするのか、1件1件のデータはバラバラでもそれぞれが前後関係という関係性で繋がるデータとするのか、など。

 今までの業務処理でよく使われているのはRelational DBです。OracleとかPostgreSQLとか、皆さんもよく耳にするアレです。異なる性質のデータの塊を、関連性を持つキーで繋げているので、そのキーで検索することで、異なるデータ間で一貫性を保つことができるわけです。

 一方、Relational DBが出てくる前にMainframeのような大型コンピュータでよく使われていたのが、Network DBです。例えば、あるデータを抽出し、その関連性を見る必要があるような場合、記録媒体(昔はテープだった!)へのアクセスに負荷をかけること無く芋づる式に取得・格納できるのがメリットでした。イメージしやすいのはWebのページのリンクみたいなものです。あるページを検索して表示したら、そのページに記事に関連するURLが書いてある みたいな感じと考えるとわかりやすいと思います。記憶媒体のアクセスがシーケンシャルからランダムアクセスになり高速になったことで、使われなくなりましたが、考え方自体はWebのページのリンクように残っています。

 

つまり、大量のデータを保存するためには、使われ方を考え、高速性も考えると複数のアクセスエントリーをもち、複数の独立したCPUでそれぞれ処理できるような、いわゆる分散処理型データベースが必要になります。記憶媒体も回転するディスクよりももっと高速性のあるメモリ型デバイスにする、さらには1st / 2nd / 3rd キャッシュ等の「目的のデータをいかに早く取り出せるか」の技術、分散環境でも重複や欠落のないデータを提供できる仕組み、要求する「アプリケーション」からのアクセスしやすさ などを考慮する必要があります。

 

C. データとデータの関連性をマッチングしてアクションを起こすこと

 "マッチング" とか、簡単に書いていますが、ここが一番重要なのです。

まず、「データ」をマッチングするにはマッチする「ロジック」が必要になります。何をデータとして何をロジックとするかを考えなければなりません。ロジックはいきなり抽象化できません。こういうデータが来た場合にどの項目を見て、その値が同じだったら(範囲内だったら...等)何をする というのいくつも検討した上で、抽象化できそうであればパラメータ化して初めて「ロジック」が出来上がります。これは「データと知識の分離」という作業になります。

 

この作業を「人」が行うのが「設計」であり、「機械的」に行うのが「機械学習」です。どちらもアウトプットとしてはロジックであり、データが来て初めて動くものになります。

ここで、ロジックの組み方にも一つ工夫が必要です。単に if〜then〜else でロジックをプログラミングすると、何が起きるでしょう?判断するパラメータが増えるに従い、ifの分岐が増えるということは簡単に想像できると思います。しかも、elseまで考えると、「ある条件(Condition)」を一つ書くことで、「どうする(Action)」を2つ書く必要があります。つまり単純計算になりますが、条件数をNとすると、アクションの数としては 2xNの数が生まれてしまいます。ここでみなさんが考えつくのは、ソースコードの量を減らすために if の中に複数の条件を書く、else の下にif を入れ子にする等だと思います。

条件の数が増えるとか条件の組み合わせが変わるたびに修正が必要になるわけですが、このプログラミング方法だと、どこを変更すればどのActionに影響がある(答えが変わってしまう)かを事前調査してから修正する必要があります。この作業、めっちゃ大変です。ましてや、そのロジックが本当に正しいかどうかの検証を、このシステムを使う側の人間に「ここをこう直してよい?」と聞いたところでわかるわけがないのです。この方法では遅かれ早かれ破綻を迎えます。

 

そこで出てくる考え方が「パターンマッチング」です。パターンマッチングは「もしそのデータがある条件に"マッチ" した場合、アクションを起こす」という書き方をします。え?前述のと何が違うかって?パターンマッチングは、「パターン(条件)に当てはまれば実行する、パターンに当てはまらなかったら何もしない」という動作をします。ということはプログラムとしてはどういうことかというと、"else"を書かない というところが一つのポイントになります。

 

elseが無い世界とは、ロジックは「マッチした条件ならxxをする」だけなので、「それ以外」の場合でアクションが必要な場合は、ロジックを明記する必要があります。単純に考えると、ソースコードが増えるじゃん!と思われますが、冷静に考えてみてください。上記のような「修正」をする場合のことを。条件間の相関関係が「疎」になるので、変更したいパラメータがあるところ「だけ」を修正すれば良いのです。従来のif-then-else ではほぼできていない「ロジックを捨てる」ということも容易になります。

 

試行錯誤を繰り返して知識をつけて行かなければならないAIの世界では、この「ある部分のロジックを追加する・書き換える」「正答率が低いことがわかったのでロジックを外す」ということを、とんでもない頻度で行われることになります。従来のプログラミング方法では全く太刀打ちできません。データと知識を分離して実装できるパターンマッチング技術が絶対必要になります。

クイズの例でもありましたが、音声を文字に起こすのも、パターンマッチング技術です。

 

人工知能はデータ + 知識です。データも知識も生き物であり、常に入れ替えが必要になります。データの入れ替えはロジックからデータが分離したことで簡単になっていますが、今後はパターンマッチング技術をもっと取り入れて、知識の入れ替えもより簡単にする必要があります。

 

D. 超高速で処理をすること

現在のフォンーノイマンアーキテクチャで動作する「コンピュータ」は、根本的には同時に行える処理は一つだけです。メモリからデータを持ってきて、命令を実行して、メモリにデータを格納する。これが一つ一つシーケンシャルに行われています。それをCPUのクロック数を上げるとかの技術で人の目にも止まらぬ超高速化をすることで、あたかもマルチタスクで動いているかのように見せています。なので、PCに向かって大好きな音楽を聞きながらこのブログのような記事を書くことが同時にできているように思えます。ありがたや、ありがたや!

しかし、AIの世界ではもっともっと高速に動作させる必要があります。現在の0か1かで動いているコンピュータでは限界があります。情報量を0か1かだけでなく、4とか8とかまで同時に扱えるようにすれば、もっと速く動作するでしょう。それは量子コンピュータが安価に使えるようになりまで待たなければならないです。

 

では現状ではどうすればよいのでしょうか。答えは「分散環境」です。あたかもオーケストラと合唱団が素晴らしい音楽を奏でるように、異なるそれぞれのコンピュータがそれぞれ仕事をして、指揮者がコントロールする世界です。グリッドコンピューティングなんかもその仲間の一つですが、もっと簡単に考えられる仕組みが出てきています。最近良く目にするのが、Graphics Processing Unit (GPU)です。CPUがシーケンシャルな動作なのに対して、GPUは並列動作になります。GPUはコア数を膨大に持つことが可能なので、並列動作環境を作りやすいですが、各コアを跨いだ処理ができません。なので、機械学習のスコアリングのような単純作業に向いています。

 

では、GPU以外の場合ばどうするのでしょう。処理するモジュールのそれぞれを「マイクロサービス」という単位で構成します。サービスとは、「データを投げて問い合わせをしたら、ある程度の処理をして返してくれる単位」と考えると良いです。例えば、病院で会計をする時、カルテを窓口に出しますよね。そうすると医療事務のきれいなお姉さま方が医療行為や投薬に対して点数を計算してお金を計算し、請求金額と明細を作ってくれます。これがサービスです。サービスは、マイクロサービスが複数集まって一つのサービスを構成します。今の例だと、データのチェック、起票や計算すること自体はお姉さま(ディシジョンサービス)がやりますが、そのデータをデータベースに格納するのはデータサービス、請求書や明細書を印刷するのはユーザインターフェースサービスというマイクロサービスの役割です。

 

この、マイクロサービス化された環境は、今の時代は「コンテナ」という入れ物の中で動作させることができるようになりました。コンテナは貨物列車のコンテナと同じで、外に行き先とかが書かれていますが、輸送する会社は中身は知らなくてよいのです。(冷蔵かそうでないか、危険物かそうでないかくらいの分類は必要ですが...)

 

世間的にはKubernatesという技術がオーケストラの指揮者の役割を行い、どのコンテナがどこで動くべきかをコントロールします。それにより、数千ものコンテナを同時に動かしてコントロールすることが可能になっています。また、コンテナ間の動作連携も可能です。これにより、超分散環境で動かすことができて、結果的にハイパースケールなパフォーマンスで処理をすることが可能になりました。

 

 レッドハット社の製品

これらの技術を支えるためのいくつかの基盤は、オープンソースで社会を変えるレッドハット社から出ています。

大量のデータ保管:Red Hat Storage (Ceph, Gluster)

超高速なデータサービス:Red Hat Data Grid, Red Hat AMQ (Kafka)

ディシジョンサービス:Red Hat Decision Manager

超高速な稼働環境:Quarkus, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform

 

 

 

 

ブラーバ jet m6 その後(まさか...?!)

 前回書いたこれの続き。

mumeno.hatenablog.com

 

International Supportとは...

うめぞーのブラーバ、アメリカのAmazonで買って、日本に持ち込んだもの。今や世界的に名の知れたiRobot社、一応

International Support | iRobot Customer Care

を標榜しています。で、日本のサポートに問い合わせをしたところ、回答がありました。

が、その内容は、「日本で販売したものではないのでサポートも修理も受けられません」というもの。外国製品あるあるですね。正規販売店を通したもの以外は面倒を一切遮断するスタイル。まぁ、ここまでは想定内。

で、iRobot社のUSの窓口に聞いたところ、「日本で使っているなら日本のサポートを受けろ」と。完全に難民化してますが... -_-#

私が勤める会社も「外資系」ですが、基本は買ったところに問い合わせをすればサポートは受けられます。Appleなんかは、その製品が偽物ではなければ、使用している国でサポートが受けられます。その当たり前が通じない。残念です。本当に。

 

まさか?っえ?!

で、今日のお話はその後のこと。

どうにもブラーバがエラーで動かないから初期化したわけですよ。で、もう一度再設定。その際にブラーバに名前が付けられます。デフォルトでは「Braava jet」。おそらく、このあと何度も初期化するだろうな、ということで、面倒なのでデフォルトの名前「Braava jet」のままセットアップをしました。

#ちなみに、正常に動いていた時は「ブラーバm6」と名付けていました。

 

そして。夜の10時とかに、「Braava jet」は突然の再起動。

え? 直った?!

いえ。そしてすぐに沈黙。でもまた再起動、そしてピコピコと聞いたことのない音や、再起動など、勝手に動き出す。動き出すと言っても、「Braava jet」が物理的に移動するのではなく、音と光が鳴り響くのみ。

サポートセンターが、シリアル番号から勝手にリモート操作でもしているのかな?と思っていたのですが、それにしてもなんかおかしい。事前通知もなく勝手に操作されている感じは、マジ気持ち悪い...うざい。うるさい。

 

そして、その翌日。やっぱり、夜の10時頃になってまた再起動やピコピコが始まるのです...おいおい。日本の夜の10時って、米国東海岸時間でいうと午前9時。

 

で、IT歴四半世紀のうめぞー、なんとなくの直感が働きました。ピキーン。

米国人が出勤後の朝9時に、タイマーで仕掛けておいたブラーバが掃除していないか?

 

Braavaは、iRobotクラウドを利用しています。iRobotクラウドに登録された情報を利用して、RoombaやBraavaの起動停止、掃除マップの登録や行動履歴やをiPhoneのアプリから操作できるようになっています。その通信はインターネットを介しているので、TCP/IPなはずです。実際にはIoT技術として注目されたMessage Queue Telemetry Transport (MQTT)プロトコルが使われているようです。

MQTTは基本、Pubisher / Subscriber がBrokerにあるTopicを介してメッセージのやり取りを行っています。そして、私うめぞーのIT的な直感は、

 

「操作系の指示は、Topicを機器特有のMAC Addressではなく、名付けたマシン名にしていないか?」

 

MAC Address (Media Access Control Address) は、インターネットに接続されるインターフェースの物理識別として世界で唯一となるように付けられているものです。48ビットで構成されているため2^48個のパターンがあります。(特別な制御系を除くと実際に使えるのはおよそ70兆個、でもこれだけあればIPv4のようにそう簡単に枯渇することもなかろう...)

Pubulisher (この場合は掃除の開始・停止指示を行うiPhoneiRobotアプリ)がこのMac Addressをtopicに指定しておけば、SubscriberとなるBraava本体は自分のMac Addressのtopicがあるかどうかを確認すればよいはずです。

 

ところが、このtopic名にマシンの名前を使ったらどうなるでしょうか。ユニークな名前にしていれば、特に問題はないですが、デフォルトで使われている名前で設定している方がたくさんいるとすると、誰のiRobotアプリからの指示なのか、わからなくなりますよね?つまり、「掃除開始」「掃除開始」「停止」「掃除開始」「掃除開始」「停止」「停止」「停止」... などという、めちゃくちゃな指示を立て続けに受けてしまって、メチャクチャな動作になりますよね。さらに、うめぞーの「Braava jet」、なぜか充電スペースから出られないのです。おかげで誰も操作していないのに、リングが白くなったり赤くなったり青くなったり、ピコンピコンと鳴り続ける「ポルターガイスト現象」となっています。。。怖い。

 

行動履歴やログ、部屋情報のデータ送信はMQTTではなくHTTPを使ってRESTでやり取りしているのではないかと想像します。データ量が多いからね。

 

そこで、改めて初期化を行い、マシン名としてこんな名前は誰も付けないだろうと、カタカナで「ダメ」と名付けました。(w

どうでしょう。暴れまくっていた操作指示がピタリと止みました。

 

f:id:mumeno:20200510001206j:plain

ダメ

MAC Address、ソフトウェア的に偽装することも可能ですが、お掃除ロボットMAC Addressを偽装させる有益な意味など存在しないし...

もちろん製品にはシリアル番号があります。Topicをシリアル番号にしておけば論理的にはユニークにはなり、偽装したシリアル番号のマシンで同じような事が起きると思いますが、マシン名を変えたことでポルターガイスト現象が収まるという上の状況の説明がつきません。

 

まさか...ねぇ。(あくまでも仮定の話です)

 

技術のお話

今日のお話の中で、レッドハットでご用意している技術・製品は下記のとおりです。
データ連携:Red Hat Integration (AMQ, Kafka, Data Virtualization)

 

常駐開発者の開放(表に出よ!アプリケーションの開発者)

世の中には「業務アプリケーション」なるものがあって、企業の活動を支援しています。携帯電話の契約の受付、月次の料金の計算、販売代理店へのコミッションの計算、製造計画、医療会計での点数計算など、それがないと業務が成り立たないアプリケーションって、結構な種類・数があると思います。

 

ところが、OSを提供しているような赤い帽子の会社に私が在籍しているということもあるのか、「アプリケーションの開発」に携わっている人があまり周りにいないんですよね。もっというと、「アプリケーションのアーキテクチャ」とか、「どういう仕組で動いている」ということに共感を持っていただける人が少ない感じです。さらに、ミドルウェアに係わっている人は、更に少ない感じなのです。

 

興味の対象

国内外を問わずいろいろな方と話す機会があるのですが、私の周りの皆さん、興味があるのは「アプリケーションをどこで動かしているか」で、「どういう仕組で動いているか」ではないようです。

「どこで動かしているか」という意味は、アプリケーションがベアメタルなサーバの上のどんなOSで動いているのか、何台動かしているのか、メモリやCPUはどれくらい使用しているのか というような意味です。彼らの興味の視点は、Virtual MachineでもContainerでも何でも良いんですが、「アプリケーションの箱」がどこにあるか だけなのです。アプリケーションの中身とか、業務に対してどのように使われているか ということに関して、意識がすごく希薄な気がします。

つまり、アプリケーションはドラえもんのポケットから出てきて、そこに置けば動くんでしょ?的な感じなのですかね。

「どういう仕組で動いているか」というのは、アーキテクチャであったり実装方法であったり、ロジックの考え方、データの流れであったりという意味です。ロジックというと、if-then-else とか SQLでのストアドプロシジャーを思い浮かべる方が多いと思いますが、ロジックの書き方はそれだけではないのです。もっと楽に、もっと楽しく書いて動かせる「ルールエンジン」なんてものがあったりします。そういうものを使ってみることで視野が広がり、アプリケーションの中身についての理解が進みます。そうすると、アプリケーションがどういう仕組みで動くから、最適なプラットフォームはこうなんだ という視点がうまれ、色々な使い方や考えなくても良かった制約などが出てきますよ。

 

開発者の姿

推測でしかないのですが、アプリケーションの開発者ってこんな状況なのではないかと思ってます。

  • 開発者は実は日本にはあまりいないのではないか?「面倒」「キツイ」「怒られる」「徹夜当たり前」... 等などの理由から開発を受けたがらない。
  • 企業側が「オフショア」と称して安いところに丸投げしているので、国内ではなく海外で開発されている。
  • 国内で設計・実装されている方々も、とにかく忙しくて、新しい情報を取りに行けない。忙しい理由は、テスト段階で発見される仕様の不具合を仕様を変えずに無理やり作り込んでいたり、必要以上のテストを行っていたり、有意義に感じられないエンドレスな会議に出ていたり。
  • 開発者の多くで「客先常駐」が標準スタイルになっていて、外部のネットワークへのアクセスができないので、新しい情報を見に行けない。
  • 一旦開発が始まると、プロジェクトを途中で抜け出す事ができず、「運用開発」と称して何年も同じアプリケーションを拡張・バクフィックスを繰り返し、そのまま定年退職...

 

COVID-19がディジタルトランスフォーメーションを邁進させている!なんていうブラックな話もあながち間違っていないのですが、アプリケーション開発における現場の改善がとても必要なのではないかと思ってしまいます。特に、典型的な3密の「常駐」という文化。

企業秘密を守らなければならない、情報漏えいを防がなければならないというのはもちろんわかるのですが、オフショアだってできているのですから、常駐をしなければならない理由はそこではないはず。もっと根本的なところから見直せると思うのです。

 

COVID-19でのリモートワークでわかったことの一つに、「皆が同じ場所にいなくてもある程度仕事ができるじゃないか」だと思います。「あれ?常駐していなくても気軽に聞けるツール(チャットとかweb会議システムとか)さえあれば、なんとかなるんじゃない?」と感じた方も多いハズ。

もちろん、リモートワークは、ひとりひとりの常識やコンプライアンスを徹底して成り立つものなのですが、これができるのであれば、開発者は常駐せず、そしてリーダーやマネージャも常駐せず、お客様の業務部門とのホットラインをチャット等で行い、モノはクラウド上で開発・実行して、いつでも進捗がわかるようにすることで、Waterfall開発ではなくイテレーション開発のほうが、品質良くモノは作れると思うのですがいかがでしょうか。

 

そして、積極的に新しい知識や方式、情報の共有に接する時間を持てるようになることで、個人の能力を高め、生産性(あまり使いたくない言葉ですが)を高め、関係者全員がスパイラルに良い方向に向かうと思います。

アプリケーション開発者を常駐という呪縛から解き放ち、節度を持った自由を持ってもらうことで、もっと良い社会できると思うのは私だけでしょうか。COVID-19の自粛後は世界が変わる(元の世界には戻らない)と言われていますが、アプリケーション開発者の作業場所が変わるっことで、アプリケーションの開発手法・品質も変わると思うんですよね。事実、赤い帽子社の製品開発者は、ずっと前から自宅で仕事をしている人が沢山います。

皆さんはどう思われますか?

 

技術のお話

今日のお話の中で、レッドハットでご用意している技術・製品は下記のとおりです。

ルールエンジン:Red Hat Decision Manager
データ連携:Red Hat Integration (AMQ, Kafka, Data Virtualization)
クラウド環境:Red Hat OpenShift Container Platform

 

ブラーバ jet m6 沈黙

今日はお仕事ネタではなく、雑談。

 

我が家にはお掃除ロボットが2台あり、吸い込み掃除機のルンバ i7と雑巾がけ掃除機のブラーバm6 がいます。いずれも昨年米国に行ったときに、プレゼントで貰ったものです。

ルンバもブラーバも、稼働させるとすっごく綺麗にしてくれます。こんな便利なものならもっと昔から買っとけばよかったと後悔したくらいです。

 

ですが、4月13日に掃除したあと、24日くらいかな?動かそうとしたら「Braavaが走行中に移動させられました」と出て、うんともすんとも動かなくなってしまいました。おかしい。動かなくなったらCLEANボタンを10秒押して再起動... もできず。CLEARボタンやHOMEボタンを適当に押していると、エラーコードをいくつかしゃべる。6とか16とか19とか...

こういうときは工場出荷状態に戻すべき というのが、私のナレッジであり、一般常識となっていると確信しているので、躊躇なく「工場出荷状態へ」をクリック。そしてもう一度、WiFiの設定から... 

というのが、甘かった... なんと、WiFi接続モードにするための"Spotボタン"と "Homeボタン"の同時2秒押しが、効かない。ボタンの入力を受け付けていない!

 

本体を隅々まで、老眼鏡を外して舐めるように探したけど、他にボタンがないんです。各ボタンの長押し、コンビネーションの長押し、長押し後に別のボタンを3回連打... しかしブラーバは沈黙。

 

詰んだ。。。

 

iPhoneに登録しているiRobot アプリを見ると、4月14日に、ソフトウェアが3.3.6にUpdateされていました。それまでは3.2.9。これのせい?でもiRobotのサイトを見てもソフトウェアのバージョンをデグレードさせるコマンドなど存在しません。それならば、放電させれば、工場出荷のバージョンまで戻るはず...

 

バッテリーを抜いて半日放置。そして再度Tryするも... 症状変わらず。

バッテリーを抜いて、さらに1日放置。そして再度Try...

 

キターーー!

SpotボタンとHomeボタンの2秒長押しが反応、WiFiと接続完了、iPhoneからコマンドを受け付けるまでにはなりました。CLEARボタンを10秒長押しすることで、再起動することも確認。ソフトウェアは3.2.9に戻りました。

 

しかし。ブラーバがホームベースから出れない事象は変わりない... orz

動作履歴から辿れるページを見ていたら、ん?「予期していない物体に衝突しました」

 

我が家には見えない物体があるんか?ポルターガイスト?むしろ、それは私?(w

 

やっぱりセンサーの故障なんだろうな... ロボットはセンサーだらけだもの。

 

米国のiRobotのサイトに行くと、米国もしくはカナダ以外に住んでいる場合のサポート

International Support | iRobot Customer Care

を ということで、日本のサイトに問い合わせ中。

ちなみに、Braava jet m6の Error Codeはこちら。

The Braava jet® m Series Error Messages Chart | iRobot Customer Care

 

進展があったらまた紹介します。

 

MacからSkype for Businessで"こんにちは"を言いたいのだ

在宅勤務が続いていますが、皆様お元気にお過ごしでしょうか。

我が家では近所の花屋さんでたたき売り?の1,000円で買ってきたユリの花が、23輪も咲き乱れ、部屋中に良い香りが漂っております!

f:id:mumeno:20200428175404j:plain

1000円のユリ

花の香に包まれ、紅茶をすすりながら仕事をしていると、血眼になってソースコードを追っていても何故か優雅な気分になれます!お試しください!

 

ところで。

在宅勤務が続き、お客様ともWeb会議の回数が増えてきます。お客様がいつも同じならばそう問題は起きないのですが、色々なお客様と会議をしていると、Web会議アプリヲタクか?ってくらい、アプリがドンドコどんどこインストールされていきます...(苦笑)

 

で、困ったのがお客様がSkype for Businessの時。Macからだと相手方に音声が届かないのです。会社にいる時は、携帯電話をスピーカーフォンにしてお客様とつなぎ、画面共有はSkype for Businessで...で良かったのですが、弊社側の参加者(ほぼ全員Mac)が在宅勤務となっていると、全員がご担当者に電話するわけにもいかないわけです。

一応、Skype for Businessの場合はダイアルインの番号があるので、そこに電話すればよいのですが、他のweb会議と同じように、PCの音声でやりたいものです。

 

そこで弊社の優秀な技術者が「発見」してきたのがこちらのページ。

Skype for Business on Mac でマイクを有効化する方法です。OSが持っているDBに無理やりレコードをinsertするという。w

https://qiita.com/gsh-kz/items/6b95603aa3d74cef8fec

 

しかし。なんと、Mac OS Catalina (10.15.x)は、セキュリティーが強くなっており、セキュリティが厳しくなっているディレクトリでは

sudo ls

さえも出来ない!commandを入れると

Operation not permitted

と出てきてしまいます。 

そこで、弊社の優秀な技術者(2回目の登場)が「発見」してきたのがこちらのページ。commandを打ち込むTerminalにフルディスクアクセスを付与するというもの。

https://qiita.com/KEINOS/items/0366f1c281b574a79cfb

 

おお?できるぞ!

INSERT into をやってみましたが、DBからの戻り値が無いので不安になりますが、

select * from access;

とやってみると、最後の行に先程入れた値

kTCCServiceMicrophone|com.microsoft.SkypeForBusiness|0|1|1||||UNUSED||0|1541440109 

が出ているので、成功しているっぽい。OSが壊れても何の保証も無いので自己責任になりますが...

解決策を紹介するページを作成いただいたお二方、大変感謝です!

 

東京都も神奈川県も新型コロナウィルスの新規感染者が減少傾向になってきていますが、まだしばらく自粛は続くと思います。なるべくストレスフリーにして穏やかにお過ごしくださいませ!