特許 7243893 モータユニットおよびマルチモータシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-03-13

(45)【発行日】2023-03-22

(54)【発明の名称】モータユニットおよびマルチモータシステム

(51)【国際特許分類】

   H04L 61/5007 20220101AFI20230314BHJP

   H04L 61/09 20220101ALI20230314BHJP

   H04L 12/28 20060101ALI20230314BHJP

【ＦＩ】

H04L61/5007

H04L61/09

H04L12/28 100F

【請求項の数】 16

(21)【出願番号】P 2022066961

(22)【出願日】2022-04-14

(62)【分割の表示】P 2018558069の分割

【原出願日】2017-12-21

(65)【公開番号】P2022100353

(43)【公開日】2022-07-05

【審査請求日】2022-04-19

(31)【優先権主張番号】P 2016250021

(32)【優先日】2016-12-22

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000232302

【氏名又は名称】日本電産株式会社

(74)【代理人】

【識別番号】100101683

【弁理士】

【氏名又は名称】奥田 誠司

(74)【代理人】

【識別番号】100155000

【弁理士】

【氏名又は名称】喜多 修市

(74)【代理人】

【識別番号】100188813

【弁理士】

【氏名又は名称】川喜田 徹

(74)【代理人】

【識別番号】100202197

【弁理士】

【氏名又は名称】村瀬 成康

(72)【発明者】

【氏名】佐藤 元樹

(72)【発明者】

【氏名】田渕 哲哉

【審査官】宮島 郁美

(56)【参考文献】

【文献】特表２０１３－５３６０９０（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１３／０１０３１９６（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０３０７９６５７（ＣＮ，Ａ）

【文献】特開２００１－３１０２８１（ＪＰ，Ａ）

【文献】特開２００２－２４７６７１（ＪＰ，Ａ）

【文献】特開平１１－２８２５４０（ＪＰ，Ａ）

【文献】国際公開第２０１６／００１２１１（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１７／０１５３６２０（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０６４８９２６２（ＣＮ，Ａ）

【文献】特表２０１０－５１１９６４（ＪＰ，Ａ）

【文献】米国特許出願公開第２００８／０１３３６８７（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０１５４２４４５（ＣＮ，Ａ）

【文献】特表２０１１－５０７００３（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１０／０２５２５１７（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０１８０２８９３（ＣＮ，Ａ）

【文献】欧州特許出願公開第０１６２６５３２（ＥＰ，Ａ２）

【文献】中国特許出願公開第１０３０１９１５６（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ１２／００－１３／１８，４１／００－４９／９０５７，６１／００－６５／８０，６９／００－６９／４０

(57)【特許請求の範囲】

【請求項1】

通信ネットワークを介して複数のモータユニットが相互に直接的に通信を行うマルチモータシステムで利用されるモータユニットであって、
モータと、
前記モータを回転させるための制御信号を生成する制御回路と、
前記制御信号に基づいて前記モータに電流を流すモータ駆動回路と、
前記通信ネットワーク内で、自身であるモータユニットを一意に識別する第１識別子、および、前記複数のモータユニットの各々を一意に識別する第２識別子を記憶した記憶装置と、
前記マルチモータシステムの他のモータユニットとの間でデータフレームの送信および受信を行う通信回路と
を備え、
前記通信回路は、
送信元である自身を示す前記第１識別子、送信先の前記他のモータユニットを一意に識別する前記第２識別子、および、前記他のモータユニットが行う動作に関する要求を前記データフレームに格納して、前記データフレームを前記他のモータユニットに直接送信し、
送信元である前記他のモータユニットの第２識別子、送信先である自身のモータユニットの前記第１識別子、および、自身が行うべき動作に関する要求を含む前記データフレームを前記他のモータユニットから直接受信し、かつ、前記他のモータユニットからの要求への応答として、送信先を示す前記第２識別子を付加し、かつ、送信元を示す前記第１識別子を付加したデータフレームを前記他のモータユニットに直接送信する、モータユニット。

【請求項2】

通信ネットワークを介して複数のモータユニットが相互に直接的に通信を行うマルチモータシステムで利用されるモータユニットであって、
モータと、
前記モータを回転させるための制御信号を生成する制御回路と、
前記制御信号に基づいて前記モータに電流を流すモータ駆動回路と、
前記通信ネットワーク内で自身であるモータユニットを一意に識別する第１識別子、および、前記複数のモータユニットの各々を一意に識別する第２識別子を記憶した記憶装置と、
前記マルチモータシステムの他のモータユニットにデータフレームを直接送信する通信回路であって、送信元である自身を示す前記第１識別子、送信先の前記他のモータユニットを一意に識別する前記第２識別子、および、前記他のモータユニットが行う動作に関する要求を前記データフレームに格納して、前記データフレームを前記他のモータユニットに直接送信する通信回路と
を備えたモータユニット。

【請求項3】

通信ネットワークを介して複数のモータユニットが相互に直接的に通信を行うマルチモータシステムで利用されるモータユニットであって、
モータと、
前記モータを回転させるための制御信号を生成する制御回路と、
前記制御信号に基づいて前記モータに電流を流すモータ駆動回路と、
前記通信ネットワーク内で自身であるモータユニットを一意に識別する第１識別子、および、前記複数のモータユニットの各々を一意に識別する第２識別子を記憶した記憶装置と、
通信回路と
を備え、
前記通信回路は、
前記マルチモータシステムの他のモータユニットからデータフレームを受信する通信回路であって、送信元である前記他のモータユニットの第２識別子、送信先である自身のモータユニットの前記第１識別子、および、自身が行うべき動作に関する要求を含む前記データフレームを前記他のモータユニットから直接受信し、かつ、
前記他のモータユニットからの前記要求への応答として、送信先を示す前記第２識別子、および、送信元を示す前記第１識別子を含むデータフレームを前記他のモータユニットに直接送信する、モータユニット。

【請求項4】

前記データフレームは、前記他のモータユニットに行わせる動作に関する要求である動作系コマンドを含む、請求項１または２に記載のモータユニット。

【請求項5】

前記データフレームは、前記他のモータユニットが有するモータに関する静的または動的な属性を示す属性系コマンドをさらに含む、請求項４に記載のモータユニット。

【請求項6】

前記動作系コマンドは、前記属性系コマンドによって指定された属性を読み出すまたは書き込む要求である、請求項５に記載のモータユニット。

【請求項7】

前記属性系コマンドは、前記他のモータユニットが有するモータに関する角度の属性を示す、請求項６に記載のモータユニット。

【請求項8】

前記角度はターゲット角度であり、
前記データフレームは、前記ターゲット角度に関する角度設定値をさらに含む、請求項７に記載のモータユニット。

【請求項9】

前記データフレームは、自身であるモータユニットが行う動作に関する要求である動作系コマンドを含む、請求項１または３に記載のモータユニット。

【請求項10】

前記データフレームは、前記モータに関する静的または動的な属性を示す属性系コマンドをさらに含む、請求項９に記載のモータユニット。

【請求項11】

前記動作系コマンドは、前記属性系コマンドによって指定された属性を読み出すまたは書き込む要求である、請求項１０に記載のモータユニット。

【請求項12】

前記属性系コマンドは、前記モータに関する角度の属性を示す、請求項１１に記載のモータユニット。

【請求項13】

前記角度はターゲット角度であり、
前記データフレームは、前記ターゲット角度に関する角度設定値をさらに含む、請求項１２に記載のモータユニット。

【請求項14】

前記第１識別子および前記第２識別子は、前記複数のモータユニットである各機器のデバイス識別子である、請求項１から１３のいずれかに記載のモータユニット。

【請求項15】

前記デバイス識別子はＭＡＣアドレスである、請求項１４に記載のモータユニット。

【請求項16】

前記第１識別子および前記第２識別子は、前記複数のモータユニットである各機器のＩＰアドレスである、請求項１から１３のいずれかに記載のモータユニット。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、モータユニットおよびマルチモータシステムに関する。

【背景技術】

【0002】

モータおよび通信回路を有する多数のモータユニットがネットワーク化された、マルチモータシステムが存在する。各モータユニットには、当該ネットワーク内で一意に各モータユニットを識別可能なＩＤ情報が予め付与されている。

【0003】

このようなマルチモータシステムにはホスト端末が存在し、ＩＤ情報を利用してホスト端末とモータユニットとの間で通信が行われる。ホスト端末からあるモータユニットにリクエストが送信される場合、ホスト端末は、リクエストに送信先のモータユニットを特定するＩＤ情報のみを付与して送信する。リクエストを受信したモータユニットは、リクエストに対する応答に、送信元を示す自身のＩＤ情報のみを付与してホスト端末に送信する。

【0004】

たとえばホスト端末が、モータユニットＡの現在の回転速度を知りたい場合、ホスト端末はモータユニットＡに、「送信先ＩＤ情報（モータユニットＡ）＋現在の回転速度のリクエスト」を送信する。一方、モータユニットＡはホスト端末に、「送信元ＩＤ情報（モータユニットＡ）＋現在の回転速度の情報」を送信する。

【0005】

