ある元栃木の工業人.jp

宇都宮, 工学系, Google earth などについて書くと思うけど山形に引っ越してしまった

全体表示

[ リスト | 詳細 ]

記事検索
検索

全50ページ

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

[ 次のページ ]

Blog Front Photo 4 : Town

イメージ 1

開く コメント(0)


宇都宮廃線マップを作りました(数年前)

イメージ 6
詳細は後記…



幼少の頃から宇都宮に住んでいる人であれば、おおよそ東武宇都宮線を利用したことがあると思います。例えば部活動の練習試合や大会で壬生や栃木市に行ったり、東武動物公園へ行ったり、最近では東京スカイツリーへ行く人もいるでしょう。

さて、東武宇都宮駅の次の停車駅が南宇都宮駅であることは多くの方がご存知のことと思いますが、ある時代、たった22年間だけ、これが違っていたそうなのです。そんな東武宇都宮駅と南宇都宮駅の間にあったという『花房町駅』について簡単に取り上げてみたいと思います。



この駅の存在を知ったのは、国土地理院所蔵の昭和初期における地形図を眺めたことが切っ掛けでした。

イメージ 1

昭和8年(1933)測量の5万分の1地形図です。現在の市域に比べてだいぶコンパクトな街であったことが伺えます。今は街中に存在する高校の多くが当時は郊外の田園地域に位置していたことも分かるなど、都市形成の資料として大変興味深い地図となっています。

さて、東武宇都宮線は昭和6年に開通しましたので、この地図に描かれた線路はできたてホヤホヤ。その線路をよく見ると、「く」の字に折れ曲がる部分にさり気なく駅のマークが書かれているのがわかりませんか?

イメージ 2

「はなぶさちやつ」

そう、これがかつて東武宇都宮線に存在していた「花房町駅」です。
今の地図で示しますと、日光街道と平成通りの交差点付近になります。

イメージ 4


実はWikipediaの「東武宇都宮線」の項目にも記載されていて、さらに言うと「花房町駅」として独立のページも存在しています。そこでは以下のように説明されています。

"1931年8月11日に東武宇都宮線が開通。翌1932年4月1日、西川田駅東武宇都宮駅間に開業した。その後、太平洋戦争戦局悪化に伴い不要不急駅として1944年6月30日に休止となり、1954年9月24日にそのまま廃止となった。"

さらに他の情報を探してみると、mixiにて以下の投稿がされていました。


なるほど、東武宇都宮駅との距離はおよそ1km。バス輸送の拡大の時代にあって、あまりにも近すぎたということなのかもしれません。

イメージ 5

花房町駅があったであろう場所の現在の俯瞰図になります。当たり前ですが、駅前としての威厳はありませんね。閑静な住宅街となっています。もし廃止されていなかったら、この場所にもささやかながらロータリーが作られていたかもしれませんね。

(まとめサイト風)



冒頭、「東武宇都宮駅と南宇都宮駅の間にあったという『花房町駅』について」という風に書きましたが、実はこれは少しだけ嘘です。南宇都宮駅は、花房町駅が設置された当時は「球場前駅」という名前の仮設駅でした。このように、現在では鉄道に疎いトカイナカの宇都宮であっても、鉄道に関して実は様々な経緯を持っていることが多いのです。

そんな知的欲求を満たすために宇都宮廃線マップを作りました(数年前)

イメージ 6

情報の多くはネットに掲載されていた内容を基に再構成したもので、詳しい説明は参考文献として情報源様にリンクするようになっています。ネット上にちらばる情報をひとつに集約して可視化したものと考えてください。なお、廃線のルートに関しましては多分に推測が含まれておりますので、ご承知おきください。

収録内容は以下のようになっております。
--------------------------------------------------------------------
 ・ 宇都宮陸軍航空廠線
    宝積寺駅から陸軍航空基地(現清原工業団地)まで存在していた線路。
 ・ 大谷石材軌道
    鶴田駅や鹿沼駅などから大谷を繋いでいた石材専用線。
 ・ 専売公社宇都宮工場専用線
    鶴田駅から専売公社工場(現中央公園)まで存在していた線路。
 ・ 富士重工業引込線
    鶴田駅からかつて鉄道車両を製造していた富士重工まで接続していた線路。
 ・ 東武鉄道宇都宮線
    主に廃駅について。
 ・ 戸祭配水場築造専用軌条
    大正期の宇都宮水道敷設の際に戸祭に存在した水道専用線路。
