top of page
20220616094307-1024x140.png

XBUSサーボプロトコル仕様概略 <Ver.1.3.2>

< はじめに >

JR PROPO(以下、弊社)製XBUSサーボモータ(以下、XBUSサーボ)にご興味をお持ちいただき、ありがとうございます。XBUSサーボ プロトコル仕様概略(以下、本ドキュメント)は、XBUSサーボをRC用途以外でもお気軽にお使い頂けるよう、そのプロトコルについて公開し、様々なホビー用途にお使いいただくための便宜を図る目的で作成されました。

今後、様々な形状のXBUSサーボがリリースされていく予定ですが、それらは基本的に統一されたプロトコルで動作できるように設計される予定ですので、用途に応じてご選択いただけるものと考えております。

昨今の高性能なマイコン基板を使い、多くのXBUSサーボを接続して、様々な作品が生み出されていくことを願っております。

< 注意事項 >
  • 本ドキュメントは、XBUSサーボのプロトコル仕様概略です。このドキュメントに掲載されていない部分については、今後の拡張の事もあり現時点では全て予約済みとします。

  • 本ドキュメントは、製品改良等及びドキュメント改良等のため予告なく変更されることがあります。

  • 本ドキュメントは、状況に応じて非公開になる場合があります。

  • 本ドキュメントの無断転載は、最新情報更新の妨げになる場合が多いですのでお控えください。但し、本ドキュメントを基にした解説等の公開や、その際に必要な正しい引用については無論問題ございません。むしろ、歓迎いたします。もしよろしければ、その際は参照用として弊社webページへのリンク等を掲示していただければ幸いです。

  • 本ドキュメントに関連するトラブル等については、弊社は一切の責任を負わないものとします。なお、製品について修理等が必要な場合には、弊社サービス部宛に通常の修理品としてご依頼頂ければ随時対応いたします。

< XBUSサーボ仕様追補 >

各XBUSサーボの一般的な製品仕様については弊社web及びカタログ等をご覧ください。ここではそれらカタログ等に掲載されていない部分についての説明を行います。

XBUSサーボは、電源投入時すぐに内部の初期化を行いますが、以下の条件のどちらかが成立するまでは、モータへ通電しません。

  • 正しいシリアルコマンドを受け取り、かつ位置の指示がなされた時

  • 正しいRC系PWM信号(以下、PWM信号)を一定数連続して受け取った時(現時点では
    50パルス以上)

一旦シリアルコマンドを受け取って動作開始したXBUSサーボは、電源がオフになるまでシリアルコマンドで動作し、PWM信号を一切受け取らなくなります。また、一旦PWM信号で動作開始した場合は、電源がオフになるまでPWM信号で動作し、シリアルコマンドを一切受け取らなくなります。
動作開始後、通電したままでシリアルコマンド、もしくはPWM信号が途切れた場合、約1.5秒後に脱力します。なおこの設定は変更でき、脱力しないようにもできます。
なお、即時脱力を行いたい場合、シリアルコマンドであれば動作角度に0を指示することで、すぐに脱力します。

< XBUS Servo Bug Information, Improvement Information >

ここでは既知のバグについての説明を行います。もし、旧バージョンにおけるバグでトラブルが発生する場合は、大変お手数で申し訳ございませんが、前述の弊社XBUSサーボ専用メールアドレスまでメール頂けましたら、対処いたします。
現時点で判明しているバグ情報、改良情報は、以下のとおりです。

table_jp1.png
< ハードウエアについて >

< シリアルバス関連仕様 >

XBUSサーボをマイコン等のホストに搭載されたUART等(以下、ホストUART)で駆動する場
合の、ハードウエア条件は以下のとおりです。1線半二重である他は、ごく普通のTTLシリアル信号です。

 3.3V TTL 1線 半二重通信(ホストUARTは通常TXモード)
 8bit, 1 start bit, 1 stop bit, non parity, LSB first
 Idle Hi Level
 250kbps BER under 1%

< 信号線仕様 >