上述のマルチモータシステムでは、各モータユニットにとっては、リクエストの送信元、および、リクエストに対する応答の送信先は常にホスト端末である。よって、ホスト端末は送信元である自らのＩＤ情報をリクエストに付与する必要はないし、各モータユニットは送信先としてホスト端末のＩＤ情報を付与する必要はない。

【0006】

たとえば特開２０１４－１１６８９号公報では、部品実装機に設けられた制御部がホスト端末として機能する。制御部は、複数の中継局を介して複数の個別機器の各々にコマンドを送信し、各個別機器から受信した通信データの個別フレームに書き込まれた情報の処理を行う。

【先行技術文献】

【特許文献】

【0007】

【文献】特開２０１４－１１６８９号公報

【発明の概要】

【発明が解決しようとする課題】

【0008】

ホスト端末を介さず、モータユニット間で通信を行うマルチモータシステムが考えられる。そのようなマルチモータシステムにおいてモータユニット間通信を行うためには、送信時に送信先ＩＤ情報だけをリクエストに付与するだけでは不十分である。応答を送信するモータユニットは、どのモータユニットに送信すればよいかが不明だからである。

【0009】

モータユニット間で通信を行うために好適なマルチモータシステムおよび当該マルチモータシステムで利用されるモータユニットが必要とされている。

【課題を解決するための手段】

【0010】

本開示による、あるモータユニットは、通信ネットワークを介して複数のモータユニットが通信を行うマルチモータシステムで利用されるモータユニットであって、モータと、前記モータを回転させるための制御信号を生成する制御回路と、前記制御信号に基づいて前記モータに電流を流すモータ駆動回路と、前記通信ネットワーク内で、自身であるモータユニットを一意に識別する第１識別子、および、前記複数のモータユニットの各々を一意に識別する第２識別子を記憶した記憶装置と、前記マルチモータシステムの他のモータユニットとの間でデータフレームの送信および受信を行う通信回路とを備え、前記通信回路は、送信元である自身を示す前記第１識別子、送信先の前記他のモータユニットを一意に識別する前記第２識別子、および、前記他のモータユニットが行う動作に関する要求を前記データフレームに格納して、前記データフレームを前記他のモータユニットに送信し、送信元である前記他のモータユニットの第２識別子、送信先である自身のモータユニットの前記第１識別子、および、自身が行うべき動作に関する要求を含む前記データフレームを前記他のモータユニットから受信し、かつ、前記他のモータユニットからの要求への応答として、送信先を示す前記第２識別子を付加し、かつ、送信元を示す前記第１識別子を付加したデータフレームを送信する。

【0011】

本開示による、あるモータユニットは、通信ネットワークを介して複数のモータユニットが通信を行うマルチモータシステムで利用されるモータユニットであって、モータと、前記モータを回転させるための制御信号を生成する制御回路と、前記制御信号に基づいて前記モータに電流を流すモータ駆動回路と、前記通信ネットワーク内で自身であるモータユニットを一意に識別する第１識別子、および、前記複数のモータユニットの各々を一意に識別する第２識別子を記憶した記憶装置と、前記マルチモータシステムの他のモータユニットにデータフレームを送信する通信回路であって、送信元である自身を示す前記第１識別子、送信先の前記他のモータユニットを一意に識別する前記第２識別子、および、前記他のモータユニットが行う動作に関する要求を前記データフレームに格納して、前記データフレームを前記他のモータユニットに送信する通信回路とを備えている。

【0012】

本開示による、あるモータユニットは、通信ネットワークを介して複数のモータユニットが通信を行うマルチモータシステムで利用されるモータユニットであって、モータと、前記モータを回転させるための制御信号を生成する制御回路と、前記制御信号に基づいて前記モータに電流を流すモータ駆動回路と、前記通信ネットワーク内で自身であるモータユニットを一意に識別する第１識別子、および、前記複数のモータユニットの各々を一意に識別する第２識別子を記憶した記憶装置と、通信回路とを備え、前記通信回路は、前記マルチモータシステムの他のモータユニットからデータフレームを受信する通信回路であって、送信元である前記他のモータユニットの第２識別子、送信先である自身のモータユニットの前記第１識別子、および、自身が行うべき動作に関する要求を含む前記データフレームを前記他のモータユニットから受信し、かつ、前記他のモータユニットからの前記要求への応答として、送信先を示す前記第２識別子、および、送信元を示す前記第１識別子を含むデータフレームを前記他のモータユニットに送信する。

【0013】

本開示による、あるマルチモータシステムは、第１、第２および第３モータユニットを含む複数のモータユニットと、前記複数のモータユニットを接続する通信ネットワークとを有するマルチモータシステムであって、前記複数のモータユニットの各々は、モータと、前記モータを回転させるための制御信号を生成する制御回路と、前記制御信号に基づいて前記モータに電流を流す駆動回路と、前記通信ネットワーク内で前記モータを一意に識別する識別子を記憶した記憶装置と、通信回路とを備え、前記第１モータユニットの制御回路は、受信したモータユニットの状態を示す状態情報を送信させる指示と、前記状態情報の送信先である第３モータユニットのモータを識別する識別子と、前記状態情報の送信タイミングと、を含む第１コマンドを生成し、前記第１コマンドを、前記通信回路を介して前記第２モータユニットに送信し、前記第１コマンドを受信した前記第２モータユニットの制御回路は、前記第１コマンドに基づいて、前記第２モータユニットの状態情報を含む第２コマンドを、前記送信タイミングで前記第３モータユニットに送信する。

【0014】

本開示による他のマルチモータシステムは、複数のモータユニットと、前記複数のモータユニットを接続する通信ネットワークとを有するマルチモータシステムであって、前記複数のモータユニットの各々は、モータと、前記モータを回転させるための制御信号を生成する制御回路と、前記制御信号に基づいて前記モータに電流を流すモータ駆動回路と、前記通信ネットワーク内で前記モータを一意に識別する識別子を記憶した記憶装置と、前記通信ネットワークを介して通信を行う通信回路とを備え、前記複数のモータユニットの各々の前記識別子は所定の順序に従って付与されており、前記所定の順序に応じて決定された１台の特定モータユニットが、前記通信ネットワーク内で行われる前記通信を調停する。

【発明の効果】

【0015】

本発明の例示的な実施形態にかかるモータユニットによれば、ホスト端末の有無にかかわらず、多対多の通信を行うことが可能になる。

【図面の簡単な説明】

【0016】

【図1A】図１Ａは、有線のシリアル通信で利用されるデータフレーム１ａの構造を示す図である。

【図1B】図１Ｂは、無線通信で利用されるデータフレーム１ｂの構造を示す図である。

【図2】図２は、共通データ構造１２を示す図である。

【図3A】図３Ａは、コミュニケーションロボット３０の外観を示す図である。

【図3B】図３Ｂは、パワーアシストスーツ３０ｂの外観を示す図である。

【図3C】図３Ｃは、業務用冷蔵ショーケース３０ｃの外観を示す図である。

【図4】図４は、マルチモータシステム１０３の模式図である。

【図5】図５は、コミュニケーションロボット３０（図３Ａ）の関節を回転させるモータユニットを含むマルチモータシステム１０３の構成例を示す図である。

【図6】図６は、ＲＳ－４８５規格の通信時のデータフレーム２ａの例を示す図である。

【図7】図７は、アービトレータ決定前の識別子を含むデータフレームＦの送信タイミングを示す図である。

【図8】図８は、モータユニット１０６Ｂがアービトレータであることを通知するデータフレーム３ａの例を示す図である。

【図9】図９は、アービトレータ決定時のモータユニットの一連の処理の手順を示すフローチャートである。

【図10】図１０は、２つの送信パターンの各々に基づく情報の送信が行われるマルチモータシステム１０３を示す図である。

【図11】図１１は、第１コマンドである、「状態情報送信タイミング指定コマンド」（「Send Status Info Timing」コマンド）が記述されたデータフレーム４ａの例を示す図である。

【図12】図１２は、状態情報送信タイミング指定コマンドのデータフィールド１２ｄの詳細を示す図である。

【図13】図１３は、第２コマンドである、「状態情報送信コマンド」（「Send Status Information」コマンド）が記述されたデータフレーム５ａの例を示す図である。

【図14】図１４は、パワーアシストスーツ３０ｂを装着した人物５０と、グリーンハウス６０とを示す図である。

【図15A】図１５Ａは、人物５０が、グリーンハウス６０の入口６２付近で収穫作業を行っているときに回転速度を高める複数のファンモータユニット６４を示す図である。

【図15B】図１５Ｂは、人物５０が移動することによって回転速度を高める、さらに他の複数のファンモータユニット６６を示す図である。

【発明を実施するための形態】

【0017】

本開示によるマルチモータシステムは、通信機能を有する複数のモータユニットと、当該複数のモータユニットを相互に接続する通信ネットワークとを有している。マルチモータシステムでは、あるモータユニットが、コマンドを、他のモータユニットに送信する。当該マルチモータシステムでは、すべての通信に関与するホスト端末を設ける必要はない。

【0018】

