きりまるのブログ

きりまるのブログ

ホームピグアメブロ

芸能人ブログ人気ブログ

前ページ
次ページ

05Jan
- 飲食店予約アプリを作る
  今回はオープンソースのWebアプリ開発環境Budibase（バディベース）を使い、お題をこなしながらWebアプリ制作の基礎を学びます。近頃、飲食店の無断キャンセルが深刻化しているようです。否、SNSが発達したことで昔から起きていた問題が顕在化しただけかも知れません。このようなトラブルを防ぐためグルメ予約サイトを利用する方法もありますが、飲食代金の支払い毎に手数料がかかることを心配する方もいらっしゃるかと思います。そこで、無断キャンセルに悩むレストランや喫茶店のオーナーさんが口頭での曖昧な約束に頼らなくてすむよう、簡易予約アプリ（仮称：EasyBook）を自作してみます。これが完成形ですと言うわけではなく、より高度な機能を持つアプリを作るために開発経験を積むのが目的です。なぜBudibaseなのか先進的なノーコード開発環境はログイン機能の実装を前提としており、不特定多数のユーザーが使えるアプリを作るのはかえって面倒です。これは、スマホにインストールしたりアカウントを開設してもらうまでもないアプリの制作には不便と言えます。いくつかノーコード環境を試して、Adaloに使用感の近いBudibaseがログイン不要のWebアプリを作るのに最適と判断しました。アプリの使いかたを決める簡易予約アプリEasyBookは次のような流れで利用します。飲食店を予約したいお客様にEasyBookのQRコードを提示しますスマホでこれを読み込むと入力フォームが表示されます代表者の氏名、連絡先、人数、予約日時、返信方法を入力して送信します EasyBookは送信日時とともに入力情報をデータベースに登録しますオーナーさんは内容を確認し、予約が確定した旨を手作業で返信しますサーバーを用意する予約アプリを運用するには、24時間休みなく動作するサーバーが必要です。ホームページを運営するためのレンタルサーバーはこのような用途に対応できないため、全ての権限を与えてもらえるVPSサーバーを借りる必要があります。サーバーの設定手順に各社いくらかの違いはありますが、導入手順はおおむね以前筆者のブログで紹介した通りです。このブログで動作検証したところ、Budibaseを動かすのに最低2GBのメモリ容量が必要だと判明しています。スペック不足のサーバーでは起動すらしないので、VPSサーバーを借りる際にはメモリ容量に気をつけてください。『GCEでVMインスタンスを立てる（おまけ付き）』ネットにはいくつも解説があるので今更のような気もしますが、Google CloudでVMインスタンスを立ててUbuntu 24.04 LTSをインストールする…ameblo.jp自前でサーバーを用意するのが難しい場合は、Budibase公式サイトで一通り試用することもできますし、有償プランを利用すれば本格的な運用も可能です。この段階でBudibaseにログインできる状態まで進めておきます。データベースを設計するまずはアプリでどんなデータを扱うかを決めます。最初はTable Name(テーブル名)を決め、そのテーブルで扱うcolumn(カラム)とoption(データ型)を定義します。ここでは、顧客管理に使うテーブルCustomerを作成します。 Column Option Add option Default value Label Name Text - None 代表者氏名 Mail Text - None 電子メールアドレス Phone Text - None 携帯電話番号／ＳＭＳ Guests Number - 1 ご来店人数 Preferred_DT Date / time - None 予約日時 Contact Single select どちらでもよい/電子メール/ＳＭＳどちらでもよいご希望連絡先 Application_DT Date / time - None - Application_DTは送信ボタンを押した日時を格納する内部情報で、アプリ画面上には表示されません。作成したテーブルCustomerは以下のようになります。アクセス権限をPublic userに設定してください（重要）。データベースの設計はこれで終わりです。ユーザー・インターフェースを設計するアプリの使いやすさは、情報をどう配置するかで決まります。ユーザーが操作しやすいよう、まっさらのキャンバスにText Fieldコンポーネントを並べていけばいいように思えますが、そう簡単ではありません。データベーステーブルの情報を表示するコンポーネントは、Formコンポーネントの中に配置するというルールを守る必要があります（重要）。下の画像を見て下さい。青い枠がForm 1の領域を示し、水色の枠がName Fieldです。これは、Name FieldはCustomerテーブルのName値を表示するためです。この部分をメニュー左側のComponentsリストで確認すると、Form 1の下にName Fieldが入れ子になっているのが分かります。この位置はコンポーネントをドラッグ＆ドロップしていつでも並べ替えることができます。上図を見て分かるとおり、他のフィールドもそれぞれ異なるFormの下に配置されているのが分かると思います。いちいち別のFormを用意するのは面倒なので、ひとつのFormに複数のFieldを入れてしまうこともやろうと思えばできます。ですが、コンポーネントのレイアウトはFormコンポーネント側で調整する仕様のため、各Fieldの表示位置を個別に調整することはできません。データベースの値と直接関係のないTextコンポーネントやButtonコンポーネントは、どのFormに属さなくても大丈夫です。データの表示先を指定するコンポーネントが配置できたら、それぞれにカラムを関連付けます。代表者氏名フィールドをみてみましょう。右メニューのField値にCustomerテーブルのNameを指定しています。これで設定完了です。他のコンポーネントも基本的には同じ要領で作業を進めます。Options Pickerのように少し特殊なコンポーネントは、右メニューでプルダウン式やラジオボタン式を切り替えられるようになっています。この設計では予約日時の項目で日付の指定とともに時間を分単位で指定する仕様になっています。Options Pickerをプルダウン式で利用すれば、例えば8:00、10:00、12:00、14:00などお店の都合に応じて限られた時間帯から選択していただくこともできます。以上で、Customerとの関連付けが完了しました。ボタンの動作を設定するテキストフォームやカレンダーフォームへの入力、ラジオボタン選択はこれで機能するようになりましたが、ボタンを押した時の動作はまだ未定義のままです。このアプリにはボタンが全部で３つあります。 Button Minus …… 来店人数を１減らす Button Plus …… 来店人数を１増やす Button Submit …… 確定した内容を送信する【Button Minus】右メニューのOn clickにアクションを設定します。Update Field value（フィールド値を更新）アクションを追加し、具体的な動作をJavaScript関数で定義します。項目Valueの右側にある⚡アイコンをクリックします。編集モードをTextからJavaScriptに切り替えて、以下のようにコードを記述します。プログラムに間違いがないことを確認したら、Saveして終了します。JavaScriptreturn Math.max((Number($("[Guests Field].Value")) || 0) - 1, 1);このコードは、現在のGuests値から1を引き、1か1より大きいほうの数字で更新します。【Button Plus】先ほどと同様に編集モードをJavaScriptに切り替えて、以下のようにコードを記述します。プログラムに間違いがないことを確認したら、Saveして終了します。JavaScriptreturn Math.min((Number($("[Guests Field].Value")) || 0) + 1, 20);このコードは、現在のGuests値に1を足し、20か20より小さいほうの数字で更新します。ここでは入力可能な数値を20に制限しています。予約できる人数の上限に設定します。【Button Submit】On clickに以下のようなSave Rowアクションを追加します。このボタンを押すと、これまでに入力したデータが一気にCustomerテーブルのレコードに書き込まれます。Add columnで項目を追加してガイドに従って操作を進め、最終的にはこのように設定します。最後のApplication_DTには入力すべき日時が事前に定義されていないため、編集モードをTextとして、以下のように記述します。Text{{ now }}この一文で、Button submitをクリックした瞬間のタイムスタンプがApplication_DTに格納されます。これにより、お客様がいつ予約を送信したのか分かるようになります。申し込み完了画面を表示する送信ボタンをクリックしたら、予約申し込みを完了したことを示すダイアログを表示させます。右メニューからModalコンポーネントとTextコンポーネントを追加し、TextをModalの下に置きます。結果は以下のようになります。ダイアログに表示する文章を編集します。このモーダル・ダイアログは送信ボタンを押すまで表示されません。Button SubmitのOn clickにアクションを追加します。Open Modalを追加し、Modal Acceptを選択します。これにより、送信ボタンを押したときデータベースへの書き込み → 予約申し込みが完了したことを知らせるダイアログの表示を連続的に処理します。予約を電子メールに通知するお客様が予約を入れたことを把握するため、自分の電子メールにその内容を通知させます。一般的なメールサーバーでも問題なく設定できますが、ここでは、GoogleのGMailを使う方法を説明します。BudibaseからGmailの送信機能を利用することになりますが、この手順を利用すると少し安全性が低下します。普段使いのメールアドレスを使うのが不安な方は、予約受付用のメールアドレスを用意することをお奨めします。GMailであらかじめ以下の２点を設定しておきます。聞き慣れない機能ですが、アプリパスワードというものが必要になります。２段階認証を有効にするアプリパスワードを生成するアプリパスワードは公式ヘルプセンターを参考に生成します。アプリ名はBudibaseとします。以下のようにアプリパスワードが生成されますので控えておきます。Budibaseに戻り、左メニューの[Settings]-[Email]を開き、SMTPの項目を設定し、Saveします。　Host：smtp.gmail.com　Security type：None/STARTTLS　Port：587　From email address：予約受付用メールアドレス　Require sign in：ON　User：予約受付用メールアドレス　Password：アプリパスワード左メニューの[Automations]で[+ New Automation]よりオートメーションAuto Sendを作成、Row Createdを選択してSaveします。Auto Sendを編集します。Row CreatedはテーブルCustomerにレコードが作られたときに発動します。Button SubmitのOn clickが発生する前にメールを送信しているので、送信ボタンの動作に変更はありません。[Add a step]でSend Email(SMTP)を接続します。Send Email(SMTP)の設定を以下のように記述します。　Send To:自分の予約受付用メールアドレス　Send From:自分の予約受付用メールアドレス　Email Subjct: 予約を受け付けましたMessageについては、右の⚡アイコンよりJavaScript編集に入ります。Trigger OutputsボタンをクリックするとCustomerテーブルのカラムを挿入できますので、この機能を駆使して以下のようなJavaScriptを作成します。このコードは少々長いのでGitHubからコピー＆ペーストすると良いでしょう。projects/EasyBook/Send_Email_message.js at main · kirinote/projectsMy miscellaneous projects. Contribute to kirinote/projects development by creating an account on GitHub.github.com以下のように記述してSaveします。formatJST関数は、協定世界時UTCで格納されている日時データを日本標準時JSTに変換する関数です。AutomationsのAuto SendをLive状態に切り替えます。完成したアプリを公開するアプリを公開する前に、アプリの名称とURLが適切なものになっているか確認します。左メニューからAppsリストを表示させるとEasyBookの右側に【…】が表示されるのでこれをクリックしてEditモードに入ります。アプリ名を決めるとURLはそれらしいものに設定されるので、とくに好みがなければ編集する必要はありません。フォーム画面右上のスイッチをONにして、AppsのEasyBookをLive状態に切り替えます。AutomationsのAuto Sendも両方Live状態となってはじめてアプリが完全に動作するようになります。右メニューのAccessをPublic userに切り替えて（重要）、Publishボタンをクリックするとアプリが公開されます。では、どこで公開されたのかURLを調べます。EasyBookの右側に【…】が表示されるのでこれをクリックしてView live appをクリックします。別にブラウザが開いてURLが表示されます。このURLにアクセスするとEasyBookアプリが開きます。フォームからダミーデータを入力し、送信ボタンをクリックするとダイアログが表示されます。Budibaseは開発用(Development)と本番用(Production)のデータベースを分けて管理しています。下図の赤枠をクリックしてBudibaseのProd（本番用）データベースを確認すると、送信されたデータが追加されています。また、予約受付用のメールアドレスにも同じ内容が送られてきます。以上で、一連の動作がちゃんと機能することが確認できました。VPSサーバーを借りただけでは静的IPアドレスがそのまま表示されます。動作に支障はないとはいえ、数字だけのサイトはあまり見栄えがよくありません。もしオーナーさんがご自分のドメインexample.comをお持ちであれば、DNSでこのサーバーにサブドメインeb.example.comを割り当てると良いでしょう。QRコード生成サイトにこのURLを入力して生成すると、QRコードが表示されます。多くのサイトで生成できますが、セキュリティの面でQRコードの本家であるデンソーのサイトを利用すると良いでしょう。QRコード作成｜QRの解析｜クーポン発行無料｜商用利用可｜クルクルマネージャーQRコードの無料作成、お店を利用するお客様へクーポンや情報配信などの販促ができるサイトです。m.qrqrq.comこのQRコードをお客様にお見せすれば、お手持ちのスマホでEasyBookを表示して予約を受け付けることができます。実環境での動作テストお手持ちのスマホでEasyBookを表示して、適当に予約情報を入力して送信してみましょう。送信後にモーダル・ダイアログが表示されればOKです。Budibaseに戻り、左メニューのDataからCustomerテーブルを選択表示します。オーナーさんはこのテーブルを確認のうえ、できるだけ早くお客様に折り返し連絡をすることになります。さらなる自動化も目指せますが、あまり手放しで運用できてしまうと想定外の予定を組まれてしまい、かえって良くないかもしれません。おわりに以上でログイン不要・インストール不要のWebアプリを開発することができました。このアプリがただちに役立つとは思いませんが、欲しい機能を追加していくことで実用的なアプリが作れるようになるでしょう。
26Dec
- Adafruit IOで温度と湿度をグラフ表示する
  久々の電子工作です。SHT40Iを使って温度と湿度を測り、WiFiでAdafruit IOにデータを送ってグラフ表示します。部品は秋月電子通商さんで買いました。ちょっとした部材を含めても、3000円ほどの予算で立派なIoTデバイスが作れます。部品表 XIAO ESP32C6 無線マイコンボード　1040円 AE-SHT40I-AD1F-R2-SIP4 温度湿度センサ　650円 AE-FRSK-120-UV-TH ユニバーサル基板　120円 SBH-331AS 電池ボックス　160円ハードウェア・デザイン回路図は以下の通りです。モジュールは２つだけとシンプルで、FRISKのケースに収納することができます。電源は単三アルカリ乾電池を直列３個として4.5Vを作ります。作成した基板は以下のようになります。システムがある程度動作することを確認できるまでは乾電池を使わず、USB接続の5V電源で動作させます。乾電池は何の保護もしていないので、絶対にUSBと同時に接続しないでください。IoTダッシュボードの準備電子工作界隈でよく知られている電子ガジェットメーカーAdafruitのアカウントを作成します。Adafruit Industries, Unique & fun DIY electronics and kitsAdafruit Industries, Unique & fun DIY electronics and kits : - Tools Gift Certificates Arduino Cables Sensors LEDs Books Breakout Boards Power EL Wire/Tape/Panel Components & …www.adafruit.comアカウントを開設すると、付帯サービスのIoTダッシュボードAdafruit IOにアクセスできるようになります。Adafruit IOでは、右上の黄色の鍵アイコンをクリックするとデバイスからデータを送信する際に必要となる自分専用のAPIキーが表示されます。このAPIキーは後ほど使います。無料枠ではデータの保存期間が30日となっています。多少の制約はありますが、欲張った使い方をしなければサービスが終了するまで支障なく使えると思います。Arduino開発環境の構築Arduino IDEを立ち上げ、以下のプログラムファイルを２つ作成します。 SHT40I_monitor.ino …… 空のsetup関数とloop関数でOK config.h …… 空のままでOK作成したファイルは、[File]-[Save as...]で最初に開かれた場所に保存するのが無難です。ファイル名と同名のフォルダ、この場合ではフォルダSHT40I_monitorの中に必要なファイルを全て保存することになります。プログラムをできるだけ簡単にするため、便利なライブラリを導入します。環境設定を行います。以下のURLをArduino IDEの設定に追加します。Additional boards manager URLs:https://espressif.github.io/arduino-esp32/package_esp32_index.jsonボードマネージャでesp32を検索してインストールします。これにより開発環境がESP32シリーズ全体を認識できるようになります。ボードセレクタでXIAO_ESP32C6を選びます。ライブラリマネージャで以下２つのライブラリをインストールします。 SHT40 by MR01Right Adafruit IO Arduinoと依存するライブラリ全て以上でプログラムの下準備が整いました。ダッシュボードのフィード設定ここで、データの受け入れ側であるAdafruit IOの設定を進めます。Adafruit IOにログインしてください。今回はデバイスが１つしかないので温度データtemperature1、湿度データhumidity1という名称のフィードを受信します。広いエリアを監視するなどデバイスを増やしたいときはtemperature2、humidity2... とった感じにすれば良いでしょう。[IO]-[Feeds]タブの[＋New Feed]からtemperature1とhumidity1を追加します。[IO]-[Dashboards]タブの[＋New Dashboard]からSHT40I-1を追加します。追加できたら、赤枠のSHT40I-1リンクをクリックしてダッシュボードに移動します。赤枠の[＋New Block]をクリックします。データの表示形式を選びます。折れ線グラフにしたいので、赤枠のLine Chartを選択します。temprature1を選択し、Next Stepを押して次へ進みます。次の画面は何もせず、ただCreate Blockを押して完了です。パネルの見た目にこだわりたい方はどうぞご自由に。同様の手順で、[New Block]からLine Chartとしてhumidity1を選択し、Create Blockを押してグラフを追加します。その結果、以下のようにグラフが２つ並びます。[Edit Layout]を押せば、各パネルを見やすいように再配置できます。以上でダッシュボード側の待ち受け体制が整いました。ファームウェア・プログラミングこの記事に直接スケッチを書くと読みづらいので、GitHubに置いておきます。projects/SHT40I_monitor at main · kirinote/projectsMy miscellaneous projects. Contribute to kirinote/projects development by creating an account on GitHub.github.comSHT40I_monitor.inoとconfig.hの内容を編集中のファイルにコピー＆ペーストしてください。スケッチのシリアル出力はパソコンでデバッグするために残してあります。現場で稼働している時は必要ないのでコメントアウトしています。このプログラムは１分間に温度と湿度の２個を送信しています。無料枠では１分間あたり最大30個のデータ受信が上限となっています。ウェイトを考慮せずにプログラムをループさせると簡単に上限を超えてしまいます。まだシステムが完成していない段階でも送信レートだけは守ってください。ディープスリープから起床したあとデータ送信の前にWiFi認証を通しており、この時に大きな電力を消費しています。実用上差し支えなければ、10～15分間隔すなわち600～900秒ぐらいまで送信間隔を広げたほうが良いでしょう。例）#define TIME_TO_SLEEP 600送信間隔を広げるとデータの取り方は荒くなりますが、乾電池の交換サイクルを延ばすことができます。単二電池や単一電池など大容量の電池を使うのも手です。config.hで定義されている変数は、以下の４箇所を自分の環境に合わせて書き換える必要があります。 IO_USERNAME IO_KEY WIFI_SSID WIFI_PASSIO_USERNAMEとIO_KEYは、先ほど開設したArduino IOのAPIキー（黄色の鍵のアイコン）で確認することができます。WIFI_SSIDとWIFI_PASSは、このデバイスが置かれるWiFiネットワークの設定に合わせてください。Arduino IDE上のプロジェクトSHT40I_monitorの編集が終わったら、XIAOボード上のBOOTボタンを押しながらUSBケーブルでパソコンに接続します。XIAO ESP32C6はBOOTボタンを押さずにアップロードできますが、このプロジェクトではディープスリープモードを使用しており、２度目のアップロード以降は電源が入ってしばらくすると書き込めなくなることがあるためです。デバイスが接続できたら、デバイスマネージャーでCOMポートとして認識されます。Arduino IDEを開き、[Tools]-[Port:]で通信対象とするデバイスのCOMポートを指定してスケッチをアップロードしてください。プログラムが書き込まれると、デバイスがとAdafruit IOに温度データと湿度データを送信し始めます。送信した後はディープ・スリープモードに移行し、設定秒数後にまた起き出してデータを送信します。パソコンに接続した状態で正しく動作することを確認できたら、USBケーブルを抜き、乾電池で動作させます。以降、デバイスがスタンドアロンで動作しはじめます。スタンドアロン動作中のデバイス冬場夜間に暖房を切ると室温が低下していくのが分かるこのダッシュボードは、スマホのWebブラウザからログインしても同じように見ることができます。出先で現状が気になったときでも安心です。Actionsによる通知[IO]-[Actions]を使えば、自分の設定した条件で通知させることができます。システムの稼働中ずっとダッシュボードを見ていられるわけではないので、Actionsをうまく設定して異常が生じた時に通知させると良いでしょう。My Actionに以下のブロックを組んでRunしておくと、受信した温度データが26度を超えたときにログイン用メールアドレスにあらかじめ設定しておいたメッセージを送ってくれます。Google検索で見つけた有償のIoTダッシュボードを比較しても、フル機能版のAdafruit IO+が年間99米ドルというのは比較的安価な部類に入るのではないかと思います。