信号ケーブルは通常のRC用サーボと同じものであり、各配線の役割も同じです。また、コネクタも通常のRC用と同じものです。

table_jp2.png

< 諸注意 >

  • パケット送受信に用いるホストUARTの出力には、万が一に備え保護抵抗として100Ωか
    ら1kΩ程度を信号に直列に入れておくのが望ましいです。ただし、信号線の浮遊容量が大
    きい場合には、小さめの保護抵抗にしないと波形が歪み、パケット抜けや動作停止(正常なパケットが到着しないことによる脱力等)が発生しますので、ご注意ください。

  • 状況によっては、ホストUARTにのみ100kΩ程度のプルアップを設置する方が、動作が安
    定する場合があります。特に後述のTX、RXの切り替え時にバスが中途半端な電圧になっ
    てしまう場合には、プルアップしておくことをお勧めします。

  • ホストUARTの信号線に保護抵抗が入っている場合に限り、5V出力のシリアル信号を受け
    取ることは可能ですが、XBUSサーボ側は保護抵抗及び保護ダイオードによるクランプと
    なるため、あまりお勧めしません。また、その場合でもXBUSサーボから返される信号は
    3.3Vのシリアル信号となります。

  • 比較的高速なシリアルバスのため、キャパシタを用いたフィルタ類は一切厳禁とします。
    オープンドレイン、オープンコレクタの使用も推奨しません。pF単位の容量でも影響を及ぼすことがあるため、配線には注意してください。長距離を伝送する必要がある場合に
    は、適宜双方向バッファ等の設置が望ましいです。

  • 通信が途中で破断した場合に備え、信号線がアイドル状態になった事を検知してリカバー
    するシステムが組んであります。アイドルであるかどうかの判定は、スタートビット発生
    後10ビット分信号がハイのままの時に判定されます。正規の信号は8bitパリティなし1ス
    トップビットです。ですので、0xFFを送信する場合において、次の1バイトのスタート
    ビットが概ね0.5bit分以上の遅延をした場合、アイドル状態と判定されパケットの受信に
    失敗する可能性がありますので、ご注意ください。

< ソフトウエアについて >

< 概 略 >

このプロトコルは、基本的にバイト列で形成されたパケットを用いて通信を行うシステムです。パケットの内容により、XBUSサーボから応答のパケットが返ってくるものと、返ってこないものがあります。


全てのパケットには、末尾にCRCが設定されており、その正当性が担保されます。XBUSサーボ内部においては、CRCエラーが出たパケットは全て破棄されます。また、ホストが受領したパケットについては、ホスト側にてCRCの確認をするのが望ましいです。
 

各XBUSサーボには後述の方法でチャンネルIDを設定できます。チャンネルIDは、一連のXBUS
の接続の中では、全てユニークでなければなりません。なお、チャンネルIDの設定は、トラブルを回避する観点で事前に個別にホストUARTに接続して行うのが望ましいです。

 

パケットには大きく分けて2種類あり、XBUSサーボの角度指示を行うチャンネルデータパケットと、その他の各種設定を行うコマンドデータパケットがあります。コマンドデータパケットについては、さらにいくつかの種類があります。
 

通常の使い方としては、ホストUARTはTXモードに設定しておき、PWM信号のように間欠的に
XBUSサーボに対してチャンネルデータパケットを送り続ける形になります。XBUSサーボは、
送り続けられる角度指示に従い続けます。

 

同一のバスに同一のチャンネルIDを持つXBUSサーボを複数接続することは、プロトコル上問題が出る場合がありますので基本的に禁止していますが、異なるチャンネルIDを持つXBUSサーボを、後述のサブIDを活用することで4個まで連動させることが可能です。
 

コマンドデータパケットを用いることで、原則として任意のタイミングで任意のXBUSサーボに対してその設定を変更することができます(一部例外あり)。また、同じく任意のタイミングで任意のステータスを確認することもできます。ただし、1線半二重ですので、バスの管理には注意が必要です。