以下では、添付の図面を参照しながら、まず、マルチモータシステムで送受信されるコマンドに関する通信プロトコルを説明する。その後、マルチモータシステムの構成および動作を説明する。

【0019】

１．マルチモータシステムで用いられる通信プロトコル
図１Ａは、有線のシリアル通信で利用されるデータフレーム１ａの構造を示している。シリアル通信の一例はＲＳ－４８５規格の通信を想定している。ＲＳ－４８５規格はＯＳＩ参照モデルでいう物理層の電気的仕様を策定する。

【0020】

データフレーム１ａは各種のデータを包含している。参考のため、図１Ａの最上段にはＯＳＩ参照モデルの層ごとの区分を示す。また図１Ａの最下段には、各データのデータサイズをバイト単位で表記している。図１Ａの最左欄は凡例である。後述する図１Ｂおよび図２でも同様である。

【0021】

データフレーム１ａは、たとえば、送信先デバイスＩＤ１０と、送信元デバイスＩＤ１１と、共通データ構造１２とを含む。送信先デバイスＩＤ１０は、送信先のデバイスを識別する識別子である。送信元デバイスＩＤ１１は、送信元のデバイスを識別する識別子である。送信元のデバイスは、通信機能を有するモータユニットであり得る。識別子は、たとえば製造時に重複することなく機器ごとに付与されたＩＤ（デバイス識別子またはデバイスＩＤ）、ＩＰアドレスである。デバイスＩＤまたはＩＰアドレスは、通信ネットワーク内でモータユニットを一意に示す識別子である。共通データ構造１２は、後述する１または２のコマンドを含むデータ構造である。

【0022】

これまで、モータを制御するためには、制御対象であるモータを識別する送信先のデバイスＩＤのみが存在していれば十分であった。送信先デバイスＩＤを指定してコマンドおよび制御データを送れば、当該モータが当該コマンドおよび制御データに従って動作していたからである。

【0023】

本発明者は、これまで考えられていなかった、複数台のモータが互いに通信し、全体として有機的に動作するマルチモータシステムの構築を検討した。そして、そのためには新たな通信プロトコルが必要であると考え、新たに、送信元デバイスＩＤ１１、および、共通データ構造１２を策定した。

【0024】

図１Ｂは、無線通信で利用されるデータフレーム１ｂの構造を示している。無線通信の一例はＷｉ－Ｆｉ（登録商標。以下同じ）規格の通信を想定している。Ｗｉ－Ｆｉ規格はＯＳＩ参照モデルでいう物理層およびデータリンク層の仕様を策定する。

【0025】

データフレーム１ｂは、ＯＳＩ参照モデルの各層のヘッダを複数含んでいる。もともと、ＩＰヘッダには宛先ＩＰアドレス２０と送信元ＩＰアドレス２１とを格納することになっている。本発明者は、送信元ＩＰアドレス２１を、上述の送信元デバイスＩＤ１１に相当する識別子として利用することができると考えた。そこで、Ｗｉ－Ｆｉ規格の共通データ構造１２を利用して行われる通信プロトコルでは、当該送信元ＩＰアドレス２１を活用することとした。

【0026】

なお、上述した有線通信および無線通信は一例である。他の任意の通信プロトコルを利用することができる。たとえば送信元のデバイスとして送信元ＩＰアドレスを利用する場合、ＩＰアドレスはＯＳＩ参照モデルでいうネットワーク層に属するため、より下位層である物理層およびデータリンク層は任意である。

【0027】

本発明者は、通信ネットワーク内で送信元を一意に示す識別子を利用して、モータ間通信を実現するマルチモータシステムを構成した。ヘッダ等に送信元を一意に示す識別子が含まれていれば本開示は適用可能である。既存の通信プロトコルであっても、送信元を示す識別子が含まれていれば、送信元デバイスＩＤ１１に相当する識別子としてモータ間通信に利用することができる。たとえばイーサネット（登録商標）規格の通信では、送信元のデバイスを表す識別子として、ＭＡＣ（Media Access Control）アドレスを利用する。ＭＡＣアドレスは、本開示にかかる送信元デバイスＩＤとして利用し得る。

【0028】

図２は、共通データ構造１２を示している。

【0029】

共通データ構造１２は、データ長フィールド１２ａと、動作系コマンドフィールド１２ｂと、属性系コマンドフィールド１２ｃと、データフィールド１２ｄとを有する。

【0030】

データ長フィールド１２ａは、共通データ構造１２の総バイト数を示す。

【0031】

動作系コマンドフィールド１２ｂは、例えばモータを動作させるための動作系コマンドを示す。動作系コマンドは、当該動作系コマンドに対応する数値（２進数表記）で記述される。動作系コマンドの一例は、ライトデータ（Write Data）、リードデータ（Read Data）、実行（Execution）および接続（Connect）である。ライトデータ、リードデータ等は、モータの動作に関連してモータユニットが行う動作である。つまり、動作系コマンドは、モータユニットが行うべき動作を指定する、他のモータユニットからの要求または他のモータユニットへの要求であると言うことができる。

【0032】

属性系コマンドフィールド１２ｃは、モータに関する属性を指定する属性系コマンドを示す。属性系コマンドもまた、当該コマンドに対応する数値（２進数表記）で記述される。属性系コマンドの一例は、現在の角度（Present Angle）、ターゲット角度（Target Angle）、角度制限（Angle Limit）およびシリアル番号（Serial Number）である。属性系コマンドは、動作系コマンドとともに指定される、モータに関する静的または動的な属性であると言うことができる。

【0033】

データフィールド１２ｄは、属性系コマンドフィールド１２ｃに対するデータが記述される。データの一例は、角度設定値、回転速度設定値、シリアル番号値である。

【0034】

上述した共通データ構造は、たとえば３バイトから１３バイトまでの範囲内に収まる、比較的短いデータ長を有する。他の通信プロトコルであるＥｔｈｅｒＣＡＴは３２バイトの大きさであるため、通信時の混在解消および回線の占有を抑制できる。さらに、動作系コマンドと属性系コマンドとを分けて規定したため、利用者（プログラム者）にとって理解しやすい。

【0035】

なお、動作系コマンドフィールド１２ｂおよび属性系コマンドフィールド１２ｃにどのようなコマンドが格納されるかについては、後の実施形態とともに説明する。

【0036】

２．マルチモータシステムの構成
次に、マルチモータシステムおよび当該マルチモータシステムを構成するモータユニットの例示的な実施形態を説明する。

【0037】

１台の製品に、複数台のモータユニットが搭載される例が増えてきた。そのような製品では、あるモータユニットが他のモータユニットと通信する必要性が高まっている。

【0038】

たとえば図３Ａから図３Ｃは、複数台のモータユニットを搭載する製品の例を示している。

【0039】

図３Ａは、コミュニケーションロボット３０ａの外観を示している。コミュニケーションロボット３０ａの矢印で示す各位置にモータユニットが搭載されている。１台のコミュニケーションロボット３０ａには約２０個またはそれ以上のモータユニットが装着され得る。これにより、ロボット３０は複雑な動きを実現することが可能になる。

【0040】

図３Ｂはパワーアシストスーツ３０ｂの外観を示している。パワーアシストスーツ３０ｂは農作業、介護作業等に使用される。図３Ａの例と同様、複数の矢印で示す各位置にモータユニットが搭載されている。なお、矢印は主として右半身側のモータユニットのみを示しているが、右半身に対応する左半身の各位置にも同様にモータユニットが設けられている。たとえば、パワーアシストスーツ３０ｂには腕力・脚力を支えるため２０個以上のモータユニットが使用され得る。なお図３Ｂには、参考のためパワーアシストスーツ３０ｂを装着した人のシルエットが記載されている。

【0041】

図３Ｃは業務用冷蔵ショーケース３０ｃの外観を示している。矢印で示す各位置にモータユニットが搭載されている。１台の業務用冷蔵ショーケース３０ｃには１０個以上のファンモータユニットが装着され得る。これにより、冷却効率を高めることができる。

【0042】

本実施形態では、上述した１台の機器に含まれる複数のモータユニットは相互に通信して、自律的かつ協調して動作する。

【0043】

たとえば、業務用冷蔵ショーケース３０ｃに搭載された複数台のうちの１台のファンモータユニットが故障したとする。故障したファンモータユニットの回転が停止したにもかかわらず、他のファンモータユニットがこれまでと同様の回転状態を維持すると冷却効率が低下する。

【0044】

そこで、あるモータユニットが故障したことを、そのファンモータユニット（以下「故障ユニット」と略記する。）自身が他のファンモータユニットに通知し、または故障ユニットとの通信ができなくなったことを他のファンモータユニットが検出する。すると、複数台のファンモータユニットのうちの、故障ユニット近傍の２台のファンモータユニットが自身の動作を変化させる。具体的には、当該２台のファンモータユニットは、回転速度の増加および減少を交互に繰り返して故障したファンモータユニットに代わって動作する。これにより、冷却効率を維持し温度ムラの発生を抑止することができる。

【0045】

