7/23　チュートリアル2 セッションSA-6　サーベイヤ計画hamana-1開発記 座席数　180 参加者数　65 ----議事録始まり---------- 岸田： 定刻になりましたので、はじめさせていただきたいと思います。 まず、サーベイヤ計画に関して説明させて頂きたいと思います。 サーベイヤ計画の始まりは昨年の秋の終わりから冬ぐらいに始まりました。 まわりの方々を巻き込んだ、結構長い計画でして、その中の1つに、今回の Hamana-1 Projectも含まれます。 このサーベイヤ計画に関しては、二上さんからお願いしたいと思います。 二上： ロケットエンジニアの二上です。まず、サーベイヤ計画とは何ぞやという話から。 もともとこのSWESTの話の中で出てきた話でして、このSWESTは、SESSAMEの活動 などとの連携がありまして、そのSESSAMEの活動の中からいろんな教材を作成し ていたのです。その中で、いろんなことをしたくなってですね。 今回はロケットを打ち上げました。このロケットはほんとのおもちゃを使ってい ます。但し、H2とまではいかないまでも、その100万分の1の大きさで同じ様な構 成で実現しています。 ここで注意して欲しいのは、単にロケットをつくるのだけでは、目的がはっきり しないし、ただつくるのならキットがある点です。 このHamana-1 Projectのリアルなテーマとして、自然環境の局地観測システムを 作りたい。これは自律型の測位システムです。これは最近のGPSであるとか、セン サー類を搭載し、画像情報を取りながら、自然環境を測位します。 この様なシステムをいろんなつくっていきたいと考えています。 例えば、スポーツ選手に色々なセンサーをつけて記録を採ってみるとかです。 以前、アイススケートの選手にセンサーをつけた話がありまして、これも同じ様 な話です。 今回はセンサーを搭載したロケットを打ち上げました。 サーベイヤ計画では色々な種類のサーベイ手段を用意し、実際に移動する物体に 取り付けて使ってみます。その手段としてロケットであるとか飛行船であるとか を用意しました。 その活動の中で学会などへの発表を行いたいと考えています。 そう言う意味で、今回はロケットを打ち上げたわけです。 このサーベイヤ計画は、元々は組み込みシステムと学習能力の向上を目的として 作られました。 例えば、年内では10月に情報処理学会のシンポジュームがありまして、飛行船を 使用したコンテストを行います。これはロケットと違って完全に自律した制御を 目指します。ここで飛行船の制御を完結した処理系で実現きるかどうかを試して みる予定です。 来年はラジコンの電動の飛行船を予定しています。これですと20分から50分飛行 して、湖の生態系を調査する事ができます。 （プレゼンの写真を指差す） この写真はアメリカのサターン3型のメインロケットエンジンでして、ある時、 打上げ済みロケットの保管庫に行った事がありその時にとった写真です。このエ ンジン一機でちょうどH2の2倍近い出力が出ます。 ここではHamana-1とロケット工学について説明します。 いろんな方に、Hamana-1のロケットの仕様など色々聞かれるのですが、この仕様 は少し変化しています。実は先週の日曜日、富士の原野の中に消えまして、、 機体を消失してしまいました。 一度目の試射では東海大学のグラウンドで、こちらのロケット(写真左、オリジ ナルのモデルロケット)を打ち上げたのですが、巧く行きまして、この調子で飛 ばそうと思ったら、原野の中に消えてしまいました。 (右の図を指しながら) ここにパラシュートが入っています。打ち上げてロケットのエンジンの推力が終 わる頃、最後の部分に逆噴射様の火薬が入っていまして、これが爆発すると此処 からロケットが２つに分かれます。 (実物を示しながら)こう言うパラシュートですね。このパラシュートが胴体の中 に入っていて、実際には２段ですが燃料が入っているのは１段だけの擬似２段の 構造を取っています。 実は富士の裾野で試射した時には、ペイロード(貨物室)のための位置観測の機器 を重心近くに入れなければならないのです。この辺りですね。 この時逆噴射の出力が足りなくてパラシュートが開かなかった。 エンジンと、ペイロードの間はこれくらいで、この間なにも入っていません。 それで逆噴射が起こっても、この間で巧く割れませんでした。 基本的な構造について説明しますと、基本的な構造は固体燃料ロケットエンジ ンと同じです。 エンジンはエステスという会社の製品を使用しています。 この会社は、ドイツでV2ミサイルを作った事に対抗してかどうか判らないのです が、これはアメリカのいいところですね、アメリカのNASAのトップにつけモデル ロケットの会社を作りました。 子供達が宇宙に興味を持たない、これは不味い、模型ロケットの会社を作れとい う事になって、エステス社がロケットを作りました。 (Hamana-1の写真を指しながら) ここが貨物室、ペイロードですね、ここに搭載モジュールとして、センサー装置 などを入れて、ロケットを打ち上げました。ここのセンサーは今回、GPSを使用し ています。このGPSで自分の情報で一番基本となる情報、位置をわかるようにしよ うというものです。 (Hamana-1の打上げ、回収までのシーケンスを指しながら) 次に、これは飛行シーケンスです。 打上げのカウントダウン、イグニッション、飛んでから逆噴射、パラシュートが 開く、着水、回収となっています。 ちょっとここで、組込みエンジニアの基礎みたいな話をしても良いと思う (模型ロケットの本の表紙写真を指しながら) ええっと、これは古い本の表紙ですが、、、昭和30年代の本ですね。 古い本ですが、これにHamana-1を打ち上げるのに必要な全てが書かれています。 今回、この本にも書いてあるのですが、私は機体の方をやりました。 この本の中に細かい事も、記載されているのですが、ロケットエンジン固体燃料 というのは、火をつけましてエンジンの中に入っている酸化剤、これは熱を加え ると酸素が出る物質です。 原理的にはHamana-1、H2Aの固体ブースター、スペースシャトルのブースターは どれも同じでして、やっている事も同じです。 ちょっとH2Aと比較して見ましょう。H2Aの全重量の99%は燃料です。この中には 打上げの対象となるペイロードの貨物も含まれます。エンジンや燃料を入れる入 れ物の質量も含まれています。 それに比べますと、ペイロードなどは、質量比といいますけどたかだか数%、ほ とんどはデッドウェイトです。 で、殆どが燃料だとすると、打ち上げて燃料を燃やしていくと減っていき、全体 の質量も経ていくわけですね。 つまり、99%が燃料ですと積分しなければならない。 これは結構面倒なのですが、推力一定で質量が変化しないとすると、四則演算で 答えが出せます。 Hamana-1の方はもう少し燃料の割合が低くなっています。この程度ですと、先ほ どと違い積分は必要ありません。四則演算で計算可能です。 こう言う風な計算や、設計などを行うという事、こういったことを組み込みソフ トエンジニアとして何がいいかというと、、例えば、人工衛星のソフトウェア仕 様を考える場合に、ソフトウェアの製品仕様書のレベルで議論していたのではそ れは明らかにならない。 実物を考える必要があるんですね。 ですが、組み込みソフトエンジニアはこのロケットを考えた場合でも、尾翼の形 がどうのとかやる機会が無い。そこでこのロケットを作ったわけです。 組み込みソフトウェアさんの中で何か読めるものが欲しいと思っていたのです。 その題材としてサーベイヤ計画を考えております。 全体の計画に関しては追々、公開していき、説明を行う予定です。 あと、今回の打上げでロケットに興味を持っていただき、もう少し詳しくロケット の話を知りたいと言う人は、JAXSの公開されているページ、ロケット打上げ隊の話 などを読んでもらえれば分かると思います。 次は、地元浜松の森さんに話をしてもらいたいと思います。 森： どうも森です。 今、話にあったとおり、ロケットって結構、興味を引くじゃないですか。 あれを見た瞬間に私は買おうと思いました。子供の頃の憧れだったりしますね。 ええっと、本題の基地局の話にもどります。 そもそもこのシステムにおいて基地局という名称そのものが変わっておりますが、、 システム全体を考えて、シーケンスをわれわれソフトウェア研究者がみずから決定 する事によって、ソフトウェアのみではない知見を得ることが目的でして、はい。 この打上げにおいて、重要な事として、実際に打ち上げる時の環境をどうやって考 えるかと言う点がありました。 基地局の動作不良など、最初の計画で収まらないのが開発ではないか？ 例えば、いきなり当日の夜にパソコンが壊れるなどそういうことを含めて開発だな と思いました。 今回の観測局、基地局では3つのことを管理しています。 １つ目は、今回のHamana-1では、飛行経路をEPROMに記録するのですが、ROMの容量 からこの時間が限られており、打上げ前のある時点から記録を取り始める必要があ ります。全部は取れません。この何時から取り始めるのかなどをシステムの仕様と して決める必要があります。 ２つ目には、秒読みソフトウェアが秒読みをはじめるのですが、、、これは画面表 示ですね。この機能を実現して全体シーケンスを管理します。 ３つ目には、観測局とは人手でロケットの軌跡を測定しています。最高高度はどの 程度なのか測定する為のもので、発射局の左辺に180mほど離れて、目視で観測する ことにより実際の観測高度を計ります。 それぞれ手に分度器を持っていてロケットを追いかけるわけですね。 (Hamana-1の打上げ、回収までのシーケンスを指しながら) で、あのHamana-1に関して、簡単に今日の打ち上げの様子を説明しますと、、 機材の配置、安全確認などが済み、打上げに問題ない事を確認した後、秒読みを開 始します。 そして秒読みがおわるとロケットエンジンへの点火、つまりイグニッションですね ええっと、先ほど言ったトラブルは、この秒読みが今回表示されなかった部分です ね。カウントダウンの後に点火し、発射、つまりイグニッションを行いました。 その一方で、観測局では、分度器を持った人が最高点を観測しております。 打上げ後、パラシュートが開き、湖面に落ちるのですが、データロガーのROMの中 に軌跡のデータがあります。このロケットを回収しなければ軌跡を得る事が出来ま せん。この回収は元カヌー部の人に回収をお願いしました。 仕様と同様に、これらの回収までのシーケンスはHamana-1では開発者が決定してい きました。これはシーケンスだけではなく、システム全体に関しても同様に開発者 が決定していきました。あと、考慮しなければならない点として、このシステムの 外側、環境についても検討する必要がありました。検討した内容は、安全確保、 法律遵守、場所でして、この場所には警察所、消防所への連絡も含まれます。 これらを踏まえ、打上げの方法、例えば回収の方法も決定していきました。これは 最初、湖面では無かったんですね。 (浜名湖周辺の地図を指しながら) ちょっとこの地図を皆さんに見ていただきたい。 エンパイヤに近くてかつ広い場所として検討して、候補として、この4つが出てき ました。この射場選びは、予想に反してかなり時間がかかっています。 例えば、浜名湖は冬はとても風が強い。風が強いと目的の場所に落下させる事が で来ません。打上げ安全基準からも、秒速8mを超えると打上げは禁止されています。 この為、Hamana-1でもロケット打ち上げはできません。 ある程度、場所も検討を加えて居ておりほぼ決まりつつあったのですが、5月に入っ てから、ロケットの発射地点から20m見学、準備の人を離さなくてはならないことが 判明し、断念しました。これもモデルロケットの打上げ安全基準に規定されています。 そこでですね、風のない所で打上げたいと言う話になるのですが、現地の状況を確認 に行きました。この確認中浜辺で風が無い事に気がつきました。 普段、相当な風がある場所なのですが、この時は風がありませんでした。この為、 砂浜の風の原因は何だろうと言う話になり、凪ではないかと言う話になりました。 陸地の土と湖の水は、温まる速さ、冷える速さが違い、温度差による風が発生します。 昼間は湖面から陸に風が吹き、夜はこの逆になるので陸から海に向かって風が吹く事 になります。凪は、風が止んで湖面が静かになった状態を指すのですが、この風が入 れ替わる瞬間は無風状態になります。この時間帯を狙おうと言う話になりました。 あと打上げに関しては本来許可は要らないのですが、花博期間中と言う事もあり、 消防署へモデルロケットの打上げを申請しました。これは7月15日に、こちらに待機 していただいている穴田さんに消防署へ書類を提出してもらいました。この申請は思 ったよりすんなりと通り、無事、許可を得ることが出来ました。 次に、開発に関してですが、今回のHamana-1 基地局の開発では、かなり制約が色々 ありました。ソフトウェア開発、特に組み込みソフトウェアの開発で制約が多くあり まして、良い勉強になりました。 例えば、JAXAの方の講演で、人とあわせて三重のフォールトレラントを確保してい る話がありましたが、Hamana-1では、無人の場合、２重のフォールトトレランスを 確保しています。また、発射に関しては、一応人間の方でも秒読みできるよう設計 しています。 その他にも、EPROMから飛翔体の軌跡データ読み出す方法も、パラレルとシリアルの 両方を準備しておいたりと色々な対策を行っています。 色々発生した問題の中で、大きなものに、GPSの電源の安定性があります。これをこ こにどう詰めるかが問題でした。回路がラッチアップしたのだろうと推測しますが、 急に高い電圧が掛かり、AVR のMPUが壊れてしまう症状になりました。これの原因は 究明できていません。 あと、最初、探査体として使用しているセンサー、GPSに関してよく判らない部分が 多かったという点も、制約ではないですが、困った点として挙げておきます。 最初は、判らなかったのですが、GPSというのは電源を入れてから10分ぐらい経たな いときっちりとした場所が判らないという点が困りました。 この事が判り、最初考えていたシーケンスを組みなおす事になりました。また、この シーケンス変更に伴い、電池が、実際の測位までに消耗してしまい、もたないという 事もわかりました。この為、外部電源を用意したり、対策を色々行なう事になり、 またシーケンスも変更する事になりました。 ということで、現在はロケット打上げ20分前からシーケンスを組んでいますが、この 部分は非常に重要な点でした。 あと、GPSの測位が出来ているかどうかを示すビーコンについても話しておきます。 今回のHamana-1では、GPSの三次元測位をしたいので、測位可能になってから打ち上 げないと、正しい位置が測位できません。外部電源を繋いでいる事もあり、三次元測 位が出来るようになった後、ペイロードに格納して、打ち上げるシーケンスにする必 要があります。この辺りも実際に実験を始めてから判った個所です。この事から、 この測位ができている、できていないビーコンの音で判別が付くように設計する事に なりました。これも機能追加です。 この様に、ビーコンを搭載する事で、シーケンスが多少変わりました。 次に、想定しなかった事象、計画当初に想定していなかった項目についてお話します。 実は、これらの殆どは想定できなかった事象ではないくて、考えが及ばなかったり、 何らかのミスが原因の類です。 最初、浜名湖の潮の満ち引きについてお話します。 ええっと、今回の打上げ、打ち上げの時間が引き潮でよかった。 この潮の満ち引きは、考えが及んでいなくて、後で調べてみると、あの浜では、数十 センチ、今回打ち上げた基地局辺りまでは水没するぐらい潮が満ちて来る様です。 もし、満ち潮だった場合、安全基準の20m離れなければならないという項目を守れなか ったのではと思います。その場合、最悪、打ち上げ場所の変更などになっていたかも しれません。 次に、計画に関する事なのですが、基地局を海岸で6時半頃にセットし始めました。が、 どうもノイズなどが載ったのか、SH3のボードが正常動作しないと言う事で、、思った より調整に時間が掛かりました。 基地局をセットする時に、ACアダプタを離すとか色々やってみて、まずは動作する 事も確認で来たのですが、、、あのような結果になりました。 その次に、時間を表示すると言う部分に関しても反省点がありまして、進行状況を 示す、今何分前だよという看板を出したのですけれども、それが見えなかった。見 えづらかった。この辺りは、進行の不手際もありまして反省すべき点です。 次々あるのですが、その次として、実際に搭載しているセンサーとしてのGPSにも 問題があってですね、当日、GPSがうまく衛星を捉えれなかったと言う話がありま す。この辺り、原因はわからない状況です。 ただこういう状況の中、基地局がハングアップしてしまいました。基地局では、 大きな数字をパソコンの画面上に出していたのですが、どうもこのパソコンが正常 動作しない。熱暴走等のご意見も頂きましたが良く判らない状況です。 あと、システムの仕様の勘違いもありました。DGPSという技術の採用に関してです。 当初基地局もGPSで測位されておき、飛翔体の軌跡とあわせて擬似的なDGPSとして 精度を上げよう話がありました。 この為には基地局でもGPSの測位を行っておく必要があります。 この辺り、基地局で発射した時刻の情報も別途必要なのですけど、GPSの測位データ 共々、データが巧く取れませんでした。その他にも、シーケンス上はGPSの電源ONは、 予定では、発射2分前と指定していました。ええ、全然間に合ってないのですね。 もともとは基地局が保存する予定でしたけれど、基地局が暴走しまうと言う想定外 の事が起きてしまい、それをカバーする為の対策を怠っていました。反省すべき点 です。 最後に、今回測位した結果に関して御話します。 私は、実際の打上げでは、観測局の報告を見る立場でした。 今回観測した測定結果を見たのですが、その最高到達地点を調べてみますと、人間 は75mと結構高く飛んでいる結果が得られました。しかし、GPSでは5.4m程度となっ ていました。流石がにこれは、これはちょっと違うなと思います。 また、あれだけ高速で移動してしまうと、緯度経度はいいけれど、高度の測定は人 間業から離れれつつありまして、ちょっと難しいかなと思いました。 今回のHamana-1の結論として見ると、発射から逆噴射、頂点から回収パラシュート で帰ってくるまでの時間が長いので、肝心なデータが抜けているように思えました。 次回に繋ぎたいと思います。 以上です 二上： いろんな失敗がはいっているのがわかると思います。 パート３は搭載した、GPSのデータロガーを開発された東海大の清水先生にお話 してもらいたいと思います。 清水先生： それでは、Hamana-1 探査体の、搭載レコーダ、GPSデータロガーの開発について したいと思います。いまスライドの一番右はしにあるHamana-1、ここにあるのと 同じように見えますが、これは富士の裾野に消えた物です。 まずモデルロケットというのを私はそれまで見たことも聞いたこともなかったの で、調べて見ました。 モデルロケットのペイロード、貨物室ですね、これに搭載可能な質量は大体40g 程度です。 GPSが必要とする電源は、88mA、3.3V、湖面に着水する為、密閉構造にする必要 があります。 データロガーですので、データを記録するのですが、搭載可能な大きさからそう 大きな回路は搭載できません。記録開始のコマンドなど、外部からコマンドを与 える必要が出てきます。ただ、密閉構造ですと、外からコマンドを与えるために は光か無線ぐらいしかありません。この辺り、検討を加えました。 また、飛翔体は、発射から着水までそんな長い時間飛んでいるわけじゃなくて、 せいぜい数十秒程度です。 この間の記録を取ればよいと仕様を決定し、搭載部品の設定を行いました。 ところがカウントダウンの途中、イグニッションの20秒前に時間がストップして しまいました。この部分、シーケンスなどもあまり考慮されておらず、たまたま 大きめのEPROMを搭載していたのでなんとかもったと言う状況です。 ただ、512kbitのEPROMはこれしかありませんでした。 具体的なデータロガーの開発に関して御話させていただきたいと思います。 元々は、モデルロケットの予備機をつくって、それぞれに違うセンサーなど、 色々載せたいという話もありました。 この探査体をどうやって作ろうか、色々検討したのですが、最終的にはマイコ ンで作りました。 Hamana-1の打合せを行いまして、当初、FPGAでやろうと4月の段階で話をし、 その日は解散したのですが、会議のあった名古屋大学からの帰りの新幹線の中 で、考えて見ますと、、EPROMは、必要な基盤面積からシリアルEEPROMにならざ るを得ないのですが、これだと512K BYTE辺りが最大の容量になります。GPSから のデータを128バイト、1パケットにして、EPROMに一秒に一回、書き込むとなる と、そう長い時間は書けません。 あと、配線規模などを考えると、FPGAじゃペイロードに格納できないと判りま して、じゃあマイコンでいこうか。マイコンでいけるかどうかの確認と、実際に 使うMPUの選定になります。そう言えば手元にAVR20ピンのマイコンがあったな、 学生にこれで検討しなさいと、言う話にしました。 彼らは、英文のマニュアルと格闘しながら開発を進め始めました。 (Hamana-1の写真を指しながら) 特に大きいのはペイロード制限でして、ここに何とか収めなければならない。 最終的には35mのカメラのフィルムケースに入れようと言う話になりました。 ロケットの仕様も決まりペイロードの仕様も決まりました。 学生への指示は、何とかその中に収めなさいと言う話になるのですが、この開発、 まったく開発経験のゼロから始まっており、大学院生がバックアップについてい ます。システムの設計や基板設計など、知識が必要な開発もありますし、開発 ツールや開発環境などの準備など、AVRへの書き込みツールなどですね。そういっ たバックエンドの物は大学院生が準備をしました。 あと、重要な条件として、FPGAなどにを採用した場合、このペイロードサイズに システムを組み込んで使用することになります。パッケージサイズの問題もあり、 回路規模も大きくなります。その他にも、FPGAではデバイスの設計とかも必要な んですが、物の調達にも注意すべき点があります。 大学というのは事務組織が大変遅くて、普通に発注すると2ヶ月、3ヶ月へいき で待たされてしまいます。以前、FPGAを使ったセミナー等で困った経験があり ます。これに対し、MPUを採用する場合、購入経路が違います。こちらはデジ キーから直接発注する事がで来ます。この様な理由からMPUの採用を考えたわけ です。 Hamana-1では湖面に着水させますので、必要な機能として完全防水という要件が あります。その他にも、例えば、なにかの拍子に電池がポロッととれてもデータ をきちんと取り出せる必要があります。これがかなり難航しました。 40ｇのペイロード中に収める為にはGPSが20gその他の回路が20g、このその他の 回路の中には電池も含まれていまして、最初は単５電池の採用を考えていました。 ただ、これですと大きさも重さも超えてしまいます。ボタン型のリチウムを直列 にする事も考えたのですが、スペック上、電流が確保できませんでした。 この為、最終的に学生達に様々な電池会社に電話し、色々探して、電流容量を確 保できる電池、カメラ用の3Vリチウム電池を探し出しました。リチウム電池では 液漏れが怖いのですが、用途を説明し、大丈夫との回答をもらった企業の電池を 採用しました。 元々は、完全防水の為、外部からコントロールするにはIrDAのインターフェース が必要だろうと言う話になり、このインターフェイスを持とうという話もありま したが、途中、重量の関係から、単５電池１本という制約をクリアする事ができ ず、このIrDAを外す事になりました。 この事で、シーケンスの中に人手が介入する必要が出てきまして、これは良い方 に転びました。ま、IrDAの回路規模も制約としては厳しいものでしたので、別の 手段を考える事になり、どうせやるなら、電波を出してラジオで聞こえるように しようよという話になりました。これですとトランジスタ１個の追加で済みます し、ベースの信号をMPUからコントロールすれば、モールス符号などを簡単に作る 事がで来ます。これは、GPSの測位ができているかどうかを知らせるビーコンとな りました。 これは、ハードを簡単にしてソフトが苦労するという典型的な例です。こう言う 機能がもう少し早く実現できていればよかった。たとえば、富士山麓に消えてしま った幻の初号機などはこれがあれば、機体探索にも使えたのではないかと思います。 この機能はよかった例です。 実際の基板と回路を見ていただきましょう。例によって表面実装部品ばっかりです。 これ一式仕上げるのに最初7時間から8時間掛かっていました。このEEPROMは足が出 ていないタイプでして、これしか入手できなかったのですが、この半田付けが難 しかった。 GPSとリチウム電池と基盤の大きさです。これをカメラケースに入れ、防水にします。 このカメラケースに発砲スチロールのフロートを付けて、回収できるようにしよう ということにしました。 こちらの写真は最後に回収して探査データを取り出す時に使用するコンバータ用の 基板です。SPIインターフェイスを使用しています。 仕様作成からまったく見たことの無い物を作り上げるのは骨のある作業です。 2004年4月17日から約3ヶ月、担当した学生には大変だったかもしれません。 今回のHamana-1では、全システムをカメラのフィルムケースに収める必要があり、 この大きさに収める為、使用する部品に対する知識、例えばリチウム乾電池の特性 など、部品の制約、打上げの為の納期や擦り合わせ、回路、電池の格納方法、そう いった様々な知識が必要になります。 その他にも、完動機２機が出来上がったのですが、その２機を搬送するのに、違う 経路をもって会場に運んだりしました。安全を確保する為、途中の事故などで失わ れる等の対策ですが、その様な事も考えました。 あと、基板の話に戻るのですが、リードレスパッケージを無理やりハンダ付けする のは、あまり、お勧めできない。この基盤を一枚作るのに、担当した学生なら、今 ですと２時間程度で作ってくれるのですが、基板のMPUの足の下を回路が走っていて、 半田付けしてはいけない足があったりと、様々な制限があって慣れないと作れない 基板となっています。多分、初めてですと、7時間とか掛かるかもしれません。 その他、仕様書の無い部品、これがなかなか苦労しました。このプロジェクトでど うにか動く回路、システムに出来たのは、唯一パナソニックさんだけがデータをリ チウム電池の仕様を公開してくださったからかもしれない。仕様書を出してくれた のは、とてもありがたかった。 この様なHamana-1 プロジェクトを通じて、感じた事だが、トラブルシューティング そのものは、初めてやる学生だけでは難しい。現象を特定する部分はベテランがアド バイスしてあげないと難しいと思われる。このへんが開発者教育向けのいいモデルに なったと思います。 二上： 次に管制発射装置についてお話していただきましょう。複数のセンサーが接続され ており、ハードリアルタイムの部分を実現しています。この部分がシステムレベ ルの仕様を束ねるておりまして、この部分を岩橋さんがやってくださいました。 岩橋さん、説明をお願いいたします。 岩橋： 岩橋です。 私関西なんですわ。Hamana-1に参加したのですが、みんなばらばらで作業をしていま した。その辺の苦労話を。 話を聞いたときは、ああ楽勝だなと最初思いました。 ただ、やり始めて見ると、まず設計をやる時間がありませんでした。 なにか話が良くわからない。連絡が来ないし。 使用するハードウェア、ルネサスのソリューションエンジン(SH3評価用基板)が届 かない。おかしいな。まあいいやと言う風に思っているうちに日が経っちゃって。 で、気がついた時には、要求仕様が変わっていました。こりゃ、まずいなぁって。 システム仕様を決める時に会議に出れなかったり、メーリングリストに入って居な かったりと、連絡が取れる様な所にいなかったので仕方ないんですが。 色々あって、設計時間を短縮したいなということで、ちょっと苦労しました。 例えば、ハードウェアの追加などがあるんですけど、僕はソフトウェア屋さんなの ですごいリスクが高かった。どうも開発記述のほうで要求仕様がなんか流動的でして、 仕様定義ということで全体モデルの明確化を図りました。 なんとなく関係者は分かっているけど明確ではない。じゃあ、システム仕様書は一 番上位に必要だと言う事で、システム仕様書を書いちゃいました。 元々、そのシステム化も物理的な仕様要求があって、あとは内部状態をどう作るか に落とし込むのですが、異常時のシーケンスはどうするかとか、管制発射装置にGPS は付けるのか、あと風速もそう。気圧計を付けるのかとか。他にも、緊急の事態に、 緊急停止ボタンを押すと止まるとか、色々あると思います。その辺りがあまり明確 ではなかった。そういった発射を抑制するような仕様にする必要がありました。 で、どのように対応するかなんですが、これは、あまり努力は報われなかったです。 これは仕様定義で、UMLで簡単な仕様定義を作ってみんなに投げる事にしました。 全体の仕様です。ここに発射台があって、発射台に点火装置があって、もしロケット が発射台に取り付けてなかったら飛ばさないという装置も付けている。あとは内部 状態を定義して開発を進めました。 (UMLの図を指し) ほとんど通常のポート入力信号で、この図の青いところが物理的な構成、赤いところ が機能要求でして。この手の開発では、、、えぇっと、これはワンパターンで、要求 が赤いところです。 実装モデルでは、青いところと赤いところがありまして。例えば、リアルタイムOSと かは青い所になります。要求には無いけど実装に必要な所を示しています。 今回の開発では、最初流用しようとしていたコードが使えない事が判り、急遽、UML から書き下ろしたのですが、これは思ったより早かった。普段使っている開発方法で ざざっと作ってしまいました。 とりあえず、開発は終わったんですけども、いっぱい失敗しました。 多重割り込みだとか、ポーリングミスとか、レジスター破壊とか、色々です。いや、 情けない話です。 あと、色々困ったこともあって、例えば、最初ソリューションボードを頂いた時点で、 ハンダゴテの熱でピンが破壊していたみたいでして。 実際に、色々問題が起こった時、自分は全然違う方向で考えてしまったのが不味かった と思います。一度はまると抜けられないからまたはまると言う悪循環になっていました。 この為、GPS関係の不備が出ました。ここで開発技術に関する失敗を整理します。 GPSの設定、交換も色々失敗してしまいました。 そのときも、こういうフレームワークというのがうまく使えそうかなと思っています。 二上： 実は私も失敗しまして。 どっちの方が日の出が早いのかと言う話で、関西の方が日の出が早いって言っち ゃいました。つい最近、時間を逆さによんでいる事に気が付いたりと、多分こう いうプロジェクトはいろんなところで失敗するものだというのは嫌というほど体 験しました。 こう言う経験を再現してもらう事が重要だと思いました。 GPSのメーカーさんもサンプル価格でだしてもらえると、盛り上がって良いと思う んですけど、ね。岸田さん。 岸田： え、ええ、そうですね。 二上： ということでいろんな教材を出していきたいと思います。 実はシーケンスを管理したり、消防所に交渉したのは穴田さんなので、この辺り をお話頂きましょう。 穴田： じつは私がこの話を聞いたのは去年の年末頃でした。 この話を聞いて私も危ないと思いました。 実は、ロケット＝ミサイル＝危険！、みたいなのが頭にあって、はじめそんなに 乗り気では無かったです。やってみると結構楽しくて、のめり込んでしまいました。 ぜひ来年のサーベイヤ計画に参加してください。 二上： なにか質問はありますか？ 観客：新藤： 新藤といいます。 非常に興味深いお話ありがとうございました。 この様な試みを聞かせていただくのはありがたい。 色々、教えていただきたい点があります。 今回、キーとなる制限事項、要素というものが全体に散らばっている、全体に関っ ている様な印象を持ちました。たとえば、GPSのスタートアップに時間が掛かるとい う話ですが、なぜヒアリングするということをしなかったのか？その辺りがなぜだ ったのでしょうか？ 二上： まさしくその通りでGPSは専門家がいるんです。 岸田さんコメントを。 岸田： ええっと、実は私、GPSの専門家ではなくて調達を担当したのですが、調達した先 が親会社という事もあり、サポートに周りました。いや、黙ってたのですが。 最初は、こまった時のサポート役だと思っていました。１週間かかって回答できな かったらごめんなさいと言おう思っていました。ただ、細かな情報とか実測値の情 報の共有は重要で、そういうのを伝達する方法、情報をいかにリアルタイムに共有 させるかと言う点が重要だと思っていました。 その為に、メーリングリストとか、Sourceforge等の環境を用意したのですが、、 このメーリングリストに登録と言う所で、失敗しています。岩橋さんを入れるの忘 れてしまいまして。それも途中、確認しなかった。たぶんそれが一番まずかった。 あと、GPSの使い方としてカーナビとか、地面でつかうもの、2次元ですね、これを 対象にした場合、約7秒程度で測位できます。一応、余裕をみて、最初は45秒と言っ ていました。 実際の測位結果を見るともっと掛かっているのですが、、最悪時間で設定しないと いけませんので2分となったと考えています。ただ、電波の状態や、建物、山など 環境によってはもっと悪くなる事もあります。 あと、アンテナ一体型なので、ゲインが稼げなかったのかもしれません。 ええっと、私はGPSの技術担当じゃなくて、購入しただけだったハズなのですが、 結構詳しくなれました。 二上： ええ、開発は、残念ながらそれでスムーズに進むほどには、必ずしもうまく いかなかった。ま、製品レベルではないでしょう。 元々、計画した時点で、時間的な絶対数が足りなかった。 それでも実現出来たのはメーリングリストと実力者が集まっていたからだと 思います。そう言う意味では、技術者にそれなりの実力があってメーリング リストが使えると新しい商品が出来るのではないかと思います。そう、+αの 組織が出来るのではないかと言うことです。 さて、実際に今回の開発で、相当苦労した学生諸君の意見も聞いてみましょう。 東海大の松下くん、御村くん、取り纏めの院生、大山くんどうですか？ 松下： 東海大学、松下です。 3ヶ月の長いプロジェクトに参加させていただいたことはありがたく思います。 今日終わってほっとしています。 二上さんとか助けていただいてありがとうございました。 御村： 東海大の御村です。 この3ヶ月間、ありがとうございました。 大山： この3ヶ月間、ありがとうございました。 大変でした。昨日も色々すいませんでした。 ----ここまで議事録です---------- 感想： 実際に実行してみないと分からない問題点が多く出てきて、実際にプロジェクト を進める際の難しさの一端が見えたような気がしました。問題点以外にも、シス テムの多重化など私自身が思いつきもしなかったことに対してきちんと対策が練 られていて聞いていて面白かったです。 ただ、議事録をとるのが忙しくて、スライドをよく見ている暇がなかったのが残念でした。