「PIC AVR 工作室」サイトの日記的なブログです。
サイトに挙げなかった他愛ないことを日記的に書き残してます。
PIC AVR 工作室 ブログ



こないだの、OpenSCADで作ってたトロコイドポンプの
プログラム、計算の関数周り以外を大改修して、
影との引き算を使わないロジックに変更してみた。

結果、動くといえば動くんだけど、やっぱり妙な
スリットが出来ちゃうのは相変わらずだなぁ。

とりあえず出来た感じはこんな。



外側8歯はもちろん、



外側4歯も大丈夫。

絵は載せてないけど外側3歯もokだった。

けど、やっぱり5枚歯以下が登場すると、変なスリット
が出てきちゃうので、色々と弄り回して、なんとか
スリットが出て来ないようにしてみたのがこの4枚歯
の例。


どうやら、歯の曲面の曲がり具合に対して、特殊変数$fa
(最小角の断片の設定)が小さすぎると、太さゼロの
ポリゴンみたいなものが出来ちゃって、だめみたい。

なので、与えられたパラメタを使い、バグらない範囲に
$faを設定するように計算する処理を入れてみた。

なぜこの値(計算式)に設定するのかについては、
単なる経験則であって、いわゆるマジックナンバー
なので、正直気持ち悪い。

あともう少し微小に分割したいんだけど、これ以上
分けちゃうと、今のロジック・計算式だとどうしても
上手くいかない。ポンプとしては少し表面が粗い。

とりあえず現時点のプログラムを載っけておく。

/**************/
/* parameters */
/**************/

// radial of outer circle
outer_r = 20;

// number of outer teeth (must be a even number)
out_teeth = 4;

// degrees par step
$fa = 15 / out_teeth;  // it is a magic number


/******************/
/* sub parameters */
/******************/

// tooth height (radial of small circle)
tooth_h = outer_r / (out_teeth * 2);

// radial of inner circle
inner_r = outer_r - (tooth_h * 2);

// number of inner teeth
in_teeth = out_teeth - 1;


/*************/
/* functions */
/*************/

// Epicycloid(outer circloid) //

function epicycloid_x (r1, r2, agl) =
                       (r1 + r2) * cos(agl)
                       - r2 * cos (((r1 + r2) / r2) * agl);

function epicycloid_y (r1, r2, agl) =
                       (r1 + r2) * sin(agl)
                       - r2 * sin (((r1 + r2) / r2) * agl);


// hypercycloid(inner circloid) //

function hypercycloid_x (r1, r2, agl) =
                       (r1 - r2) * cos(agl)
                       + r2 * cos ((-(r1 - r2) / r2) * agl);

function hypercycloid_y (r1, r2, agl) =
                       (r1 - r2) * sin(agl)
                       + r2 * sin ((-(r1 - r2) / r2) * agl);


// trochoid //

function trochoid_x (r1, r2, agl) = 
    (floor( agl / (360 / r2) * 2) % 2 == 1)
    ? epicycloid_x (r1, tooth_h, agl)
    : hypercycloid_x (r1, tooth_h, agl);


function trochoid_y (r1, r2, agl) = 
    (floor( agl / (360 / r2) * 2) % 2 == 1)
    ? epicycloid_y (r1, tooth_h, agl)
    : hypercycloid_y (r1, tooth_h, agl);



/***********/
/* modules */
/***********/

// a trochoid //

module trochoid_gear (a, b) {
  for (i = [1: (360 / $fa)]) {
    echo(i);
    agl1 = i * $fa;      // now angle
    agl2 = (i+1) * $fa;  // next angle
  
    x1 = trochoid_x(a, b, agl1);
    y1 = trochoid_y(a, b, agl1);
    x2 = trochoid_x(a, b, agl2);
    y2 = trochoid_y(a, b, agl2);
        
    echo (x1, y1);
    polygon (points = [[0,0],[x1,y1],[x2,y2]] );
  }
}



/**************/
/* draw gears */
/**************/


