neuron F4についての異常挙動

[tongtybj]

@chibi314

dragonで、neuron F4に4つのサーボ(関節x2 + ジンバルx2)を接続して、 spinalとCAN通信させたところ、 十数秒ぐらいで、spinal,neuronともに点滅が止まる。 2つのサーボ(関節x2 or ジンバルx2)では、ずっと点滅する。 これは、現masterブランチ, v1.0.4両方で起きる現象です。

つぎはどうデバッグすべきでしょうか。

[tongtybj]

追記: 3つのサーボ(関節x2 + ジンバルx1)は問題ない。 訂正: 3つのサーボ(関節x2 + ジンバルx1)もフリーズする

[tongtybj]

いまはこちらのテストセットで試しています。 やはり2個で大丈夫だけど,3個以上だとCANが止まる模様です。

[chibi314]

neuronが一個でサーボが多数あるとパケットが多すぎてneuronが死にます 対策はまだ考えてないです

[tongtybj]

これはF4バージョンのコードの特有の問題？ 前のF1はなかったけど、F4だとこうなるということ？つまり、F1とF4でサーボ通信の実装が違うという理解であっている？

[chibi314]

F1でもなると思います

[tongtybj]

なるほど・・・

今まで、dragonのF1のneuronに4つのサーボを繋げても大丈夫だったのは、奇跡ということになるのかな。 あと、ちょうど今同じテストセットでF1のneuronに変えてテストしているけど、フリーズはしないね・・・

[tongtybj]

メモ1: F4のtruestudioプロジェクトに

• neuron/neuron_f1/CAN
• neuron/neuron_f1/Motor
• neuron/neuron_f1/Servo
• neuron/neuron_f1/Initializer
• neuron/neuron_f1/Imu

を差し替えて、焼き込み、同じテストを行っています。 20分近く経つけど、フリーズしない。

次は、 neuron/neuron_f1/Servoだけ差し替えてテストしてみる。

[chibi314]

F4のfirmwareだけで起こるというのは把握してませんでした

[tongtybj]

F4のfirmwareだけで起こるというのは把握してませんでした

まだ憶測だけど、neuron/neuron_f4/neuronlib以下のなにかが悪さをしているような気がする。 今は、F1のfirmwareを差し替えた状態で、4つサーボをつなげて、半日ぐらい様子を見ようとおもう。時間があるときにウェブカメラを覗いてみてみて。

[tongtybj]

いろいろやって、今のところたどりついた解決案は、send_data_flag == falseのサーボは、能動的に角度等のデータ読み取りをしないようにする: #329

例： https://github.com/tongtybj/aerial_robot/blob/396496b1e085c06034e48400d66bb941f0a8bec2/aerial_robot_nerve/neuron/neuronlib/Servo/Dynamixel/dynamixel_serial.cpp#L194 https://github.com/tongtybj/aerial_robot/blob/396496b1e085c06034e48400d66bb941f0a8bec2/aerial_robot_nerve/neuron/neuronlib/Servo/Dynamixel/dynamixel_serial.cpp#L316

また、角度オフセットの更新など必要な時だけ、一時的に読み取る: https://github.com/tongtybj/aerial_robot/blob/396496b1e085c06034e48400d66bb941f0a8bec2/aerial_robot_nerve/neuron/neuronlib/Servo/Dynamixel/dynamixel_serial.cpp#L77-L95

[tongtybj]

• ステップ1: 1個のneuron(#329 を焼き込んだ)で4つサーボつないで、うち2つがsend_data_flag = true。 一日放置しても大丈夫だった。また、ttl_rs485_mixed_ がtrue/false、両方で試した。 これはneuronが1個なので、spinalからサーボへの目標角度指令の送信レートが500Hzで、最大負荷とみなせる。

• ステップ2: dragonの4つのneuronのうち、半分が #329、半分が最新のmasterを焼き込んだ。最新のmasterを焼き込んでサーボを4つ繋げたものは数十秒でフリーズしてしまう(最大負荷ではないのに、なぜフリーズするのだろう・・・)。一方、#329 を焼き込んだものは、今のところ大丈夫そう(数時間経過)。

• 補足: neuronのインジケータをサーボ通信に合わせて(点滅=正常接続)評価してみた結果、わかったことが、いわゆるフリーズという現象時では、CANだけ死んで(spinalの点滅が止まった)、neuronの方のサーボに関するインジケータは正常に点滅している。つまり、どういうことなんだろう・・・CAN1とUASRT2が同じバスを使っていて、CANの方が圧迫されたから？

[chibi314]

F1で大丈夫だった理由はなんですか？

[tongtybj]

理由ははっきりわかっていない・・・ 推測だけど、CAN1とUASRT2(RS485)のデータ転送のタイミングが奇跡的にズレているからだとおもう。 ちなみに、データシートみると、F1とF4のCAN1とUASRT2はともにAPB2のバスを共有している。そういう意味で違いはないけど、バスの速度に関しては、F1だと32MhzでF4は50Mhz.

今ちょうど、移動机でF1にtag1.0.4を焼きこんで、サーボを4つ繋げてテストしています。もう2時間は過ぎているけど、まだ大丈夫そう。

[chibi314]

send_data_flag=trueのサーボを4つつなげると死にますか？

[tongtybj]

昼間のF1のテストは2/4 (4つの内、2つがsend_data_flag=true)でやってて、大丈夫だった。 さっき, 4/4でやってみたら、見事フリーズした。

いままでの結果をまとめると

• F1: 2/4(◎), 3/4(◎), 4/4(×)
• F4: 2/4(×,ドラゴン上で確認), 3/4(×), 4/4(×)

[chibi314]

F4: 2/4(×)は #329 で改善したんですよね？

あと，これらはspinalに対してneuronをいくつつなげていますか？ F4:2/4以外は1対1ですか？

[tongtybj]

テストべットでのneuronの数は1で、1:1と記し、 ドラゴンはneuronの数が4で、1:4と記す。

今までの#329 なしでのテストをまとめると、

• F1:

  • 2/4:
    • 1:1 : ◎
    • 1:4 : ◎
  • 3/4:
    • 1:1: ◎
  • 4/4
    • 1:1: x

• F4:

  • 2/4:
    • 1:1 : x
    • 1:4 : x
  • 3/4:
    • 1:1: x
  • 4/4
    • 1:1: x

329 によって、 F4は以下のように改善しました。

• F4:
  • 2/4:
    • 1:1 : ◎
    • 1:4 : ◎

[tongtybj]

Solved by #329