17Dec
- GCEでVMインスタンスを立てる（おまけ付き）
  ネットにはいくつも解説があるので今更のような気もしますが、Google CloudでVMインスタンスを立ててUbuntu 24.04 LTSをインストールする手順のメモです。無料枠内で収まるよう慎重に設定しているつもりでも、いかなる理由で課金が始まるか分からないため参考程度としてください。個人的な都合でプロジェクト名をBudibaseと命名していますが、今回の手順とは無関係ですので無視してください・・・としていたのですが、試行錯誤したところ条件付きでBudibaseが動作しましたのでおまけとして追記します！プロジェクトを作成するプロジェクト名をBudibaseとしてプロジェクトを作成し、プロジェクト選択ツールでプロジェクトをBudibaseに切り替えます。プロジェクトを作成すると、ユーザーに仮想プライベートクラウドVPCが与えられます。VPCのファイアウォールルールは仮想ネットワーク空間、つまりユーザーが立てるインスタンス全体で設定が共有されます。ここでポートを設定しただけではどのインスタンスにも影響しません。ファイアウォールルールには任意の名称のターゲットタグを命名することができ、設定を反映させたいインスタンスにこのタグを貼り付けることでポートを個別に制御します。インスタンス内で稼働しているUbuntuのファイアウォールUFWは無効となっており、ポートの開閉はVPC側で管理されていることが分かります。インスタンスを作成する[ナビゲーションメニュー]-[Cloudの概要]-[ようこそ]に移動し、[VMを作成]をクリックします。Compute Engine APIを有効にします。マシンの構成は以下の設定とします。名前：ins1 リージョン：us-west1（オレゴン） Series：E2 マシンタイプ：e2-micro（2 vCPU、1コア、1GBメモリ）OSとストレージは以下の設定とします。オペレーティングシステム：Ubuntu バージョン：Ubuntu 24.04 LTS x86/64, amd64 noble image ブートディスクの種類：標準永続ディスクサイズ（GB）：30データ保護は以下の設定とします。バックアップなしネットワーキングは以下の設定とします。 HTTPトラフィックを許可するにチェック HTTPSトラフィックを許可するにチェック標準永続ディスクとは普通のHDDのことで、無料枠はこれを選ぶ必要があります。その他のオプションは有料枠で、高速アクセスが可能なSSDを併用あるいは使用します。同じメニュー内にあるネットワークインターフェースを展開します（赤枠）。外部 IPv4 アドレスを静的外部IPアドレスを予約に設定します。ネットワークサービスティアがプレミアムとなっていることを確認のうえ、[完了]ボタンを押して設定を終了してください。名前はとりあえずins1-nic として予約します。これで外部からの安定したアクセスに必要な静的IPアドレスを貸してもらえます。以上でインスタンスの仕様が決定しました。画面下に表示されている[作成]ボタンを押すとVMインスタンスが作成されます。以下のように料金がかかるように表示されていますが、全ての設定項目が無料枠内での利用となっていれば課金はありません。VMインスタンスの一覧にins1が表示されたらサーバーにアクセスできるようになります。SSH接続の準備SSHの設定をおこなうため、メニュー右上にあるCloud Shellを立ち上げます。以下のコマンドでSSHキーを生成します。usernameは任意のユーザ名を設定してください。途中で訊かれるパスフレーズとともにSSH接続の際に必要となります。$ssh-keygen -t rsa -f ~/.ssh/my-ssh-key -C username生成された秘密鍵の確認をします。$sudo cat ~/.ssh/my-ssh-key表示された暗号テキストは、メモ帳などに貼付け、my-ssh-keyというファイル名で保存しておきます。ファイルを保存する際、-----END OPENSSH PRIVATE KEY-----の後ろは改行しておく必要があります。生成された公開鍵の確認をします。$cat ~/.ssh/my-ssh-key.pub表示された短めの暗号テキストは、メモ帳などに貼付け、my-ssh-key.pubというファイル名で保存しておきます。公開鍵を登録します。VMインスタンスを編集します。SSH認証鍵を登録します。my-ssh-key.pub の中身をペーストして保存します。以上でSSH接続の準備が整いました。SSH接続のテスト筆者のＰＣはWindowsベースのシステムなので、使い慣れたTeraTermを使います。ホストには割り当てられた静的IPアドレス、TCPポートは22番、サービスはSSHを選択します。SSH認証鍵の生成中に決めたユーザ名、パスフレーズを入力し、認証方式ではあらかじめ保存しておいた秘密鍵ファイル my-ssh-key を指定します。無事に接続できると以下のコンソール画面が現れます。以上で、無事にローカルから米国オレゴン州のサーバーにSSH接続できるようになりました。22番ポートを閉鎖する22番ポートは管理用アクセスポートとしてよく知られているため、攻撃を受けないよう対策する必要があります。ここでは普段は22222番ポートからアクセスすることとして、22番ポートは閉鎖します。ネットワークインターフェースのdefaultを選択します。続いて、ファイアウォールタブを選択します。[＋VPCファイアウォールルールを作成]をクリックし、ルールを２つ作成します。ルール①　名前：allow-ssh-22222　一致したときのアクション：許可　ターゲットタグ：allow-ssh-22222　送信元IPv4範囲：0.0.0.0/0　プロトコルとポート：指定したプロトコル > TCPにチェック>ポート：22222ルール②　名前：deny-ssh-22　一致したときのアクション：拒否　ターゲットタグ：deny-ssh-22　送信元IPv4範囲：0.0.0.0/0　プロトコルとポート：指定したプロトコル > TCPにチェック>ポート：22この記事ではインスタンスが１つしかないので、ルール名とターゲットタグ名を同じにしています。これら２つを作成したらいったんVMインスタンス画面まで戻り、編集をクリックします。ネットワークタグに先ほど作ったタグallow-ssh-2222とdeny-ssh-22を追加して保存します。TeraTermを立ち上げ、22番ポートを使ってログインします。ログインできたら以下のコマンドでファイル sshd_config を編集します。テキストエディタVimの使い方は省略します。$ sudo vim /etc/ssh/sshd_config22番ポートをコメントアウトし、代わりに22222番ポートを指定し、ファイルを保存します。#Port 22Port 22222以上の設定を反映させるため、インスタンスを停止し、再起動します。$ sudo shutdown -r now再起動したら、TeraTermのTCPポート番号を22222に変更してログインできることを確認してください。これで、22222番ポート経由でSSH接続できるようになりました。最後に、使用しないルールを無効化します。VPCファイアウォールルールにある default-allow-ssh を選択してください。ファイアウォールルールの詳細に入ったら、編集ボタンを押して編集モードに入ります。[∨ルールを無効にする]を展開すると、以下のメニューが現れるので無効に切り替えて保存します。VPCファイアウォールルール一覧を確認すると、default-allow-sshの行が無効となっていることが分かります。以上で22222番ポートでのSSH接続を許可し、危険な22番ポートを閉鎖しました。その他セキュリティ周りはおいおい設定していくと良いでしょう。インスタンスを削除するときの注意点静的IPアドレスは貴重な資源ですので、インスタンスを削除して使っていなくても保持しているだけで課金対象となります。不要なインスタンスを削除したときは、同時にナビゲーションメニューのVPCネットワークメニューにて静的IPアドレスを解放しましょう。（おまけ）Budibaseをインストールしてみた元はといえば、GCEの無料枠でBudibaseが動けば完全無料でWebアプリが運用できるんじゃないか？という安易な考えでVMインスタンスを立てたわけですが、当初はBudibaseをインストールしてもなぜか動作しませんでした。試行錯誤の末、メモリ容量を2GBに拡張すれば正しく動作することが判明しました。原因はメモリ不足――GCEの有料枠でないとBudibaseは動かない――ということです。せっかくここまでGCEを使いこなしてきたわけですから、有料枠に昇格してでもBudibaseを運用できればそれで良いかなと思うようになりました。無料枠だけ食い逃げしようと思っていたのに、まんまとGoogleの罠にかかってしまいました (^_^;)というわけで、無料枠で作ったインスタンスを削除して仕切り直します。インスタンスに割り当てていた静的IPアドレスもいったん解放します。今回のマシンの構成は以下の設定とします。名前：ins1 リージョン：us-west1（オレゴン） Series：E2 マシンタイプ：e2-small（2 vCPU、1コア、2GBメモリ）有料枠ですその他の設定は従来通りです。単にBudibaseを動作させるだけなら標準永続ディスクのサイズはデフォルトの10GBでも大丈夫ですが、本格的に開発するならいくらか課金して拡張しておいたほうが良いかもしれません。設定に誤りがないか注意しながらインスタンスを作成します。[＋VPCファイアウォールルールを作成]をクリックし、Budibase用のルールを作成します。10000番ポートを解放します。ルール③　名前：allow-budibase-10000　一致したときのアクション：許可　ターゲットタグ：allow-budibase-10000　送信元IPv4範囲：0.0.0.0/0　プロトコルとポート：指定したプロトコル > TCPにチェック>ポート：10000allow-budibase-10000が登録されたことを確認します。動的ネットワークインターフェースのネットワークタグにルール①、ルール②、ルール③を追加します。続いて、SSH公開鍵は無料枠で作ったときのものを登録します。SSH認証鍵を新たに生成する必要はありません。TeraTermでログインするためのユーザ名、パスフレーズも使い回せます。一時的にファイアウォール22番ポートdefault-allow-sshを有効に、deny-ssh-22を無効とします。続いてTeraTermから22番ポートでログインします。ログインできたら以下のコマンドでファイル sshd_config を編集します。$ sudo vim /etc/ssh/sshd_config22番ポートをコメントアウトし、代わりに22222番ポートを指定し、ファイルを保存して一旦TeraTerm接続を終了します。#Port 22Port 2222222222番ポートで無事ログインできたら、deny-ssh-22を有効に、default-allow-sshを無効に戻してください。以上で再び22番ポートを閉鎖できました。Budibaseをインストールするインストールコマンドを以下に示します。コマンド中のusernameは自分が決めたユーザ名に差し替えてください。$ sudo apt update$ sudo curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - && sudo apt-get install -y nodejs$ sudo mkdir -p /etc/apt/keyrings$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null$ sudo apt update$ sudo apt install -y docker.io$ sudo apt install -y docker-ce docker-ce-cli containerd.io$ docker -v$ docker compose version$ sudo systemctl start docker$ sudo systemctl enable docker$ sudo npm install -g @budibase/cli$ budi --version$ budi hosting --initこの初期化プロセスで２つ確認が入りますが、特にこだわりがなければyと改行で進めてください。これによりサーバーの10000番ポートでBudibaseの初期画面にアクセスすることが決まります。$ cat .env$ sudo usermod -aG docker username$ sudo reboot～再起動～$ budi hosting --startこの起動プロセスは少し時間がかかりますが、最後にWebページ公開の許可を求められますのでyを入力してください。Budibaseが起動します。ブラウザに http://ipaddress:10000 を入力すると、すぐさまhttp://ipaddress:10000/builder/adminに転送され、管理者登録画面が表示されます。もし502 Bad Gatewayエラーが表示されたときは、しばらく時間をあけて再度アクセスを試みてください。それでもだめな場合は、以下のコマンドでローカルから問い合わせて応答があるか確認してください。curl -I http://localhost:10000ローカルで応答があれば、続いて外部IPアドレスでも応答があるか確認してください。curl -I http://ipaddress:10000これによりサーバー設定のどこに問題があるか、ある程度切り分けができます。管理者の登録が完了すると、次回のログインからは単純なログイン画面になります。以上で、GCEのVMインスタンスを構築してBudibaseを稼働させることができました。残念ながら無料枠のスペックではBudibaseは動かせなかったのですが、有料枠はコマンドの応答も軽く、きびきびとした動作になりました。
30Oct
- VTOLドローンの制作（５）
  最低限必要な部品が揃ったので、順次組み立てていきます。配線は結束バンドで構造部材に縛り付けるだけのため、見た目はよろしくありません。あとは組み立てだけだなぁと思っていたら、作業を始めるとサーボモーターの付属ケーブル長がモノによってまちまちであることに気づきました。コネクタの位置が左右の主翼で異なるうえ、最短距離で配線すると画像の赤枠部分のように接続部が他の部材と干渉するなど、ちょっと面倒な問題が出てきました。市販の組み立てキットなら部品同士の干渉を意識することはないでしょうが、ゼロから作るとこういう不都合も解消しないといけません。サーボモーターの付属ケーブルには、模型界でJRコネクタと呼ばれる端子が使われています。電子工作や自作パソコン界ではデュポンコネクタとかQIコネクタ、2550コネクタなどとも呼ばれ、名前がはっきり定まっていない不思議な部品です。構造が単純で2.54mmピッチの角ピンが相手なら確実に接続でき、汎用性が極めて高いために多くのメーカーが模造品を製造して今に至ります。ドローンは電気信号で機体を制御するフライ・バイ・ワイヤ方式で、電気信号が途切れたらすぐ制御不能になります。コネクタの接触不良や振動による脱落などあってはなりません。工場出荷時点のサーボモーターはしっかり品質管理されていますが、ケーブルを切ってコネクタを捨てたら後は自分で圧着品質を保証しなければなりません。信頼性を確保するため、純正に最も近いとされる圧着工具HARWIN Z20-320を使いました。スウェーデンPressmaster社のOEM品です。充電はG FORCE G3充電器がシンプルでとても使いやすいです。重心位置を正しくとるにはカウンターウェイトとしてのバッテリーがまだ軽いため、より容量の大きなものを買いなおすことになりそうです。充電できたらバッテリーの状態を確認します。CellMeter 8というモニターを使うと各セルの充電状態を確認することができ、バランス放電機能も備えています。さらに、ラジコン愛好家なら絶対に欲しいであろうサーボモーターの動作テスト機能もついています。サーボの調整はこのモニターが届く前に済んだので、使う機会を逃しました。出先で手軽に電池残量を確認できるので、ホビイスト必携のアイテムと言えます。
24Oct
- VTOLドローンの制作（４）
  フィラメントの種類で重量がどの程度違ってくるか検証するため、翼幅180mm、翼弦長160mmの翼を作って重量を比較してみました。材料は安価な標準PLAと、軽量な低密度PLAです。スライサの設定はインフィル６％、壁面層数１、充填パターンは３Dハニカムです。YouTubeで欧米のモデラーの作り方を見ると軽量化を意識してフィラメントの吐出経路を設計レベルで管理していますが、かなりの手間がかかるようなのでそこまではしていません。今回使用した低密度PLAは”プリフォームド”と呼ばれる発泡済みフィラメントです。モデルプレーン界隈でよく話題にのぼる発泡性PLAはノズル温度を変えて密度を自在に調整することができますが、このフィラメントはそれができません。その代わり、印刷条件の違いによらずモデルの重量を一定に保てるという利点があります。 ELEGOO PLA　密度：1.26g/cm3　価格：1,899円@1kg Polymaker PolyLite™ LW-PLA　密度：0.8g/cm3　価格：4,730円@800g　上の画像の通り、LW-PLAはPLAの86%の重量となりました。公称密度では計算上64%まで軽量化できるはずですが、現実的にはこの程度の軽量化にとどまるようです。画像では分かりづらいのですがLW-PLAの表面は無駄な樹脂で結構荒れており、リトラクションが足りなかったかなという反省はあります。とはいえPolymaker社の推奨設定値のままプリントしてこの部分だけでも機体を10.6g軽量化できたので、モーターの負担を減らすためにも少々お高いLW-PLAを使わざるを得ないようです。翼前縁側の本体部分は、軽量化を優先してLW-PLAを使いました。翼後縁側のエルロンやラダーベータなどの舵は厚みがない縦長でピンホーンも一体で造形しているため、ラフトの定着性と寸法精度を優先してPLAを使っています。この部分はつや消しのPLAが似合うようです。　サーボホーンと舵はΦ1mmの金属棒で接続し連動させます。このあたりは自作も可能かも知れませんが、市販の部品セットを使ったほうが確実でしょう。この部品は特に決まった呼称はないようで検索に苦労するのですが、AliExpressでは「プルロッド」「プッシュロッド」などと検索すると見つかります。購入するロッドの長さは在庫の中から指定できますが、当初これがどの部分の長さのことか現物が手元に届くまで分かりませんでした。今回使用した40mmと70mmの部品の画像を示します。ロッド先端はネジが切ってあり、画像右側のナイロンクレビスをねじ込むことでリンク距離を多少調整できます。
