本文へ移動

復旧と工場出荷時ファームウェア

確認済み 2026-11-01

結果: 正しい回復手順を選択し、動作前に設定を確認します。 接続診断から開始します : 間違ったポートまたはボーレートでは、ブートローダーの回復は必要ありません。

手順を選択してください

状況 手順
モーターが反応します。通常の保存された設定を復元する そのモーターのバックアップを使用する Node.js settings restore
モーターが反応します。意図的に工場出荷時のソフトウェアに戻す 工場出荷時のフラッシュとその後の Python 修復/検証
転送が中断された後、アプリケーションが応答しません。電源/配線/ID/ボーチェック済み 1 つのモーターのみが接続されたブートローダー recover
元のキャリブレーションは失われ、以前のスナップショットは存在しません 別のモーターのバックアップを代用しないでください。正確なモデルの設定を取得し、再調整する

通常の設定に戻す

モーターを切り離し、機構をサポートし、トルクをオフにし、書き込みをロックし、アラームの原因を取り除きます。 npm run settings -- backup によって作成された JSON を使用します。

macOS / Linux
npm run settings -- restore --port "$SERVO_PORT" --id 1 --file tools/settings/backups/servo-1-before-flash.json
Windows PowerShell
npm.cmd run settings -- restore --port "$env:SERVO_PORT" --id 1 --file tools/settings/backups/servo-1-before-flash.json

--id および --baud は、 の現在の接続 を表しており、必ずしもバックアップされた値である必要はありません。このツールはモデルをチェックし、変更された設定を書き込み、ID/ボーの変更に従い、リードバックを検証します。トルクを有効にしたり、動作コマンドを送信したりすることはありません。失敗後も部分的な変更が残る場合があります。復元はアトミックではありません。

このコマンドは出荷時設定にリセットしたテンプレートを修復せず、Python settings.py バックアップを受け入れません。

工場出荷時のファームウェアに戻す

これは、 SCServo21-GD32-TTL 3.10 ハードウェアと一致する場合にのみ使用します。ソースには、そのイメージとマニフェストが tools/flash/factory/ に含まれています。工場出荷時の起動時にサーボの ID が 1 に変更され、バスの競合が発生する可能性があるため、サーボを分離します。

macOS / Linux
tools/flash/.venv/bin/python tools/flash/flash.py flash --manifest tools/flash/factory/release.json --port "$SERVO_PORT" --id 1
Windows PowerShell
.\tools\flash\.venv\Scripts\python.exe tools/flash/flash.py flash --manifest tools/flash/factory/release.json --port "$env:SERVO_PORT" --id 1

現在の ID を使用して、 FLASH を確認します。通常の転送中は電源を接続したままにしてください。その後、ツールは以前の接続を確認し、必要に応じて 1,000,000 ボーで ID 1 を確認し、動作している接続を報告します。終了コード 2 は、工場出荷時のファームウェアは応答したが設定が変更されたことを意味します。

工場出荷時のソフトウェア に戻った後、最初は正しいように見えても設定を修復します : 保存された設定が無効な場合、ファームウェアは組み込みのデフォルトを使用できます。

ブートローダーの回復

は目的のサーボ のみを接続してください。リカバリは ID によって対処されないため、現在のモデルを確認したり、アップロード前に設定をバックアップしたりすることはできません。この例では、一致するファクトリ 3.10 を回復します。

macOS / Linux
tools/flash/.venv/bin/python tools/flash/flash.py recover --manifest tools/flash/factory/release.json --port "$SERVO_PORT" --id 1
Windows PowerShell
.\tools\flash\.venv\Scripts\python.exe tools/flash/flash.py recover --manifest tools/flash/factory/release.json --port "$env:SERVO_PORT" --id 1

動作を確認します。 のプロンプトが表示された場合にのみサーボの電源を入れ直し、USB アダプターを接続したままにしてください。ツールはブートローダーを最大 60 秒待機します。回復後に予想される ID/ボーを指定します。回復は保証されません。ブートローダーが応答しない場合は出力を保存し、ハードウェアをチェックします。

リカバリの電源再投入ステップを通常のアドレス指定されたフラッシュに適用しないでください。

工場出荷時の設定を修復して確認する

工場出荷時ファームウェアの書き込みまたは復旧後は、設定が失われる前に同じモーターから作成した Python バックアップ、または通常の flash 操作で生成した before_registers_hex を含むレポートを使用します。Node.js のバックアップ形式は使用できません。この例では現在の ID を 1 としています:

macOS / Linux
tools/flash/.venv/bin/python tools/flash/settings.py restore --port "$SERVO_PORT" --id 1 --file backups/servo-1-factory-recovery.json
Windows PowerShell
.\tools\flash\.venv\Scripts\python.exe tools/flash/settings.py restore --port "$env:SERVO_PORT" --id 1 --file backups/servo-1-factory-recovery.json

尋ねられたら、「RESTORE」と入力します。このツールは工場出荷時の 3.10 をサポートし、検出されたカスタム ファームウェアを拒否します。設定を復元し、リセット テンプレートを置き換え、書き込みをロックし、モーターを再起動します。 ID/ボーの変更に従い、モーションコマンドを送信せずに検証します。

次に、サーボの電源を入れ直し、 が復元した ID とボーを使用して確認します。

macOS / Linux
tools/flash/.venv/bin/python tools/flash/settings.py verify --port "$SERVO_PORT" --id 1 --file backups/servo-1-factory-recovery.json
Windows PowerShell
.\tools\flash\.venv\Scripts\python.exe tools/flash/settings.py verify --port "$env:SERVO_PORT" --id 1 --file backups/servo-1-factory-recovery.json

バックアップが別の ID を復元する場合は、最後のコマンドの --id 1 を変更してください。レポートは backups/settings/ に保存されます。エラー後はトルクを無効のままにしてください。修復処理は部分的な書き込みを元に戻さず、自動再試行もしません。

完了チェック: アプリケーションが応答し、電源の再投入後に設定が検証され、物理オフセットの意味と制限が確認されました。キャリブレーションが失われた後に作成されたバックアップでは、以前の値を回復することはできません。再キャリブレーションには、新しいポーズの記録と更新されたモデルの検証が必要です。


ドキュメント ホーム · ソース リビジョン: a995f77 。 Extension 9.0 。