--------------------------------------------------------------------
こう見ると鶴田駅って以外にターミナル駅だったんですね…ということが分かるマップです。
名称での検索や参考文献を読んでいただくと、より一層面白いと思いますので是非是非。

以上、宜しくお遊びくださいませ。


関連記事



開く コメント(0)


Teensy3.2という、ArduinoIDEにて開発できる32bitマイコンボードがある。

イメージ 1


Arduino pro miniとほぼ同じくらいのサイズでありながら、Cortex M4を搭載した96MHz動作のスゴイやつだ。出力ピンも揃っていて使いやすく、Arduinoライクに書けて書き込みも速いので最近はこいつを使う機会が多くなっている。

そのなかで、ハードウェアデコーダ機能によるインクリメンタル型のエンコーダの読み取りについてチャレンジしてみたので、備忘録がてら軽くここに置いておこうと思う。

ただし、このコラムはある程度マイコン開発に慣れた人を対象にしている。
ご了解いただきたい。



Quadrature Decoder mode とは

マイコンのような組み込みデバイスは、その名の通り機械を制御する装置に組み込まれて使われることが多い。機械を動かすもの、いわゆるアクチュエータの状態を読み込み、加工(計算)して、期待通りの動きとなるようその挙動を制御する。

アクチュエータとして世間に大人気なのはモータであるが、このモータの状態を読み込むセンサとして回転エンコーダが一般的に使われている。この回転エンコーダのうち、インクリメンタル型と呼ばれるタイプの値を読み込むのが、直交デコーダ(Quadrature Decoder)である。

直交デコーダはソフトウェア処理として実装することもできるが、インクリメンタル型の性質上、割り込み処理の増大によりマイコンのリソース効率が非常に悪くなる。特に複数のエンコーダchを処理しようとすると、読み飛ばしや挙動の不安定化に至ってお話にならない。(ここでは、500pulse/rot程度のエンコーダのモータ軸直付け程度を想定している)。

従って、この地味なのに高負荷で、致命的な処理をハードウェアにアウトソーシングできるかどうかは、マイコンでモータ制御を行う上で欠かせない点なのである。

さて、Teensyシリーズの開発は、拡張したArduinoIDEを使用することで行われる。この拡張機能は同時にMsTimer2やThreadのような信頼性のある様々なライブラリも導入するのだが、実はこの中に「Encoder Library」というのがあって、これを使うと任意のピンを使ってA相とB相によるインクリメンタル型エンコーダの読み取りを行うことができる。

ところがどっこい。このライブラリはいわゆるソフトウェアデコーダであり、その内実はピン割り込みによるカウントに過ぎない。つまり、回転速度やメインプロセスによっては読み飛ばしが生じる恐れが拭えないのである。

前述の理由から、できることならハードウェアデコーダで済ましたいわけだが、ある程度、能力の高い汎用マイコンにはハードウェアに様々な機能が搭載されていて、32bitにもなればまぁ間違いなくハードウェアデコーダが存在していると考えて良い。

というわけで、Teensyのコアのデータシート(MK20DX256)から該当機能を探してみた。

イメージ 2
イメージ 3
K20 Sub-Family Reference Manual (FreeScale)


ありました。ハードウェアデコーダ機能 『Quadrature Decoder mode』(QDmodeと呼ぶことにする)

構造としてはPWMやタイマー割り込みに使用するFTM counterを、内部クロックではなく外部ピンの状態に応じてアップ&ダウンカウントを行うもののようだ。

A相B相の立ち上がりをsynchronizerで同期信号に変換し、フィルターを通したうえでFTM counter directionでクロック信号と方向信号を出力、最後にFTM counterで積算するという流れである。

今回はこれを使うために、図中の各変数やら何やらの設定を行う。

ちなみになぜFFの直列二段で同期信号へ変更するのかと言うと、MCU内部クロックの立ち上がりと外部信号の立ち上がりがニアミスすると、内部で保持した値が不定になることがあるのだとか。この状態をメタステーブル状態と呼んで、直列二段のフリップフロップで避けるのが常識らしい。詳しくは↓。