13Oct
- VTOLドローンの制作（３）
  翼の形状と配置は計算によっておおよそ求まるので設計はしやすいのですが、思いのほか検討が厄介なのは胴体です。形状の自由度が高すぎるために、最適な形状を探るのがなかなか大変です。VTOLモードではローターが重心位置で機体を吊り上げます。尾翼は重心から離れた所にあるため、吊り合いをとるにはこれに対向する質量が機首側に必要です。物理的には下図の２通りどちらも平衡しますが、左側のアームが胴体の質量に含まれるため、胴体の全長を半分にすればバッテリーの重量（≒容量）を２倍以上増やせることになります。３ＤＣＡＤで設計する際は、航空機同様に機体の断面図を並べることからはじめます。胴体内にはおおまかに言ってフライトコントローラとバッテリーの２つを収容しますので、それらを配線しやすいよう十分な内部空間を設ける必要があります。まだ手探りなので決め打ちした胴体寸法を叩き台にしますが、部品配置が確定したらタイトな設計に改めて機体重量を削減します。なにぶん飛ばすことに必死なので、貨物区画つまりペイロードは考慮していません。実用機ではフライト・ミッション毎に貨物の重量が変化するので、機体重心にペイロードを設けられるよう他の区画をうまくレイアウトする必要があるでしょう。仮設計の胴体断面断面を見て分かるとおり、胴体下部は少し膨れています。垂直離着陸を前提としたドローンなので、着陸装置がありません。旅客機のような丸っこい胴体ではドローンを置いた時に左右に転んでしまうので、少しでも座りが良くなるようにしました。この平べったい腹はV-22オスプレイやCH-47チヌークにも同じ意匠が見られます。断面が増えるほど形状の手直しが大変になるため、必要最低限の断面だけでそれっぽい形を作っています。仮設計の胴体ソリッドモデル手元の３Dプリンタは全長180mmまでのため、胴体はモデルを２つに分割してSTLやSTEPファイルに書き出します。材質は一般的なPLAです。向かい合う面にΦ2mm、12mmLの穴を設け、Φ2mmドリルで穴径を整えます。Φ2×20mmのステンレスピンを刺して位置決めし、分割面にアクリサンデー接着剤を塗布して接着します。底面には幅4mmの穴を両サイドに設け、フライトコントローラとバッテリーを結束バンドで固定します。裏側は結束バンドで膨れますので、機体を安定に接地させるため機体下部を少し底上げしています。分割した胴体パーツという感じで何もかも直感だけで部品を作っていますが、このまま制作を続けてまともに飛ぶドローンができるかは依然分かりません。だんだん不安になってきました。
21Sep
- VTOLドローンの制作（２）
  ロータ周りの制作を進めます。今のところ下図のような見た目になりそうですが、とにかく飛ばせる状態まで持っていくことに専念するので胴体は簡素なものになります。尾翼の重さを相殺するため、バッテリの位置と容量をどう調整するかが問題です。前後バランスが悪いからとバラストを載せるような余裕はありません。フライト制御の正確さは、ティルト機構をどこまで簡素にできるかによります。機構部が複雑になるほど部品間のバックラッシが累積し、フィードバック制御を不安定にします。このため、ティルト機構用サーボの角度がそのまま制御角となるように設計します。サーボモータを買うとそれに見合うサーボホーンが付属しますが、この部分は多少重くとも加工精度の高いサーボホーンでなければいけません。サーボモータGX1306MGはトルクが4kgf・cmと心許ないのですが、アルミ製のサーボディスクが付属しています。これ以上のトルクを求めると一気に大きい製品群に移行するため、しばらく使ってパワー不足でなければこれを使います。サーボアーム長すなわちサーボ軸とモータ取り付け面との距離は4.5cmで、トルクは0.89kgfまで減じます。ロータ用ブラシレスモータはQA2205-1400KVを使用します。データシートによれば、プロペラを正しく組み合わせると出力効率が7g/Wを超えるようです。8"×4"プロペラを使うと左右２つのロータの合計推力は900gf程度となりますが、CW/CCWペア品の入手性が良くないのでこれに近い8"×3.8"プロペラを使います。消費電力が8.5A以下に収まることを見込んでEMAX D-Shot Bullet12A ESCを選定し、ティルト機構に固定します。この部分は強度が必要なので構造部材の印刷にPLA+を使います。右ローター用ティルト機構VTOLモードで機体が安定するよう重心の位置を調整しますが、固定翼モードに遷移すると重心が前に移動します。ホバリング用ロータと前進用ロータが分かれている機体なら重心をとるのが簡単なので、その点は羨ましいです。関連情報をネットで調べるうち、ドローンと呼べる代物かは別として無人航空機登録が避けられそうにない気がしてきました。管理のうえでもそろそろ機体に名前をつけようと思います。
13Sep
- VTOLドローンの制作（１）
  大枠が決まったので制作を始めます。とはいえ、飛ぶ保証はありません。ティルト機構を実装するとき、各部材の相対角度が重要になります。このためフレームに使う翼桁の断面を４mm角のカーボンチューブとします。この設計では左右の主翼用スパーに450mm×２本、テールブームに382mm×１本を使います。プロペラの回転軸を主翼の翼弦に一致させたいという構造上の理由により、主翼で翼桁を懸架する構造としました。カーボンチューブを高さ方向に24mm離してＴ字型に交差させます。メインフレームは取り付け角３度のNACA4412、翼幅40mmを冠したPLA製の軽量な構造体です。３Dプリンタの印刷可能範囲は180mm立方なので、翼を機能別に分けて印刷します。これらのパーツはΦ2mm×20mmステンレスピンを刺して接続します。サーボのプッシュプル・ロッドはサーボホーンが中立位置にあるとき、わずかに傾くようにします。水平に取り付けると、ロッドを突いた時に舵が逆方向に動くおそれがありますし、傾けすぎるとサーボ角によってロッドと舵面が干渉しやすくなります。下図は尾翼の場合ですが、主翼にも同様の工夫を施しています。ドローン上方からローターの回転方向を見ると回転方向が反対向きですので、プロペラはCW/CCW用のペアを手配する必要があります。モーター番号とサーボ名称は下図のとおりPWM出力ポートを割り当てます。今回制作するドローンはバイコプターモードと固定翼モードを行き来する垂直離着陸機です。トライコプターの後部ローターにあたるMotor 4を使用しませんが、ArduPilotはMotor 4の設定を済ませているかチェックしているため、とりあえず空きポートに割り当てておく必要があります。ArduPilot Planeの基本的なコンフィギュレーションパラメータは以下のようになります。 Q_ENABLE = 1 Q_TILT_ENABLE = 1 Q_TILT_MASK = 3（1+2） Q_TILT_TYPE = 2 （VectoredYaw） Q_FRAME_CLASS = 10（Single/Dual） Q_FRAME_TYPE = 4（V-Tail）MATEKSYS H743-WLITE フライトコントローラの場合、エルロン、ラダーベータ、ティルトモータ用サーボとプロペラ用モータのPWM出力を上部基板中央のポートに集約することができます。下の表ではSkyWalkerシリーズのPWMパルス幅をデフォルト値にしていますが、デジタルプロトコルであるDShot対応のＥＳＣを使う場合、モータのMin/Trim/Max設定値は無視されます。今回はDShot対応のEMAX BULLET 12A ESCを使用しますので、コンフィギュレーションパラメータQ_M_PWM_TYPE=6（DShot600）とします。MATEKSYS H743 WLITEにおいてはポート番号S7～S10までGroup3に割り当てられており、これら全てがDShot600に切り替わるため通常のPWM出力として使用できなくなります。使用する部品や機体の設計によってこれらの値は変わります。この表は筆者が備忘録として使っていますので、予告なく内容を書き換えることがあります。 Port No. Reverse Function Min Trim Max S3 1 Aileron 1000 1500 2000 S4 1 Aileron 1000 1500 2000 S5 0 VTailRight 1000 1500 2000 S6 1 VTailLeft 1000 1500 2000 S7 0 Motor 1 (右) 1000 1000 2000 S8 0 Motor 2 (左) 1000 1000 2000 S9 0 Motor 4 (不使用) 1000 1000 2000 S10 0 Disabled 1100 1500 1900 S11 0 TiltMotorFrontLeft 1000 1500 2000 S12 1 TiltMotorFrontRight 1000 1500 2000 S11とS12については以下のコンフィギュレーションパラメータによってティルト機構の揺動範囲を設定します。 Q_TILT_FIX_ANGLE = 15 Q_TILT_YAW_ANGLE = 15ティルト機構に可動範囲240度のサーボモーターを使用した場合、Mission PlannerのServo Output画面にてS11とS12のゲージ内数値が1125あるいは1875と表示されていればＯＫです。一つ一つの重量に気を遣いながら部品を作っていますが、推力と機体重量の兼ね合いで構造の変更と部品の再選定を繰り返すうちに徐々に大型化しています。仕様変更で組み立て済みのモジュールを破棄したり、納期のかかる部品を再注文して待たされたり、なかなか大変です。固定翼機は小さいプロペラでも対気速度を稼げば主翼の揚力で離陸することができますが、VTOL機は垂直離着陸時にプロペラ推力だけで機体重量を持ち上げる必要があります。固定翼モードではティルト機構の複雑さが負担となり、VTOLモードでは固定翼の重さが負担となります。VTOL機は推力重量比と航続時間のバランスを取るのがとても難しいことが分かります。ラジコンなりドローンなりを初めて設計するなら固定翼機かクワッドローター機から手をつけるべきだったのかも知れませんが、今から手戻りするのもなんですのでこのまま続けようと思います。
27Aug
- VTOLドローンの設計を検討する
  あれこれ調べるうちに何かドローンが作りたくなってきました。とはいえクワッドローター機では手応えがなさそうなので、V字尾翼を持つティルトローター型VTOL機を設計できるのか検討してみます。これはあくまで検討です。機体の制御にはArduPilot Planeを採用します。ローター径が大きすぎると室内での試運転がしづらく、小さすぎると推力不足で浮揚できません。上向きのプロペラだけで浮揚するバイコプターと違って主翼も必要ですので、機体が大きくなりすぎないように設計します。とはいえ機体重量が100g以上となるのは確実で、航空法の無人航空機に該当するため機体が組み上がれば機体登録が必要です。おおまかに以下の仕様を目指します。プロペラ：8"×3.8" 2B翼型：主翼 NACA4412，尾翼 NACA0012主翼寸法：翼幅840mm，翼弦長160mm，取り付け角2.5°，後退角0°，上反角0°尾翼寸法：翼幅360mm，翼弦長120mm/80mm，25%後退角10°，上反角35°主翼アスペクト比：5.25翼面荷重：48.4g/dm2VTOLモード最大離陸重量：650gf固定翼モード巡航速度：46km/h固定翼モード最高速度：60km/hレイノルズ数領域：～100,000フライトコントローラ：MATEKSYS H743-WLITEＧＰＳ/コンパス：FOXEER M10Q-120 V2無線通信方式：ExpressLRS小型から中型のVTOL機は一般的に、揚力を補助するため後方にもう一つローターをつけて合計３つ、あるいはそれ以上のローターを搭載しています。ですが、今回は実機のように２つのローターで浮揚させることを目標にします。駆動部が簡素になり機体を軽くできる反面、ピッチの制御が難しくなることが予想されます。VTOLモードではローターからのダウンウォッシュが主翼に当たるため、これによる揚力低下を警戒しなければいけません。ただ、同タイプの実機であるベル社の新型機V-280バローを見ると、エンジン出力に余裕があるからかローター半径は主翼面とまともに干渉しており、ダウンウォッシュによる悪影響をあまり気にしていないように見えます。NACA4412特性模型飛行機の主翼は下側がほぼ平面で製作しやすいClark Yが好まれていますが、今や３Ｄプリンタで自由な形を出力できますからこれに近いNACA4412を採用します。揚力だけを考えるとNACA6系に良いものがありますが、NACA6系は全体的に反りが大きくエルロンの操作に差し支えること、表面粗さを十分抑えないと性能を生かせないことなどから今後の課題としました。ネットを探していると評判の良い翼型をみかけることがありますが、airfoiltools.comで特性グラフを比較してもNACA4412より素直な翼型はなさそうに思えます。対気速度ゼロのVTOLモードから固定翼モードに移行する際にできるだけ早く主翼から揚力を得たいので、迎え角を2.5°と設定しています。主翼にエルロン用サーボモータを埋め込む設計のため、迎え角の調整は主翼の設計を見直す一大作業になります。主翼の対気速度が8.2km/hのときレイノルズ数Re=25000のグラフに相当し、迎え角2.5°で揚力係数CL=0.5を確保します。重量650gfの機体が対気速度が46km/hを超えると主翼の揚力で機体が上昇するようになります。水平尾翼容積係数VHは、主翼面積SW、主翼空力平均翼弦MAC、水平尾翼投影面積SH、モーメントアーム長lHとおくと以下のように求まります。VHは一般的に0.3～0.6の範囲と言われるため、これに収まるようモーメントアーム長lHを逆算しました。ティルト機構フライトの要となるローターのティルト機構には、回転角240°仕様のサーボモーターを使います。参考にした製品のPWMパルス幅は500～2500uSecですが、これはメーカーや型式によって仕様が異なるかも知れません。機体のヨー・ロール制御にモーター傾斜角±15°の幅を持たせるため、回転角90°仕様のサーボモーターは使えません。固定翼モードではローターを機体水平方向に向けますが、この時のPWMパルス幅は1125uSecです。VTOLモードでは機体を吊り上げるためパルス幅1850uSecで鉛直上向きとなります。機体反対側サーボモーターのパルス幅は上図と逆になります。フライトコントローラの設定により、出力パルス幅は1000～2000uSecの間で制御されます。以上でおおまかな方針が固まりましたが、本当にこの設計で飛ぶかは作ってみないと分かりません。
04Jul
- トランスウィングについての考察
  トランスウィングは、米国コロラド州のプテロダイナミクス社が開発した自律制御VTOL航空機です。左右主翼上に各２基のプロペラを備える固定翼機であるとともに、飛行中に主翼を折りたたむとクワッドコプターに変形し、垂直離着陸ができます。U.S. Navy photo by Chief Mass Communication Specialist John R. Fischer/Released, Public domain, via Wikimedia CommonsF-14トムキャットやV-22オスプレイのように、可変機構を備えた航空機は構造が複雑になり整備性が低下します。ですが同社のコンセプト実証機X-P4Transwing®はウィングスパン軸から45°傾けたヒンジを支点に主翼端部をロッドで押し引きして90°ピボットさせる簡素な機構で、故障率の低減に寄与しています。簡素な機構とはいえ特許を取得しているため、第三者がこれを真似ることはできません。特許上ではプロペラの駆動方式を限定しておらず電動でもターボプロップでも良いことから、将来的には小中大型機あらゆる機体サイズでラインナップが展開される可能性があります。実質的に固定翼機でありながら滑走路は不要で、小型機なら車輪式の着陸装置も必要ありません。着陸時点でプロペラも含めて機体がコンパクトに畳まれていることから、格納・輸送・展開がスピーディにおこなえるため運用効率は同クラスの固定翼機やクワッドコプターに勝ると言えます。クワッドコプター形態では４基のプロペラ推力だけで機体を浮揚させますが、固定翼形態に移行すれば主翼から揚力が得られるようになります。このため巡航時は２基のプロペラを休止することができ、一般的なクワッドコプターと比べてエネルギー効率が良いぶん巡航速度と航続距離を稼ぐことができます。仕組みの上では、万が一プロペラの半数が故障した場合、固定翼形態で生きているプロペラを始動するだけで飛行特性を損なうことなく適切な場所での軟着陸に持ち込むことができます。これは高価値物資、例えば輸血用血液製剤などを目的地まで”とにかく届ける”ことが約束できる点でロバスト性が高くミッションクリティカルな用件に適しています。米国海軍もこの機体の有用性を理解しており、遠洋航海中の艦艇への物資輸送に役立つものと期待して本格導入を目指しています。2024年のリムパック演習にてアーレイ・バーク級ミサイル駆逐艦カーティス・ウィルバーにて運用テストを行い、物流ミッションを遂行できることを実証しました。全ての国の海軍が同じ事情を抱えていますが、最新鋭のイージス艦といえど全てのシステムが万全な状態で任務に就いていることはないと言われています。比較的整備状態が良いとされる海上自衛隊においても、艦載システムの何割かは整備中だそうです。ですが整備に必要な交換部品はたいてい小さな部品やモジュールであり、それさえ手に入れば当該システムはすぐ復旧します。とはいえ小さな部品のために輸送ヘリを使うにもコストがかかりますし、着艦は艦艇の揺動で危険を伴うため、できればこんな微妙なミッションは避けたいところです。そういった輸送需要の９割をカバーする50lb(22.7kg)未満の小口貨物輸送に小回りの効くUAVが欲しい、という米海軍の要望に応えるための取り組みがX-P5 Transwing®です。ジェット燃料JP-5による電動ハイブリッドエンジンを搭載するX-P5は、最大積載量22.7kgで巡航速度129km/h、航続距離は740kmとなっています。740kmは東京都～山口県の距離にあたり、その半分の距離である東京都〜京都府間の370kmを無給油で往復できる計算です。370km即ち200nmは排他的経済水域ＥＥＺの半径にあたるので、適当な離島に補修部品のデポを設置すれば遠洋航行中の船舶に対する緊急輸送が可能になります。米海軍が要求している航続距離はこれが理由ではないかと推測します。本邦には狭隘な山間部集落や平坦地の少ない離島が点在しています。このためUAVには自律運航機能と垂直離着陸機能に加えて長距離巡航能力も求められますが、トランスウィングならこれに対応できます。プテロダイナミクス社は最大積載量280kgのX-P7の開発を考えており、いずれ中型貨物輸送のニーズにも対応したいようです。トランスウィングは独特な姿勢制御を除いて技術面の課題も欠点も見あたらないことから、価格が手頃なら自衛隊をはじめ民間にも意外と早く普及するのではないかと思います。