図４は、複数のモータユニット３２ａ～３２ｅが相互に通信する、本実施形態によるマルチモータシステム１０３の模式図である。後述のように、各モータユニットは、モータおよび種々の回路要素を含んでいる。各モータユニット３２ａ～３２ｅは、たとえば上位装置１５０からの指示に従って動作を開始する。

【0046】

たとえばモータユニット３２ａは、自身が故障したことを検出して他のモータユニット３２ｂおよび３２ｅに、故障したことを示す故障通知コマンドを送信する。故障通知コマンドを受信すると、モータユニット３２ｂおよび／または３２ｅは受信応答コマンドをモータユニット３２ａに送信するとともに、モータユニット３２ａを代替して動作する。「代替して動作する」の一例を説明する。モータユニット３２ａ～３２ｅがファンを回転させるモータである場合、モータユニット３２ｂおよび／または３２ｅは、これまでよりも回転速度を高くする。これにより、モータユニット３２ａが送出すべき風量を、モータユニット３２ｂおよび／または３２ｅが送出する風量によって補うことができる。つまりモータユニット３２ｂおよび／または３２ｅは、モータユニット３２ａを代替して動作することができる。

【0047】

なお、モータユニット３２ａが、上述したコミュニケーションロボット３０の１つの関節機構を駆動させるための部品である場合には、他のモータユニットがいくら余分に動作したとしてもモータユニット３２ａの動作を完全には代替できない場合もあり得る。そのような場合には、モータユニット３２ｂおよび／または３２ｅは、予め定められた範囲内でモータユニット３２ａの機能を代替するよう動作すればよい。

【0048】

モータユニット３２ａの故障に関する情報は、モータユニット３２ｂおよび３２ｅをそれぞれ経由して、モータユニット３２ｃおよび３２ｄに伝達されてもよい。モータユニット３２ｃおよび３２ｄもまた、予め定められた範囲内でモータユニット３２ａの機能を代替するよう動作すればよい。または、モータユニット３２ｃおよび３２ｄは、補助を行えないことを示す通知コマンドをモータユニット３２ａまたは上位装置１５０に通知してもよい。

【0049】

なお、図４のマルチモータシステム１０３では、通信可能なモータユニット同士が線で結ばれているが、記載された線および矢印は一例である。線で結ばれていないモータユニット同士も相互に通信を行うことができる。

【0050】

上述のようなモータユニット間通信を実現するためには、多くのモータユニットのどのモータユニットからコマンドを受信したのか、および、どのモータユニットにコマンドを送信すればよいのか、を各モータユニットが把握する必要がある。そこで、図１Ａに示す「送信元デバイスＩＤ１１」または「送信元ＩＰアドレス２１」が、送信元を示すデータとして利用可能である。「送信元デバイスＩＤ１１」または「送信元ＩＰアドレス２１」は、受信したコマンドに対する応答を送信する送信先としても利用され得る。

【0051】

以下、モータユニットの構成と、モータユニット間で行われる通信を説明する。

【0052】

図５は、本実施形態による、コミュニケーションロボット３０ａ（図３Ａ）の関節を回転させるモータユニットを含むマルチモータシステム１０３の構成例を示している。図５の例では記載の便宜上、２つのモータユニット１０６Ａおよび１０６Ｂが示されているが、図３Ａ～図３Ｃおよび図４に示すように３以上であってもよい。

【0053】

マルチモータシステム１０３は、モータユニット１０６Ａおよび１０６Ｂを有している。モータユニット１０６Ａは、通信回路１１０Ａと、プロセッサ１１２Ａと、メモリ１１３Ａと、モータ駆動回路１１４Ａと、関節用モータ１１６Ａと、関節機構１０４Ａとを有する。モータユニット１０６Ｂは、通信回路１１０Ｂと、プロセッサ１１２Ｂと、メモリ１１３Ｂと、モータ駆動回路１１４Ｂと、関節用モータ１１６Ｂと関節機構１０４Ｂとを有する。モータユニット１０６Ａおよび１０６Ｂは、インテリジェントモータ（登録商標）と呼ばれることがある。なお、上述の説明では、一例として関節機構１０４Ａおよび１０４Ｂはそれぞれモータユニット１０６Ａおよび１０６Ｂに含まれるとしたが、含まれなくてもよい。

【0054】

なお、本明細書ではモータユニット１０６Ａおよび１０６Ｂは、図５に示す上位装置１５０を介して通信を行ってもよいし、上位装置１５０を介することなく互いに直接データフレームを送受信する通信を行ってもよい。

【0055】

通信回路１１０Ａおよび１１０Ｂはそれぞれバッファ１１１Ａおよび１１１Ｂを有している。バッファ１１１Ａおよび１１１Ｂには、予め、モータユニット１０６Ａおよび１０６Ｂをそれぞれ識別するための識別子が格納されている。当該識別子は、通信可能な範囲の通信ネットワーク内で一意に識別可能な文字および／または数字であればよく、たとえばＩＰアドレス、または、上述した、デバイスごとに重複なく付与されたＩＤ（デバイスＩＤ）であり得る。

【0056】

データフレームを受信したとき、通信回路１１０Ａおよび１１０Ｂは、それぞれ、物理層、データリンク層の処理を行い、データフレームの送信先デバイスＩＤ１０（図１Ａ）がバッファ１１１Ａおよび１１１Ｂに格納されている自身の識別子と一致するか否かを判定する。一致する場合には、通信回路１１０Ａおよび１１０Ｂは当該データフレームの処理を続行し、一致しない場合には当該データフレームを破棄する。

【0057】

Ｗｉ－Ｆｉ規格による無線通信が行われる場合には、上述の自身の識別子としてＩＰアドレスを採用し得る。通信回路１１０Ａおよび１１０Ｂは、データフレームの宛先ＩＰアドレス２０（図１Ｂ）が自身のＩＰアドレスと一致するか否かを判定する。その後の処理は上述の処理と同じである。

【0058】

データフレームの処理を続行する場合には、通信回路１１０Ａおよび１１０Ｂは、データフレームに、さらにＯＳＩ参照モデルにおけるＩＰ層、トランスポート層等毎の処理を順次行い、共通データ構造１２を抽出する。上述のように共通データ構造１２には動作系コマンド１２ｂ等が含まれている。通信回路１１０Ａおよび１１０Ｂは、それぞれ、コマンドを抽出し、プロセッサ１１２Ａおよび１１２Ｂに送信する。

【0059】

プロセッサ１１２Ａおよび１１２Ｂはいずれも、半導体が集積された信号処理プロセッサである。プロセッサは「信号処理回路」または「制御回路」とも呼ばれる。プロセッサ１１２Ａおよび１１２Ｂは、それぞれ、指定された回転速度でモータ１１６Ａおよび１１６Ｂを回転させるための信号を生成する。当該信号は、たとえばＰＷＭ信号である。またプロセッサ１１２Ａおよび１１２Ｂは、他のモータユニットから送信されたデータフレームに含まれる共通データ構造１２に含まれるコマンドおよびデータを解釈し、コマンドの内容に応じた処理を行う。

【0060】

メモリ１１３Ａおよび１１３Ｂは、他のモータユニットと、当該モータユニットの識別子とを対応付けたテーブルを予め保持している。つまり、識別子は各モータユニットの通信回路に予め設定され、当該識別子が他のモータユニットのメモリに保持されている。プロセッサ１１２Ａおよび１１２Ｂは、データフレームの送受信を行いたいモータユニットが決まれば、当該モータユニットの識別子を特定し、通信回路１１１Ａおよび１１１Ｂに指示することができる。

【0061】

モータ駆動回路１１４Ａおよび１１４Ｂはそれぞれ、ＰＷＭ信号に応じた大きさおよび方向で電流をモータ１１６Ａおよび１１６Ｂに流す。これにより、モータ１１６Ａおよび１１６Ｂは時計回りまたは半時計回りに回転する。モータの回転に伴い、モータの回転軸に取り付けられた関節機構１０４Ａおよび１０４Ｂも時計回りまたは半時計回りに回転する。その結果、モータの回転に応じた速度、角度および方向で関節機構が動作する。

【0062】

回転させる速度および時間等は、属性系コマンドフィールド１２ｃおよびデータフィールド１２ｄ（図２）を利用してコマンドの一部として指定され得る。プロセッサ１１２Ａおよび１１２Ｂは、指定された回転速度および回転時間でモータ１１６Ａおよび１１６Ｂが回転するよう、ＰＷＭ信号を生成すればよい。

【0063】

３．送信先モータユニットおよび送信元モータユニットを示す識別子の例
例として、モータユニット１０６Ａがモータユニット１０６Ｂの現在の回転速度を知りたい場合を考える。なお、本明細書および図面では、データ構造に記述される値を２進数または１６進数によって表記する。これらは単に形式が相違するに過ぎず、図面の紙面等との関係で選択されるにすぎない。当業者であれば、これらの実体は同じであることが理解される。なお、１６進数の数値には「０ｘ」が付されている。

【0064】

モータユニット１０６Ａはモータユニット１０６Ｂに、「モータユニット１０６Ａの識別子＋現在の回転速度のリクエスト」を送信する。モータユニット１０６Ａの識別子は、モータユニット１０６Ａを示す送信元デバイスＩＤ１１（図１Ａ）、または、モータユニット１０６Ａを示す送信元ＩＰアドレス２１（図１Ｂ）に記述される。