linear_extrude(10) {

  // outer gear
  trochoid_gear (outer_r, out_teeth);
  
  // inner gear
  translate ([0, outer_r * 3, 0]) {
    trochoid_gear (inner_r, out_teeth - 1);
  }
  
  
  translate ([outer_r * 3, 0, 0]) {
    difference () {
      // outer gear
      trochoid_gear (outer_r, out_teeth);
      
      // inner gear
      translate ([tooth_h * 2, 0, 0]) {
        trochoid_gear (inner_r, out_teeth - 1);
      }
    }
  }  

}


「outer_r」に、外側ギヤの平均外周(凸と凹を均した
円周)を指定して、「out_teeth」にギヤの歯数を指定
すれば、外側がその歯数のトロコイドポンプの図形を
描いてくれるという寸法。

これを、そのままライブラリとして利用するための
ことを、まだ詰め切れていないので、あとでもう
ちょっと整理する必要あり。

ちなみに現状は、ポリゴン(2Dオブジェクト)でそれぞれ
の断面を描くところまでが大事な処理の中心で、それを
extrudeで立体化しているのはサンプルとしてのおまけ。

なので、ライブラリ化するとしたら、この立体化している
部分は実行させない必要があるので、「include」では
なく、「use」で読み出す必要あり。

ただ、その際に、ライブラリ内部で$faを操作している
ので、その辺がちゃんと動くのかどうかとか、そもそも
$faをライブラリファイルの中でいじっているときに、
呼び出し元に悪さしないのかどうかとかを忘れて
しまった…。
あとでその辺整理しなおしてみようかなと。



このポンプの図形(断面)はトコロイド曲線だろうから、

https://www.youtube.com/watch?v=2NOpQG_pzq8&t=150

こういう感じの流体ポンプにも応用できるはずなんだ
よな。


なんにしても、現状の計算式を元にしちゃうと、ギヤの
中心からポリゴンを描こうとしちゃうため、太さがゼロ
のポリゴンが出て来ておかしなことになっちゃうので、

http://aozoragakuen.sakura.ne.jp/taiwa/taiwaNch04/hikari/node4.html

この2つのベクトルを別々に扱って、内側は内側の軌跡
だけを繋いで平面を作り、外側は外側だけで平面を作り、
それらを合成する、っていう感じに分ければ、太さゼロ
のポリゴンは出て来ないだろうと思うんだよな…

でもなぁ。厳密に言うと、太さゼロのポリゴンなんて、
本当は出来ていないはずなんだけど、これができちゃう
理由って、なんだろう?内部が単精度か何かで計算して
いたりするの?うーーーん。





https://twitter.com/Yokohama_Geo/status/1036442684016095232

サマータイムで、IoT機器みたいな、すでに配置して
あるような機器のメンテは結構やばそうだな。
特にこういう、地震計みたいなやつ。




https://www.youtube.com/watch?v=1AJ3y5vH4is&t=332

100均でタイマーライトなんて売っているのか…。
作ろうと思っていたのに。

この時間を設定するメカ(というか回路部分)、なかなか
興味深いんだけど、回路自体はこの間Aliexで買った、
長時間タイマーモジュールと似ているなぁ。

でも、これが100円で売ってるなら、1個欲しい。セリア
かな?ダイソーかな?





https://twitter.com/handaru20pF/status/1029936308553052160

「よし」

https://twitter.com/yori_shirou/status/1030431258231300097

「よし」





https://twitter.com/tks/status/1036423945778475008

>「がんばったらできた」経験を現在進行系で
>やってないと老け込む

解る気がする。

そういえば、多感な時期に聴いた音楽って、それから
ずっと引きずるものなんだけど、それって、若いころ
は気になった音楽があったら、歌詞やメロディーを
一生懸命覚えたり、楽器持ってる人は弾けるように
練習したりっていう、「がんばる」を無意識のうちに
多かれ少なかれやっていたからなのかなぁ?って気が
してたりする。

最近は、良い音楽に出会っても、あまり一生懸命
聴かないもんな。



コメント ( 0 )




こないだの、OpenSCADのトロコイドポンプで、条件に
よってへんな裂け目が出来ちゃう件。ちょっと作戦を
練り直した。

三項演算子を使って、角度によって「epicycloid」
と「epicycloid」を自動的に切り替えるようにする
ことで、影部分から切り取ったり合成したりといった
ブーリアン演算をしなくていいように修正してみる。


とりあえずなにか出力されたんだけど…



なにかがおかしい。関数の計算式か、造形の処理か…