25Jun
- サイクロローターをつくる
  このブログではOpenFOAMでサイクロローターをシミュレーションしましたが、本当に360°推力偏向が実現できるのか気になったので実際に製作して確かめてみました。『サイクロローターの気流を可視化する』最近注目されているサイクロローター式eVTOL機について、回転翼がどういう動きをするものか不思議に思ったので少し調べてみました。元々はオーストリアの技術者エ…ameblo.jp回転中心とブレードの位置関係は以下の図で表されます。この図では翼型にCLARK Yを描いていますが、実際に回転させると円周方向に揚力が発生します。これは有害抗力にしかならず装置を振り回して壊してしまうだけですので、上下対称翼型を使うことにします。このためブレードの固定を容易にすることも含めてNACA0015と若干厚めの翼型を採用しました。翼弦長45mm、翼幅120mmです。実在するローターではブレード数は４枚から６枚と様々ですが、推力・抗力・重量にそれぞれ一長一短があるので中をとって５枚としました。この辺りの事情は一般的な航空機用プロペラと変わらないと思います。筆者の学生時代は製図にドラフターを使っていたため、五角形の機械を設計するのは本能的に避けたいほうですがCADのおかげで簡単に設計できるようになりました。筆者が持っている3Dプリンタの造形寸法は縦横高さ各180mmです。全ての部品がこの範囲に収まる必要があるので、FreeCADでサイズ感を検討してローター回転半径Rは70mm、支持間隔P-Mは20mm、オフセット半径eは9mmとしました。その結果コンロッドLは73.36mmとなりました。実機を作りたくなったもう一つの理由は、ローター内の障害物であるシャフトの直径を明らかにすることです。以前OpenFOAMでシミュレーションした時は４枚のブレードが雰囲気中をただ周回しただけでしたが、実際の機構では中心に邪魔なシャフトが存在します。このシャフトの直径が分かれば、将来的にもっと正確なシミュレーションができるでしょう。結果、この設計を通して構造上外径25mmのシャフトがローター中央に配置されることが分かりました。このたび制作したサイクロローターの風洞実験とOpenFOAMによるシミュレーションの条件を揃えることができたことになります。ローターの回転に使うブラシレスＤＣモーターは、実機のローター回転数領域である1200rpmオーバーを軽く出力します。ブレード角の制御にはステッピングモーターを使います。世界的に入手しやすい、良く知られている部品を選びました。これらをArduino Uno R3を使って制御します。ブラシレスＤＣモーター：D3536-750KVＥＳＣ（Electronic Speed Controller）：SKYWALKER 50A-UBECステッピングモーター：28BYJ-48 5VDCモータードライバボード：ULN2003AブラシレスＤＣモーターの最大出力は350W、2セルLipoバッテリーは7.4Vなので350/7.4=47.3AよりＥＳＣの容量は50Aクラスとなります。50A-UBECは同じ電流容量50Aで新機能が追加された新モデルV2が出回っていますが、旧モデルを使用しています。一見、上位互換のように見えますが旧モデルは2〜4S Lipo対応、V2は3〜4S Lipo対応と仕様が違いますので手配する時に注意が必要です。プーリー穴径の都合により軸径5mmでKV値の最も低い型式を選定しましたがこれでも速すぎるので、2GTプーリーを駆動側40T：従動側80Tとしてローター回転数を半減しています。タイミングベルトには幅6mm×周長220mmを使用し、軸間距離は計算によって48.5mmと求まりました。というわけで、必要な部品を作って組み上がった実験装置がこれです。前回の投稿で３Ｄプリンタで生成可能な標準フレームSPF1616を考案したのは、実のところこのプロジェクトのためでした。モーターのマウント位置を微調整するためにフレームのスリットを活用しています。Five-bladecyclorotor,Designed by kirimaru 2025手作りの実験装置とはいえ、風圧を感じられるほどの高速回転が求められます。このためローターがスムーズに回転するよう各シャフトにベアリングを入れてあります。各ブレードに直径2mm×18mmのステンレスピン３本を立て、それぞれミニチュアベアリング682ZZで保持します。直径8mmの内部シャフト両側に配したDDLF-1280ZZでローターシャフトの同心円上に保持します。ローター本体は6704ZZの２個使いでＴ型ベアリングホルダーが片持ちします。スケッチとピン配置は以下のGitHubリポジトリを参照してください。projects/cyclodevice/crf_control/crf_control.ino at main · kirinote/projectsMy miscellaneous projects. Contribute to kirinote/projects development by creating an account on GitHub.github.comArduinoには5Vを分圧する10kΩBカーブ可変抵抗RK09K1130AAUを２個接続しており、A0ピンに入力した可変抵抗”JOG”でブレード角θの制御、A1ピンに入力した可変抵抗”VOL”でローターの回転数を制御します。ユニバーサル基板には可変抵抗の他に0.91インチOLEDディスプレイを載せており、I2C通信で制御します。赤黒線はドライバ基板への5V電源供給です。実験装置の操作手順を示します。 ArduinoとＥＳＣの電源が切れていることを確認します。ＥＳＣの電源はまだ入れないでください。 Arduinoの電源を入れ、２つのツマミを最小、CCW方向一杯に絞ります。ローターが突然動かないよう、ツマミの原点復帰を確認するまでプログラムが待機します。ＥＳＣの電源を入れ、中立までJOGツマミをCW方向に回します。この操作で待機状態が解除され、続いてスロットル信号の最大幅と最小幅をＥＳＣに学習させます。ディスプレイが運転モードの表示に移行したら、VOLツマミを少しずつCW方向へ回します。ローターが回転を始めます。 JOGツマミをCCW方向／CW方向にある程度まで回すと、ブレード角が変化します。ツマミを中立に戻すとそこでブレード角が保持されます。このＥＳＣは、スロットル制御範囲がパルス幅1100〜1940uSecと規定されています。VOLが最小にあるときこれを下回るパルス幅1000uSecが出力され、ローターは回転しません。　D6ピン出力：スロットル校正信号 2000uSec → 1000uSecD6ピン出力：スロットル周波数 50HzVOLをCW方向にゆっくり回すとローターはゆっくり回転を始め、さらに回すと回転数が上がります。モーターの回転方向が逆のときはモーター端子U、V、Wのうち２つの結線を入れ替えると反転できます。ドローンではバッテリーを使用しますが、これは実験ですので正確に7.4Vを供給するため定電圧電源を使用しました。モーター起動時の突入電流が大きいため、過電流保護の閾値を1Aに設定しました。バッテリーを使用すると回転数が安定しないかも知れません。ＥＳＣへの供給電力（参考）実験１：ブレード角可変機構の動作確認実験２：ローターとブレード機構を組み合わせての動作確認実験室は無風ですが、回転中のローターに手を近づけると充分に風を感じます。ブレード角を変えるとこの排気方向も刻々と変化するのが感じられ、この仕組みによって推力を全周方向に可変できることが確認できました。ここまでやると水溶性グリコールによる煙流線などを駆使してどうにか可視化したくなりますが、実際にやろうとするとなかなか大変です。何か良い方法がないか探してみようと思います。サイクロローターを搭載した中型eVTOLの研究はCycloTech社が先行していますが、同社のブレード角可変機構はコンロッドを保持する円形ハブがローター回転軸から自在にオフセットすることで推力方向を瞬時に可変させることができます。これに比べて筆者の採用した古典的なクランク方式は、部品配置が軸対称となっておらず偏心による振動がどうしても生じます。また推力を180°偏向させたいとき、姿勢を制御するうえで少しでも無難な推力方向を勘案してクランクの遷移にCCWまたはCWのどちらでいくべきか決める必要があります。遷移が完了するまで余計な方向への推力が生じ、つまりは安定性も応答性も劣ると言えます。CycloTech社の機構は、推力方向がニュートラルのとき部品の重量バランスがとれる点がとても魅力的に映ります。
28Apr
- 標準構造部材をつくる
  筆者はよく３Ｄプリンタで色々なものを作っています。ミニチュアの実験装置ぽいものを作るときに、構造部材が欲しくなったので通販で買おうかなと思って探しましたが、安くて使い勝手の良さそうなものが見当たりません。見た目が良く、軽量で、頑丈そうな構造部材。３Ｄプリンタで都度作ればいいことですが、とはいえ車輪の再発明はしたくありません。イメージしたものがないか探したところ、こんなのがありました。3D printed beam that is as stiff as steel | RepRap LtdA while ago Naomi Wu 机械妖姬 very kindly sent us one of Creality's infinite-Z belt printers. Lots of people have printed long I beams on this type of machine, but we thought that we'd…reprapltd.comブレース構造ですね。なかなか頑丈そうですが、ちょっと大げさかな？結局、これでいいやというものが見つからなかったので自分で設計することにしました。別に大したものじゃないんですけどね。で、考案したのが標準PLAフレーム16mm x 16mm - SPF1616です。今回はスクリプトを記述してモデリングを行えるOpenSCADを使用します。コンセプトは押し出しアルミフレームと同じです。スクリプトの行頭で定義している変数Lengthを必要な長さに調整することで、任意の全長の構造部材が生成されます。OpenSCADの画面で[Design]-[Render F6]でレンダリングし、[File]-[Export]-[Export as STL... F7]を押してSTLデータを書き出します。３Ｄモデルとしてはやや小ぶりですので、正確に形状を印刷するため100mm/s程度の低速で印刷してください。設定のついでに加速度も下げたほうが良いでしょう。一般に３Ｄプリンタは、ノズル径が0.4mmとなっています。各部の寸法を0.4mmの倍数にとったとき最も密にパスを描きます。強度上やむを得ない部分を除いて、できるだけこの原則に沿って各部の寸法を決めました。現在手に入る最小のフレームはミスミさんの15mm角アルミフレームですが、16mm角にしたのはスライサが得意とする寸法としたかったからです。2mm厚の固定金具を両側に取り付けると構造部の最大幅が20mmとなり、構造の検討が簡単になります。SPF1616 断面寸法図筆者は、ちょっとした工作で最も使われる締結ソリューションはＭ３ネジ／ナットだと考えています。SPF1616は溝にＭ３ナットを通すことでどの位置でもネジ固定できます。溝深さ4.4mmにつき、板厚2mmの取り付けにＭ３×６が使えます。フレームの中央に直径4.6mmの丸穴があり、これはAmazonで容易に手に入るuxcellのＭ３インサートナットの挿入に適した外径としています。穴にインサートナットを立て、熱したハンダごてで突くとゆっくり沈んでいきます。この直径も全長と同じく変数HoleDiaで再定義できます。実際に手に取ると、構造部材がPLAでできているだけで軽量感があります。卓上実験装置を作りたいとき、フレームとしては最小クラスとされる15mm角アルミフレームでもまだ大袈裟なときに役立つかなと思います。作ったスクリプトをGitHubに置いておきます。このコンセプトを気に入った方がこれに合う金具や構造部材を作ってシェアしてくれると嬉しいです。3d-models/SPF1616 at main · kirinote/3d-modelsContribute to kirinote/3d-models development by creating an account on GitHub.github.comMakerWorldにも置いておきました。こちらではOpenSCADをインストールせず、Web上で寸法をカスタマイズしてモデルデータをダウンロードすることができます。https://makerworld.com/ja/models/1366991-standard-pla-frame-16mm-x-16mm-spf1616
04Apr
- geditの使い心地を良くする
  Ubuntu 24.04のテキストエディタについてこちらで書いたとおりgeditを使いはじめたのですが、徐々に違和感を覚えるようになってきたので思い切って対策しました。この記事で対策したのはgedit 46.2です。違和感その１：句読点が上にずれるデフォルトだと特定の条件が揃うと日本語入力時に句読点が上にずれるという怪現象が起きるので、これを対策、もとい回避しました。この問題をネット検索するとこれで症状が治まりましたという報告は出てくるのですが、結局今現在は対策されたのされてないの、という結果報告的な投稿が見当たりません。唯一見つかったのはこちらの報告で、バグは認識しているが修正コストが結果と釣り合わないため処置しないこととした（ステータス：won't fix）ということです。この記事の不具合がこれと原因が同じだと、今後もgeditのデフォルト設定がUbuntu Sans Monoであるかぎり同じ現象に首を傾げる人が出てきそうです。結局、HackGenを採用することで句読点の問題は解消しました。HackGenは実績ある日本語プログラミング用フォントのひとつで、個人の好みでその派生タイプであるHackGen35 Regularを選定しました。文字幅比率半角3：全角5とすることでソースコード部分の読みやすさに重点を置いたバージョンです。OpenFOAMのコードは一行あたりの単語数が少なめです。代わりに説明的なパラメータが多く、文字列は長めです。アスキーアートとは無縁ですし、日本語のコメントも少ないことから、文字幅が揃わなくてもいいので半角英数をゆったり読みたいというのが理由の一つです。ＩＭＥを変更したり内部設定を触ることもなくフォント変更で症状が治まり、ついでに他に気になっていた事柄も一気に解決したのでこれで良しとします。違和感その２：配色がきついデフォルトで収録されているカラースキームがどれも色がきつめなのが気になっていました。どれに切り替えても「欧米か！」とツッコみたくなるようなテイストが漂っています。日本にカラースキームを積極的に提案する人が少ないのが理由だと思いますが、テキストファイルは長時間編集するのでとにかく目への負担は減らしたいところです。というわけで、パパッとカラースキームを変更できそうなプラグインを探しました。GeditSchemerというプラグインがあるものの、残念ながら現行のgeditには対応しておらず動きませんでした。仕方ないので既存のテーマ.xmlを調整しようとしたところ、色の名前がピンク、イエロー、パープル、シアンなど原色ばかり定義されていて色使いのセンスがまるでないことが判りました。これではいくら探しても目に優しいテーマなど見つかるはずがありません。海外には日本のように奥深い色彩文化がないらしいので仕方ありません。そこで、こちらで紹介されている日本の伝統色のRGBデータをカラースキームファイルに登録し、和名で指定することにしました。このような素晴らしい色彩情報を公開いただいたことに感謝です。これを新規作成したファイルkiri.xmlにペーストして、以下のフォルダに配置してください。フォルダ.localは隠しフォルダですので、ファイルブラウザでホームフォルダへ移動し [Ctrl]+h キーを押して出現させてください。/home/user/.local/share/gedit/stylesgeditを再起動すると、バーガーメニュー > Preferences > Font & Colors > Color Schemeにてカラースキーム"Kiri"が選べるようになります。これでOpenFOAMのケースファイルを開くと、以下のようなルック＆フィールになります。コメントと行番号は、普段は気にしないで良いようにかなり暗くしました。シャープで始まる行はコメントとしますが、シェバンは例外でテキスト扱いとしています。テキストは白を若干暗くして目の負担を軽減し、カーソルを本来の白としています。数値と真偽値は落ち着いた色味としています。とはいえ色使いは個人の好みによります。伝統色のRGB値は全て定義してあるので、色を変えたいときはこちらのサイトを見ながら色名で指定することができます。XMLファイルはGitHubより入手してください。GitHub - kirinote/gedit-themesContribute to kirinote/gedit-themes development by creating an account on GitHub.github.com