< チャンネルデータパケット >

XBUSサーボへの角度指示を行います。本パケットのバイト列は以下のとおりです。

table_jp3.png

なお、本パケットに対するXBUSサーボからの応答パケットは発生しないので、ホストUARTは
パケット送信後もTX状態のままで構いません。
基本的には、接続されている全てのXBUSサーボに対する角度指示を一つのパケットに内包し、一括送信する形になります。しかし、XBUSサーボは本パケット内に自身宛のデータが無くてもエラーとは判定しませんので、例えば複数パケットに別々のチャンネルIDの角度指示を載せる等して、分割して送信することも可能です。

< 解説1> チャンネルIDについて

各XBUSサーボには、それぞれにユニークな8bitのチャンネルIDが割り振られますが、これは以下のような構造になっています。

table_jp4.png

チャンネルデータパケットで指定できるのはサーボIDのみであり、サブIDは0を指定します。
チャンネルデータパケットを受け取ったXBUSサーボは、XBUSサーボ自身のサブIDに何番が指
定されていようと、サーボIDが一致する指示に従います。

後述する個々のXBUSサーボの各種設定については、サブIDを含めたチャンネルIDの一致で動作するため、これにより最大4個までのXBUSサーボが、同一のサーボIDによって同期的に動作することが可能になります。


製品出荷時のチャンネルIDは0x01です。

< 解説2 >  指示値について

High Lowの2byteで位置指示を行います。この値は、従来のPWM信号の概念を踏襲しており、
以下のような符号無の値で指示します。XBUSサーボは概ね850-2150uSecの範囲で動作するよ
うになっています。それ以外の範囲での角度指定については、脱力します。

0x0000      800uSec
0x1249      900uSec          (-60°、-75°、or -90°)
0x7FFF      1500uSec       (0°)
0xEDB6      2100uSec      (+60°、+75°、or +90°)
0xFFFF      2200uSec 

ただし、後述のリミット値が設定されている場合、その値よりも外側の指示についてはリミット値でクリップされるため、設定によっては脱力せず、リミット位置で停止します。現時点では、リミット値が工場出荷時に800-2200で設定されているため、事実上リミット値は無効になっています。

< 解説3 >  繰り返しについて

本パケットは不定長であり、ユーザが必要とするチャンネル数分のデータを内包した形で1個のパケットとして送信できます。ただし、同じサーボIDは複数指定できないため、サーボIDの最大数(50個分)が限度となります。


繰り返す場合は4項の4バイト分を一塊として繰り返す形になりますので、それぞれチャンネルIDと指示値が繰り返し表記される形になります。
 

本パケット内では、チャンネルIDは連続していてもいなくても構いませんし、チャンネルIDの順番にも特に制限はありません。

<< 一例 >

table_img1_edited.png

基本的にXBUSサーボはパケットの先頭から順番に自身のサーボIDを探しますので、長いパケットの場合は最初と最後でミリセカンドレベルのタイミング差が出る可能性があります。
 

XBUSサーボ自身が持つバッファサイズを超えるパケットが送信された場合、たとえCRCが正常であってもエラーになります。その結果、当該パケットは無視され次のパケットを待つモードに戻ります。その際なんらかのステータスが返送されるわけではありませんのでご注意ください。基本的に各XBUSデバイスは最低でも16個分のデータを受信できるだけのバッファを持っています。XBUSサーボにおいては、通常50個分のデータを受信できるだけのバッファを持っています。

< 解説4>  CRC8について

CRCの計算範囲はパケットの先頭からCRC枠の直前までです。

本パケットに適用されるCRC式は以下のとおりです。CRCの範囲は、パケットの先頭からCRC
手前までのバイト全部です。本ドキュメント末尾にサンプルソースを掲載しましたので、参考にしてください。

 X8 + X5 + X4 + 1 

 

全てのパケットにおいてCRCのチェックを行いますので、ホスト側のコードを書く上では重要なポイントの一つになります。

< コマンドデータパケット >

