CDROMに実行環境を焼いて、直接CDROM上からBrickOSを用いたプログラムのコンパイルが
できるようになった。このCDさえ持っていけば、大抵のWindowsマシンでシリアル版IRタワーでの
MindStormプログラム開発が可能である。
USB版IRタワーはドライバが必要なので、ユーザアカウントしかない場合には
このCDROMだけでは何ともならないのであるが、とりあえず、ソースをダウンロードして
クロスコンパイラを構築なんてことをしなくても、お手軽に開発が進められるように
なったので良かった～
LEGOのRCXモジュールをプログラムするのに、ETロボコンで用いたクロス環境を
構築していて、思いのほか苦労してしまった。
実は、クロス環境を構築していたマシンは、ライブCygwinの実験マシンであり、
これがうまくいったらMindStormクロス環境もライブCygwinに入れてしまおうという
目論見があるのである。
BrickOSのホームページには
Cygwin上のインストール方法からインストールのためのスクリプトまで用意されていて
この通りにやれば問題ないはずだったのだが・・・
実は、ライブCygwinの環境実験の途中で自分のCygwin環境のマウント情報をすべて
クリアして実験していたのである。その後、クロス環境を構築しようとして、
ルートディレクトリ(/)だけマウントしたのであるが、これだとコンパイラがぼろぼろ
エラーをはきまくる。
出しているエラーがライブラリのパスや定義の不足が原因であるのはメッセージから
あきらかだったので、コンパイルオプションにパスを追加したり色々と手を打って、
コンパイラ自体は生成したのであるが、あまりにもエラーが多く、何かがおかしいと
不思議に思っていた。
BrickOSのコンパイルでも案の定エラーが発生し、Makefileの作りの問題でコンパイルオプションを
手軽には渡せないので、原因の追究をきちんとすることにした。
そうしたら、実は、Cygwinは/bin, /libを /usr/bin, /usr/libにマウントしていて、
ライブラリは両方にあることを前提に多くのプログラムが動いていることが分かった。
普通に環境を構築すれば全然問題ないのであったが、色々と実験を繰り返すうちに
標準環境がなくなっていたのである。
トラブルの原因として、もっとも嫌らしいのは、Cygwinがマウント情報をWindowsのレジストリに保持する点だろう。
UNIXのように起動時にファイルからマウント情報を読み取ってくれれば、このようなことは
発生しなかったのである。
まぁ、ともかく、一段落なので、これから確認作業をして、CDROMでBrickOSの実行環境を
配れるようにしたいものだ。
（ソースからコンパイルするというのは、多少初心者には敷居が高いのでライブCygwinで
何もしないでBrickOSが使えるとうれしいのである）
何度か出ているけれど、秋に飛行船ロボコンがある。
アーキテクチャ委員の一人として、参加者からの質問もモニタする立場にあるのだけれど、
どうも、みんな「飛行船の制御」を考えていないような気がしてならない。
今回のロボコンの技術的チャレンジは通信部分だったり、飛行船の位置情報の取得だったりと
課題満載なのであるが、その部分は「コンテスト対象ではない」のである。
飛行船という浮体を小さなプロペラで制御するプログラムをモデルベースで開発するということが
あくまでもコンテストの課題なのである。
であるからして、飛行船が浮くとか浮かないとかは実は参加者はあまり考える必要はなく
あくまでもコンテスト対象のモデルに注力して欲しいのであるが、中々伝わっていないらしい。
（実は、身内のチームにすら伝わっていないので、一般参加者には無理のないことかも）
ETロボコンと同じく、ここでもきちんと物理モデルを立てて、
そいつに外乱の要因を併せて考えれば、「技」なんてものは、
論理の世界にマッピングできると私は信じているのである。
そうすれば、すり合わせが得意な日本の組込み業界なんてのも
もう少し属人性を低減し、エンジニアリングに落とし込めると
思うのであるが・・
さて、残りの期間に、みんながどこまでモデルを精密化できるのか、楽しみだ。
Powered by WordPress