31Mar
- サイクロローターの気流を可視化する
  最近注目されているサイクロローター式eVTOL機について、回転翼がどういう動きをするものか不思議に思ったので少し調べてみました。元々はオーストリアの技術者エルンスト・シュナイダー氏が実用化したもので、フォイト・シュナイダープロペラと呼ばれ船舶分野で先行していた推力偏向技術です。理論そのものは古くから知られていたもののあまり評判は良くなかったらしく、高度な機構制御ができる時代になってようやく航空分野に持ち込まれたようです。動作原理についてはWikipediaをご覧ください。Cyclorotor - Wikipediaen.wikipedia.org典型的な設計では４枚あるいは６枚の翼が円周上に配置され、クランク機構によって特定の角度で迎角が大きく振れるようになっています。これによって水泳のクロールのように空気を力強く掻き込むような動きを実現しており、推力に寄与しないストロークポジションでは抗力を最小化するよう翼列が水平となります。ネット検索すると論文がいくつか出てくるのですが、興味深い研究が見つかったので読んでみました。それがポーランドのシレジア工科大学動力工学ターボ機械学科による研究です。Influence of Geometrical Parameters on the Shape of the Cycloidal Function Curve of a Fan with a Cycloidal Rotorこの研究では翼弦長50mmの翼型CLARK Yを使用して風洞実験を行っています。諸元がすべて明らかになっているので、OpenFOAMでのシミュレーションに利用できそうです。諸元の確認クランク機構を理解するためには、各部の角度と寸法を規定しなければいけません。この論文では以下のように定義してあります。Oは回転中心、Pは翼の旋回中心で翼弦長50%位置、Rはローター半径、MはコンロッドLの取り付け位置です。eがオフセットリンクで、この角度が推力方向の制御に用いられます。eの角度と機構全体が生ずる推力／揚力方向との関係性を求めるには多くの計算が必要のように思います。aは途中計算に必要なP-E間の距離を示し、以下の数式で求まります。途中式をすっ飛ばして、必要な翼の角度θは以下のサイクロイド関数で求まります。回転数が与えられたとき、ある時刻における４枚の翼それぞれの迎角が求まります。論文によるとLabVIEWで各部寸法を検討した結果、R=70mmにおいてe=13mm、ε=292deg、d=27mm、L=74mmとなったとのことです。これらの数値を無からひねりだす過程が彼らの研究のハイライトと言えるでしょう。残るaは式(3)にローター角度ψを与えることで求まります。式(6)に出揃った変数を代入すれば、欲しかった角度θが求まります。シミュレーションの準備各要素の位置関係が分かったので準備を始めます。今回はESI版のOpenFOAM v2406を使います。インストールの方法はこちらをご覧ください。ゼロからケースファイルを作成するのは大変なので、テンプレートとなるケースを導入します。イタリアはジェノバ大学からのスピンオフ企業Wolf Dynamics社が公開しているオーバーセット・メッシュのチュートリアルをこちらから辿って入手します。ファイル名はdynamicMeshes_2025_clean.tar.gzです。この圧縮ファイルを解凍し、ケースファイルfoil_shmmeshと座標生成ユーティリティgen6DoFを$FOAM_RUNにコピーして動作することを確認しておきます。このケースはふらつきのある翼に生じる力係数を求めるためのものですが、オーバーセット・メッシュ対応の非定常圧縮性流体ソルバーpimpleDyMFoamを利用しており今回のシミュレーションの出発点とするのに最適であろうと判断しました。なお、ケースファイルの実行に先立ちrun_solver.shの最後にreconstructParコマンドが抜けているので追記する必要があります。このチュートリアルでは領域左側のinletから流速1m/sの空気を流していますが、今回のシミュレーションでは流速Uを0m/s、すなわち無風状態でローターがどのように空気をかき混ぜるかを見ます。もちろん、流速Uを書き換えればローターに風を当てることもできます。参照した論文ではローター回転速度1000rpmで風洞実験していますが、迎角を計算しやすくするため1200rpmでシミュレーションします。他の論文ではほぼ同じ大きさのローターを1400rpmで回転させて模型を飛ばしていることから、この辺りの回転数で検証するのが妥当であろうと思います。翼の周速度V[m/s]は以下の公式で求めます。直径D[mm]、回転数N[rpm]とすると、V = π * D * N / (1000 * 60) = π * 140 * 1200 / (1000 * 60) = 8.79[m/s]となります。翼の代表長さ0.05m、高度0kmのとき、レイノルズ数は30094となります。ちなみにヤマトホールディングス社とサイクロテック社が共同開発している中型eVTOL機CCY-01の資料によれば、ローター半径0.25m、回転数2600rpm、巡航速度120km/hとのことです。この場合翼の周速度は68.07m/sとなり、これが120km/hすなわち33.33m/sで飛行すると翼の速度は101.4m/sにもなるのでいよいよ空気を圧縮性流体とみなす必要があります。翼型STLモデル作成FreeCADを使ってこちらの手順でCLARK Y翼型を作成します。翼弦上の中央をモデル原点とし、翼弦長50mm、TOP方向すなわちZ軸方向に±125mm（翼幅250mm）押し出しておきます。TOP方向から見て0deg、180deg、90deg、270degの順番で回転させた４パターンを作成し、それぞれclarky1.ast、clarky2.ast、clarky3.ast、clarky4.astを書き出し、拡張子を.stlに変更します。できたSTLファイルをエディタで開き、行頭のsolidと行末のendsolidをMeshからairfoilに書き換えます。この辺りの事情はこちらとこちらをご覧ください。ケースファイルの編集フォルダfoil_shmmeshをcycloidにリネームし、以後このケースファイルcycloidを編集していきます。フォルダairfoilをairfoil1にリネームし、これと同じ内容のフォルダairfoil2、airfoil3、airfoil4を複製します。続いて、これらのフォルダ配下のconstant/triSurfaceに入っていたairfoil.stlを削除し、先ほど作成したclarky*.stlとそれぞれ番号を合わせて差し替えます。airfoil*の編集まずairfoil*の初期位置を示します。水色がairfoil1、灰色がairfoil2、橙色がairfoil3、茜色がairfoil4です。これらはセルセット番号、ゾーンＩＤとも数字を一致させます。airfoil*のblockMeshDictでは、翼弦長50mmの翼型を覆うメッシュを切ります。長辺80mm、短辺40mmとします。airfoil1とairfoil2は横長、airfoil3とairfoil4は縦長のそれぞれ同じメッシュ寸法になります。例）airfoil1, airfoil2vertices( (-0.04 -0.02 -0.025) ( 0.04 -0.02 -0.025) ( 0.04 0.02 -0.025) (-0.04 0.02 -0.025) (-0.04 -0.02 0.025) ( 0.04 -0.02 0.025) ( 0.04 0.02 0.025) (-0.04 0.02 0.025));blocks( hex (0 1 2 3 4 5 6 7) (40 20 1) simpleGrading (1 1 1));例）airfoil3, airfoil4vertices( (-0.02 -0.04 -0.025) ( 0.02 -0.04 -0.025) ( 0.02 0.04 -0.025) (-0.02 0.04 -0.025) (-0.02 -0.04 0.025) ( 0.02 -0.04 0.025) ( 0.02 0.04 0.025) (-0.02 0.04 0.025));blocks( hex (0 1 2 3 4 5 6 7) (20 40 1) simpleGrading (1 1 1));続いて、airfoil*のsnappyHexMeshが参照するSTLファイル名とnameを書き換えます。nameはwingからwing*となります。例）geometory{ "clarky1.stl" { type triSurfaceMesh; name wing1; }}また、locationInMeshの値はairfoil*全てが異なります。これらは軸対称に配置されるので、翼型を覆うメッシュの隅をどれも同じように狙っています。airfoil1: (-0.039 0 0)airfoil2: (0.039 0 0)airfoil3: (0 -0.039 0)airfoil4: (0 0.039 0)フォルダairfoil*配下のファイル編集はこれで終わりです。できたメッシュは後の工程でしか見られませんが、参考までにメッシュを切ったairfoil1を見てみます。メッシュの中心がY軸方向に70mmオフセットされていることが分かります。backGround/0, backGround/0_orgの編集先ほどサーフェスメッシュ名wingをwing*と書き換えました。これに伴い、フォルダ0と0_orgで定義されているwingについて、境界条件はそのままにwing*を書き加えます。ファイルを見れば何をすべきか分かると思いますが、修正箇所が多いので見落としのないようにしてください。なおファイルzoneIDは他のファイルと定義の仕方が異なっているので、以下のように修正します。"(inlet|outlet|topAndBottom|wing1|wing2|wing3|wing4)"{ type zeroGradient;}backGround/systemの編集領域backGroundはX軸、Y軸とも0.5mの正方形、Z軸は0.05mのメッシュとします。blockMeshDictを以下のように修正します。vertices( (-0.25 -0.25 -0.025) ( 0.25 -0.25 -0.025) ( 0.25 0.25 -0.025) (-0.25 0.25 -0.025) (-0.25 -0.25 0.025) ( 0.25 -0.25 0.025) ( 0.25 0.25 0.025) (-0.25 0.25 0.025));blocks( hex (0 1 2 3 4 5 6 7) (100 100 1) simpleGrading (1 1 1));続いて、controlDictを以下のように編集します。修正すべき行はバラバラですが列挙します。endTime 1;writeInterval 0.001;maxCo 4; // 最大クーラン数。ここでは変更しませんが必要に応じて変更のことpatches ("wing1" "wing2" "wing3" "wing4"); // この行は２か所ありますlibs ("libutilityFunctionObjects.so"); // 242行目、旧書式のため新書式に更新最大クーラン数は、条件を試行錯誤するうちは６程度まで上げて計算を早く済ませ、うまく解析できそうなら段階的に下げます。時間がかかっても信頼できる結果を得たいのであれば１まで下げることになります。続いて、setFieldDictとtopoSetDict_movingZoneを編集します。チュートリアルではゾーンは背景の0と翼の1しかありませんでしたが、翼が４つに増えたのでzone IDは4まで必要です。もちろんセルセットもc4、movingZoneも4まで必要です。これらの修正方法はファイルを見れば分かるので例示しません。続いて、topoSetDictを編集します。このファイルでzone IDを割り当てる領域を特定します。insidePointsは翼の初期角度を多少振っても領域を逸脱しない場所を指定しています。actionsだけ抜き出します。actions( { // 全領域をc0とする name c0; type cellSet; action new; source regionToCell; sourceInfo { insidePoints ((-0.249 -0.249 0)); } } { // c0を複製してc1を作成する name c1; type cellSet; action new; source cellToCell; sourceInfo { set c0; } } { // c0以外の領域をc1とする name c1; type cellSet; action invert; } { // c1の中にc2を作成する name c2; type cellSet; action new; source regionsToCell; sourceInfo { // c2領域を指定 insidePoints ((0 -0.065 0)); set c1; } } { // c1からc2を除外する name c1; type cellSet; action delete; source cellToCell; sourceInfo { set c2; } } { // c1の中にc3を作成する name c3; type cellSet; action new; source regionsToCell; sourceInfo { // c3領域を指定 insidePoints ((-0.065 0 0)); set c1; } } { // c1からc3を除外する name c1; type cellSet; action delete; source cellToCell; sourceInfo { set c3; } } { // c1の中にc4を作成 name c4; type cellSet; action new; source regionsToCell; sourceInfo { // c4領域を指定 insidePoints ((0.065 0 0)); set c1; } } { // c1からc4を除外する name c1; type cellSet; action delete; source cellToCell; sourceInfo { set c4; } });以上でairfoil*の編集で示した画像の通りzone IDが割り当てられます。backGround/constantの編集まず、dynamicMeshDictを開くとmovingZoneが設定してあります。翼４つ分必要ですので、movingZone1〜movingZone4まで用意します。また、各翼のモーション制御を個別で行いますので、後に生成するモーション座標データ6DoF1.dat〜6DoF4.datを各movingZoneに指定します。設定項目内のCofGはCenter of Gravityすなわち重心座標ですが、ここではモーションの原点座標になります。これは各movingZoneごとに座標が異なります。movingZone1: CofG (0 0.07 0)movingZone2: CofG (0 -0.07 0)movingZone3: CofG (-0.07 0 0)movingZone4: CofG (0.07 0 0)それ以外の編集箇所はファイルを見れば分かりますので例示しません。チュートリアルで使用したモーションデータ6DoF.datは必要ありませんので削除してください。代わりにここに置く翼４つ分のモーションデータをこれから生成します。gen6DoFの編集フォルダcycloidと共に扱うフォルダgen6DoFについて説明します。gen6DoFは、６自由度のモーションデータを生成するプログラムです。C++言語でユーザーオリジナルのプログラムを組んでコンパイル＆ビルドすることができます。このgen6DoFを実行するとデータファイルを書き出します。フォーマットは行頭でデータ点数を宣言した後、各行は時刻 - 並進移動量 - 回転量の順となります。テキストエディタでデータファイルを見るとこのようになっています。数学関数にOpenFOAM独自のものを使用するため、その流儀に従ってプログラミングする必要があります。このソースコードはローター回転数1200rpmを前提として1mSecごと1秒間分のモーションデータ1000点を出力します。このケースで使用するソースコードgen6DoF.cを以下に示します。#include "List.H"#include "vector.H"#include "Vector2D.H"#include "Tuple2.H"#include "OFstream.H"#include "mathematicalConstants.H"using namespace Foam;// Variables for this case:// Rotor radius [m]const scalar R = 0.070;// Tension member length [m]const scalar L = 0.074;// Tension member fixed length from blade pivoting point [m]const scalar d = 0.027;// Shift arm length [m]const scalar e = 0.013;// Eccentric phase angle ε [deg]const scalar epsilon = 292;// Blade inclination angle θ [deg]scalar theta;// Position of the rotor blade ψ [deg]//scalar psi;// Distance between shift arm and blade pivoting point [m]scalar a;scalar angleCalc1(const scalar& rotAmpZ, const scalar& t){ scalar psi_rad = ((rotAmpZ * t * 20) + 270) * M_PI/180; scalar epsilon_rad = epsilon * M_PI/180; scalar theta_rad; scalar a_sq; a_sq = e*e + R*R - 2*e*R * Foam::cos(psi_rad + epsilon_rad + M_PI/2); a = Foam::sqrt(a_sq); theta_rad = (M_PI/2) - Foam::asin((e/a) * Foam::cos(psi_rad + epsilon_rad)) - Foam::acos((a*a + d*d - L*L)/(2*a*d)); theta = theta_rad * 180/M_PI; return rotAmpZ * t * 20 + theta;}scalar angleCalc2(const scalar& rotAmpZ, const scalar& t){ scalar psi_rad = ((rotAmpZ * t * 20) + 90) * M_PI/180; scalar epsilon_rad = epsilon * M_PI/180; scalar theta_rad; scalar a_sq; a_sq = e*e + R*R - 2*e*R * Foam::cos(psi_rad + epsilon_rad + M_PI/2); a = Foam::sqrt(a_sq); theta_rad = (M_PI/2) - Foam::asin((e/a) * Foam::cos(psi_rad + epsilon_rad)) - Foam::acos((a*a + d*d - L*L)/(2*a*d)); theta = theta_rad * 180/M_PI; return rotAmpZ * t * 20 + theta;}scalar angleCalc3(const scalar& rotAmpZ, const scalar& t){ scalar psi_rad = ((rotAmpZ * t * 20) + 0) * M_PI/180; scalar epsilon_rad = epsilon * M_PI/180; scalar theta_rad; scalar a_sq; a_sq = e*e + R*R - 2*e*R * Foam::cos(psi_rad + epsilon_rad + M_PI/2); a = Foam::sqrt(a_sq); theta_rad = (M_PI/2) - Foam::asin((e/a) * Foam::cos(psi_rad + epsilon_rad)) - Foam::acos((a*a + d*d - L*L)/(2*a*d)); theta = theta_rad * 180/M_PI; return rotAmpZ * t * 20 + theta;}scalar angleCalc4(const scalar& rotAmpZ, const scalar& t){ scalar psi_rad = ((rotAmpZ * t * 20) + 180) * M_PI/180; scalar epsilon_rad = epsilon * M_PI/180; scalar theta_rad; scalar a_sq; a_sq = e*e + R*R - 2*e*R * Foam::cos(psi_rad + epsilon_rad + M_PI/2); a = Foam::sqrt(a_sq); theta_rad = (M_PI/2) - Foam::asin((e/a) * Foam::cos(psi_rad + epsilon_rad)) - Foam::acos((a*a + d*d - L*L)/(2*a*d)); theta = theta_rad * 180/M_PI; return rotAmpZ * t * 20 + theta;}int main(int argc, char *argv[]){ // End-time of the table [sec] const scalar endTime = 1; // Number of entries in the table const label nTimes = 1000; // Amplitude of the translation [m] const vector transAmp(0.07, 0.07, 0); // Frequency of the translation [rad/s] const vector transOmega(125.6637, 125.6637, 0); // 1200 rpm // Amplitude of the rotation [deg] const vector rotAmp(0, 0, 360); // Frequency of the rotation [rad/s] const vector rotOmega(0, 0, 0); List<Tuple2<scalar, Vector2D<vector>>> timeValues(nTimes); forAll(timeValues, i) { scalar t = (endTime*i)/(nTimes - 1); timeValues[i].first() = t; timeValues[i].second()[0] = vector ( transAmp.x()*Foam::sin(transOmega.x()*t) * -1, transAmp.y()*Foam::cos(transOmega.y()*t) - 0.07, transAmp.z()*Foam::sin(transOmega.z()*t) ); timeValues[i].second()[1] = vector ( rotAmp.x()*Foam::sin(rotOmega.x()*t), rotAmp.y()*Foam::sin(rotOmega.y()*t), angleCalc1(rotAmp.z(), t) ); } { OFstream dataFile("6DoF1.dat"); dataFile.precision(6); dataFile.setf(std::ios::fixed); dataFile << timeValues << endl; } forAll(timeValues, i) { scalar t = (endTime*i)/(nTimes - 1); timeValues[i].first() = t; timeValues[i].second()[0] = vector ( transAmp.x()*Foam::sin(transOmega.x()*t), transAmp.y()*Foam::cos(transOmega.y()*t) * -1 + 0.07, transAmp.z()*Foam::sin(transOmega.z()*t) ); timeValues[i].second()[1] = vector ( rotAmp.x()*Foam::sin(rotOmega.x()*t), rotAmp.y()*Foam::sin(rotOmega.y()*t), angleCalc2(rotAmp.z(), t) ); } { OFstream dataFile("6DoF2.dat"); dataFile.precision(6); dataFile.setf(std::ios::fixed); dataFile << timeValues << endl; } forAll(timeValues, i) { scalar t = (endTime*i)/(nTimes - 1); timeValues[i].first() = t; timeValues[i].second()[0] = vector ( transAmp.x()*Foam::cos(transOmega.x()*t) * -1 + 0.07, transAmp.y()*Foam::sin(transOmega.y()*t) * -1, transAmp.z()*Foam::sin(transOmega.z()*t) ); timeValues[i].second()[1] = vector ( rotAmp.x()*Foam::sin(rotOmega.x()*t), rotAmp.y()*Foam::sin(rotOmega.y()*t), angleCalc3(rotAmp.z(), t) ); } { OFstream dataFile("6DoF3.dat"); dataFile.precision(6); dataFile.setf(std::ios::fixed); dataFile << timeValues << endl; } forAll(timeValues, i) { scalar t = (endTime*i)/(nTimes - 1); timeValues[i].first() = t; timeValues[i].second()[0] = vector ( transAmp.x()*Foam::cos(transOmega.x()*t) - 0.07, transAmp.y()*Foam::sin(transOmega.y()*t), transAmp.z()*Foam::sin(transOmega.z()*t) ); timeValues[i].second()[1] = vector ( rotAmp.x()*Foam::sin(rotOmega.x()*t), rotAmp.y()*Foam::sin(rotOmega.y()*t), angleCalc4(rotAmp.z(), t) ); } { OFstream dataFile("6DoF4.dat"); dataFile.precision(6); dataFile.setf(std::ios::fixed); dataFile << timeValues << endl; } Info<< "End\n" << endl; return 0;}このプログラムでは、翼が70mmの半径で回転する動作にZ軸の回転を使わず、X軸とY軸の並進運動で表現しています。Z軸の回転は翼の角度を決めるのに使い、サブルーチンangleCalc*()で迎角θを計算して翼の回転角度ψに加算しています。angleCalc3()で計算したairfoil3の絶対角度をグラフに描くと以下のようになります。翼の水平姿勢との相対角度すなわち迎角θに注目した論文のグラフでは-cos波とそう変わらない波形に見えましたが、領域との絶対角度ψ+θで見るとクセのある動きをしていることが分かります。gen6DoF.cは以下のコマンドでコンパイル＆ビルドします。$ cd $FOAM_RUN$ cd gen6DoF$ wclean$ wmakeこれで$FOAM_USER_APPBINに実行ファイルgen6DoFが生成されます。$FOAM_USER_APPBINとはディレクトリで言うと~/OpenFOAM/user-v2406/platforms/linux64GccDPInt32Opt/binとなっています。では、このプログラムを実行します。$ cd $FOAM_USER_APPBIN$ ./gen6DoF同じ場所に6DoF1.dat, 6DoF2.dat, 6DoF3.dat, 6DoF4.datが一気に生成されます。これをbackGround/constantにコピー＆ペーストします。decomposeParDictの編集ケースファイルの至る所にCPUコアに領域を割り付けるdecomposeParDictがあります。これについてはユーザーの計算機によってnumberOfSubdomainsの並列数（=CPUコア数）は違いますし、XYZ軸それぞれの分割数nの設定も違ったものになります。解析にはとにかく時間が必要ですので、計算機の性能を活かせるように設定してください。スクリプトの編集コマンドをバッチ処理するBashシェルスクリプトについて説明します。初期状態でrun_all.sh, run_mesh.sh, run_solver.shの３つのスクリプトがあります。run_all.shは全てのプロセスを通しで実行するスクリプトで、実態はただrun_mesh.shとrun_solver.shを呼び出しているだけす。run_mesh.shはメッシュ作成のみ、run_solver.shは解析のみ行います。スクリプトを分けることで、うまく解析できない時に工程を切り分けて状況を確認することができます。run_solver.shでは変数nprocsで計算に使うコア数を指定しています。これもできるだけ多くのコア数を設定しておくと良いでしょう。run_mesh.shのコマンド列はこのケース独特のものになりますので以下に示します。#!/bin/bashcd airfoil1blockMeshsnappyHexMesh -overwrite | tee log.snappyHexMeshextrudeMeshcreatePatch -overwritetransformPoints -translate '(0 0.07 0)'cd ..cd airfoil2blockMeshsnappyHexMesh -overwrite | tee log.snappyHexMeshextrudeMeshcreatePatch -overwritetransformPoints -translate '(0 -0.07 0)'cd ..cd airfoil3blockMeshsnappyHexMesh -overwrite | tee log.snappyHexMeshextrudeMeshcreatePatch -overwritetransformPoints -translate '(-0.07 0 0)'cd ..cd airfoil4blockMeshsnappyHexMesh -overwrite | tee log.snappyHexMeshextrudeMeshcreatePatch -overwritetransformPoints -translate '(0.07 0 0)'cd ..cd backGroundblockMeshmergeMeshes . ../airfoil1 -overwritemergeMeshes . ../airfoil2 -overwritemergeMeshes . ../airfoil3 -overwritemergeMeshes . ../airfoil4 -overwritetopoSettopoSet -dict system/topoSetDict_movingZonerm -r 0cp -r 0_org 0checkMesh | tee log.checkMeshsetFields | tee log.setFieldscd ..スクリプトの編集は以上です。airfoil*はそれぞれメッシュを作成して領域を初期位置上下左右に70mm移動し、その結果をbackGroundのメッシュにマージします。このブログの最後で述べますが、このスクリプトで本来しておくべきtransformPoints -rotate-z <deg>は技術的な理由で省略しています。解析の実行今回の解析では手始めにinletから風を送り込まず無風状態0m/sでどう空気が流れるかを見ますので、backGround/0/UとbackGround/0_org/Uの2つのファイルを開き、以下のように編集します。internalField uniform (0 0 0);これでケースファイルの準備が全て整いました。以下のコマンドで解析を開始し、ParaViewで可視化します。$ cd $FOAM_RUN$ cd cycloid$ sh run_all.sh$ cd backGround$ paraFoamparaFoamで解析結果を可視化すると、無風の中1200rpmで回転するローターを1mSec刻みで観察することができます。流速Uを表示する際、ColoringのRescale to custom rangeを0〜20[m/s]に狭めると見やすくなります。しかしながら、翼をよく見ると本体が青っぽく表示され、周囲の色に溶け込んで外形が見づらくなっています。画像にいくつかフィルタを入れて見やすく加工します。Pipeline BrowserのbackGround.foamを選択して、SliceをZ Normal方向、ColoringをUとして追加します。OpenFOAMはこの解析を２Ｄとして計算しましたが、ParaViewはこれを３Dモデルと認識しており、何も処置しなければユーザーは六面体の側面を見ることになります。このまま翼形状をくり抜くと遠近法で翼の断面が見えてしまいますので、純粋に２Ｄ表示に戻すためにSliceしなければいけません。次いでThresholdを追加し、ScalarsをcellTypes、Lower Thresholdを0、Upper Thresholdを1.5、ColoringをUとします。ParaViewはcellTypesを表示することができますが、翼の部分のcellTypeが2となっていることが分かります。そこでThresholdを1.5以下とすることでcellType2の翼を表示から除外することができます。最終的にThreshold1だけを表示させると、翼がくり抜かれて流れがとても見やすくなります。このときの設定を以下に示します。では、ローターの回転を観察してみましょう。以下は1200rpmでローターを回して１秒が経過した時の様子です。流速分布流速グリフ表示 Scale Factor 0.004迎角はローターが領域左側で最大となるので空気は左側から流入して右側に流出するものと予想していましたが、シミュレーションによれば下側から多く流入して少し右上に流出する傾向にあることが分かりました。下流の流れは論文のFigure 16.に近い結果であり、ＣＦＤ、レーザードップラー流速計による実測結果とも傾向が一致しています。ところで、この解析の２ステップ目、つまりシミュレーション開始後1mSecの状態を見ると、airfoil3とairfoil4の回りに大きな流速が生じています。これは１ステップ目のairfoil3とairfoil4は初期配置の時に迎角をつけておらず、たった1mSecで角度が30度変化したために計算上このような結果が出たものと思われます。これを防ぐにはスクリプトにtransformPoints -rotate-z <deg>を追記して初期配置の段階で翼に迎角をつけておけばスムーズに始動できます。しかしその後の角度データ全てにオフセットをかけることになり、シミュレーションで最も重要なパラメータである迎角を直感的に捉えることができなくなります。とはいえローターを１秒間も回せばその影響は消え去るようですので、初期配置の段階で迎角をつけないことにしました。連続的にステップを観察すると、下流側の翼が気流を乱しがちなのが分かります。論文によればコンロッドの取り付け位置であるdを変化させると上流側と下流側の最大迎角に差をつけることができます。下流側の翼がもう少し良い角度で気流に相対するよう、dあるいは翼弦長の50%としたPを調整すれば効率を改善できるかも知れません。改めて論文を読むと、最適なPの位置は翼弦長の35〜50%としか書いていませんので彼らも翼弦長50%がベストではないと考えているようです。なお、様々な研究によりサイクロローターが生み出す推力は翼の揚力によるもので、その方向は気流の方向と一致しないことが分かっています。以上で、サイクロローターが生み出す気流を可視化することができました。簡略化のため論文で言及されていた領域中央のφ15mmシャフトの存在は考慮しませんでしたが、このケースの手法は６枚ローター、独特なサイクロイド関数、有人機クラスの機体にも適用できると思います。翼と力の働く方向の関係を整理しやすいように翼の初期位置を決めたにも関わらず複雑な気流を生み出すことから、プロペラやジェットエンジンと違って力の働く方向は実験的に求める必要があるだろうなという印象を受けました。追記後日、解析領域を1m四方に拡げて計算しました。左側より1m/sの風を入力し、ローターを1200rpmで10秒間回転させました。気流は左側から流入するようになりましたが、右斜め上に流出する傾向は変わりません。ローターの上側は至って穏やかなようです。こんなケースファイルでも欲しい方がいらっしゃるようですので、GitHubに置いておきました。これはあくまで趣味であり、シミュレーションの正確性は追求していませんのでご了承ください。ケースファイルの設定はこの記事と異なり、inletから1m/sの風を入力しています。openfoam-cases/cyclorotor at main · kirinote/openfoam-casesContribute to kirinote/openfoam-cases development by creating an account on GitHub.github.com