XBUSサーボへの各種設定を行います。本パケットのバイト列は以下のとおりです。

table_jp6.png

なお、本パケットに対しては、後述する一部の例外を除き、基本的にXBUSサーボから後述の
Status Commandを用いた応答パケットが発生しますので、ホストUARTはパケット送信完了
後速やか(数uSec程度)にTXを開放してRXに切り替え、Status Commandパケット受信の準
備をしてください。


ただし、ホストUART内部に送信バッファを持つ場合、確実にパケットのバイト列が送信完了していることを確認してから切り替えを行わないと、XBUSサーボがパケットを全て受信できず、エラーになる場合があります。


現時点では明確なタイムアウトは設定されていませんが、遅くとも14mSec以内に何らかの反応がなければ、失敗したものと見做して構いません。

< 解説1 >  コマンドについて

本パケットは、以下の3つのコマンドに適用されます。

 

0x20 Set Command      
> 後述するオーダーに沿った値を設定するコマンド
0x21 Get Command    
> 後述するオーダーに沿った値を読み出すコマンド
0x22 Status Command    

> 応答に使われるコマンド(ユーザ使用不可)

ホストがSet Command、またはGet Commandを送信すると、XBusサーボは後述するオー
ダーに沿った作業を行い、その結果として基本的には同じオーダー/同じバイト数のStatus
Commandを応答してきます。

XBUSサーボから送信されたStatus Commandは、通常当該オーダーに関する現状の値を返し
てきます。Set Commandに対する応答の場合、状況によっては、設定しようとした値ではなくXBUSサーボ側での限界値にクリップされた値で帰ってくることがあります。

XBUSサーボが対応できないオーダーだった場合、後述のUnsupported Orderに変更された
Status Commandが返ってきます。この場合、Data2は存在しませんので、元のオーダーによってはバイト数が1バイト少ないサイズで返ってくることに注意してください。

このように、Status Commandのパケットサイズは変化する可能性がありますので、必ず受信中の2バイト目で判断して受信長を決めるようにしてください。

< 解説2 >  チャンネルIDについて

前項のチャンネルIDと同仕様ですが、ここではサブIDも適用されます。従って、最大200個の
XBUSサーボを相手にできますが、本コマンドは応答が前提であることもあり、1個のXBUS
サーボにつき毎回1パケットを必要とします。


また、Set Commandついては、ここに0x00を指定するとすべてのチャンネルIDを持つXBUS
サーボに対して効力を持ちます。このケースに限っては、Status Commandを用いた応答パ
ケットは発生しません。なお、誤ってGet Command に0x00を指定してしまっても、応答はあ
りませんのでご注意ください。

< 注意 >​

複数のXBUSサーボが接続された状態で、チャンネルIDに0x00を指定したID変更やリセット関係のオーダーを実行すると、全てのXBUSサーボが同じチャンネルIDになってしまいます。その後のチャンネルIDを指定したコマンドデータパケットに対しては、それぞれがほぼ同時に応答してしまってバスが混乱するので注意してください。​

< 解説3 >  About Order, Data

オーダー、データに関する役割等は以下のとおりです。本パケットでは、オーダーによってはData2~4が存在せず、パケット全体のバイト数も変化することに注意してください。2バイトのデータについては、特に断りがない限りData1が上位バイト、Data2が下位バイトとなります。また、基本的に符号付データとして扱います。符号無データに関しては、備考にunsignedと記述してあります。


3バイト、4バイトのデータについては、オーダーによって扱い方が異なります。
 

一部のオーダーを除き、基本的に全てのオーダーは後述のOperate Modeにて動作し、指示に成功すれば即座に動作に反映されます。
 

基本的に、Parameter Writeコマンドを送信しない限り、パラメータはROM領域には記録され
ません。但し、後述のようにいくつかの動作については例外的に即時書き込まれるので注意してください。

なお、バージョン7までのXBUSサーボは通常のPWM信号でも動作しますが、その際以下のオーダーにて設定された内容は反映されません。