もうちょっと見直そう。





https://www.youtube.com/watch?v=Vpbwj3WqfbY

昨日のポン子。ウェザ散歩、なかなか面白かったな。
好評だったのに、「もう二度とやりません」って言ってた。
みんな、「えーーーー?」って残念がってたからなのか、
番組後半で、またやろうかな的なこと言ってたから、
またやるのかも。

https://www.youtube.com/watch?v=Vpbwj3WqfbY&t=1517

この香川のは、銭形平次だよな。





https://twitter.com/kunukunu/status/1035517800054317057

NTSCもすごいけど、それを複数チャンネル送るアンテナ
の線もすごいし、もっと言うと、文字だの写真だの
動画だの、さまざまなデータをツイストペア線2本だけで
送っちゃうLANの方がすごそうだな。





https://twitter.com/Konimiru/status/1036053435890581505

この新京成の線路はなんでこんなおかしなことになって
しまったのかは、昔からずっと気になっている。

https://www.youtube.com/watch?v=aRdwBJ2gJj8
https://www.youtube.com/watch?v=cuPhZWV6Dqk





https://twitter.com/rods_skyfish/status/1035595382254751750

これよりもアグレッシブなテニスというと…

https://twitter.com/fp_ll/status/780405386276777984

これかな?





https://twitter.com/tomozh/status/1036096302323384325

いいっすねぇ。これいいっすねぇ。
この当時から、こういう基板の図って、レトロチックな
印象を持ってた。
これに、さらにカセットケースが登場してくると、また
乙なものがあるよな。





https://twitter.com/yontengoP/status/1035872316146704386

JAVA。

売ってるのか、これ。へぇ。けっこう嫌いじゃない
んだよな。




https://twitter.com/RotaryDrunker/status/1035757741602615298

サマータイム。
日本は時代を逆行するの好きだからな。





https://twitter.com/syouwaoyaji/status/1035293548889788416

これは多分、こいつなりの「反省と再発防止」という
やつなんだろうな。こんな事態に陥った原因を考え、
再発しないように手を打った、と。



コメント ( 0 )




https://twitter.com/yrm__/status/1033890153331212289

JavaScriptの極小エンジン「MINIScript」。へぇ。

フットプリントがROM 8kB、RAM 1kBって、これもしかして
Cortex-Mシリーズはもちろん、AVRでも動いたりしない?

こういうのって、ランタイムだけなの?それともJIT
コンパイラも入れてのサイズなの?
さすたに、JITコンパイラが8kBで動くって…むりっぽい
気がするんだけど。

サブセットらしいけど、サクサク動く系の高級言語が
こんな小さいフットプリントで使えちゃうの、すごい
ねぇ。





台風21号、やばそうだよな。気圧がすごいもんな。これを
書いてる時点の最新版で、915hPaだからなぁ。しかも、ほぼ
上陸間違えなしっぽい。
被害が出ないと良いけどなぁ。

https://twitter.com/EarthUncutTV/status/1035154367941201920

やばそうだよな。「typhoon spring rain salad」

https://twitter.com/EarthUncutTV/status/1035481595338055680

落雷って、「battering」っていうのか。へぇ。
辞書しらべてみたら、「殴打」とか「虐待」って書いてある
からお空から地面に向かって殴打するイメージなのかな。





https://www.youtube.com/watch?v=ZqGFtqZZXFA

いつもの吉田製作所さんの動画。Raspberry Pi3 B+がPCとして
どのくらいの速度なのかをチェックしている。

オイラはシリアルかリモートの黒い画面で繋いでwebサーバ
的に使えればなんでもいいと思っているんだけど、やっぱ
PC用途で使いたい用途もあるだろうな。なかなか面白い
内容だった。1GBメモリじゃぁたいしたことできないと
思い込んでたけど、やっぱ、モデル落ちしたスマホくらい
の能力あるんだから、このくらい動くんだろうな。

GPUにメモリ振ってやれば、動画もサクサク動くっていう
のがなかなか興味深い。

それにしても、そろそろ2GBくらい搭載したRaspberry Pi4
の登場が待たれるよな。





https://twitter.com/moriteppei/status/1032954855478808576

子供食堂、無料じゃなくて10円っていうの、これすごい
イイカンジだな。