16Mar
- openSUSE 15.6でOpenFOAM v2406を使う
  OpenFOAMに興味を持った当初は、財団版とESI版の違いがまったく分りませんでした。ですが使っているうちに財団版は基礎研究向け、ESI版は応用技術向けとして棲み分けているのが理解できるようになりました。openSUSE 15.6にESI版OpenFOAM v2406をソースコードをビルドする流れでインストールしてみます。ESI版は財団版と違ってParaViewが統合されていないため、自力でParaViewをビルドしてparaFoamコマンドを用意しなければいけません。財団版はOpenFOAMの関数拡張に専念したい研究者がParaViewを手早く使えるように統合され、ESI版は技術者向けに新機能の実装にリソースを費やすため開発主体でないParaViewには深く関与しないという方針の違いによるようです。前回のブログでは財団版とESI版を共存させることだけを考えたため、ESI版の環境設定がいい加減になっていました。ネットで調べても環境設定を網羅的に説明したサイトが見あたらないことから、今回はESI版に特化してより堅実なインストールを行うことを目指します。参考にしたのはこちらの動画の手順ですが、OSのマイナーバージョンアップのせいか少し様子が違っていたのでこれを修正しました。インストール環境OS: openSUSE 15.6 LeapDesktop: XfceGPU: NVIDIA RTX3050YaST起動その１YaSTコントロールセンターよりソフトウエア管理を起動します。パッケージマネージャを読み込む過程で”信頼できないGnuPG Keyを取り込む”ダイアログが表示されますので「信頼する」ボタンを押して先へ進みます。NVIDIAドライバの差し替えNVIDIAビデオカードの性能を引き出すため、オープンソースのドライバからプロプライエタリなドライバに差し替えます。検索タブにて”nvidia”を検索します。検索対象は名前、キーワード、概要の三つです。nvidia-open-driver-G06-signed-kmp-defaultを削除し、代わりにnvidia-driver-G06-kmp-default（とその依存パッケージ）をインストールします。続いて、インストール済み（利用可能）に表示されているバージョンが570台のG06関連のパッケージ、かつopen-driverでないものを全てインストールします。その他、nvdockとnvtopもインストールします。以下のパッケージ群をインストールします。このとき、依存関係が自動変更されてからパッケージがインストールされます。端末での作業ここからターミナルエミュレーターを使用します。この中に不要なものもあるかもしれませんが、下手に省略して作業が途中で詰まっては原因究明が困難になりますのでとりあえず入れておきます。$ cd ~$ sudo zypper install gcc-c++ gcc-fortran blas-devel lapack-devel patterns-devel-C-C++-devel_C_C++$ sudo zypper install git-core cmake boost-devel gnuplot mpfr-devel openmpi-devel glu-devel$ sudo zypper install -t pattern devel_C_C++$ sudo zypper install patterns-base-x11 patterns-fonts-fonts patterns-fonts-fonts_opt patterns-base-x11$ sudo zypper install xorg-x11-fonts libX11-devel libXcursor-devel libXt-devel$ sudo zypper in -t pattern fonts$ sudo zypper install libqt5-qttools libqt5-qttools-devel$ sudo zypper in libqt5-qtx11extras-devel libqt5-qtsvg-devel libQt5Xml-devel libQt5Network-devel libqt5-qtbase$ sudo zypper in libqt5-qtbase-devel libQt5WebKit5-devel libqt5-qtxmlpatterns-devel libQt5Help5 libqt5-dxcbplugin$ sudo zypper in -t pattern devel_qt5YaST起動その２YaSTコントロールセンターよりソフトウエア管理を起動します。検索タブにて”qt6”を検索します。検索対象は名前、キーワード、概要の三つです。libQt6Core6を削除します。このとき、依存するパッケージが根こそぎ削除されます。ファイルのダウンロードと展開OpenFOAMフォルダを新規作成し、必要なアーカイブをダウンロードして展開します。$ cd ~$ mkdir OpenFOAM$ cd OpenFOAM$ wget https://dl.openfoam.com/source/v2406/OpenFOAM-v2406.tgz$ wget https://dl.openfoam.com/source/v2406/ThirdParty-v2406.tgz$ tar -xzvf OpenFOAM-v2406.tgz$ tar -xzvf ThirdParty-v2406.tgz$ rm OpenFOAM-v2406.tgz$ rm ThirdParty-v2406.tgz.bashrcの編集ファイルマネージャーでホームを開き、[Ctrl]+hキーを押すと普段は見えない隠しファイル.bashrcが表示されます。/home/user/.bashrcをテキストエディターで開き、最終行に以下の内容を追記し、保存します。ParaView起動時にQtがディスプレイのDPI設定値を参照しますが、システム構成によっては未定義と判断して警告が出ることがありますので、正しい値を.bashrcで設定しておきます。#ここからexport QT_FONT_DPI=96export PATH=/usr/lib64/mpi/gcc/openmpi/bin/:$PATHexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64/mpi/gcc/openmpi/lib64/alias of2406="source $HOME/OpenFOAM/OpenFOAM-v2406/etc/bashrc"#ここまで.bashrcの内容は以下のようになります。編集を終えたらホームを表示しながら[Ctrl]+hを押して再び隠します。$ cd ~$ source .bashrc$ of2406$ foam以上のコマンドで/home/user/OpenFOAM/OpenFOAM-v2406フォルダに飛べることを確認します。$ cd ~$ sudo zypper install fftw3-devel gsl$ foamSystemCheckこの時点でSystem check: PASS と表示されればOKです。コンパイルとビルドOpenFOAM本体とParaViewをコンパイル＆ビルドします。$ foam$ ./Allwmake -j -s -l・・・相当な時間がかかります。今しばらくお待ちください。$ foamInstallationTestBase configuration ok. Critical system ok. と表示されたら正常終了となります。$ cd ~$ mkdir -p "$FOAM_RUN"$ of2406$ cd ~/OpenFOAM/ThirdParty-v2406$ ./makeParaView・・・こちらもそれなりに時間がかかります。もうしばらくお待ちください。問題なくparaview-5.12.1をインストールできたら、次のコマンドを入力します。$ wmRefresh$ foam$ ./Allwmake -jチュートリアルの試運転代表的なチュートリアルであるcavityを実行します。$ tut$ cd incompressible/icoFoam/cavity/cavity$ blockMesh$ icoFoam$ paraFoam一時ファイルcavity.foamが生成され、ParaViewが起動することを確認します。また、[Help]-[About...]にてOpenGLレンダリングにGPUを使用していることも確認します。動作確認を終えたら、チュートリアルを元の状態に戻しておきます。$ foamCleanTutorials$ cd ~petsc4foamのインストールGPUの処理能力でOpenFOAMを高速化するため、まだ実験段階にあるPETScライブラリを導入します・・・とはいえ高度な実装ゆえ筆者は全く理解していませんので、導入手順だけ書き留めておきます。$ cd ~$ cd OpenFOAM/ThirdParty-v2406$ wget https://web.cels.anl.gov/projects/petsc/download/release-snapshots/petsc-lite-3.21.2.tar.gz$ tar -xzvf petsc-lite-3.21.2.tar.gz$ rm petsc-lite-3.21.2.tar.gz$ ./makePETSC$ foam$ cd modules/external-solver$ ./Allwmake -prefix=openfoam$ export PETSC_DIR=$HOME/OpenFOAM/ThirdParty-v2406/petsc-3.21.2/$ export PETSC_ARCH=DPInt32$ export LD_LIBRARY_PATH=$PETSC_DIR/$PETSC_ARCH/lib:$LD_LIBRARY_PATH$ foamHasLibrary -verbose petscFoam$ cd tutorials/basic/laplacianFoam/flange$ ./Allrun$ cd ../../..$ ./Allclean$ cd ~petsc4foamをケースファイルに組み込むにはかなりの知識が必要です。見事使いこなせた方はどんどんＳＮＳに上げていただきたいと思います。