QDの設定

Teensy3.2には3つのタイマー(カウンタ)があり、それぞれFTM0、FTM1、FTM2として存在している。QDmodeはこのうちFTM1とFTM2を使う。ちなみにFTM0は広範囲に使われているので、このマイコンの基幹として位置づけられているようだ。

まず、レジスタについて、 FTMEN = 1  QUADEN = 1 として設定をせよとのこと。

FTMENとQUADENはどこにあるのかというと…
イメージ 4
K20 Sub-Family Reference Manual (FreeScale)
https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

FTMx_MODEの1ビット目と、FTMx_QDCTRLの1ビット目である。なお、xはFTMの番号である。
以上のことを踏まえると、
FTM1_MODE |= 0;
FTM1_MODE |= 1<<2; //WPDIS
FTM1_MODE |= 1<<0; //FTMEN
FTM1_QDCTRL = 0;
FTM1_QDCTRL |= 1<<0; //QUADEN
となる。ちなみにWPDISは書き込み制限の解除らしい。Teensyならやらなくても可能。

ブロックダイアグラムを見ると、synchronizerの先にFilterが存在する。これはシステムクロックを4分周した周波数より高周波な入力をフィルターするものらしい(P831)。

イメージ 10
K20 Sub-Family Reference Manual (FreeScale)
https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf
使わないなら以下のようになる。
//FTM1_QDCTRL &= ~(1<<7) ; //PHAFLTREN
//FTM1_QDCTRL &= ~(1<<6) ; //PHBFLTREN
QUADENのときに既にゼロにしたから実を言うと書く必要が無い。CH(n)FVAL[3:0]についても同様。

さらに読み進めると、PHAPOLとPHBPOLを設定しろという。
これは論理の逆転を行うもので、まぁつまり両方ゼロで良いので特に書く必要はない。
(レジスタの値がゼロであることが確実でない場合は、もちろん処理したほうが良い)

QDmodeのための設定はだいたいこのくらいで終わりである。



ピンの設定

案外忘れがちなのが、ピンの設定である。FTMの設定がされても、入力ピンが設定されていないとウントモスントモ云わないので注意が必要である。

マイコンのピンには複数の機能が重複していることが多い。このマイコンにおいては、default、ALT0〜ALT7として機能が割り振られている。P206を見てみると、

イメージ 8
K20 Sub-Family Reference Manual (FreeScale)
https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

FTM1_QD_PHAとPHBはALT7に登録されている。従って、PTA12とPTA13のピンをALT7にすれば良い。

イメージ 9
K20 Sub-Family Reference Manual (FreeScale)
https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

ALTの設定はPORTx_PCRnの8〜10ビットで決定される。従って、FTM1の場合は下のように書ける。
PORTA_PCR12 |= B111 << 8; //pin set ALT7
PORTA_PCR13 |= B111 << 8; //pin set ALT7
マイコンあるあるだが、PTA12とは PORTA_PCR12 の略称である。



FTMの設定と桁溢れフラグ

値が内部でどのようにカウントされているのかを表す以下のような図がある。

イメージ 5

イメージ 6
K20 Sub-Family Reference Manual (FreeScale)
https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

FTM counterの中で、CNTINからMODまでの領域でアップ、ダウンカウントを行っている。このCNTINとMODも設定が必要である。CNTIN=0とすれば、MODの値が最大カウント値になる。MODの取りうる値は16bitの範囲内だ。
FTM1_MOD = 5000 - 1;
FTM1_CNTIN = 0;
もうひとつ重要なのはTOFとTOFDIRである。カウント値が飛ぶ際にTOFが1に、それがアップカウントの場合はTOFDIRが1、ダウンカウントの場合はTOFDIRが0となるようだ。

TOFDIRはFTMx_QDCTRLの1ビット目、TOFはFTMx_SCの7ビット目にある。

イメージ 7
K20 Sub-Family Reference Manual (FreeScale)
https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

値はFTMx_CNTの中にあるので、カウント値の取得はTOFを監視しながら以下のようになる。
int ct = 0 ;
int over = 0 ;
int Count = 0 ;
int MAX_COUNT_VALUE = 5000 ;

void setup(){
  //略
}

