Darkside(https対応しました)

2021年11月の記事

<< 前のページ

2021年11月30日(火) 21:25

自作パーツ切り出し

 ワッシャー型をもう1つ切り抜いた後、いよいよ本丸の外側フタを切り出す。

 光出力100ワットに絞ったレーザーで六角形の切れ込みを入れ、光出力を200ワットに上げて切断。そこそこ綺麗に仕上がった。

 折り曲げてみると、サイズは全く問題無し。

 厚さ1ミリのステンレス板を折り曲げたとき、仕上がり寸法がどうなるか厳密には分からない。やってみたら、カンがほぼ的中していたようだ。
 最小限の内部空間が確保され、高さもオリジナルに合った寸法にjなっている。何度か作り直しも覚悟していたので、一発OKは嬉しい誤算だ。

 レーザー加工機が必要なのは、ここまでである。

 次は、現物合わせしながら正確な位置にハンダ付けを行わねばならない。

written by higashino [Sタンク 1/16] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2021年11月29日(月) 21:13

金属ギヤ化への長い道

 ファイナルギアの蓋は、両サイドにある。内側は単純なワッシャー形状であり、内径9ミリ・外径25ミリでいい。
 外側は突き出す必要があり、基本を六角形として折り目付きの花弁型。花弁は僅かに台形にしたかったが、作図方法が分からず長方形で妥協。

 六角形の折り目は別データーにしておき、出力を落としたレーザーによる切れ込み入れである。
 ツールパスを作ろうとしたら、半年ぶりで Fusion 360 のメニューが変わっていて困惑した。
 以前は製造>新しい操作>2Dミル>2D輪郭だったのだが、新しい操作というメニュー項目がどこにも見当たらない。
 結論は、製造>ミル>2D>2D輪郭だった。その後は、ほぼ旧設定画面通りで何とかなった。

 まずは、久しぶりの稼働試験と中央穴サイズの確認を兼ねて、単純なワッシャー型を切り出す。
 久しぶり過ぎて座標のリセットを忘れてしまい、想定と全く違う位置でレーザー照射。いちおうステンレス板の上には違いないので、大事にはならず。

 中央穴は直径9.1ミリの設定で、バッチリ。

 このまま正式採用できる。

written by higashino [Sタンク 1/16] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2021年11月28日(日) 21:38

気分転換で転進

 今度は発想を逆転させ、Jetson Nano がI2Cタイミング信号を操作。dsPIC 側がそれを回避する。
 Jetson Nano の電源を入れていない場合はタイミング信号が常時Lになっているから、dsPIC 側の動作を妨げない。dsPIC はGPIOをリアルタイムに読めるので、干渉回避はより確実に行えるはず。

 だが、干渉回避できない感じ。はっきりしないのは、それどころでは無くなったから。
 三端子レギュレーターが突然過熱し、dsPIC が動作しなくなる。その症状が再発した。それも、再現性が不安定という厄介な状態だ。以前も同様の症状があって、コネクター部分で短絡が発生していると結論。コネクターと配線を交換し、収まったはずだった。だがまた再発し、Sタンクの車体を動かすと発生頻度が明らかに高くなることから、配線のどこかが短絡寸前になっていることが想定される。それも、配線が動き易いコネクター周辺が最も怪しい。

 幸いにして Jetson Nano を動作させなくても症状は出るので、一部のコネクターを抜いて再現性を見ることにより、短絡犯を絞り込むことは可能だ。これを解消しないことには、I2C干渉どころではない。

 いいかげん精神的に疲れて来たので、ギアボックス作成を先に進めることにする。
 ファイナル付近のギアが度々破損し、遂に金属ギア化を決意。特注ギアが、少し前に届いた。

 ラジコンで金属製ギアだと、大抵はアルミや真鍮である。
 しかしこれは、工業用機械仕様のギア用高強度鋼である。例によって、ハンダ付けとスポットろう付けを駆使して仕上げる。

 最難関は何と言っても、破損しまくりの上にデフギヤを兼ねている複雑構造のファイナルギヤだ。

 シャフト軸が入る6角穴が空いた、特注形状。図面だけで、タミヤの純正部品がピタリとハマる仕上がりになって来た。亜鉛ダイキャスト製のタミヤ部品も、できれば高強度鋼で特注したかった。だが、コピー図面を作るのが至難なので、断念した。どのような図面を出せばコピーになるのか、分からなかったのだ。

 更に、オリジナルの形状が複雑なので、筐体全体を特注図面にすることも断念。自分でステンレス板を切り出し、組み立ててようやく完成する。
 切り出すには、これもいつも通り Fusion 360 で図面作成。久しぶりに Fusion 360 を立ち上げると、1年の期限切れになっていた。個人用無償ライセンスを更新しなくては。

written by higashino [Sタンク 1/16] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2021年11月27日(土) 22:07