10Mar
- UbuntuにOpenFOAMをデュアルインストールする
  これまで財団版OpenFOAMを使ってきましたが、長期的にはESI版も使えないと困る様相を呈してきました。個別にパソコンを用意するわけにもいかないので、一台でどちらも使えるようにします。先に財団版を入れてからESI版を入れます。両方とも導入できましたら、XSim様が紹介しているシェルスクリプトを拝借して財団版とESI版を切り替えられるようにします。最後におまけとして、ESI版しか要らない人のための手順を紹介します。財団版OpenFOAMのインストール執筆時点で財団版はOpenFOAM12がリリースされていますが、筆者は現在XSimを利用しており、エクスポートフォーマットがOpenFOAM11用ということもあって当面はこれに従おうと思います。まずはセットアップ直後のまっさらなUbuntu24.04.2に財団版OpenFOAM11をインストールします。インストール手順は公式の手順どおり進めれば問題なく完了します。$ cd ~$ sudo sh -c "wget -O - https://dl.openfoam.org/gpg.key > /etc/apt/trusted.gpg.d/openfoam.asc"$ sudo add-apt-repository http://dl.openfoam.org/ubuntu$ sudo apt update$ sudo apt -y install openfoam11インストールが正常終了すると、端末に以下のような指示が表示されます。これに従って./bashrcを編集します。** To use OpenFOAM please add**** . /opt/openfoam11/etc/bashrc**** To your ~/.bashrcDockからファイルブラウザを立ち上げ、ホームを表示して [Ctrl]+h キーを押すと隠しファイルが現れます。隠しファイルが見えない時隠しファイルが見えている時この中に.bashrcという名前のファイルがあるので、これをテキストエディターで開きます。.bashrcの最終行に、先ほど表示された緑色の文字列をコピー＆ペーストして保存します。最初のドットも必要ですので注意してください。作業を終えたら、もう一度 [Ctrl]+h キーを押して隠しファイルを消します。.bashrcの内容を更新し、foamRunコマンドを認識することを確認します。$ source .bashrc$ foamRun -help続いて、ケースファイルの実行用ディレクトリを生成します。このディレクトリは/home/user/OpenFOAM配下に現れます。$ cd ~$ mkdir -p $FOAM_RUN一連の動作を確認します。$ cd $FOAM_RUN$ cp -r $FOAM_TUTORIALS/incompressibleFluid/pitzDailySteady .$ cd pitzDailySteady$ blockMesh$ foamRun$ paraFoamおなじみpitzDailyの画面が出ました。初見の方のために付け加えると、ParaViewを起動したらとりあえず画面左にある緑色のApplyを押してください。財団版と一緒に入ったParaViewが参照しているPV_PLUGIN_PATHを確認します。$ cd ~$ printenv PV_PLUGIN_PATH/opt/openfoam11/platforms/linux64GccDPInt32Opt/lib/paraview-5.11端末に表示されたパスをメモしておきます。ESI版OpenFOAMのインストール現時点ですでにOpenFOAM2412がリリースされていますが、ネットで充実してきたチュートリアルの解説などは前バージョン2406を使っています。チュートリアルを試している時にバージョン違いによるエラーに悩まされたくないので、しばらくは2406で行こうと思います。まずは作業に必要なcurlコマンドを追加してからOpenFOAM本体をインストールします。$ cd ~$ sudo snap install curl$ curl https://dl.openfoam.com/add-debian-repo.sh | sudo bash$ sudo apt update$ sudo apt install openfoam2406-defaultここで、端末に以下のような表示が出ます。** Different ways to setup OpenFOAM (www.openfoam.com)** - shell session: /usr/bin/openfoam2406** - select for login shell: openfoam-selector --set openfoam2406** - source from ~/.bashrc file: . /usr/lib/openfoam/openfoam2406/etc/bashrcDockからファイルブラウザを立ち上げ、ホームを表示して [Ctrl]+h キーを押すと隠しファイルが現れます。この中の.bashrcをテキストエディターで開きます。.bashrcの行末に、先ほど表示された緑色の文字列をコピー＆ペーストします。最初のドットも必要ですので注意してください。また、最終行にexportコマンドと先ほどメモしておいたPV_PLUGIN_PATHのパスを追記して保存します。. /usr/lib/openfoam/openfoam2406/etc/bashrcexport PV_PLUGIN_PATH=/opt/openfoam11/platforms/linux64GccDPInt32Opt/lib/paraview-5.11作業を終えたら、もう一度 [Ctrl]+h キーを押して隠しファイルを消します。再び端末を表示し、以下のようにコマンドを打ちます。OpenFOAM2406が起動し、ヘルプが表示されればOKです。続いて端末から直にsimpleFoamを実行すると、コマンドは認識するもののエラーが出て停止します。このエラーは読み込むべきケースファイルが見当たらないというだけですので今は問題ありません。$ source .bashrc$ openfoam2406user$ simpleFoam -helpuser$ exit$ simpleFoam続いて、ケースファイルの実行用ディレクトリを生成します。このディレクトリは財団版と同じ/home/user/OpenFOAM配下に現れます。$ cd ~$ mkdir -p $FOAM_RUN$ cd $FOAM_RUNこれで実行用ディレクトリ/home/user/OpenFOAM/user-v2406/runが現れ、このディレクトリに移動しました。続いて、このディレクトリにチュートリアル群を丸ごとコピーし、代表的なケースファイルであるpitzDailyを実行してみます。ParaViewは財団版でインストールされたparaFoamコマンドを共用する形になります。$ cp -r $FOAM_TUTORIALS $FOAM_RUN$ cd tutorials/incompressible/simpleFoam/pitzDaily$ blockMesh$ simpleFoam$ paraFoamケースファイルpitzDailyが無事処理できればOKです。インストール先上記の作業の結果、財団版とESI版はそれぞれ以下の場所にインストールされました。財団版：/opt/openfoam11ESI版：/usr/lib/openfoam/openfoam2406切り替えスクリプトの作成財団版とESI版を切り替えるために、シェルスクリプトを作成します。作成手順はXSimホームページにあるこちらに従います。ホームにswitchFoamVersionという名称のファイルを作成します。sudoは不要です。$ cd ~$ touch switchFoamVersionテキストエディターでswitchFoamVersionを開き、先程紹介したページにあるシェルスクリプトを貼り付けます。このとき、スクリプトに記述されている変数を今自分がインストールしたバージョンに修正する必要があります。以下はその２行を抜粋したものです。右辺の変数はそれぞれの版をインストールした時に指示された緑色の文字になります。AVAILABLE_VERSION[]の下に空白行があるのは、将来別のバージョンをインストールしたらそこに追記してねという意味でしょう。・・・中略・・・AVAILABLE_VERSION["11"]=/opt/openfoam11/etc/bashrcAVAILABLE_VERSION["v2406"]=/usr/lib/openfoam/openfoam2406/etc/bashrcto_version="11" # Default version・・・中略・・・続いて、switchFoamVersionの最終行にexportコマンドと先ほどメモしておいたPV_PLUGIN_PATHのパスを追記して保存します。export PV_PLUGIN_PATH=/opt/openfoam11/platforms/linux64GccDPInt32Opt/lib/paraview-5.11作成したswitchFoamVersionファイルを/usr/local/binに移動し、実行権限を付与したら作業は完了です。$ sudo mv switchFoamVersion /usr/local/bin$ sudo chmod +x /usr/local/bin/switchFoamVersion切り替えテスト先程紹介したXSimのページで試したのと同じ要領で、うまく切り替えができるかテストします。$ . switchFoamVersion -helpUsage: . switchFoam VERSION [OPTIONS]Options: -help Shows this help -version <version> Switches to the version explicitly Available versions: v2406 11$ . switchFoamVersion v2406OpenFOAM version is switched to v2406.$ . switchFoamVersionOpenFOAM version is switched to 11.$ . switchFoamVersion 11OpenFOAM version is alredy 11.切り替え時にバージョンを指定しなければDefault versionに指定した版に切り替わります。以上で、財団版とESI版の切り替えができるようになりました。この仕組みは今後バージョンが上がっても大きくは変わらないのではないかと思います。忙しい人のためのESI版インストール手順【おまけ】研究室に配属されたら、先輩から「よう新入り、これお前のパソコンだから。とりあえずESI版のOpenFOAM入れとけ」と言われるかもしれません。何も知らない新人さんがOpenFOAMをソースファイルからコンパイルして確実に動かすのは難しいので、動けばいいだけなら以下のコマンドでコンパイル済みのものをインストールできます。ここではUbuntu 24.04 LTSを例にします。Ubuntuに元から入っているテキストエディタは日本語ＩＭＥと相性が悪いので、動作が安定しているgeditに差し替えます。$ sudo apt purge gnome-text-editor$ sudo apt install gedit$ sudo snap install curl$ curl -s https://dl.openfoam.com/add-debian-repo.sh | sudo bash$ sudo apt update$ sudo apt install openfoam2406-default$ openfoam2406OpenFOAM本体のインストールが完了しました。ホームフォルダを開いて [Ctrl]+h キーを押し、隠しファイルを表示します。現れた.bashrcファイルを開き、以下の行を最終行に追記します。source /usr/lib/openfoam/openfoam2406/etc/bashrcalias paraFoam="paraFoam -builtin"ファイルを保存したら.bashrcの内容をシェルに反映します。続いて作業フォルダ$FOAM_RUNを生成し、ParaViewをインストールします。$ source ~/.bashrc$ mkdir -p $FOAM_RUN$ sudo apt install paraviewこれでインストールは完了しました。動作確認として、ESI版独自の機能であるオーバーセットメッシュ（overset mesh）を使ったチュートリアルrigidBodyHullを実行してみます。ケースファイル本体と、それが参照する形状ファイル一式を作業フォルダ$FOAM_RUNにコピーします。$ tut$ cd multiphase/overInterDyMFoam$ cp -a rigidBodyHull $FOAM_RUN$ cd $FOAM_RUN/rigidBodyHull/overset-1$ mkdir -p constant/triSurface$ cd $FOAM_RUN/rigidBodyHull/overset-2$ mkdir -p constant/triSurface$ tut$ cd resources/geometry/rigidBodyHull$ cp HULL.obj.gz $FOAM_RUN/rigidBodyHull/overset-1/constant/triSurface$ cp {BLADES,HUB,MRF_REGION}.obj.gz $FOAM_RUN/rigidBodyHull/overset-2/constant/triSurface$ cd $FOAM_RUN/rigidBodyHull$ ./Allrun$ paraFoam以上でESI版OpenFOAM v2406が正しく動作することが確認できました。
08Mar
- wingMotionを試す
  OpenFOAMにはwingMotionという解析領域の中をふらふらと移動する翼のチュートリアルが付属しています。移動メッシュの使いみちを把握するためOpenFOAM11で実行してみようと思います。geometryフォルダには翼弦長1、翼幅1、迎角5度の翼型wing_5degrees.objが保存してあるので、これを任意の翼型に差し換えて様子を見ることもできます。原点座標と配置方向は以下の画像をご覧ください。位置関係示すため点群を表示しています。翼型のサーフェスは筒状になっており、側面にサーフェスは張られていません。Allrunすれば処理を一気通貫でやれるかも知れませんが、計算時間を最適化するため途中でファイルを編集しますのでコマンドを手打ちします。まずはチュートリアルの/incompressibleFluid/wingMotionフォルダを$FOAM_RUNに貼り付けた状態から始めます。$ cd $FOAM_RUN/wingMotion$ cd wingMotion_snappyHexMesh$ blockMesh$ snappyHexMesh -overwrite$ checkMesh$ cd ../wingMotion2D_steady$ extrudeMesh$ createPatch -overwrite$ checkMesh$ foamRun$ cd ../wingMotion2D_transient$ cp -R ../wingMotion2D_steady/constant/polyMesh constant$ mapFields ../wingMotion2D_steady -sourceTime latestTime -consistent$ cp pointDisplacement 0/pointDisplacementさてここで本題の計算を始めますが、移動メッシュの解析には結構な時間がかかるため計算機のCPUコア数を最大限使用します。/wingMotion2D_transient/system/decomposeParDictを開き、numberOfSubdomainsとsimpleCoeffs、hierarchicalCoeffsの３か所を設定します。numberOfSubdomainsには計算に使用するCPUコア数を設定し、simpleCoeffsとhierarchicalCoeffsはX軸とY軸のセル数を掛けた値がCPUコア数となるよう調整します。元ファイルは４コアで2*2*1でしたが、例えば8コアでは4*2*1とします。Z軸のセルは１つしかないのでそのままです。mpirunの引数npにはCPUコア数を指定します。$ decomposePar$ mpirun -np 4 foamRun -solver incompressibleFluid -parallel > log &$ reconstructPar$ paraFoamparaViewで可視化した結果は珍しいものでもありませんので特に示しませんが、よく見るとメッシュはモデルに追従してスポンジのように歪むだけです。このチュートリアルは振動や揺動の考慮には適しているようですが、モデルにあまりダイナミックな動きはさせられないことが分かりました。
05Mar
- 解決）Ubuntuのテキストエディターで日本語入力がダブる
  筆者はUbuntu 24.04.2 LTSを利用していますが、標準のテキストエディターGNOME Text Editorで日本語入力がダブるというトラブルに見舞われました。これ、ネットで検索するとわりと前からあるトラブルだったようです。解決方法は、以前採用されていたテキストエディターgeditを使うことです。$ sudo apt purge gnome-text-editor$ sudo apt install gedit$ geditLinuxは好きですが、Windowsと違ってオープンソースであるため、いつまで経っても未完成のままというまさに現代のバベルの塔と化しています。世界中に優秀なコーダーがいるのに、ディストリビューションだのフレーバーだのが分化しすぎて、開発リソースが完全に分散してしまったのが残念です。OSレベルだけでなくアプリケーションレベルでもハードウェアレベルでもある話で、いつの時代も元祖ナントカと本家ナントカの争いが絶えません。