Reverse, Neutral, Travel High, Travel Low, Limit High, Limit Low

 

バージョン8以降は反映されるようになりました。

table-jp72.png

<別表1> Parameter Reset、Parameter WriteにおけるIndex

table-jp8.png

<別表2> Productにおける応答値/機種名一覧

■ 新JR PROROモデル [ 応答値 / 機種名 ]

[0x02A5/S89CYC] [0x02A4/S87CYC] [0x021A/E555XBUS] [0x02A3/S8477BL] [0x0297/S8911BL-2K] [0x0295/S8955SS-2K] [0x029C/S8944] [0x0293/S8912SHV-2K] [0x0299/S8914SHV-2K] [0x292/S3911-2K] [0x028A/S3411-2K] [0x029D/S3415-2K] [0x029B/S1855-2K]


■ 旧JR PROROモデル [ 応答値 / 機種名 ]

[0x0200/NX8921] [0x0201/NX3421] [0x0202/NX588] [0x0203/NX8925] [0x0204/NX3425] [0x0205/NX6421] [0x0206/NXR89] [0x0207/NXR34] [0x0208/NXB8921] [0x0209/NXB8925] [0x020A/NXB89G] [0x020B/NX8931] [0x020C/NX8935] [0x020E/NX35G] [0x020F/NX396] [0x0210/NX319] [0x0211/NX189]

< 解説4 >  CRC8について

CRCの計算範囲はパケットの先頭からCRC枠の直前までです。


本パケットに適用されるCRC式は、前項と同じく以下のとおりです。CRCの範囲は、パケット
の先頭からCRC手前までのバイト全部です。本ドキュメント末尾にサンプルソースを掲載しましたので、参考になさってください。

 X8 + X5 + X4 + 1 

全てのパケットにおいてCRCのチェックを行いますので、ホスト側のコードを書く上では重要なポイントの一つになります。

< パケット送信間隔について >

通常、XBUS用RC受信機においてはこれらのパケットを14mSec間隔で送出しています。原則としてパケットの送信間隔はこれが標準ですが、XBUSサーボの実力値としては、さらに間隔を詰めた送信を行うことが可能です。
 

ただし、どこまで詰めることができるのかについては機種によって異なる可能性がありますので、将来に渡って保障可能な間隔も14mSecとします。
 

この問題は、特にチャンネルデータパケットにおいて重要になります。XBUSサーボに高速な反応を期待する場合、指示値を出力するペースを速くする必要があるからです。
 

何チャンネル分のデータを一つのパケットに載せて送信するのかによっても、どこまで詰めることができるのかは変化します。チャンネル数が少なければ、パケット一つに必要な処理時間が短くなるからです。
 

パケット送信間隔を短くしすぎた場合、先行パケットの処理が終わらないうちに後続パケットが到着してしまう可能性があります。この場合、後続パケットはロストすることになりますが、再度パケット取得に復帰するには、ロストパケット送信終了後、最低でも1バイト分以上のアイドル時間が必要となる事に注意してください。
 

参考例ですが、現行機種で実験した場合、4チャンネル分のデータを載せたパケットで、
1.5mSec程度の送信ペースで問題なく動作した実例があります。この場合、パケットの理論的な時間は0.84mSecになり、パケット間隔は0.66mSecになります。

 

同様に50個分のデータを載せたチャンネルデータパケットの時間は、理論値で8.2mSecとなり
ます。仮に60フレーム/秒で動作させた場合、フレームレートは16.67mSecとなりますので、
一般的なモーション動作には充分に間に合う計算になります。

 

ただし、これらの理論値はあくまでホストUARTからの送信がビット列的に最密で送信された場合であり、ホストUARTのプログラミングによっては、バイト間に隙間ができてしまう等、所定の性能が出ない可能性がある事に注意してください。

なお、現行機種のXBUSサーボ制御周期は1mSecもしくは0.5mSec(2Kモデル)ですので、そ
れらよりも短縮することには意味がありません。但し、将来の機種においてはこの限りではありません。