全く実用にならない

 Jetson Nano のC言語プログラムが、まっとうに GPIO を読めているのかどうか確認する。
 23番ピンよりもカメラ切り替えに使っている19番ピンの方が、試験には便利。そこで、21番ピンもついでに有効化する。
 gpio16 と gpio17 を有効にし、/sys/class/gpio を確認。すると、gpio16 と gpio17 は確かに存在するが、昨日作成した gpio18 がない。え!もしかしてリセットしたら消えるの!?

 だとすれば、gpio18 が読めなくなったのも当然だ。

 そこで、再度 gpio18 を作成し、すぐにカメラ表示プログラムを動かす。すると、明らかにエラー頻度が激減した。しかし、反応も鈍い。コンマ数秒のループに入ってしまっている。dsPIC 側も、反応が悪くなっている。
 とは言え、恐らく基本戦略は成立しそうだ。ここから改良しよう。

 python だと圧倒的に遅いとは言え、0.1ミリ秒のオーダーでポーリングできるはず。それならば、十分に処理速度は間に合う。
 GPIO の初期化も python 任せにすれば楽だし、C言語の方ではチェックせず python のメインルーチンでチェックするようにしてみよう。
 やってみると、なかなか調子が良い。時々エラーは出るが、エラーが出た時は値を利用しない、という程度の処理で実用上は問題がない。dsPIC 側でもリセットは発生するが、これなら dsPIC 側でタイムアウトを検出するよう修正すれば合格だろう。

 さっそくタイムアウトを検出しようとして、間違いに気付いた。マスター専用であるソフトウェアI2Cでは、タイムアウトという概念がない。送り出すクロックに従って機械的に読み書きしているだけで、決まった時間で必ず処理は完了する。無限ループに入るような可能性は、どこにも存在しないのだ。
 ならば、なぜリセットが掛かるのだ?
 WDTに引っ掛かっている訳ではないのか?

 WDTが実は有効になっていない、というのを疑ってMCCを確認すると、設定1秒で有効になっている。

 何が問題なのか、分からない。そこで、I2C同期信号のマージンを3ミリ秒から5ミリ秒に増やし、挙動が変化するかどうか試してみる。その結果は、何も変わらない。
 Jetson Nano でのI2Cエラー発生頻度も、dsPIC のリセットも、何ら改善されない。液晶表示の乱れからも、I2Cバスが干渉しているのは明白。時分割は一定の効果があるものの、干渉を完全には防げていない。それでも実用的ならまだいいが、dsPIC が何十秒も沈黙を続ける場合もある。
 WDTが効いてくれずに、何十秒も受信不能に陥るのだ。dsPIC は受信機やってるので、止まると送受信できなくなる。

 現状では、全く実用にならない。

written by higashino [Sタンク 1/16] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2021年11月26日(金) 21:30

時分割してる?

 I2Cのクロック100KHzの場合、大雑把に1バイトをアクセスするのに0.1ミリ秒を要する。
 dsPIC では1軸しか読まないので、0.5ミリ秒で読める。この0.5ミリ秒の開始でGPIOをHにし、終了するとLにする。Jetson Nano ではGPIOがLの期間に傾斜センサーを読む。しかしそうすると、読み始めたとたんに dsPIC の読み取りが始まってしまう可能性もある。それを避けるには、まずHになるのを待ち、それがLに変化する瞬間を待てば確実である。だが、それでは待ち時間が無駄である。
 Jetson Nano でも読み出しに2ミリ秒は要しないので、dsPIC は3ミリ秒先行させてGPIOをHにする。

TO_PIN23_SetHigh();
__delay_ms(3);
signed long x = ADXL355_readAcc(ADXL355_ADR_X);
TO_PIN23_SetLow();

という感じだ。Jetson Nano では、とにかくピン23がLだったら傾斜センサーを読み始める。23番ピンは GPIO18 なので、仕込みをする。管理者権限で、

cd /sys/class/gpio
echo 18 > export

これで謎のファイル /sys/class/gpio/gpio18/value が出現する。このファイルを読めば、GPIOの状態が文字列の "0" と "1" として取得できるという謎の実装になっている。たかがGPIOのアクセスに擬似ファイルを使っているせいで、恐ろしく遅い。

 そこで、少しでも高速アクセスすべく、傾斜センサー読み取りルーチンの先頭でGPIOをチェックするようにする。遅い中でも、やはりC言語によるアクセスが断然速いことは、以前確認済みだ。

 こうして dsPIC と Jetson Nano による時分割I2Cアクセスを試すと、それなりに動作する。

 カメラ映像は、時々乱れるが乱れは少なく、実用可能。
 dsPIC の方も、ほぼまっとうに値を拾っている。

 しかし、Jetson Nano 側では時々I2Cのエラーを検出しているし、dsPIC 側も時々WDTに引っ掛かってリセットが掛かっている。
 dsPIC のソフトウェアI2Cはタイムアウト検出していないため、I2Cバスの衝突などで状態が狂って無限ループに入ると、WDTでリセットが掛かる。また、そもそも受信機 dsPIC は処理が重く、更新頻度は秒間10回ぐらいしかない。つまり、時分割しなくても衝突頻度は低いはずなのだ。

 要するに、Jetson Nano 側がGPIOを読めておらず、時分割が機能していないのではないか?という疑いが出ている。

written by higashino [Sタンク 1/16] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

<< 前のページ

Darkside(https対応しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4