01Mar
- 続・ベイパーコーンについて考えてみた
  前回の記事ではOpenFOAMでベイパーコーンの可視化に失敗しました。シミュレーションの前提条件に問題があった可能性があるため、もう少し条件を変えて同じように検証してみることにしました。チュートリアルの動作確認今回は遷音速領域のシミュレーションに適しているとされる圧縮性ソルバーを採用します。手始めにOpenFOAM11に付属しているチュートリアルprismを実行してみます。このチュートリアルは圧縮性流体用非定常ソルバーrhoPimpleFoamを使って三角柱周りの超音速流れを解析します。乱流モデルは標準k-εモデルです。解析空間は全長1mです。チュートリアルでの流速は650m/sおよそマッハ1.9ですが、このまま実行しても他のブログと同じ結果が出るだけです。折角ですから、遷音速領域335.28m/sまで減速して結果を見たいと思います。チュートリアルの保存場所から作業場所$FOAM_RUNにケースファイルをコピーします。$ cp -r /opt/openfoam11/tutorials/fluid/prism $FOAM_RUN$ cd $FOAM_RUN/prism/prism/0/Uを開き、ファイル内の数値650を全て335.28に修正し保存します。解析空間がどのようなブロックで構成されているかparaFoamで見てみます。$ paraFoam -block$ blockMesh$ rhoPimpleFoam$ paraFoamポスト処理メッシュ流速分布静圧分布温度分布三角柱の後方に圧力と温度の低い領域が円錐状に広がっています。流速に至っては、後方で470m/sおよそマッハ1.37と音速を超える状況となっています。遷音速で飛ぶ航空機では、機体周りの気流が部分的に音速を超える可能性があることが分かりました。モデルのスケール調整この検証の過程でSSAM-Gen5という素晴らしい航空機モデルを手に入れましたが、OpenFOAMで解析するためにはスケールを正しく調整しておく必要があります。これまではモデルをXSimに投入するさいに都度スケールダウンしていました。今回はチュートリアルをベースにケースファイルを編集しますので、モデルを使用する前にスケールを調整しておきます。gen5_full.stlをフォルダ$FOAM_RUNに配置し、surfaceConvertコマンドでスケールを1/1000に縮小します。$ cd $FOAM_RUN$ surfaceConvert -clean -scale 0.001 gen5_full.stl gen5_real.stl$ surfaceCheck gen5_real.stl生成されたgen5_real.stlは、OpenFOAMから1/1スケールのモデルとして認識されます。surfaceConvertコマンドを利用して生成されたSTLファイルをメモ帳で開くと、solidがpatch0という名称となっています。一方、XSimの[形状のインポート]-[形状の編集]タブでgen5_full.stlから縮小したSTLファイルは、solidがgen5_fullという名称となります。snappyHexMeshDictのregionsは、surfaceConvertを使用した時とXSimを使用した時とで名称が異なります。XSimで生成したsnappyHexMeshDictを流用する時は、regionsの定義をgen5_fullからpatch0に修正する必要があります。今後ケースファイルに組み込む航空機モデルにはgen5_real.stlを使用します。ケースファイルvpconeを作成先ほど流速Uを335.28m/sに変更したチュートリアルprismを、vpconeに名称変更します。/vpcone/constant配下にフォルダtriSurfaceを新規作成し、その中にgen5_real.stlを配置します。/vpcone/system/blockMeshDictを以下のように全面的に書き換えます。convertToMetersは1で、頂点verticesの座標がそのままメートルになります。prismの複雑なブロックメッシュを取り払い、代わりに全長50m、幅30m、高さ30mの簡素なブロックを作成します。ブロックの構造についてはこちらを参照してください。ベースメッシュは25cmのメッシュで、288万セルとなります。使わないprismWallを取り除き、代わりに解析空間の側面に上下と境界条件と同じsideWallを定義します。これで全体が壁で閉じたからっぽの風洞ができます。航空機モデルgen5_realのサーフェスは後ほど組み込みます。FoamFile{ format ascii; class dictionary; object blockMeshDict;}convertToMeters 1;vertices( (-10 -15 -15) // vertex number 0 ( 40 -15 -15) // vertex number 1 ( 40 15 -15) // vertex number 2 (-10 15 -15) // vertex number 3 (-10 -15 15) // vertex number 4 ( 40 -15 15) // vertex number 5 ( 40 15 15) // vertex number 6 (-10 15 15) // vertex number 7);blocks( hex (0 1 2 3 4 5 6 7) (200 120 120) simpleGrading (1 1 1));defaultPatch{ type empty;}boundary( inlet { type patch; faces ( (0 4 7 3) ); } outlet { type patch; faces ( (1 2 6 5) ); } bottomWall { type patch; faces ( (0 3 2 1) ); } topWall { type patch; faces ( (4 5 6 7) ); } sideWall { type patch; faces ( (0 1 5 4) (2 3 7 6) ); });sideWall用の定義を追加/vpcone/0配下にはT，U，alphat，epsilon，k，nut，pと７つのファイルでそれぞれ定数が定義されています。解析空間の側面にsideWallを追加したので、ここにも定数を全て定義します。また、prismWallはgen5_realに書き換えます。これらのファイル全ては手順が同じですので、ファイルTを例にとって説明します。なお、元のファイルTは温度が300Kすなわち摂氏26.85℃と定義されていますが、国際標準大気表より海面高度0mで摂氏15℃としたいのでuniform 300のところを全て288.15に置き換えます。・・・中略・・・ topWall { type inletOutlet; inletValue uniform 288.15; value uniform 288.15; } sideWall // topWallからコピー＆ペースト { type inletOutlet; inletValue uniform 288.15; value uniform 288.15; } gen5_real // prismWallから名称変更 { type zeroGradient; }・・・中略・・・見てのとおり、追加したsideWallはtopWallと同じ定義を設定しています。また、航空機モデルgen5_realのサーフェスはprismWallのゼロ勾配を引き継いでいます。残り６つのファイルもこれと同じ要領で定義しなおしてください。航空機モデルの組み込み続いて、解析空間に航空機モデルを組み込みます。/vpcone/system/surfaceFeaturesDictを新規作成し、以下のように記述します。FoamFile{ version 2.0; format ascii; class dictionary; location "system"; object surfaceFeaturesDict;}surfaces( "gen5_real.stl");includedAngle 165.0subsetFeatures{ nonManifoldEdges no; openEdges yes;}writeObj yes;このファイルにより、gen5_real.stlを読み込んで特徴線の抽出を行うことができます。STLモデルへのメッシュ適合続いて/vpcone/system/snappyHexMeshDictを新規作成し、以下のように記述します。locationInMeshでは、どこにメッシュを生成するかを指定するため解析空間の内側かつ航空機モデルの外側の座標（-5, 0, 0）を指定しています。regionsがpatch0となっていることに留意してください。このpatch0は、航空機モデルのASCII形式STLデータをエディタで開くと行頭solidと行末endsolidの２か所に定義されています。ケースファイルを実行したとき、STLファイル名が合っているのにFATAL ERRORが出る場合は、この定義がsnappyHexMeshDictのregionsと一致していない可能性があります。FoamFile{ version 2.0; format ascii; class dictionary; location "system"; object snappyHexMeshDict;}castellatedMesh true;snap true;addLayers true;geometry{ gen5_real.stl { type triSurfaceMesh; name gen5_real; regions { patch0 { name gen5_real; } } }}castellatedMeshControls{ features ( { file "gen5_real.eMesh"; level 1; } ); refinementSurfaces { gen5_real { level (0 0); regions { patch0 { level (0 0); patchInfo { type wall; } } } } } refinementRegions {} locationInMesh (-5.0 0.0 0.0); maxLocalCells 100000000; maxGlobalCells 100000000; minRefinementCells 1; nCellsBetweenLevels 3; resolveFeatureAngle 30; allowFreeStandingZoneFaces false;}snapControls{ nSolveIter 30; nSmoothPatch 3; tolerance 4.0; nRelaxIter 5; nFeatureSnapIter 10;}addLayersControls{ layers { } relativeSizes true; expansionRatio 1.0; finalLayerThickness 0.3; minThickness 0.03; nGrow 1; featureAngle 60; nRelaxIter 5; nSmoothSurfaceNormals 1; nSmoothNormals 3; nSmoothThickness 10; maxFaceThicknessRatio 0.5; maxThicknessToMedialRatio 0.3; minMedianAxisAngle 130; nBufferCellsNoExtrude 0; nLayerIter 50; nRelaxedIter 20;}meshQualityControls{ maxNonOrtho 65; maxBoundarySkewness 20; maxInternalSkewness 4; maxConcave 80; minFlatness 0.5; minVol 1.00E-13; minTetQuality -1e30; minArea -1; minTwist 0.05; minDeterminant 0.001; minFaceWeight 0.05; minVolRatio 0.01; minTriangleTwist -1; nSmoothScale 4; errorReduction 0.75; relaxed { maxNonOrtho 180; }}debug 0;mergeTolerance 1e-5;以上のように大規模なファイルですが、色々なケースファイルを見ると、ファイルを分割するテクニックを利用しているものを見かけます。慣れて来たらそのようなテクニックを真似ると良いでしょう。並列処理への対応現代のパソコン向けＣＰＵは、当然のようにコアを複数個搭載しています。チュートリアルのprismは小規模であったため、１コアでも大して時間はかかりませんでした。ですがそれなりの結果が出れば調子に乗ってどんどん大規模な解析をしてしまうので、今のうちにマルチコア対応しておきます。以下の内容で/vpcone/system/decomposeParDictを新規作成してください。ここでは例として解析空間を４つのサブドメインに分割し、ひいては４コアを使用します。FoamFile{ version 2.0; format ascii; class dictionary; location "system"; object decomposeParDict;}numberOfSubdomains 4;method scotch;たったこれだけの記述でマルチコアＣＰＵによる並列処理が可能になります。今回は細かい設定の要らないscotchメソッドを採用しましたが、他にも色々な分割方法があります。解析時間の設定最後に解析時間と間隔などを決めます。/vpcone/system/controlDictを新規作成し、以下のように記述します。特に重要な設定箇所は解析時間endTime、解析間隔deltaTです。これらはメッシュ密度と相まって解析結果に大きく影響します。計算実行中にクーラン数が出力されますが、最大クーラン数が１を下回るようにパラメータを調整します。記録間隔writeIntervalは、細かく刻むほどアニメーションがなめらかになります。FoamFile{ format ascii; class dictionary; location "system"; object controlDict;}application foamRun;solver fluid;startFrom startTime;startTime 0;stopAt endTime;endTime 0.08;deltaT 5e-05;writeControl runTime;writeInterval 0.008;purgeWrite 0;writeFormat ascii;writePrecision 6;writeCompression off;timeFormat general;timePrecision 6;runTimeModifiable true;vpconeの流速はprismのおよそ半分です。同じように解析しようとするとendTimeはprismの倍の時間が必要で、全長も50倍あるのでprismの100倍の0.04秒必要です。ですがこの間に航空機が進む距離はたったの13.4mです。せめて航空機の全長20mは空気を通過させたいので、倍の時間をとって0.08秒とします。writeIntervalを0.008秒とすると、解析時間全体で10コマ記録されます。deltaTはとりえず100倍の5e-05として、最大クーラン数がどうなるか見てみます。解析の実行ケースファイルが全て整ったら、解析をはじめます。並列処理は効率を上げるためバックグラウンドプロセスで行い、経過はlogファイルに書き出します。$ cd $FOAM_RUN$ cd vpcone$ blockMesh$ surfaceFeatures$ decomposePar$ mpirun -np 4 snappyHexMesh -overwrite -parallel > log &$ reconstructPar$ rm -rf ./processor*$ decomposePar$ mpirun -np 4 foamRun -solver fluid -parallel > log &$ reconstructPar$ rm -rf ./processor*$ paraFoamプロセスを並列処理するたびに解析領域の分割と結合をします。snappyHexMeshを実行すると290万セルとなりました。ソルバーを実行すると最大クーラン数は0.7となりました。クーラン数は１未満が適正ですので、いい感じに収まったと思います。並列処理中のメモリ使用量はおよそ8GBでした。バックグラウンドで動いているソルバーを止めたいときは、書き込みの続くlogファイルを見て、controlDictのendTimeを現在計算中の時刻より少し先に書き換えると安全に終了させることができます。ソルバーの完走に膨大な時間を費やす前に、取り急ぎ結果をチラ見するのに便利です。計算をただちに終了したい場合は、mpirunを実行した時にコンソールに表示されるプロセスIDを指定してkillコマンドを発行します。[1] 123456$ kill 123456ポスト処理解析空間メッシュ流速分布静圧分布温度分布参考画像出典：Wikimedia Commons, U. S. Navy with the ID 110606-N-TU221-408静圧分布（３Ｄ）温度分布（３Ｄ）考察これらの図から、機体の凸部後方から低温低圧の領域が円錐状に広がっているのがわかります。キャノピー後方、エアインテーク下部で低温低圧となっている他、不思議なことに尾翼後方に大きな温度勾配があります。この低温低圧が凝結雲の発生する条件を満たすとすれば、前回記事で紹介した写真に見える雲の出現位置と形状ともによく合致します。機体後部には高温のジェット気流もありますから、急激な温度上昇によって凝結雲が消えます。このため一見ボリュームがあるように見える雲も、特に機体後方で生じているのは円錐の表面だけと考えられます。機体の速度は音速に満たない遷音速335.28m/sですが最大流速は384.51m/sおよそマッハ1.1となっており、機体周辺に流速が音速を超える超音速流が見られます。ベイパーコーン形成の原因の一つとして考えていた「音」は、結果として生じたとしても関与はしていないことが分かりました。ただこれは学術的な研究ではなく素人の考えに過ぎませんので、現象の説明にはあくまで専門家の見解が必要です。OpenFOAMでは無理かなと思ったこともありましたが、なんとか遷音速で飛ぶ航空機に現れるベイパーコーンを可視化することができました。まだ空力的に洗練されていなかった頃の戦闘機モデルで試すとより派手な円錐が見られるかも知れません。計算機の仕様筆者の計算機は1CPU Xeon E5-2695 v4 128GBです。CPUクーラーはNH-P1、GPUはRTX3050 KalmX 6GB、電源はPX-500を使用し、完全ファンレスで静かに稼働します。今の所GPUをソルバーの並列処理に使うことはできませんが、NVIDIA RTXシリーズはparaView NVIDIA IndeX™プラグインに対応しておりデータセットを高速に表示することができます。
14Feb
- べイパーコーンについて考えてみた
  先日、空力を研究されている方から航空機が生み出すベイパーコーンについての話題を提供して頂き、あれこれ考えるうちに解析してみたくなりました。とくに興味を持ったのは、ベイパーコーンの発生する位置とその形状についてです。ベイパーコーンとは遷音速で飛ぶ航空機に見られる現象で、以下の画像のような円錐状の雲が生じます。面白いのは、雲が機体全体を覆っているのではないという点です。出典：Wikimedia Commons, U. S. Navy with the ID 110606-N-TU221-408ベイパーコーンは空気中の水分が断熱膨張冷却によって凝結されて雲になったものです。機体周りの一部で気圧が低下し、湿度の高い環境で露点を下回ると空気中の水分が凝結して雲が発生します。この現象は湿度の高い空気の入ったフラスコから注射器で空気を一気に抜くとできるのと同じ原理によります。速度と関係なく見られる現象ですが、機体周りにプラントル・グロワートの特異点が現れた時に急激な気圧勾配が表れます。この特異点を表す公式にマッハ数Ｍが入っているために、音速が関係しているように見えるのです。詳しい解説は以下のWikipediaを参照してください。プラントル・グロワートの特異点 - Wikipediaw.wiki実験でベイパーコーンを発生させるにはどんな規模の風洞設備を持ってしても困難と思われますので、シミュレーションでどうにかできないか検討します。仮想空間に条件を作り出して雲の発生を観察できるような超絶便利なソフトを筆者は知らないのですが、OpenFOAMで円錐状の流速勾配／圧力勾配が再現できれば雲ができたことになると考えました。が、結論から言いますと可視化できませんでした！以下の手順は、それが判明する前から備忘録を兼ねて編集していたもので、消すのが勿体ないので記録に残します。航空機モデルの用意まずは音速で飛びそうな航空機モデルを探索します。戦闘機の精密な３Ｄモデルならネット上に多くありますが、これらはエアインテークの穴もモデリングされており、ここに流れ込む気流が全体の計算結果に影響する恐れがあります。従って、ジェット機の空力性能を正確に評価するには、結果を比較するために標準化されたモデルが必要です。この分野では長らくカナダ国立研究評議会が考案した”標準空力モデルSDM”が使われてきました（下の画像）。しかし現在では時代遅れのモデルとなっており、これでやってみようという気になれません。出典：VSP Airshow, Standard Dynamics Model, DSTO-TR-2600そこで今回はオーストラリアのニューカッスル大学とシドニー大学の研究チームが考案した”シドニー標準空力モデルSSAM”を採用します。これは最新鋭機の空力性能を評価するためのモデルで、その形状は米軍の第５世代戦闘機F-22ラプターを模したものとなっています。このモデルで空力性能を解析した研究論文はこちらで読むことができます。SSAM-Gen5と呼ばれるこのモデルはエアインテークが塞がれたソリッドモデルとなっており、エアインテークの存在が空力計算に悪影響を及ぼさないよう配慮されています。見た目も洗練されており、これならいい結果が得られそうな気がします。出典：Aerospace 2023, 10(9), 746,A Generic Model for Benchmark Aerodynamic Analysis of Fifth-Generation High-Performance Aircraftこの論文で使われた機体モデルはこちらから入手することができます。モデルデータはSTEP形式で収録されています。FreeCADでgen5_full.stepをインポートして、そのままSTL形式でgen5_full.stlにエクスポートすると良いでしょう。Blenderでインポートするには別途プラグインが必要です。モデルを実寸に修正する公開資料によれば、F-22実機の寸法は以下の通りです。　全長 62 ft 1 in= 18.92m　翼幅 44 ft 6 in= 13.56mgen5_full.stlの機体全長は1となっていますので、BlenderでモデルをインポートしてXYZスケールを18.92倍します。同名のSTLファイルにエクスポートすると、全長18.92となったモデルが上書きされます。この翼幅を計測すると13.499となり、実機の翼幅にかなり近い数値になることが分ります。モデル原点はノーズコーンの先端です。XSimの起動こちらのチュートリアルに従って解析領域を決定します。モデルの全長をおよそ20mとして、全長160m、全幅50m、全高50mの風洞にモデルを配置します。XSimのプロジェクト名はvpconeとします。形状のインポートモデルファイルgen5_full.stlをドロップします。例によって全長18.92kmというとんでもない大きさで認識されますので、[形状の編集]タブにて拡大縮小率を0.001します。[形状の追加]タブ-[タイプ]：直方体[形状の追加]タブ-[パラメーター]-[最小座標]：(-40, -25, -25)[形状の追加]タブ-[パラメーター]-[最大座標]：(120, 25, 25)直方体を追加すると以下のようになります。メッシュモデルを覆うように再分割領域を追加します。目標ベースメッシュ数は空間分解能と計算時間のトレードオフになりますので、どちらも許容できる範囲に調整してください。[体積メッシュ設定]-[目標ベースメッシュ数]：80000[体積メッシュ設定]-[再分割設定]-[レベル間のメッシュ数]：3[体積メッシュ設定]-[再分割設定]-[範囲タイプ]：直方体[体積メッシュ設定]-[再分割設定]-[最小座標]：(-10, -10, -10)[体積メッシュ設定]-[再分割設定]-[最大座標]：(50, 10, 10)[体積メッシュ設定]-[再分割設定]-[再分割レベル]：2[体積メッシュ設定]-[再分割設定]-[範囲タイプ]：表面（領域）[体積メッシュ設定]-[再分割設定]-[領域：gen5_full[体積メッシュ設定]-[再分割設定]-[再分割レベル]：3[レイヤーメッシュ設定]-[厚み比率]：0.3[レイヤーメッシュ設定]-[領域]：gen5_full[レイヤーメッシュ設定]-[レイヤー層数]：3基本設定非定常解析を行います。[終了時刻]：1（秒）[時間間隔]-[クーラン数による自動設定]：オン[時間間隔]-[初期時間間隔]：0.0001（秒）[時間間隔]-[最大クーラン数]：0.9[解析タイプ]：乱流[乱流モデル]：Realizable k-ε モデル物性[物性名]：Air初期条件こちらにて海面高度75ft、750mphで飛行するF/A-18Cでベイパーコーンが観測されたとのことですので、流速は335.28m/sとします。海面高度はそれほど高くなく、空気の物性は標準値とほとんど変わらないので0mとします。海面高度0mにおける音速は340.29m/sです。[物理量]：速度[値]：(335.28, 0, 0)流れ境界条件流入口、流出口、モデル表面のみ条件を設定します。条件が設定されていない領域は断熱のすべり壁になります。[領域]：XMin[タイプ]：流速指定[流れ境界条件パラメーター]-[流速]：335.28[流れ境界条件パラメーター]-[流入温度]：288.15[領域]：XMax[タイプ]：自然流入出[領域]：gen5_full[タイプ]：静止壁計算設定[並列数]：お使いのコンピュータのCPUコア数出力代表面積は揚力方向を指定すると自動計算されます。[タイプ]：指定時刻ごと[間隔]：0.1（秒）[全体]タブ：残差，y+値[領域]タブ-[領域]：gen5_full[領域]タブ-[タイプ]：力係数[領域]タブ-[代表速度]：335.28[領域]タブ-[代表長さ]：18.92[領域]タブ-[代表面積]：109.59858633546901（揚力方向）エクスポート[フォーマット]：OpenFOAM 11エクスポートをクリックするとvpcone.zipがダウンロードされますので、これを展開して得られたフォルダvpconeを$FOAM_RUNに配置します。解析実行以下の手順で解析を実行します。$ cd $FOAM_RUN$ cd vpcone$ chmod 755 ./Allclean$ chmod 755 ./Allrun$ ./AllrunparaFoamの起動解析が終了したら、paraFoamを起動します。$ ./paraFoam結果の確認まずはモデル断面のメッシュを確認します。あまり綺麗ではありませんが、そのままです。なぜならば予想と違う結果が出たことでメッシュにこだわる理由を無くしたからです。流速のカラーマップは300m/s〜370m/sの範囲としています。メッシュ流速分布流速分布（3D Glyphs）静圧分布流線表示遷音速の気流中にモデルを置いたことでエッジの効いた形状部分に変化が見られますが、期待した円錐状の”何か”が見当たりません。流れもほぼX軸方向で整っており、とりたてて大きな乱流がモデル周りに生じているように見えません。あえて気になるところと言えば、機体形状の凹凸部分で静圧が低下しているというごく普通の結果だけです。これより、ベイパーコーンは気流とあまり関係なさそうであることが分かりました。考察のようなものOpenFOAMを使えばすべてを明らかにできると思いこんでいましたが、この考えは改めねばなりません。思いついたのは、この記事の冒頭で排除した「音（圧力変動）」が関係しているかも知れないことです。今回のシミュレーションでは音波の影響を考慮していませんので、当然、結果にも反映されません。ここで音の性質を確認しておきます。以下の図は音源が移動した場合に音波がどのように拡散するかを示したものです。音源が静止している場合は全周一様に音が伝わりますが、音源が移動するとその方向に音波が偏り、音速では音源から音が逃れることができずに大きな衝撃波が生じます。超音速（Supersonic）に入るともはや音が音源に追従できず、衝撃が円錐状に広がるようになります。円錐の鋭さは速度に依存し、音速の２倍で移動すると角度θは30°となります。ただし、記事冒頭のベイパーコーンの画像は音速未満の速度で観測されたものですから、雲の形が似ていようとも超音速の計算を当てはめることはできません。しかしながら、遷音速（Transonic）においても音の偏りによって衝撃波は生じていて、急激な気圧変化はすでに始まっているのかも知れません。円錐状の凝結雲がキャノピーなど機体凸部の後方に見えるのは、衝撃波が引き起こした気圧低下に機体横断面積の減少に伴う断熱膨張が重畳され、部分的に冷却効果が強まったためではないかと推測します。以上、ベイパーコーンに興味を持ったために余計なことをしてしまいました。この結論はあくまで推測ですので、正確な情報をお持ちの方がいらっしゃいましたらぜひコメント、ご連絡いただけたらと思います。追記もう少し調べてみたところ、遷音速領域の解析には圧縮性ソルバーsonicFoamやrhoCentralFoam/shockFluid等が適しているとの情報がありました。この手法を今後取り入れてみようと思います。

前ページ
次ページ