【0065】

図６は、ＲＳ－４８５規格の通信時のデータフレーム２ａの例を示している。データフレーム２ａは図１Ａのデータフレーム１ａに対応する。なお、図１Ｂに示す、無線通信で利用されるデータフレーム１ｂに対応する例の説明は省略するが、当業者であれば、図６の例に基づいて理解することができる。

【0066】

データフレーム２ａには、送信先デバイスＩＤ１０としてモータユニット１０６Ｂを示す１バイトの値"00000010"が記述され、送信元デバイスＩＤ１１としてモータユニット１０６Ａを示す１バイトの２進数値"00000001"が記述されている。

【0067】

また、共通データ構造１２には、動作系コマンド１２ｂとして、データの読み取りを示す「リードデータ（Read Data）コマンド」に対応する１バイト値"0x01"が記述されている。また、属性系コマンドフィールド１２ｃには、現在の回転速度を示す"Present Speed"に対応する２バイト値"0x00,0x21"が記述されている。他のデータフィールドは本開示には特に関係しない。よって他のデータフィールドの説明は省略する。

【0068】

モータユニット１０６Ｂは自身宛てのコマンドを含むデータフレーム２ａを受信する。モータユニット１０６Ｂのプロセッサ１１２Ｂは、送信元ＩＤとして付加されている識別子に基づいてメモリ１１３Ｂに記憶されているテーブルを参照し、当該データフレームを送信したモータユニットが、モータユニット１０６Ａであることを特定する。

【0069】

モータユニット１０６Ｂは、データフレーム２ａの共通データ構造１２に含まれる動作系コマンドおよび属性系コマンドを解釈して、モータ１１６Ｂの現在の回転速度を読み取る。その結果、モータユニット１０６Ｂはモータユニット１０６Ａに、「送信元ＩＤ情報（モータユニット１０６Ｂ）＋現在の回転速度の情報」を送信することができる。モータユニット１０６Ｂが送信するデータフレームの具体的な説明は省略する。なお、モータユニット１０６Ｂはコマンドを受信した直後に、コマンドを受信したことを示す受信応答コマンドをモータユニット１０６Ａに送信してもよい。

【0070】

４．マルチモータシステム内の通信を調停するモータユニットの決定方法
背景技術欄で説明したように、各々が通信機能を具備した多数のモータユニットが通信ネットワークを構成している場合には、別途設けられたホスト端末と各モータユニットとが通信を行っていた。ホスト端末は通信開始の順序、および、タイミングを調整する調停を行っており、通信の衝突を回避していた。

【0071】

上述のとおり、本開示によるマルチモータシステム１０３（図４）にはホスト端末を設ける必要はないため、通信を調停するホスト端末の存在を前提とすることができない。よって、新たに通信を調停するための仕組みが必要となる。

【0072】

マルチモータシステム１０３にはモータユニットのみが存在するため、通信を調停するモータユニットを如何に決定するかが問題となる。さらに、通信を調停するモータユニットが決定された後、新たなモータユニットが通信ネットワークに接続された際、通信を調停するモータユニットを如何にして知るかが問題となる。

【0073】

そこで本発明者は、以下のように通信を調停するモータユニットの決定方法、および、決定されたモータユニットの周知方法を策定した。

【0074】

以下の説明では、通信を調停する特定のモータユニットを「アービトレータ（arbitrator）」と呼ぶ。アービトレータは「特定モータユニット」とも呼ばれ得る。

【0075】

４．１．アービトレータの決定方法
まず、アービトレータの決定方法を説明する。以下の説明では、各モータユニットの動作を説明するが、各モータユニットの実際の動作はプロセッサ１１３Ａ（図５）等が行うことに留意されたい。

【0076】

図４に示すマルチモータシステム１０３が、１台の装置（たとえばコミュニケーションロボット３０（図３Ａ））内に構築されているとする。当該装置に電源が投入されると、各モータユニットが一斉に起動し、通信可能な状態に移行する。この時点ではまだアービトレータは存在しない。ただし各モータユニットはバッファ１１１Ａに、自身の識別子（デバイスＩＤまたはＩＰアドレス）を有している。

【0077】

各モータユニットは、バッファ１１１Ａに格納された自らの識別子を通信ネットワーク全体に送信する。この方法としては、たとえばＯＳＩ参照モデルにおけるデータリンク層におけるブロードキャストを用いることができる。「ブロードキャスト」とは、同じデータリンク内の全宛先を指定し、１対不特定多数で行われるデータ通信をいう。これにより、各モータユニットは通信ネットワークに存在する全てのモータユニットの識別子を共有することができる。たとえばモータユニット１０６Ａ（図５）は、得られたすべてのモータユニットの識別子を、メモリ１１３Ａに格納する。

【0078】

各モータユニットの識別子は所定の順序に従って付与されている。モータユニットの識別子がＩＰｖ４のＩＰアドレスである場合には、ＩＰアドレスを構成するＩＰアドレスネットワーク部とＩＰホストアドレス部のうち、ＩＰホストアドレス部の数値により、各モータユニットを順序付けることができる。また、モータユニットの識別子がデバイスＩＤである場合にも、デバイスＩＤをたとえば２進数によって表現することにより、各モータユニットを順序付けることができる。

【0079】

本実施形態では、所定の順序で付与された識別子に応じてアービトレータとして動作する。より具体的には、本実施形態では、識別子が最も小さいモータユニットがアービトレータとして動作する。上述したとおり、各モータユニットは、通信ネットワーク内のすべてのモータユニットの識別子を、メモリ１１３Ａに格納している。よって、各モータユニットは、どの識別子が最も小さいかを判定することができる。最も小さい識別子を有するモータユニットが自身であると判定すると、当該モータユニットは、自身がアービトレータであることを、通信ネットワークの他のすべてのモータユニットに通知する。通知は、アービトレータを通知するコマンドおよび自身の識別子を含むデータフレームを、ブロードキャストすることによって実現され得る。本明細書では、アービトレータであることを示す識別子を、「プライマリＩＤ」と定義する。

【0080】

次に、モータユニットの識別子を共有する際の変形例を説明する。

【0081】

各モータユニットが他の全てのモータユニットの識別子を共有しようとする時点ではアービトレータが決定されていないため、各モータユニットが自らの識別子を一斉にブロードキャストする可能性がある。これでは通信の衝突が発生し、モータユニットの識別子を共有することができない、またはモータユニットの識別子を共有するまでに相当の時間を要する可能性がある。

【0082】

そこで各モータユニットは、自らの識別子を利用して識別子を送信する時刻を調整してもよい。上述のとおり、各モータユニットの識別子は所定の順序に従って付与されている。そのため、識別子を示す数値に、予め定められた時間（たとえば２０ミリ秒）を乗じて得られた時間だけ識別子の送信を遅らせる。

【0083】

図７は、アービトレータ決定前の識別子を含むデータフレームＦの送信タイミングを示している。図７の例は、図４に示すモータユニット（Ｍ／Ｕ）３２ａ～３２ｅの送信タイミングを示している。各モータユニットの識別子は、モータユニット３２ａ～３２ｅから１つずつ昇順で増加しているとする。各データフレームＦには、モータユニット３２ａ～３２ｅ各々の識別子が格納されている。これにより、通信ネットワーク上を流れるデータフレームの衝突を防止しながら、各モータユニットは通信ネットワーク上のすべてのモータユニットの識別子を共有することができる。

【0084】

４．２．アービトレータ決定時の周知方法
次に、通信を調停するモータユニットの周知方法を説明する。

【0085】

図８は、モータユニット１０６Ｂがアービトレータであることを通知するデータフレーム３ａの例を示している。データフレーム３ａは図１Ａのデータフレーム１ａに対応する。なお、図１Ｂに示す、無線通信で利用されるデータフレーム１ｂに対応する例の説明は省略するが、当業者であれば、図８の例に基づいて理解することができる。

【0086】

データフレーム３ａには、送信先デバイスＩＤ１０としてブロードキャスト通信であることを示す１バイトの２進数値"11111111"が記述され、送信元デバイスＩＤ１１としてモータユニット１０６Ｂを示す１バイトの２進数値"00000010"が記述される。

【0087】

また、共通データ構造１２には、動作系コマンド１２ｂとして、データの書き込みを示す「ライトデータ（Write Data）コマンド」に対応する１バイト値"0x02"が記述されている。また、属性系コマンドフィールド１２ｃには、プライマリＩＤを示す２バイト値"0x00,0xC1"が記述されている。他のデータフィールドは本開示には特に関係しない。よって他のデータフィールドの説明は省略する。

【0088】

なお、識別子が最も小さいモータユニットがアービトレータとして動作する、というアービトレータ決定方法は一例である。識別子が最も大きいモータユニットがアービトレータとして動作してもよいし、識別子を用いた所定の演算によってアービトレータを決定してもよい。または、各モータユニットが有する識別子以外のパラメータを利用してアービトレータを決定してもよい。

【0089】

