blog
blog 2011/.../2019
2019/02/28
ダウンロードは、ここをクリックxdu-3.0-p190615.tgz
2016/08/13
mm8a に向け、2月から7月にかけてブラシレスモーターを製作した。
KitMill Qt-100 を入手（定年のお祝い）し，3D-CAD でモーターのパーツを設計、製作。
3D-CAD は Autodesk Fusion360 、趣味ユーザーは無料で使える。
log,exp 関数を作成
log/exp/pow 関数
2015/05/24
[OV9640]のピン配置調査完了。
調査手順：
1. テスターでピン間の抵抗を測定。ショートしているピン3ピンを発見→GNDと判断
2. GND に対し、高抵抗を介して２V程度のパルスを加え，各ピンの性質を見る。
平滑されるピンは電源ピン。（3本発見）
CMOS I/O はオープンに見える。CMOS I/O の保護ダイオードを介して検波され，VDDIO に電圧が現れるため，VDDIOピンを特定。
1ピンだけGNDにショートしたりオープンになったりするピンがある。おそらくSCCBのデータ出力？
3. VDDIO ピンに３Vを供給し，再び各ピンの性質を見る。今度はCMOS出力ピンが低インピーダンスになり、特定。CMOS入力の中で高抵抗でプルダウンされているものが2ピン。RESETとSTANDBYと思われる。
GND2本にはさまれたCMOS入力ピンをXCLK入力と推定。
また、残る電源2本のうち1本に2.3Vほど現れた。AVDDと推定。最後に残る電源が1.8Vロジック電源。
4. mm6基板から 1.8V, 2.5V, 24MHz を供給。SCCBインターフェースも接続。
各種信号が出始めるので，CMOS出力のピンが特定できた。
5. SCCB でレジスタアクセス。最初タイミングが合わず、アクセス出来なかったが、調整してアクセスできた。これにより全ピンを特定できた。
2015/05/20
aitendo で購入した 「CMOSカメラモジュール（1.3M） [OV9640] 」のピン配置がわからない。HPのデータシート「OV9640FBG」とは異なるモジュールである。
モジュール内部のチップは OV9640 であると仮定して、ピン配置の調査を開始する。
mm-6 基板を用いてセンサー電源を供給、SCCB(i2c) コントロールなどを行う。
gcc-4.6.3 移植で fpu 使用時にバグ。float 比較が cmpsf 命令に変換できず，__ltsf2()などの関数呼び出しになる。
sr.md に (define_expand "cbranchsf4" ...)と、対応する (define_insn "*cmpsf_internal" ...) を記述する必要があった。
2014/12/14
gcc-3.4.6 から gcc-4.6.3 に、 newlib-1.11.0 から newlib-2.1.0 に更新し，srプロセッサ移植コードを修正した。
簡単なテストプログラムで動作確認できた。
complex などが使えるようになる。
2014/11/23
第35回マイクロマウス競技会に参加。
予選では 17秒693 25位、特別枠として決勝に。
決勝では 29秒302 21位 でした。
予選，決勝とも1、２回目のトライアルでは最短経路を求められず，3回目でようやく最短経路を走りました。
mm-7aは1回のトライアルにつき6枚の画像を撮影します。画像はそれぞれ1312x972x8bit の赤の色差画像です。これをSDカードに記録するには20秒近くかかってしまうため、失敗時の画像は保存していませんでした。
最短経路を求められた3回目の画像は保存してあり，画像処理の過程を再現することができるのですが，100%壁の検出が成功した結果が残っているのみで、1，2回目の失敗の原因は不明のままです。
画像処理アルゴリズムはこれまで3度の競技会に参加して得た、様々な照明条件での迷路画像を用いて改善し，認識確度を上げてきました。3月に参加したAPEC大会では本番前の調整走行を含めてほぼ100%の認識が出来ていたのですが...
不調の原因として考えられるのは，カメラをリフトアップしたときの撮影角度の精度が画像処理の許容範囲を越えてずれた可能性があります。メカのガタがだいぶ増えている可能性があります。仰角の1〜2°のずれが致命的です。
2014/03/17
APEC 28th Annual Micromouse Contest
2014年3月17日 Fort Worth, Texas USA
http://mouse.la.coocan.jp/index.php?APEC2014-report
2014/01/29
mm-7a は第34回全日本マイクロマウス大会で、完走は果たした。
しかし、走行速度は予選通過レベルに至らず。
決勝迷路でのエキジビション走行タイムは優勝マウスの1/4以下であった。
カメラによる全迷路解析は何とか実現できたが、タイムトライアル競技で予選も通過できないのは悔しい。
走行速度が上がらないのは主に重心が高く、かつ車軸より前方にあるためである。
直線走行での加減速では、加速度 -2500 mm/s^2 を越えると減速時にタイアのスリップが起こり始める。加速時はもう少し余裕がある。加速、減速で差が大きいのは重心の高さによる。
回転半径90mmのスラローム回転時は、速度300mm/s を越えるとタイアのスリップが起こり始める。重心が高いことに加え、車軸より前方にあるためスリップ限界がかなり低い。
次の課題として、カメラを用いるコンセプトを維持しつつ、速度を追求してみようか。
完全4輪駆動はどうか。
in-wheel motor で4輪独立駆動。ステアリングは受動的に出来るか?
（前(後)輪2輪を平行リンクで繋ぎ、左右の車輪を独立に速度制御することでステアリングを受動的に切ることが出来るか?）
HXM1400-2000 の様なoutrunner brushless はどうか?磁極の位置センサを設けて駆動する必要あり。低速域が問題。
前輪、後輪の制御で安定に走行性御できるか？制御要素が多く、制御目標に対して直交していない？
2013/10/26
追加した加速度センサはノイズ、ドリフトが想像以上に大きい。同じメーカーのジャイロ(LY3100)は非常に安定なため、ジャイロを全面的に信頼した走行制御に切り替えたのだが。加速度センサはタイアのエンコーダによる速度検出の低速域を補間する目的で追加したが、心許ない。
新たな走行制御は形になってきた。ただ、機体の重量が大きく（157g)また重心が高い（35mm）ため、加速度が出せない。直進でせいぜい 3m/s/s。自宅の小さな迷路は直線で最大5区画なので大きな速度のテストが出来ない。
2013/09/15
９月 走行制御の改良に着手。
左右タイヤの回転数平均（走行距離）を、同相で、ジャイロで検出した角度を差動で駆動輪に与える。走行距離目標と角度目標との誤差をそれぞれ同相、差動で加え、それぞれPIDループフィルタを介して左右駆動輪を制御する。
８月 迷路の画像から壁を判別するアルゴリズムを改善。昨年の予選迷路画像では全迷路を正しく検出出来る。もっと画像が欲しいが...
７月 加速度センサ、FFCコネクタ変換、I2CでSW、LEDを増設
'ハッピーPCB'で基板作成
2013/03/30
mimeTeX を導入
http://www.forkosh.com/source_mimetexmanual.html
数式を TeX 流に記述し、cgi で画像に変換、挿入する。
- 例：
<img src="../cgi-bin/mimetex.cgi?x=\frac{-b\pm\sqrt{b^2-4a} }{2a}"> - インストール：
http://www.forkosh.com/mimetex.html からサーバーのOSに合わせたバイナリ：
Precompiled Binaries / Linux(i386) mimetex.zip をダウンロード、解凍し、HP の cgi-bin/ 以下に mimetex.cgi をコピー
以上で OK。
2014/12/追記：上記テストをしたときは表示出来ていたと思うが，現在 nifty のホームページサービスでは cgi が php,perl,ruby のみに制限され、使えない。
新たに MathJax http://ja.wikipedia.org/wiki/MathJax を用いるプラグインを導入。
MathJax plugin: http://abicky.net/pukiwiki/plugins/index.php?mathjax.inc.php#q53234f0
例：
#mathjax(x=\frac{-b\pm\sqrt{b^2-4a} }{2a})
インライン記述： $x=\frac{-b\pm\sqrt{b^2-4a} }{2a}$
インライン記述： \( x=\frac{-b\pm\sqrt{b^2-4a} }{2a} \)
ブロック記述：
\begin{eqnarray}
f(\bm x) &=& (x_1 + x_2)^2 \\
&=& x_1^2 + 2 x_1 x_2 + x_2^2
\end{eqnarray}
2013/03/26
迷路最短経路計算ソフト手直し
走行時間を比較して最短を求める。斜めの長い経路が選ばれる。
迷路のパターンによっては探索の木が広がり、多くのメモリを必要とする。
斜めを積極的に選ぶようにしたが、斜め走行の経験が少ないので安定走行の自信がない。
小さな迷路でどうやって詰めていくか?
2012/12/29
Xilinx ise 用ダウンロードケーブル Digilent JTAG HS-1
ドライバインストール手順 (Fedora-15) 覚書
http://lighttomorrow.wordpress.com/2011/12/18/how-to-install-digilent-cable-driver-for-xilinx-design-suite-on-ubuntu-11-10/
1. libusb libusb1-1.0.8-7.fc15.i686
2. Digilent Adept Runtime
digilent.adept.runtime_2.9.9-i686.tar.gz
3. Digilent Adept Utilities
digilent.adept.utilities_2.1.1-i686.tar.gz
4. Digilent Plugin for Xilinx Design Suites
libCseDigilent_2.4.3-i686.tar.gz
libCseDigilentをインストールすることで、root 権限なしにダウンロードできるようになる。
2012/12/20
迷路画像解析ルーチン見直し（高速化）
matrix 演算、ループの内側を最小化。歪み補正前にクリップ判定
迷路解析時間 10s -> 6s に短縮
2012/12/19
mm7t main FPGAの回路見直し。
- sr_cache i-cache と d-cache のアクセス混在時の誤動作
DRAM 上のプログラムを実行してDRAMのデータを参照で誤動作していた。
bus ready の条件抜けを解消してOK - CPUクロック高速化検討 30M->42Mはmet 48Mはtiming met難
クロック高速化でcache誤動作->migの転送終了条件抜け。転送終了直前のFIFOホールドで誤動作。
dirtyセット条件記述ミス
42M化で迷路解析時間 17s -> 10s に短縮
2012/11/24
33回大会予選 結果はリタイア
1回め、迷路撮影、解析後走行 5,0区画の北壁に衝突。おそらく5,0区画付近の壁が数ヶ所抜けて、そこを最短と判断したらしい。
3回め、迷路撮影、解析後走行 1,4区画の東壁に衝突。
5回め、11,10区画北壁に衝突。この回は、画像とログが残った。
迷路東からの外光が迷路上面に斜めに反射し、白く光っており、1回めに抜けたのはおそらくこの原因。偏光フィルタが有効と思われる。
3回めの抜けは不明。h0l画像の角度誤差か? 画像ログが欲しい。
5回目の抜けは縦壁と横壁のコントラストが大きい区画で明るい壁にスレッショルドが引っ張られて暗い壁が抜けていた。アルゴルで改善可能なはず。
他に、走行用フォトセンサが斜め上からの光で飽和気味で、走行が少し不安定。フォトセンサの感度を下げ、Dレンジを確保し、遮光をしっかりする。
2012/11/23
mm-7 何とか完成。 2011年 33回大会に参加
試走会で初めてフルサイズ迷路を撮影した。これまで1/3サイズの縮小迷路を撮影した画像のみで迷路解析ソフトをチューニングしてきたが、実迷路の壁、床の白黒が除去出来るか?
実迷路撮影後、カメラパラメータ(主にΦの中心値を設定)を設定。
迷路解析させたところ、遠方の横壁2ヶ所ほど抜ける。→壁判定スレッショルド決定アルゴルを調整し、試走迷路で100%解析できるようになった。
ただ、撮影した画像を見ると周辺部のボケが激しい。中心部のフォーカスはあっているので球面収差が大きいようだ。周辺と中央のバランスを取ってフォーカス調整した方がよいのだが、余裕が無い。
今年から、ゴール四方の壁の色が黄色になるとのこと。(10/17改訂？)今回は特別に申し出れば赤に変えてくださるとのこと。次回は黄色も判別する必要がある。(B-Y画像で可能か?)
2012/１〜11
2012/1月から仮想設計を初め、6月回路設計完、6/20 P板.com から基板納入。
今回は、0.8ピッチのDDR3の実装と、BGA3個同時実装が心配。費用の点から部品の予備はほとんど無い。
まずは電源チェック、FPGAのコンフィグ確認、基板は1発完動！
カメラ基板から回路組み込み、チェック。MT9P401はすんなり動作。ただ、96MHz動作をすると発熱が大きい。電源ドロップが心配。
メイン基板、DDR3の動作チェック。xilinx mig の exsample design を組み込んでチェック。難なくOK。
後はmm-6で作ったsr-cpu,mmc,pwm,encoder,...各種回路を流用組込み。
spartan-6でcpuのクロックアップを狙ったが、タイミングmetし辛く断念。
7月、友人が迷路解析のアルゴリズム検討を申し出てくれたので、ハードの開発に専念。
10月、友人のアルゴリズムの説明を受ける。友人は何とLabViewのグラフィック言語で検討しており、そのままmm-7のCには持ってこれない。また、実行速度の観点での見直しが必要。解析の手順、考え方をいただいて、Cに組み込む。
2012/01/03
2011年 32回大会はリタイア。
ラインレーザーの光量に対し、会場の照明に照らされた迷路壁上面の赤色が大きなレベルで、位置検出が誤動作。
ラインレーザー案を考えた時点で壁の赤色は懸念だったはずだが、照明光に対する検証を怠ったための失敗。
根本的な方向性が間違っていた。
LONG号の小峰さんが過去に CCDカメラで8x8くらいの範囲を見渡すマウスを作られた。現在のCMOSカメラなど入手可能な部品の進化を考えると、迷路全体を一度に見渡してしまうことが可能になっている。
少し仮想設計をしてみよう。<カメラマウス仮想設計>
2011/06/12
mm6_cache の構成変更。BRAM使用率削減し、 sr_sub DRAMリードキャッシュ sns_cache を追加。
sr_sub のsns_cache デバッグ中 pcの初期化、リセットベクタのフェッチ不具合発見、修正。これまで i/d メモリ共通だったので気づかず。
sns_cd のセンサーデータ処理に、R-Y 処理を追加。
2011/05/22
libgcc のfp代替を作成 __addsf3,__mulsf3, ... fplib.c
/home/shin/opencore/cvs/xgcc-sr/fplib
2011/05/05
sns_cd.vhd 画像信号のSDRAM書き込み時、画面右端のVアドレスがずれる件、
snsfifo のempty flagのタイミング（アドレス）が64のため、Hの最後のデータがFIFOから出ない。→ empty = 62/63にして OK。
2011/04/24
fcmp 命令追加。OK
gcc binutils fcmp 追加OK
2011/04/20
print_dbl() 関数でシミュレーション。 app/sr_test/fptest srsim とisim 突合せ。
sr_fpu.vhd float 命令の０処理 bugfix
gauss-fp を実行。OK
オプション -mfpu でコンパイルした結果に _ltsf2 などfloat比較関数が呼ばれる。fcmp命令追加?
2011/04/19
fpu 実装、デバッグ、合成
fputest.c sim reference
sns_vid をダミーにして合成。xst area で合成。
gauss-fp を実行。動作し始め。演算一部異常。
print_dbl() 関数がテストベンチになるか？
2011/04/10
/home/shin/opencore/cvs/sr-core/hdl/sr_fpu.vhd
pkg_optab-fp.vhd
2011/04/07
gcc multilib compile
gcc-3.4.6/gcc/config/sr/t-sr
MULTILIB_OPTIONS = mfpu/mfpu-ex
configure --enable-multilib
2011/04/06
opencore/cvs/xgcc-sr/srsim debug OK --> commit
opencore/cvs/sr-core/hdl/sr_fpu.vhd edit start
2011/04/02
sr processor fpu の検討
xgcc2/srsim
opcodes-fpu.ods --> optabgen.pl --> optab.h
simcore.c
ophdlgen.c --> pkg_optab-fp.vhd
xgcc2/cgen-latest/cgen/cpu/sr.cpu
xgcc2/gcc-3.4.6/gcc/config/sr/sr.*
xgcc2/gdb-6.7.1/sim/sr.c
- gcc のオプション -mfpu で fpu 命令イネーブル -mfpu-ex で sqrt,divsf 追加
- binutils は fpu enabled
multilib ?