■ XBUS設定器 エキスパードモード マニュアル

ここではXBUS設定器のエキスパートモードについて解説します。

 

エキスパートモード起動方法

XBUS設定器に電源を供給する際、下ボタンを押したまま起動するとエキスパートモードに入ります。起動直後はなんら違いがありませんが、ファンクションの量がかなり増えており、設定可能な項目が増やされています。

エキスパートモード使用方法

通常の使用方法と同じです。設定可能な項目が増えていますが、全て前述のオーダーに関して設定することが可能になっています。

■ 参考

CRC8算出用サンプルソース

source_code_CRC8.png

チャンネルIDの変更方法について

チャンネルIDの変更については、不慮のトラブルをできるだけ避けるため、以下の手順でないと変更されないようになっています。単純にIDオーダーを送信しただけでは変更されませんので、ご注意ください。

  1.   XBUSサーボへModeオーダーを送信し、ID Setting Modeに移行させる

  2.    XBUSサーボへIDオーダーを送信し、IDを変更する
    (この段階で自動的に元のモードに戻る)   

受信機のXBUSポートについて

弊社XBUS対応プロポ及び受信機をご使用の場合、XBUSモードをモードAにした時点で、プロ
ポの操作に合わせ、受信機のXBUSポートから本ドキュメントで述べたコマンドが送出されています。


基本的に、14mSecのインターバルでチャンネルデータパケットが送出され続けており、プロポからXBUS対応サーボへのパラメータ調整が行われる場合はコマンドデータパケットが送出されます。


この際、いくつかの注意点がありますので、受信機のXBUSポートをご利用の際はご注意ください。

  • チャンネルデータパケットは、最大でも16チャンネル分の枠しかありません。17チャンネル以上のプロポの場合、例えば後半4チャンネル分のみ入れ替わり挿し代わりで違うチャンネルへのデータになったりします。必ずどのID向けのデータかを確認し、データの位置で判断しないようにしてください。

  • 受信機やリモートアンテナの機種によっては、パケットの最後、CRCの手前に2バイトのダミーデータが挿入されている場合があります。これは無用のデータですので、無視してください。

  • チャンネル数の少ない受信機であっても、XBUSパケットは送信機からのデータをそのまま流しています。

  • プロポにおけるスティック操作等のデフォルトは±100%となっており、これはサーボにおいては±40度(120度動作時)または±60度(180度動作時)を意味します。最大の動作量を必要とする場合は、±150%とすることで±60度(120度動作時)または±90度(180度
    動作時)まで動かすことができるようになりますので、必要に応じてプロポのトラベルア
    ジャストを変更してください。

  • チャンネルデータパケットの中に、時々CH-Functionに0x80のフラグを立ててくるものが
    ありますが、これはフェイルセーフの情報ですので、このチャンネルデータは無視してください。0x40にもフラグが立つコトがありますが、これはフラグを無視していただいて構いません。当然、0xC0の場合はチャンネルデータを無視するコトになります。

■ 旧XBUSコンバーターについて

XBUSサーボに混在して従来のPWMサーボを使用したい場合、弊社ではコンバーターをご用意しております。ただし、コンバーターについては対応する機能が限定されており、以下の機能のみ作動します。

 

  • チャンネルデータパケットの全機能(但し、16チャンネル分まで)

  • コマンドデータパケットの以下のオーダー
    >>> Mode,  ID,  Version,  Unsupported,  Parameter Reset,  Parameter Write, 
           Reverse,  Neutral,  Travel High,  Travel Low

また、4ポートのコンバーターの場合、初期状態やチャンネルIDのリセット等を行った直後は、サーボIDに全て1、サブIDにそれぞれ0から3の値がセットされます。
 

なお、コンバーターが出力するPWM波形は20mSec間隔で固定されているため、それより高速
にパケットを送信しても対応できません。速くても14mSec間隔程度でのご使用をお願いしま
す。

■ 新XBUSコンバーターについて