void loop() {
  ct = FTM1_CNT;
 
  if(FTM1_SC & 1<<7){ //TOF
    FTM1_SC &= ~(1<<7); //Clear TOF
    if(FTM1_QDCTRL & 1<<1) over += MAX_COUNT_VALUE; //TOFDIR
    else                             over -= MAX_COUNT_VALUE;
  }

  Count = ct + over;

  Serial.println( Count );
  delay(50);
}
上の例はポーリング処理の場合である。これが正常に動くのは「ポーリング周期がエンコーダパルスに対して十分に早い」かつ「正転逆転の動きが十分に緩慢である」という条件を満たす場合のみなので注意されたい。

例えば、ポーリング周期のあいだに、桁上りと桁下がりが瞬時に行われたとしよう。具体的にはMODが4999だったとして、4999→0→4999のときである。このとき、カウント値(ct + over)は4999であるべきだが、QDは桁上りと下がりを経験したためTOFは1だしTOFDIRは0である。従って、上記のプログラムではoverは-5000され、カウント値(ct + over)は-1となってしまう。

以上のことから、ポーリングである程度ロバストな処理とするなら、実はTOFとTOFDIRを使わない次のようなやり方が良いように思う。
int ct = 0 ;
int over = 0 ;
int Count = 0 ;
inr tmpCount = 0 ;
int MAX_COUNT_VALUE = 5000 ;

void setup(){
  //略
}