図９は、アービトレータ決定時の各モータユニットの一連の処理の手順を示すフローチャートである。ステップＳ１において、各モータユニットは、自身の識別子を格納したデータフレームＦを通信ネットワークにブロードキャストする。

【0090】

ステップＳ２において、各モータユニットは、他のモータユニットがブロードキャストしたデータフレームを受信する。これにより、各モータユニットは通信ネットワーク上のすべてのモータユニットの識別子を共有することができる。

【0091】

ステップＳ３において、各モータユニットは、すべてのモータユニットの識別子のうち、自身の識別子が最も小さいか否かを判定する。自身の識別子が最も小さい場合には処理はステップＳ４に進み、そうでない場合には処理は終了する。

【0092】

ステップＳ４において、当該モータユニットは、自身の識別子をプライマリＩＤとして格納したデータフレーム３をブロードキャストする。これにより、通信ネットワーク上のすべてのモータユニットは、どのモータユニットがアービトレータであるかを識別することができる。

【0093】

上述の方法によって決定されたアービトレータは、以後通信ネットワーク内で行われる通信の順序、タイミング等の調停を行う。具体的には、各モータユニットからアービトレータ宛ての通信要求等のコマンドを受信すると、アービトレータは、送信を許可するモータユニットには通信許可応答を送信する。これにより、通信ネットワーク上の調停が実現される。なお、調停方法は周知の任意の技術を利用することが可能であるが、これ以上の具体的な説明は本開示の範囲外であるため省略する。

【0094】

アービトレータは周期的に図８に示すデータフレーム３を通信ネットワークに送信する。これにより、他のモータユニットは、現在のアービトレータを知ることができる。また、事後的に電源が投入されたモータユニットもアービトレータが既に決定されていることを知ることができる。

【0095】

４．３．アービトレータの変更方法
いま、故障等によってアービトレータが周期的なデータフレーム３を送信できなくなった場合を考える。

【0096】

当該通信ネットワークに存在する他のすべてのモータユニットは、予め定められた時間、たとえば１秒、だけ待ち、依然としてデータフレーム３を受信できない場合には、新たなアービトレータを決定するため、図９に示す処理を再度実行する。これまでアービトレータであったモータユニットは通信ができないため、次に小さい識別子を有するモータユニットがアービトレータになる。アービトレータになったモータユニットが、プライマリＩＤを通知するデータフレーム３をブロードキャストすることにより、他のすべてのモータユニットは、プライマリＩＤを、アービトレータとなったモータユニットの識別子に更新する。これにより、以後、各モータユニットは、新たなアービトレータ宛てに通信要求等のコマンドを送信して調停を求めることができる。

【0097】

なお、共有しているすべてのモータユニットの識別子の中から、次に識別子が小さいモータユニットが、自らがアービトレータであることを他のモータユニットに通知してもよい。当該方法によれば、図９の処理を新たに実行するよりも迅速にアービトレータを決定することができる。

【0098】

上述のいずれかの処理によれば、アービトレータに故障が発生した場合でも速やかに次のアービトレータを決定することができる。

【0099】

アービトレータの変更は、故障時に限られない。たとえば以下のような状況が発生した場合には、アービトレータを変更してもよい。

【0100】

アービトレータの挙動に異状が発生したと判断される場合には、他のモータユニットにアービトレータの権限を委譲することができる。「異状」とは、たとえばアービトレータがデータフレーム３を送信しているにも関わらず、当該アービトレータが他のモータユニットからの通信要求を一定時間以上受け付けない、等の状況である。これはアービトレータとして動作するモータユニットを、悪意のある第三者が乗っ取った場合が想定される。アービトレータの権限を委譲することにより、アービトレータが乗っ取られたとしても当該マルチモータシステム１０３は制御を失わず、継続して動作することができる。

【0101】

アービトレータとして動作するモータユニットには、他のモータユニットよりも大きな処理負荷がかかる。そのため、任意のタイミング、または、予め定められたタイミングでアービトレータを変更することにより、特定の１台のモータユニットに処理負荷がかかりすぎないよう、処理負荷を他のモータユニットに適切に分散させることができる。これにより、特定の１台のモータユニットの製品寿命のみが縮むことを避けることができる。

【0102】

上述の処理によれば、マルチモータシステムにホスト端末が存在していなくても、ホスト装置に代わるアービトレータを通信ネットワーク上のモータユニットから選出することができる。これにより、ホスト装置が存在しないモータユニットの通信ネットワークにおいて、通信の衝突等を避けて通信を行うことができる。

【0103】

５．マルチモータシステムにおいて行われる、モータユニット間通信
以下、マルチモータシステム１０３において行われるモータユニット間通信の具体例を説明する。

【0104】

ロボットに代表されるように多くの電動製品には複数のモータユニットが搭載され、互いに連携を取りながらシステム全体の統合的な動作を実現している。これにはモータユニットの状態（ＳＴＡＴＵＳ）情報の通知が欠かせない。上述のように、制御用通信ネットワークは、単一のホスト装置が全モータユニットの状態情報を回収する中央管理型ネットワークであった。

【0105】

命令側と実行側の二体関係を前提とする通信プロトコルでは、要求された状態パラメータを命令者ただ１個体に通知させるだけでよく、送信先の指定に一つのアドレスしか指定できないようになっている。何らかの理由で命令者以外のモータユニットに情報の送信が必要になった場合には、命令者が介入（中継）せざるを得ない。

【0106】

中央管理型ネットワークの制御システムで採用される従来の通信プロトコルでは、複数のモータユニット間で状態情報を共有しようとすると、命令系統の切り替えや仲介デバイスを介した三体間通信を行わなければならず、通信上無駄が多い。センサーとして大量のデータをやり取りする必要のあるマルチモータシステムの通信ネットワークでは、状態情報を効率的に送信しネットワーク負荷を低減できるよう、改善が求められる。

【0107】

そこで本発明者は、モータユニット間通信を実現するために検討を重ね、新たな通信手順を策定した。具体的には、本発明者は、新たに２つのコマンド（状態情報送信コマンドおよび状態情報送信タイミング指定コマンド）を策定した。

【0108】

本実施形態では、２つのコマンドは組み合わせて用いられ、「送信する状態情報の種類」、「送信先（複数指定可能）」、「送信タイミング(周期)、送信開始終了時間」の設定情報を指定できる。

【0109】

当該２つのコマンドを用いることにより、あるモータユニットがもつ任意の状態情報を、ネットワーク内にある任意のモータユニットまたは他のデバイスに、任意のタイミングで送信させることができる。また、どの状態情報をどのモータユニット等に送信するかは、一度にまとめて指定できる。２つのコマンドを用いた動作の概要は以下のとおりである。

【0110】

まず、マルチモータシステムは、第１、第２および第３モータユニットを含む複数のモータユニットと、当該複数のモータユニットを接続する通信ネットワークとを有する。マルチモータシステムでは、通信ネットワークを介してコマンドの送受信による通信が行われる。

【0111】

第１モータユニットのプロセッサは、第１コマンドを生成して、通信回路を介して第２モータユニットに送信する。第１コマンドである「状態情報送信タイミング指定コマンド」（または「Send Status Info Timing」コマンド）は、第２モータユニットの状態を示す状態情報を送信させる指示、および、状態情報の送信先である第３モータユニットのモータを識別する識別子を含む。状態情報を送信させる指示は、送信すべき時刻、間隔等の送信タイミングの指示を含む。

【0112】

第１コマンドを受信した第２モータユニットのプロセッサは、第１コマンドに基づいて第２コマンドを生成し、第１コマンドによって指定された送信タイミングで第２コマンドを第３モータユニットに送信する。第２コマンドである「状態情報送信コマンド」（または「Send Status Information」コマンド）は、第２モータユニットの状態情報の値を含む。

【0113】

第１モータユニットが、第２モータユニットに第１コマンドを送信しておけば、以後、第１コマンドによって指定された送信タイミングで、第２モータユニットは第３モータユニットに第２コマンドを送信する。これにより、命令系統の切り替え、および仲介デバイスを介した三体間通信を行う必要がない。また、ネットワークに接続された複数のモータユニットは、通信量を抑えながら互いの運転状況を効率よく共有することができる。なお、必要があれば、ホスト端末を利用する従来の通信方法を採用することもできる。

【0114】

以下、図１０を参照しながら具体例を説明する。上述の、第２のモータユニットから第３のモータユニットにどのような情報を送信させるかを示す様式を、以下では「送信パターン」と呼ぶ。

【0115】

図１０は、２つの送信パターンの各々に基づく情報の送信が行われるマルチモータシステム１０３を示している。モータユニット３２ｆが当該２つの送信パターンを送信する例を説明する。以下の説明ではモータユニット３２ａ～３２ｆの通信には制限を特に設けないが、上述したアービトレータとして動作するモータユニットの調停処理によって通信が許可され、情報が送信されればよい。

【0116】