XBUSサーボに混在して従来のPWMサーボを使用したい場合、弊社ではコンバーターをご用意しております。ただし、コンバーターについては対応する機能が限定されており、以下の機能のみ作動します。

 

  • チャンネルデータパケットの全機能

  • コマンドデータパケットの以下のオーダー
    >>> Mode,  ID,  Version,  Unsupported,  Parameter Reset,  Parameter Write, 
           Reverse,  Neutral,  Travel High,  Travel Low

また、4ポートのコンバーターの場合、初期状態やチャンネルIDのリセット等を行った直後は、サーボIDに全て1、サブIDにそれぞれ0から3の値がセットされます。

 

なお、コンバーターが出力するPWM波形はXBUSパケット到着時に1発パルスが出る仕様ですので、通常は14mSec間隔になります。

■ 同一関節を複数のXBUSサーボを用いて構成する場合

二足歩行ロボットの一部でよく見られるリンク形状の脚(以下、リンク脚)を構築する場合や肩のROLL軸等、複数のサーボを連動させてトルクアップを図るケースがありますが、この場合、XBUSサーボを用いると非常に簡単に設定できます。
 

XBUSサーボでは、サブIDを用いて最大4個までのXBUSサーボを連動させることができますの
で、たとえばリンク脚の各軸にそれぞれ同一サーボIDで異なるサブIDのXBUSサーボを装備する方法がお勧めです。

フレーム組み立て中、各XBUSサーボにリバース、ニュートラル位置、最大角(トラベル)を設定し、個々のXBUSサーボのズレ等を調整すれば、概ね同期して動作することになります。この調整値は、書き込みオーダーさえ送ってしまえば個々のXBUSサーボが内部に記録し、電源を切っても覚えていますので、一度設定してしまえば、あとはメンテナンス等で再調整する以外は再設定の必要はありません。

 

モーション送信時は、当該サーボID+サブIDをゼロにした単一のチャンネルIDにてデータを送れば良く、同一サーボIDの最大4個ともまとめて駆動することが可能です。ですので、チャンネルデータパケット生成の負担や、モーション作成時のデータ的な負担を軽減することが可能になります。

■ ホストUARTのTXのみでの使用について

本来、XBUSサーボは1線半二重でのやり取りを前提に設計されています。そのため、ホスト
UARTには半二重通信のための送受信切り替えが必要であり、場合によっては外部回路が必要な場合があります。しかし、以下の条件に合致すれば、ホストUARTのRXを使用せず、切り替え回路も不要で、TXのみで動作させることが可能です。

  • 動作中、XBUSサーボの状況を一切確認しない。

  • XBUSサーボへの設定を行うときは、個別に接続して行う。

  • 複数のXBUSサーボが接続された状態では、一切コマンドデータパケットを送信しない。

つまり、事前に全てのXBUSサーボの設定を済ませておきさえすれば、チャンネルデータパケット自身はRXを使用しないので、TXのみで動作させられる事になります。簡易的に動作させたい場合は、こちらがお勧めです。

■ XBUSサーボに使用しているマイコンについて

現時点では、XBUSサーボにはNXP社(旧Freescale社)のMKL16シリーズを48MHzで駆動し
て使用しています。従いまして、現時点での各ポートの厳密な電圧レベル等は、当該マニュアルの参照をお願いします。但し、今後の製品についてはその限りではありませんので、あまり厳密な電圧レベルに依存した使い方はお勧めしません。

 

MKL16マイコンのファームにはセキュリティが掛かっており、無闇に読み出そうとすると、
チップの仕様により内部が全てクリアされますのでご注意ください。クリアされた場合、一切動作しなくなります。復活させるにはファームウエアの再書き込み等、修理が必要になります。修理の際は、クリアなさった旨のご申告がないと、基板異常と判断の上、基板そのものの交換作業が発生し高額な修理になる可能性がありますので、ご注意ください。

 

参考までに、マイコンの信号入力部分の回路略図を掲載します。

schematic diagram.png
bottom of page