void loop() {
  tmpCount = Count;
  ct = FTM1_CNT;
  Count = ct + over;

  if ( (Count - tmpCount) > MAX_COUNT_VALUE/2 ){
    over -= MAX_COUNT_VALUE;
  else if ( (Count - tmpCount) < -MAX_COUNT_VALUE/2 ){
    over += MAX_COUNT_VALUE;
  }

  Count = ct + over;

  Serial.println( Count );
  delay(50);
}
要は、Countの値は必ず連続的であることを用いた桁あふれ処理といえる。ただし、これもポーリングの間にMOD/2を超えるパルスが入力されないことが前提ではある。だからMODを最大値の0xFFFFに設定しておけば大体のシステムには対応できると思われる。



あとは上のプログラムをうまく組み合わせれば動く。以上!

/* メモ */
ポーリングを使わずに割り込み処理でやりたい勢はTimer Overflow Interrupt(36.6.1 P899)を使うと良い。やり方は知らないので頑張ってほしい。既にハードウェアQDを試した先人たちのライブラリは割り込みを使ってるので、それが参考になるかも。https://github.com/michaeljball/QuadDecode (github)

割り込みは便利だけど、前述のように瞬間的に桁上りと桁下がりを行った場合には割り込みが多重になったりするのかなぁなんて思う。先人のライブラリはフィルターを利用して4クロック以下の信号を無視するようにしているので、瞬間的な信号の問題をなくしているみたい。でもそこまでするならポーリングで十分なのでは…?

/* メモ */
ハードウェアデコーダーなのに読み取り処理速度遅くね???って感じな気がする。ソフトウェアによるライブラリと最大読み取り可能回転速度が同じような気がする。

フィルターも無効化してるし、怪しいのはsynchronizerか?とはいえ、システムバスクロックの48MHzを同期に用いていて、しかも一回転2000パルスのエンコーダーを用いていたとしても、秒速2万4千回転は許容できるハズなんだ。電気的なアレコレだとしたら厄介だなぁ。

/* メモ */
オーバーフロー割り込みハンドラ。ポーリングを嫌う場合はコチラ。
これを実行するにはFTMx_SCのTOIEをEnable、FTMx_CnSCのCHIEをEnable(?)。

より確実にするなら。
FTMx_SCのCPWMS=0、MSnB=0、MSnA=0。
FTMx_COMBINEのDECAPENx=0、CONBINEx=0。

フィルターつけるなら。
FTMx_QDCTRLのPHAFLTREN=1、PHBFLTREN=1。FTMx_FILTERのCHnFVAL=(4分周カウント値)

/* メモ */
ライブラリのソフトウェアでは読み取りミスが生じているとの報告がちょくちょくある。徐々に原点がズレてしまうそうだ。それに対して、ハードウェアでは同様の問題が生じていない模様。ハードウェアを開拓する意義があったことに一安心。

開く コメント(0)



最近、地下鉄が流行ってませんか?
いや、正確には、立体的な形状として表した上の写真のような立体路線図のことなんですが。

この記事は2009/10に作成した
「東京地下鉄深さ3Dマップ」 ある元栃木の工業人.jp (旧:常人には到底理解出来ないブログ)
のリメイク記事です。(年齢が年齢なだけに内容が黒歴史)

地下鉄というのは乗車している分にはあまり感じないが、実は凄まじいアップダウンがされている。それは例えば他の路線を跨ぐため、あるいは河川を潜るためであったり、駅のホームによる制限だとか、遂には対核兵器用シェルターのためなどと云われることもある。それらは大都会の地下を編むように張り巡り、さながらニューロンのように1つの巨大なネットワークを構築している。

地理、土木、都市形成についてニッチに語り合うブラタモリ(NHK)が人気となる昨今において、大都会東京の地下鉄はどうなってるんだ?見てみたい!という流れになるのは必然なのかもしれない。その潮流の中において2018年のはじめに誕生したのが『東京地下鉄立体線路 東京メトロ編』(バンダイ)というカプセルトイである。

(また前置きが長いぞ)


イメージ 2


ひとつ300円というのは高めに思うが、9路線を1つのガチャにするのではなく、前編と後編として4路線と5路線に分けてるあたりに集めてほしいという担当の良心が見える。これは許される。

ちなみに筆者も地元で見つけたので一回試してみた。路線長も長く、ダイナミックなアップダウンをする路線といえば千代田線と有楽町線である。いや、丸の内線も捨てがたいが…などと想いながら回したところ、なんと一発目で有楽町線を引いた。これはミラクル。訝しげに眺めるオカンの前で組み立てていたが、今思うとどう見てもヒモQで遊んでいるようにしか見えんよな。


イメージ 1
一発目で有楽町線を引いたので満足。もし次があるなら千代田線を狙いたい。


そんなこんなで立体の地下鉄路線図がTLを賑わせているなか、次のようなコラムを発見した。


「東京地下鉄立体路線図をARでつくってみた」 川島優志 2018/05/07

イメージ 4


僭越ながら要約すると、息子さんに前出のカプセルトイを買ってあげたいが場所がないでしょと奥さんに怒られたので場所を取らないARで作ってしまおうというお父さんの奮闘記録である。この息子さん絶対に賢くなる。

記事をサラサラと見てみると、氏が自身で3Dデータを作成して、ARに投影したようである。面白い。


イメージ 5


リンクポチー


イメージ 6


イメージ 7
それわしやないか〜い


というような事がありまして、このモデルについて約10年ぶりに記事をリメイクすることになったのでした。


イメージ 9
Tokyo subway depthmap Ⅱ

2009年に以下の3つの3Dモデルを作成しました。

1,Tokyo subway depthmap
2,Tokyo subway depthmap Ⅱ
3,東京地下鉄立体マップ(データ版)

1 は各路線のデータをフォルダー訳するなどGoogleEarthでの閲覧を目的としたもの。 2 は各路線をカラフルなチューブ状で表現したもの。 3 は 1 と 2 で使用した素データとなっています。

すべて3D WareHouseにて公開しているもので、ダウンロードデータはSketchup用のskpファイルと、GoogleEarth用のkmlファイル。ただし、Tokyo subway depthmapに関してはGoogleEarthでの表示用であるので、KMLファイルでの閲覧を推奨しています。


イメージ 10
Tokyo subway depthmap

これらの3Dモデルはその根本として、東京の地下鉄を3Dで見れたら面白いだろうなという興味と、ネット上にも殆ど情報のない砂漠の状態をなんとかしようという無償の愛によって成り立っています(マジ)。

従って、この理念に適った利用においては自由に使用して戴いて構いません(一次データの転売はNG)。
また、何かしらコンテンツに使用した場合は一報頂けると筆者が喜びます(マジ)。

あと金銭が関わる恐れのある場合には、気軽にご相談ください。
(3Dデータをそのまま転売しようとする馬鹿者も居りましたのでその点慎重なのはご理解ください)


イメージ 11
東京地下鉄立体マップ(データ版)

ちなみに、どのようにして作成したかに関しては以下に詳しいです。
「東京地下鉄の深さ」 Kazu.の倉庫
(これも黒歴史になりつつある)

基本的な標高データは 「日本鉄道旅行地図帳 5号 東京―全線・全駅・全廃線 (5) 」 新潮「旅」ムック に記載されていた地下鉄駅の深さ情報を元にしています。そこからGoogleEarthの標高情報を加味して駅の標高値に変換し、垂直方向への拡大を加えてアップダウンを誇張した上で各点を線形補間、最後に頂点を円弧補間してなめらかな曲線としています。従って、駅から駅の間は情報がないということと、円弧補間による情報の欠落が存在していますのでご留意願います。要は、前述の理念の通り厳密性を求めていないモデルになります。

二回目ですが、偉大なる情報源様です。買う価値あります。宜しくおねがいします(アフィじゃないです)。
イメージ 8
情報源は神様です。大切にしましょう。





そもそもどうしてこの3Dモデルを作ろうと思ったのだろうか。実はそのきっかけに関しては未だに思い出せていない。前述のカプセルトイ、「東京地下鉄立体線路」のバンダイ担当者は次のように発言している。

「『東京地下鉄立体線路 東京メトロ編』の企画は今から10年ほど前、『もしこんな商品があったら自分がほしいだろうなと思うもの』として発案したものです」
ねとらぼ - 「謎のアート」「血管みたい」 東京メトロ路線図を高低差まで表現したガチャ、なぜ生まれたか

10年ほど前、という点において、筆者が作りたいと思い始めた時期と重なっている。もしかするとこの頃に地下鉄の立体形状に関して何かテレビの特集でもあったのだろうか。はたまた立体化した模型を作った人でも居たのだろうか。

いずれにせよ、10年の月日を経て我々に時代が追いついた訳である。


バンダイの担当者、友だちになろう。


それでは今回はこのへんで。

開く コメント(0)

イメージ 1

2014年にHTML5がW3Cから発表され、これまで専用アプリケーション上でしか表現し得なかったようなグラフィカルな表現が、オンラインのウェブブラウザ上で実行できるようになった。

国土地理院が提供する 「地理院地図」 もその波に乗ったサイトのひとつである。

国土地理院はかなり初期からネット上で国土の基盤的情報を発信してきた。1:25000地形図の「ウォッちず」、航空写真の「空中写真閲覧サービス」などである。その後、「電子国土」を旗印にしてウェブ上でそれらを統合した情報提供・閲覧プラットフォームの構築が進められていた中で、ブラウザのグラフィック機能を拡張したHTML5WebGLの登場はまさに渡りに船だったに違いない。

イメージ 18
「ウォッちず」 というなつかしい響き…

さて、地理院地図はその基盤として規格化された各種地図情報の膨大なデータベースが存在する。これは地理院タイルとして構造の片鱗を見ることができるのだが、その中にはメッシュ状の数値標高データも含まれている。従って、地理院地図では画像情報と標高情報から3D表現に優れたWebGLによる三次元の地形表示を行うことが可能となっている。

ちなみにウォッちず時代でも『立体視システム』という地形図と標高数値データから生成されたステレオグラムによって、立体的に閲覧できる進歩的なサービスが存在していた

イメージ 19
立体視閲覧サービスとはこんな感じの立体視画像。サービス停止が悔やまれる。
地図閲覧サービス(試験公開)の「立体視システム」の開発

Web環境の劇的な進歩と共に進んだのが3Dプリンタの普及である。業務用として流通していた高価な3Dプリンタが低価格化によって一般市場へ降りてきたことにより、アマチュアによる三次元造形手段の確立とデータ規格STLの標準化が進んだ。

電子国土による閲覧プラットフォームと標高データの整備、そして三次元造形データの需要増という環境が揃った以上、3Dプリンタ用の地形STLデータを出力するサービスが搭載されたのは至極尤もな話であった。

まぁそんなこんなで、長い年月を経て現代技術は、好きな地形を手軽に造形できるという地形趣味人たちの理想に追いついたわけでした(導入が長い)。



 ・ ・ ・



今回は地理院地図3Dから入手したSTLデータを光学式3Dプリンタ:Form2にて出力してみたので、それについて備忘録がてらここに報告する次第。キーポイントはデータの中抜き加工と補修処理。

ところで最近は目次を付けるのが解説系コラムのスタンダードのようだけど、ここを見てる人は藁をも掴む想いの限られた境遇の人だろうから優しくしないフォーマットでそのままいきますよ。

 | 地理院地図からSTLデータを取得する

イメージ 2

お好みの地形を中心として、お好みの地形表現(地形図、陰影図など)にしたあと、

機能 > 3D > 大 (or 小 or カスタム)

と操作する。これにより下図のようなWebGLによる三次元表示が実行される。ちなみに、標高データの精密さは上図の状態のズームレベルに依存する。つまりあるズームレベルで3Dの小(1024)を実行したときと、その倍に拡大してから3Dの大(2048)を実行したときとでは、表示範囲は一緒でも地形の分解能は半分になる(イメージ)。

イメージ 3

これだけでもぐるぐるできて楽しいのだが、注目すべきは下部の「STLファイル」である。着色可能な立派な3Dプリンタをお持ちでない限りはSTLデータで十分である。「ダウンロード」からSTLデータを保存する。

(ところで「ブラウザでぐるぐる回す用のファイルです」という表記はなかなか嫌いではない)

 | 光学式3Dプリンタ用に加工する

プリンタは主に積層造形と光造形とに大別できる。積層造形は自動で内部を空洞(メッシュ状)に構成するので体積の過多はあまり気にする必要はない(もちろん限度はある)。が、しかし光造形は空洞とならずに全て充填するという欠点(利点)が存在する。しかも材料費は安いものでもリッター2万円くらいする。

従って、光学式3Dプリンタで造形する場合は、いかに表面の形状と十分な強度を満たしつつ内部を肉抜きしてコスト低減できるか、というのが課題となる場合が多い。いわゆる最適リブ配置問題である。

地理院地図からダウンロードしたSTLファイルは下図のような形状(標高約1000m地点)であるが、この状態で光造形を行うのはもちろん論外である。

そこで、ここでは中抜きと余計な部分のカットを行う。今回は試行錯誤のすえ「Meshmixer」というAutodesk社のフリーソフトを用いることでこれらを解決した。失敗事例は末部に記載したので暇なら読んでほしい。

Meshmixer - AUTODESK Research
http://www.meshmixer.com/japanese.html


イメージ 4

MeshmixerにSTLデータをインポートした様子が上図である。表面の形状しか求めていないのに体積が大きく非常に無駄が多い。

まず最初に中抜き加工を行う。

イメージ 5

編集 > 中抜き

これにより物体内部に空洞が生まれる。なお、「オフセット距離」によって厚みを調整するのだが、2mmくらいで丁度よいように思う。もちろん造形の大きさなどによって変わってくるため、適宜考える必要がある。

また2mmにしては表示されてるの厚すぎない?という意見もご尤もで、ダウンロードしたSTLデータは実寸(150メートル四方)なんだけど、Meshmixer内では150ミリメートル四方に変換されていたりする。これは「解析>単位・寸法」から変更できたりするが、わざわざやる必要も無いような気がする。まぁ、そこはいろいろ上手くやってほしい。

内部が空洞になったら、次は余計な部分のカットを行う。

イメージ 6

編集 > 面でカット

これによって、ある水平面から下を全カットすることができる。切れ目はリメッシュされるので穴は空かないし、空洞が破れることで下図のように非常に造形しやすそうな形状を得ることができる。

イメージ 7

あとは「エクスポート」でSTLデータを出力する手筈なのだが、その前に3Dデータに乱れがないか確認を行ったほうが良さげだろう。そこで次項ではそれについて記載する。

 | データの乱れを整形する

例えば河川や険しい地形なんかだと、ノイズが反映されて不自然な地形になっていることがある。下図はその例であるが、特に構造物もない渓谷に丘ができてしまっている。

イメージ 8

このような場合、

選択 > (特定の部位を選択する) > 削除と充填

から修正することができる。もちろん違う方法もあるがここでは取り扱わない。上図を修正した結果が下図である。恐らくこの方がより自然と思われる。

イメージ 9

次に、垂直に近いような険しい崖や渓谷などではギザギザが生じやすい。これはジャギーとかエイリアスとか呼ばれるもので、離散的な均等サンプリングに基づくメッシュ構造のために十分な分解能が得られていないことが原因である。あまりにギザギザしていると造形に支障が出かねないので、少し改善した方が良さそうである。

イメージ 11

このような場合、

選択 > (特定の部位を選択する) > 再メッシュ

からあるていどギザギザを緩和することができる。これが正確な地形なのか?と言われると答えに窮するが、まぁ自分が納得できる程度に収めるのが良いような気がする。

イメージ 10

 | 光学式3Dプリンタへ送信する

ここまでの過程ほ経て、下のようなSTLデータを得ることができる。

イメージ 12

ここから先は造形する3Dプリンタによって作業内容はまちまちであるが、ここではForm2での実行の様子について軽く触れる程度に留めておこうと思う。

Form2ではデスクトップアプリとしてPreFormというソフトウェアが用意されている。これはSTLのインポートから印刷設定、サポート編集、配置などが行えるシンプルかつ高機能なソフトウェアである。そこに先のSTLデータをインポートした様子が下図となる。

先に書いたように、このSTLデータは一辺が150メートルという巨大なものなので、アプリケーション上で拡大縮小を行って調整するかたちとなる。今回は一辺を50ミリメートル程度に収めているが、ここらへんは皆さんのお好みになると思う。リッチな人には是非とも大きく作っていただきたい。

イメージ 13


 | 造形する

イメージ 17

造形結果は上の写真の通り。左が栃木県の日光華厳渓谷と第一いろは坂、右が奈良県下北山の池原ダム。どちらも河川地形だが、性質は大きく異なっていて興味深いところがある。

イメージ 20
こちらが池原ダム付近。穿入蛇行を利用したダムの様子がよくわかる。

イメージ 21
こちらが華厳渓谷付近。左岸の僅かな緩斜面に刻まれた第一いろは坂の九十九折が確認できる。

Form2は色の出力ができないため、造形結果はもちろん単一色となる。今回は白レジンにしたため、立体的なレリーフマップというわけである。


 ・ ・ ・


以上、地理院地図の3Dデータから光学式3Dプリンタ(Form2)で出力した話でした。

 | おまけ:試行錯誤のよもやま話

ここから先は前述の手順に至るまでの試行錯誤の過程について軽く記載する。

肉抜きと無駄の削減をすることが目標であったわけだが、最初の目論見はSTLデータを3DCADへ取り込んでシェル(中抜き機能)を使えば楽勝じゃねーのというものだった。実際にSolidWorksへ取り込んだ結果が下図。真っ黒なのは全てラインである。

イメージ 14

軽く整形してからシェルを実行してみる。既に激重である。

イメージ 16

ダメでした。

そもそもCADというのはプリミティブな形状の組み合わせと関数によって複雑な形状を表現することに特化したアプリケーションである。それに対して標高データというのは全てがユニークな値であり、データ処理量としては非常に多量なものであるわけだ。この点を考慮すると、Sculptrisのような3Dモデリングソフトのほうがユニーク形状の処理は得意なのかもしれない。

3DCADを使うという誤った認識を拭えていなかったことから、次の目論見はSTLデータ量を削減してCADに取り込もうというもの。使ったのはMeshLabというフリーソフト。

イメージ 15

しかし頂点数の削減を行ってもエラーのある形状となる場合が多く、断念。MeshLabは使わないほうが良さそうである。そこで出会ったのが前述のMeshMixer。こいつは非常に優秀で、頂点数の削減もかなり見事にやってのけた。

さすがAUTODESK!

で、頂点数を減らしてCADに取り込んだものの、やはり処理が重くてダメでした。

そうこうしているうちにMeshMixerの機能に慣れてくると、どうも中抜き機能が結構優秀そうだ、ということと、水平面でカットする機能があるぞ、ということでCADを使う考えを撤廃。今回のコラムの手法に至ったわけでした。



 ・ ・ ・



今回はこんな感じになりました。地形に興味があって、なおかつ光学式3Dプリンタを所有しているという類まれなる奇跡的な条件に合致する人にしか需要のない記事ではあったけれども、何かしら参考になればと思う。

以上。


開く コメント(0)

全50ページ

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

[ 次のページ ]


.


プライバシー -  利用規約 -  メディアステートメント -  ガイドライン -  順守事項 -  ご意見・ご要望 -  ヘルプ・お問い合わせ

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

みんなの更新記事