モータユニット３２ｆは、それぞれ異なる送信パターンを記述した２つの第１コマンドを、モータユニット３２ｃおよび３２ｅに送信する。たとえばモータユニット３２ｆは、モータユニット３２ｃへ第１送信パターンを記述した第１コマンドを送信する。当該第１コマンドを受信したモータユニット３２ｃは、第１送信パターンに従って、モータユニット３２ａに第２コマンドを送信する。またモータユニット３２ｆは、モータユニット３２ｅへ第２送信パターンを記述した第１コマンドを送信する。当該第１コマンドを受信したモータユニット３２ｅは、第２送信パターンに従って、モータユニット３２ｂに第２コマンドを送信する。

【0117】

たとえば第１送信パターンは、モータユニット３２ｃに流れる電流に関する情報をモータユニット３２ａに１０ミリ秒周期で送信させることを示す。一方、第２送信パターンは、モータユニット３２ｃの温度に関する情報をモータユニット３２ｂに１０秒周期で送信させることを示す。

【0118】

送信すべき状態情報として、他に「電圧値の情報」を指定することもできる。状態情報の送信先を識別する識別子、送信すべき状態情報である「電流」、「電圧」、および「温度」、および送信周期である「１０ミリ秒」、「１時間周期」および「１０秒周期」は、第１コマンドに対応する「状態情報送信タイミング指定コマンド」によって指定される。

【0119】

一方、第１コマンドを受信したモータユニットは、送信すべき状態情報を、第２コマンドである「状態情報送信コマンド」に含め、当該第２コマンドを、第１コマンドで指定されたモータユニットに送信する。

【0120】

なお、送信パターンに記述される、あるモータユニットの状態情報の送信先として、複数のモータユニットを指定することが可能である。送信先のモータユニットに応じて、状態情報の具体的な内容を別個独立に指定してもよい。

【0121】

図１１は、第１コマンドである、「状態情報送信タイミング指定コマンド」（「Send Status Info Timing」コマンド）が記述されたデータフレーム４ａの例を示している。図１２は、状態情報送信タイミング指定コマンドのデータフィールド１２ｄの詳細を示している。

【0122】

一方図１３は、第２コマンドである、「状態情報送信コマンド」（「Send Status Information」コマンド）が記述されたデータフレーム５ａの例を示している。データフレーム４ａおよび５ａは図１Ａのデータフレーム１ａに対応する。なお、図１Ｂに示す、無線通信で利用されるデータフレーム１ｂに対応する例の説明は省略するが、当業者であれば、図１１および１２の例に基づいて理解することができる。

【0123】

図１１に示すデータフレーム４ａには、送信先デバイスＩＤ１０としてモータユニット３２ｃを示す１バイトの値が記述され、送信元デバイスＩＤ１１としてモータユニット３２ｆを示す１バイトの値が記述される。図１１では各モータユニットを示す値の具体例は省略し、モータユニット３２ｃおよび３２ｆの参照符号のみを示している。

【0124】

また、共通データ構造１２では、動作系コマンド１２ｂとして、「ライトデータ（Write Data）コマンド」に対応する１バイト値"0x02"が記述されている。属性系コマンドフィールド１２ｃには、状態情報の送信タイミングを指定する「状態情報送信タイミング指定（Send Status Info Timing）コマンド」に対応する２バイト値"0x00,0x74"が記述されている。さらにデータフィールド１２ｄには図１２に示す情報が記述されている。

【0125】

図１２の例では、データフィールド１２ｄには、８つのサブフィールド１２ｄ－１～１２ｄ－８が存在する。括弧内の数値は、各サブフィールドのバイト数を表す。

【0126】

本実施形態では各フィールドは以下の内容を表している。サブフィールド１２ｄ－１は、送信すべき状態情報が「電流」であることを示す。サブフィールド１２ｄ－２は、開始時刻の単位が「ミリ秒」であることを示す。サブフィールド１２ｄ－３は、開始時刻が「即時」であることを示す。サブフィールド１２ｄ－４は、終了時刻の単位が「ミリ秒」であることを示す。サブフィールド１２ｄ－５は、終了時刻が「無制限」であることを示す。サブフィールド１２ｄ－６は、周期の単位が「ミリ秒」であることを示す。サブフィールド１２ｄ－７は、周期が「１０ミリ秒」であることを示す。サブフィールド１２ｄ－８は、送信先が「モータユニット３２ａ」であることを示す。

【0127】

図１２に示すように、データフィールド１２ｄには、どのモータユニットに、いつ、何を送信すべきかが指定されている。これにより、データフレーム４ａを受信したモータユニットは、自身の状態情報を、指定されたモータユニットに、指定されたタイミングで送信することができる。状態情報の送信時には、図１３に示すデータフレーム５ａが利用される。

【0128】

図１３を参照しながらデータフレーム５ａを説明する。図１０に示すモータユニット３２ｃからモータユニット３２ａに状態情報が送信される例に沿って説明する。

【0129】

データフレーム５ａには、送信先デバイスＩＤ１０としてモータユニット３２ａを示す１バイトの値が記述され、送信元デバイスＩＤ１１としてモータユニット３２ｃを示す１バイトの値が記述される。図１３では各モータユニットを示す値の具体例は省略し、モータユニット３２ａおよび３２ｃの参照符号のみを示している。

【0130】

また、共通データ構造１２では、動作系コマンド１２ｂとして、「状態情報送信（Send Status Information）コマンド」に対応する１バイト値"0x14"が記述されている。属性系コマンドフィールド１２ｃには、「現在の電流」に対応する２バイト値"0x00,0x48"が記述されている。なお、データフィールド１２ｄには、「現在の電流」を示す数値が記述される。

【0131】

第１送信パターンに基づいて、モータユニット３２ｃは、モータユニット３２ｃに流れる電流値の情報をモータユニット３２ａに１０ミリ秒周期で送信する。

【0132】

図１０に関連して説明した、モータユニット３２ｆからモータユニット３２ｅに送信される、第２送信パターンを含む第１コマンドの構成は、図１１および１２に準ずる。また、当該第１コマンドに従ってモータユニット３２ｅがモータユニット３２ｎに送信する第２コマンドの構成もまた、図１３に準ずる。モータユニット３２ｅは、第２送信パターンに基づいて、モータユニット３２ｅの温度の情報をモータユニット３２ｂに１０秒周期で送信する。

【0133】

これにより、あるモータユニットが、他のモータユニットに一度送信パターンを送信するだけで、マルチモータシステム１０３内に存在する複数のモータユニットが、必要なタイミングで自発的に、送信命令の重複なく状態情報を他のモータユニットと直接共有することができる。本実施形態によれば、ホスト端末を介して通信する必要がないため、通信帯域等の資源の浪費および通信ネットワークの混雑を抑制できる。

【0134】

なお、状態情報の送信パターンは、セキュリティー等の制限要請がなければ、ネットワーク内にあるどのモータユニットからでも指示できる。自動送信モードにおける送信周期は、ミリ秒から秒、分、時、日、年にわたるワイドレンジで任意に設定することができる。送信される状態情報は、モータユニットの属性値として定められるすべてのパラメータを対象にできる。また、送信パターンは任意のタイミングで書き換え可能である。さらに、通知の送信を開始する時刻と終了する時刻を設定することもできる。

【0135】

上述の説明では、第１コマンドである、「状態情報送信タイミング指定コマンド」（「Send Status Info Timing」コマンド）の送信先は、特定の１つのモータユニットであった。また、第２コマンドである、「状態情報送信コマンド」（「Send Status Information」コマンド）の送信先も、特定の１つのモータユニットであった。しかしながら、これらは一例である。第１コマンドおよび第２コマンドの一方、または両方の送信先として、ブロードキャスト通信であることを示す１バイトの２進数値"11111111"が記述されてもよい。これにより、同じデータリンク内のすべてのモータユニットを送信先に設定することができる。

【0136】

また、第１コマンドおよび／または第２コマンドの送信先として、複数のモータユニットをまとめて指定することもできる。複数のモータユニットを１つのグループとし、各グループを一意に特定する識別子（グループＩＤ）を予め割り振っておく。各グループに属するモータユニットは、自身が属するグループＩＤがデータフレームに記述されているか否かを判定し、自身が属するグループＩＤが記述されている場合には、当該データフレームを取得する。このように、自身の識別子とは別に、グループの識別子を設けることにより、いわゆるマルチキャスト送信が実現される。

【0137】

上述した送信パターンを利用した状態情報の送信は、送信パターンを生成したモータユニットが意図した時刻に行われることを要する。そのため、送信周期、開始時刻、終了時刻等の基準となる時刻、たとえば現在時刻、はモータユニット間で同期している必要がある。

【0138】

通信ネットワークは伝送距離の長短およびトラフィックの多寡に応じて、伝送遅延の程度が異なるため、時刻を示す情報をモータユニット間で伝送すると、相互に同期しない可能性が生じる。

【0139】