https://twitter.com/sudamin/status/1035159432739446784

これはなぜかピンとくる。
訛りのある英語でしゃべって、スペルを覚えたりする
ような気がする。

https://www.youtube.com/watch?v=Bq1hqfoFOYI

おぉ。サーキットベンドに使ってる人がいる!!!





https://japanese.engadget.com/2018/08/08/palm-fcc-android-8-1/

Palmのアンドロイドスマホ。
このキーボードスライド式がたまらんな。

日本の技適は通らないのかな?





http://tsukuru-hito.com/e10607974.html

ピコレーザープロジェクター。へぇ。これ、こないだ
MFT2018で見かけたやつかな?

MEMSスキャナーでレーザーだから、ピント合わせ要らない
みたい。発熱も小さいみたい。面白いなぁ。


PCのディスプレー。今使ってるような液晶のやつだと、
それなりに大きさ必要になって邪魔だから、こういう
プロジェクターを常用にして、壁にスクリーン貼って、
普段からプロジェクターで使う方が便利なのかもしれん。

MEMSのプロジェクターなら、OLEDとちがって、焼きつき
の問題も無いだろうしな。

http://dimeiza.hatenablog.com/entry/2018/07/14/131234

1280掛ける720だと、今使ってるデスクトップのLCDや
ノートPCよりもより縦が少しせまくなってしまうな。
輝度も、昼間の部屋ではちょっと無理っぽいかな。





https://twitter.com/KIMIKO_PEACE/status/1035329134317076481

公文書の問題、本当に危機的状況な気がするな。
公文書の代わりに、後世の人が正しく歴史を評価できる
ように、大事な情報を残しておく方法って、ないもの
なのかな。

ブロックチェーン使って、事実上改ざんできないように
してしまう方法はあると思うんだけど、それ以前に、
「記録として残さない」ための法律まで作っちゃう
とはな…。

そもそも、会議の発言を残さなくて良い”議事録”って、
何の意味があると思ってるんだろうな?



コメント ( 0 )




こないだOpenSCADで書いてみた、トロコイドポンプの
スクリプト。いくつかの条件下で、ポリゴンに割れ目が
生じてしまうという件。



こんな風になっちゃうやつ。理由を探ってみることに。

ロジックから考えると、特におかしなことはやって
いなくて、



この図の左下の花びら型から、右のトンガリを引いて、
それに左上のギザギザを足しているだけの、単純な
造形なので、これだけ考えれば、おかしな割れ目は
出来ないはずなんだよなと。

じゃぁ、なんで割れ目が出来ちゃうのかをあれこれ
考えてみた。


仮説として1個思い浮かぶのは、仕上がりの立体の周囲
の波型曲線上で、「変曲点」にあたる部分(凸と凹が切り
替わる点)は、中心点から見ると、曲線の接線がちょうど
中心点の方を向いてしまうという計算式になっている
なぁ、と。

それを念頭に、もし、桁落ちなんかによる計算誤差が
含まれると、隣り合うポリゴンが微妙に入れ替わって
しまって、内部的には裏返ったポリゴンが生じたり、
もしくは厚みがゼロの「妙なポリゴン」が生じたり
するのではないかな?と。

その「妙な」ポリゴンが悪さしているような気がする…。





というわけで、解決するとしたら、ロジックを少しばかり
変えないといけない気がする。

現在は、上記のように、外側に膨らむ花びら型と、内側
に膨らむギザギザ型を別々に描いて、それらを合成する
というロジックになっているんだけど、この曲線を描く
ロジックを分けずに済ませたいなと。

そのためには、現在は「epicycloid」と「hypercycloid」
を別々の関数として計算させているんだけど、これらを
統合して、角度によって内部で自動的に切り替えて、
いっぺんに描画できるようにしてやるのがいいのかな?と。


ただ、OpenSCADの関数って、C言語の関数とかと違って、
単純に「計算式」を記述する、いわゆる関数なので、
内部にif文を入れ込んだり、forループを組み込んだり
といったことが出来ないんだよな。

三項演算子は使えるので、その辺をうまく使って、きれいな
式で表せられるといいんだけどな。
三項演算子、嫌いなんだよな。




コメント ( 0 )



   次ページ »