そのため本実施形態では、モータユニットのプロセッサを動作させるオペレーティングシステム（ＯＳ）の時刻管理機能を利用する。ＯＳは、たとえばネットワーク・タイム・プロトコル（Network Time Protocol；ＮＴＰ）を利用して、予め設置されたＮＴＰサーバにアクセスする。ＮＴＰサーバは、ＧＰＳ、標準電波、原子時計等の正確な時刻源に直結されている。各モータユニットのＯＳは、ＮＴＰサーバから取得した時刻に基づいて各モータユニットが持つ時計（図示せず）を、正しい時刻（絶対時刻）へ同期させる。ＯＳが所定の周期で、または、通信ネットワークの混雑が十分少ないタイミングで上述の同期処理を実行することにより、各モータユニットは絶対時刻を保持することができる。絶対時刻の取得処理は、通信開始に先立って行っておけばよい。

【0140】

送信パターンを生成するモータユニットは、当該絶対時刻に基づいて状態情報の送信周期、開始時刻、終了時刻等を指定する。これにより、絶対時刻を保持し、送信パターンを受信したモータユニットもまた、意図された通りのタイミングで状態情報を送信することができる。

【0141】

上述した動作は、たとえば「絶対時刻１２時００分００秒に、所定の状態情報を、特定のモータユニットに送信する」という、各モータユニットへの動作予約であると言える。指定されたモータユニットは、絶対時刻が１２時００分００秒に到達したときに動作する。これにより、モータユニット間の同期動作が実現される。当該方法によれば、通信で遅延が発生するような、長距離通信またはトラフィックが多い状態での通信であっても、同期動作が可能になる。

【0142】

送信パターンに基づく状態情報の共有は、たとえば挙動監視用途でも利用され得る。

【0143】

あるモータユニットは、送信パターンに基づいて動作する特定のモータユニットから状態情報を定期的に受信する。受信した状態情報のログ管理を行うことで、特定のモータユニットが不正な第三者に乗っ取られているか否かを監視することができる。ここでいう「ログ管理」とは、状態情報の送受信が定期的に行われているかどうかの確認のみならず、予定された内容の状態情報が受信されていることの確認も含み得る。

【0144】

以上、本開示の実施形態を説明した。上述の例は本開示によるモータユニットおよび複数のモータユニットで構築されたマルチモータシステムを制限するものではない。

【0145】

上述の例では、送信先デバイスＩＤ１０または送信元デバイスＩＤ１１として、モータユニットのＩＰアドレスまたはデバイスＩＤを利用した。しかしながら、モータユニットの主要な機能部品はモータであるため、当該識別子はモータの識別子と呼ぶこともできる。

【0146】

６．モータユニット間で通信を行うマルチモータシステムの変形例
図３Ａの例では、コミュニケーションロボット３０ａ内の複数のモータユニット同士が互いに通信する態様を説明した。また図３Ｂおよび図３Ｃの例では、それぞれパワーアシストスーツ３０ｂ内の複数のモータユニット同士、業務用冷蔵ショーケース３０ｃ内の複数のモータユニット同士が互いに通信する態様を説明した。いずれの例でも、１つの系（１つの製品）の中に含まれる複数台のモータユニット間の通信を想定していた。

【0147】

しかしながら、異なる系にそれぞれ含まれるモータユニット同士が互いに通信することも可能である。

【0148】

図１４は、パワーアシストスーツ３０ｂを装着した人物５０と、グリーンハウス６０とを示している。グリーンハウス６０には、矢印で示す位置に、空調用ファンを回転させる複数のファンモータユニットが設けられている。

【0149】

いま、人物５０が、グリーンハウス６０内で野菜の収穫作業を行う例を考える。人物５０は、パワーアシストスーツ３０ｂを装着して、パワーアシストスーツ３０ｂからのアシスト力を得て野菜を収穫し、野菜を収納した収穫かごを運搬する。

【0150】

本例では、パワーアシストスーツ３０ｂの複数のモータユニットとグリーンハウス６０の複数の空調用ファンとが相互に通信し、連携して動作する。

【0151】

たとえば、人物５０がパワーアシストスーツ３０ｂを利用して作業をしている位置周辺では、熱のこもり等による温度ムラが発生することが想定される。そこで、人が収穫かごを持って収穫作業をしているときは、パワーアシストスーツの１または複数のモータユニットが、グリーンハウス６０の各ファンモータユニットに、現在動作中であることを示す通知を送信する。この通知により、グリーンハウス６０の各ファンモータユニットは、人物５０がパワーアシストスーツ３０ｂを利用して作業中であることを知る。

【0152】

本実施形態では、グリーンハウス６０の各ファンモータユニットは、パワーアシストスーツ３０ｂの位置を示す情報を取得する。パワーアシストスーツ３０ｂの位置は周知の方法で取得され得る。たとえばパワーアシストスーツ３０ｂに無線タグが内蔵されており、無線タグから送信されるビーコン信号を、グリーンハウス６０内の１または複数のアンテナ装置によって受信する。周知の到来方向推定アルゴリズム、たとえば最尤推定法、を利用することにより、ビーコン信号の到来方向を推定することができる。これにより、グリーンハウス６０内の無線タグの位置、つまりパワーアシストスーツ３０ｂの位置を推定することができる。

【0153】

パワーアシストスーツ３０ｂの位置の情報を取得したグリーンハウス６０の各ファンモータユニットは、自律的に自身のモータの回転を制御する。パワーアシストスーツ３０ｂの位置から所定範囲内、たとえば１５ｍ以内、に存在するファンモータユニットは、回転速度を通常よりも高める。これにより、パワーアシストスーツ３０ｂの温度ムラの発生を抑制することができる。

【0154】

図１５Ａは、人物５０が、グリーンハウス６０の入口６２付近で収穫作業を行っているときに回転速度を高める複数のファンモータユニット６４を示している。

【0155】

また、図１５Ｂは、人物５０が移動することによって回転速度を高める、さらに他の複数のファンモータユニット６６を示している。

【0156】

図１５Ａおよび図１５Ｂのいずれの例でも、ファンモータユニット６４および６６以外の他のファンモータユニットは通常の回転速度で回転している。

【0157】

なお、パワーアシストスーツ３０ｂの総消費電力の大きさから、人物５０の運動量の大きさを推定することができる。パワーアシストスーツ３０ｂの各モータユニットがパケットに消費電力の大きさを示すデータを格納して送信することにより、グリーンハウス６０の各ファンモータユニットは総消費電力の大きさを算出することができる。総消費電力の大きさに応じて、グリーンハウス６０のファンモータユニットはモータの回転速度を増減させればよい。より具体的には、総消費電力の大きさに応じた複数の区分を設け、総消費電力が最も大きい区分に属する場合には、対象となるファンモータユニットは最も速くモータを回転させる。このとき、対象となるファンモータユニットを決定するための「所定範囲」を広げてもよい。一方、総消費電力が最も小さい区分に属する場合には、対象となるファンモータユニットは通常の回転速度よりも高速ではあるが、最速ではない回転速度でモータを回転させる。

【0158】

パワーアシストスーツ３０ｂを、人物５０の関節の動きを検出するセンサとして利用することもできる。たとえばグリーンハウス６０内に入った人物５０の具合が突然悪くなり、人物５０が倒れたとする。早急な処置が好ましい上に、倒れたままの状態で長時間が経過すると、グリーンハウス６０内の室温によっては人物５０が熱中症になる危険性がある。

【0159】

そのような場合を想定して、パワーアシストスーツ３０ｂは、人物５０の動きを一定時間、たとえば１５秒、検出できているか否かを監視している。相互に通信することにより、いずれのモータユニットも１５秒以上モータを駆動させていないことが検出されたときは、各モータユニットは緊急信号に相当するパケットを送信する。当該パケットは、たとえば動作系コマンドとして、データの書き込みを示す「ライトデータ（Write Data）コマンド」に対応する１バイト値"0x02"を含み、さらに属性系コマンドとして、緊急事態であることを示す２バイト値"0x00"を含む。

【0160】

当該パケットを受信した各ファンモータユニットは、「パワーアシストスーツのモータが緊急信号を発信している」ことを示す通知を上位装置１５０に送信する。上位装置１５０は、通知の受信に応答して緊急事態が発生していることを管理者または家族に通報する。通報を受けた管理者または家族は、人物５０の様子を確認しにグリーンハウス６０に向かうことができる。

【0161】

なお、上述の実施形態は一例であって本開示によるマルチモータシステムを制限しない。

【産業上の利用可能性】

【0162】

本開示によるモータユニットは、通信ネットワークを有するマルチモータシステムに利用可能である。当該マルチモータシステムは、複数のモータの制御に広く用いられ得る。

【符号の説明】

【0163】

１０３ マルチモータシステム
１０４Ａ 関節機構
１０６Ａ モータユニット
１１０Ａ 通信回路
１１１Ａ バッファ
１１２Ａ プロセッサ（制御回路）
１１３Ａ メモリ
１１４Ａ モータ駆動回路
１１６Ａ 関節用モータ
１０４Ｂ 関節機構
１０６Ｂ モータユニット
１１０Ｂ 通信回路
１１１Ｂ バッファ
１１２Ｂ プロセッサ（制御回路）
１１３Ｂ メモリ
１１４Ｂ モータ駆動回路
１１６Ｂ 関節用モータ
１５０ 上位装置

【図1A】

【図1B】

【図2】

【図3A】

【図3B】

【図3C】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15A】

【図15B】