Ohara Lab

Ohara Lab | Software

en ja

尾原研 / ohara-lab-su (github) / ohara-lab-su (docs) / ohara-lab (PyPI)

Ohara Lab では、実験装置制御・ラボオートメーションのためのソフトウェアを中心に、研究・実験で利用する各種ツールを開発している。

実験装置制御では、特定の Framework や通信 protocol に依存しない DeviceClass を基本単位とする。 DeviceClass は単独で利用でき、ネットワーク越しに利用する場合のみ、BL774 互換の REST / FastAPI、gRPC、TANGO などの通信 Frame を用途に応じて付加する。 通信方式や上位システムが変化しても、機器固有の制御資産をできるだけそのまま利用できる構成を基本としている。

更新履歴

HISTORY

DeviceServer と DeviceClass

以下では、各機器に対応する 制御プログラム (DeviceClass) と、 通信フレームを用いた デバイスサーバー (DeviceServer) を紹介する。

通信Frame・共通機能

others

インストール・利用方法

利用する機器の DeviceClass パッケージを起点に導入する。PyPI で配布されているパッケージは pip install <device-package> で導入でき、宣言された依存パッケージは pip が解決する。システム全体や通信 Frame を一律に事前インストールする必要はない。

DeviceClass は Python から直接利用できる。ネットワーク越しに利用する場合は、対象 DeviceClass が対応する通信方式（ese774 / gRPC / TANGO など）と、パッケージに同梱されたデバイスサーバー起動スクリプトを利用する。対応する通信方式やスクリプトの提供状況はパッケージごとに異なる。

既存の DeviceClass を利用する場合は各パッケージの説明を参照する。独自のデバイスサーバーを開発する場合の技術的な説明は、「DeviceClass・デバイスサーバー開発」にまとめている。

DeviceClass・デバイスサーバー開発

DeviceClass は通信方式から独立した機器制御クラスであり、デバイスサーバーはその機能をネットワーク越しに公開するための構成である。開発時には機器制御の実装と通信 Frame の実装を分離する。既存パッケージを導入するだけの場合は、上記の「インストール・利用方法」を参照する。

開発に必要な設計、実装、クライアント、型情報、運用上の注意点はサブ記事にまとめた。

スサノオとは？

return

島根大学が開発する、DeviceClass を基本単位とした一連の計測システムを Sustainable Unified Systems Architecture for Networked Operations and Orchestration の頭文字を取り、スサノオ (SUSANOO) と読んでいる (*)。 SPring-8 での利用に向けて BL774 互換 (ese774) の通信 Frame を持つが、 DeviceClass 自体は特定の Framework や通信 protocol に依存しない。 測定・解析・可視化・判断などをトータルで扱うための、 デバイス単位の緩やかな結合を基本思想としている。

(*) 名前は変わる可能性がある。島根県はスサノオと命名されたプロジェクトがあまりにも多すぎる。

スサノオの概要

return

スサノオでは SPring-8 における MADOCA/DARUMA や ESRF の TANGO のようなフルスタック型のプロトコル・フレームワークを新たに構築することは目的としない。

スサノオの基本単位は、特定の Framework や通信 protocol に依存しない DeviceClass である。 機器固有の制御を DeviceClass として分離して維持し、 ネットワーク越しに利用する場合にのみ、BL774 互換の REST / FastAPI、gRPC、TANGO などの通信 Frame を用途に応じて付加する。 TANGO を含む既存の制御基盤を置き換えることではなく、 通信方式や上位システムが変化しても、機器制御資産をできるだけ作り直さず利用できることを重視する。

その上で、必要な DeviceClass や解析機能をデバイスオブジェクトとして緩やかに結合し、 測定・解析・可視化・判断などを組み合わせる。

無論、デバイスサーバー単位の構成は、 MADOCA や TANGO でも一般的なものである。 ただし、スサノオでは、 それらのような大規模なフレームワーク・共通基盤やプロトコルそのものを新たに設計することは目的としない。 スサノオでは、マイクロサービスとして作成したデバイスサーバーや解析機能を、 必要に応じて組み合わせられることのメリットを重視するからだ。

そしてスサノオでは、 ターゲットとなるデバイスと、目的に応じた通信速度・フレームワークとの結合をしやすいように、 フレームを切り替えても同じように使えるようにする。 つまり、基本はシンプルな透過型プロキシ構成である。

同時に、スサノオは BL774 互換としての立ち位置を持つ。 これは、公式に BL774 REST server のコードを基盤にしており、 get や post のルールを BL774 側の真似をしているところである (まだ、不完全である)。 なにより、マネージメントや API セットにはまだ大きな規定や仕組みはない。 つまり 774 API セットに対応しているわけではなく、 774 Basic System 未満である。

意図的に、ユーザーレベルのマネージもアクセス権も作らない。 最大規模でも、 SPring-8 の BL 単位。 研究室のラボの機器とアクセスフリーなヤクザなユーザー構成を前提とする。

そして、基本センスとしては、スサノオはフレームワーク側として API を統一整理する代わりに、 制御クラス側に API の規定を任せている。 つまり、透過型プロキシ として動的ディスパッチ を軸としたフレームであり、 制御クラス側の python の API がそのままクライアント上での API となる。 API を揃える場合は制御クラス側で揃える。

これは、最初からデバイスサーバー を増やす前提のもとで設計されているためであり、 デバイスごとに基本となる API が異なるためだ。 モーター系など、すでに揃えるべき API セットが固定されたものを扱うことよりも、 多種多様なデバイスに対する対応の容易さ の方を重視している。 言い換えると徹底的にミニマム志向で作られているともいえる。

透過型プロキシとは？

return

スサノオでは、 デバイスへのアクセスを透過型プロキシ (Transparent Proxy) として構成している。

プロキシとは、クライアントと実際のデバイスの間に入り、 通信を仲介するプログラムである。 しかし、スサノオでは単に通信を中継するだけではなく、 できるだけ元のデバイスクラスをそのまま利用できることを重視している。 つまり、利用者はネットワークの存在をほとんど意識することなく、 ローカルの Python オブジェクトを扱うような感覚でデバイスを操作できる。

スサノオ自身は、デバイス固有の API を新たに定義したり、 複雑な抽象化レイヤーを追加したりしない。 基本的にはデバイス制御クラスのメソッドをそのまま公開し、 クライアント側から呼び出せるようにするだけである。 そのため、

という特徴を持つ。 もちろん、 ロボットのように複数メーカー間で共通化したい API については、 制御クラス側でインターフェースを整理することもできる。 しかし、その責務はフレームワークではなく、各デバイスライブラリ側に委ねている。 このように、 通信機構を共通化しつつ、 デバイスクラスの機能をできるだけそのまま利用できることが、 スサノオにおける透過型プロキシ 構成の特徴である (*)

*) そもそも、 BL774 をはじめとする機器制御フレームワークでは、 ネットワークの向こうにある機器をローカルなオブジェクトに近い形で扱う、 透過的な構成が広く用いられている。 Device、 Device Class、 Device Server という関係と名称も一般的なものであるが、 スサノオにおけるこの名称分類は TANGO の影響を強く受けている。

動的ディスパッチとは？

return

スサノオでは、デバイス制御クラスのメソッドをネットワーク越しに呼び出すために、 動的ディスパッチ (Dynamic Dispatch) を利用している。

例えば、デバイス制御クラスに

device.move(...)
device.stop()
device.get_position()

というメソッドがある場合、クライアント側でもほぼ同じ形で

device.move(...)
device.stop()
device.get_position()

と呼び出すことができる。 内部では、

client.move (...)
        ↓
network
        ↓
server
        ↓
device.move (...)

のように、クライアントから送られた メソッド名と引数をもとに、 サーバー側が対応するデバイスクラスのメソッドを探して実行している。 通常の Web API では、move、stop、get_position などの処理ごとに 個別の API を定義する必要がある。 動的ディスパッチ を利用すると、 制御クラスにあるメソッドを比較的そのまま公開できるため、 新しい機器や新しい機能を追加するときの通信部分の記述を大幅に減らすことができる。

これはスサノオの 透過型プロキシ を実現するための基本的な仕組みの一つである。 つまり、 制御クラス側の Python API を、できるだけそのままネットワーク越しの API として利用する という考え方である。

スサノオでは、当初は Pydantic/OpenAPI を用いて API の I/F を明示的に定義する方式を用いていた。 しかし実際に運用すると、制御クラス側に Python API がすでに存在するにもかかわらず、 通信側にも同じ I/F を定義して維持する必要があり、多種多様なデバイスを追加していく上では面倒であった。 そのため現在は、 DeviceClass の Python API をそのまま I/F とする完全な動的ディスパッチを基本としている。

一方、動的ディスパッチだけでは、 利用できるメソッドや引数の型などの I/F が外部から分かりにくい。 そのため、Pydantic/OpenAPI を用いた明示的な API 定義も残しており、 OpenAPI による I/F が必要な場合には選択して利用できる。

より詳しい仕組みと Pydantic/OpenAPI との関係については、 動的ディスパッチと API の定義 に記す。

ロボット制御

return

特にスサノオ (仮) の自動化の中核として、ロボット制御のデバイスサーバーが挙げられる。 当然ロボットに関しては各社独自のフレームワークなど、大変な力を入れている。 それらを置換するものではない。 各社のロボットは、ハードウェアとしての目的が異なるために I/F の違いが大きい. スサノオではこれらをある程度統一的な API-I/F として揃える。 つまり各社 API の緩やかな抽象化を行う。 各社を横断した API セットは、メーカーではできない、大学らしい設計となる。 各社の違いを超えて、実験する人が容易に置き換えることを目的としている。

デンソーウェーブcobotta

return

デンソーウェーブのロボットでは、 コントローラ内部の Motion Generator / Robot Motion が実際のモーション制御を担い、 その上位に PacScript、ORiN2、b-CAP などの制御 I/F が用意されている。

TP や WINCAPS から作成する通常のロボットプログラムは、 デンソーウェーブ独自のロボット言語である PacScript としてコントローラ上で実行される。 一方、PC からは ORiN2 を介して制御できるほか、 より低レベルには b-CAP を直接利用してコントローラへアクセスすることもできる。

ORiN2 はロボットを含む各種デバイスを共通のオブジェクトとして扱うためのフレームワークであり、 Provider を介して各デバイスへ接続する。 RC8 への通信ではその下位で b-CAP が利用されるため、 ORiN2 は上位のデバイス抽象化、 b-CAP はコントローラへアクセスする通信プロトコルという関係になる。

ユニバーサルロボット

return

Universal Robots のロボットは、 Robot Arm、Control Box、 Teach Pendant から構成される。 実際に各関節を協調して動かす制御の中心は Control Box 側にあり、 TP 上の PolyScope はその上位にある操作・教示・プログラミング環境である。 PolyScope で作成したロボットプログラムや外部 PC から送信した URScript は、 最終的に Control Box 側の URControl で実行され、ロボット動作へ変換される。

外部 PC との通信には Universal Robots 公式の RTDE、 Primary / Secondary Interface、 Dashboard Server など複数の I/F が用意されている。 このうち RTDE は、外部 PC と UR controller の間で controller の状態、 I/O、汎用レジスタなどを双方向に読み書きする公式 I/F である。 ただし RTDE 自体に movej や movel のようなロボット動作命令が定義されているわけではない。 RTDE で渡した値をどの動作に使うかは、必要に応じて controller 側のロボットプログラムが受け持つ。

現在スサノオで使用している RTDEControlInterface は Universal Robots 純正 API ではない。 これは SDU Robotics が開発するオープンソースライブラリ ur_rtde の API であり、 Universal Robots 公式 RTDE とロボット側で動作する control URScript を組み合わせ、 PC から moveJ、moveL、servoJ などを呼べる形にまとめたものである。 したがって、Universal Robots 公式の RTDE と SDU Robotics の ur_rtde は明確に区別して扱う必要がある。

現在の実装では、 モーション制御に SDU Robotics の RTDEControlInterface、 状態取得に RTDEReceiveInterface、 I/O に RTDEIOInterface、 コントローラ管理に Dashboard Server、 controller message / error の取得に Primary Interface を利用している。

JAKA

return

JAKA の協働ロボットでは、 Robot Arm と Controller が実際のモーション制御を担い、 その上位に JAKA App による教示・操作、 Controller 上で実行するロボットプログラム、 外部 PC 用の公式 SDK / 通信 I/F が用意されている。 外部 PC からは C/C++、C#、 Python の公式 SDK を利用でき、 V3 Controller では gRPC の利用が推奨されている。一方、TCP/IP 外部制御プロトコルも公開されており、Controller の状態取得や制御を独自に実装することも可能である。

公式 GitHub では SDK や ROS / ROS2 関連資産も公開されている。 ただし Python SDK は jkrc とメーカー提供の native library を利用する構成であり、 公開 GitHub repository が存在することと、 SDK 全体が純粋な OSS であることは分けて考える必要がある。

FAIRINO

return

FAIRINO の協働ロボットでは、Robot Arm と Control Box がモーション制御を担い、WebAPP / Teach Pendant が教示・操作環境となる。Controller 上のロボットプログラムには Lua が用いられ、これとは別に外部 PC から公式 SDK を用いて Joint / Cartesian motion、Jog、Servo motion、I/O、状態取得などを直接操作できる。

Python、C++、C#、Java の公式 SDK が GitHub で公開されており、Python SDK は Apache-2.0 で公開されている。このため Python から独自の制御 class を構築する場合、第三者 wrapper を必須とせず、メーカー公式 SDK をそのまま基盤として利用しやすい。

Dobot

return

Dobot の CR / CRA 系協働ロボットでは、 Robot Arm と Controller がモーション制御を担い、 DobotStudio Pro が教示・操作・プログラミング環境となる。 外部 PC 制御では Controller の TCP/IP protocol が公開されており、 管理 command、motion command、real-time feedback などが異なる通信経路として整理されている。

公式 GitHub では TCP/IP protocol を Python から利用する TCP-IP-4Axis-Python が MIT License で公開されているほか、 ROS / ROS2 関連資産も公開されている。 このため通信 protocol から Python 制御 class まで追いやすく、 独自のデバイス制御層を構築しやすい構成である。

FANAC

return FANACのスサノオでの制御アレコレ

…

デバイスサーバー単位の緩やかな結合

return

自動化・自律化などの大きな枠組みを作らずに、 あくまでデバイスサーバー単位での緩やかなシステム構成を中心に据えるのがスサノオ (仮) である。 それはフィジカル AI 時代に対する一つの回答であるのは言うまでもない。

どのような汎用 API を用意して、どのような大きな構成を見据えた巨大なフレームワークを作っても、 上位の命令・実行系は AI を含めて今後も大きく変化していくと考えられるからだ。

その時に残るシステムバックエンドは、 保守メンテナンスに優れたデバイス単位のミニマムな構成である。 インテリジェントな構成はその上位に任せれば良い。

上位の実験シーケンスや知能化の手法は今後も変化していく。 一方で、長く利用されるのは、保守性に優れたデバイス単位のコンポーネントである。 スサノオでは、そのような下位レイヤーをできるだけシンプルに保ち、 上位の知能化や自動化は利用者が自由に構築できるようにする。

解析との結合による自動・自律実験

return

スサノオ (仮) では、それぞれのデバイスが分散環境に配置されていても、 利用者はネットワークを意識することなく扱うことができる。 つまり、ハードウェアは利用者から見れば、ただのデバイスオブジェクトである。

これは何を意味するか？

デバイスオブジェクトを、 解析用のプログラム・オブジェクトと同じように扱い、 互いに組み合わせることができるということである。

測定を行うデバイスオブジェクトと、 解析、可視化、判断を行うプログラム・オブジェクトを緩やかに結合することで、 測定結果を解析し、その結果から次の動作や測定条件を決定する、 自律的な自動実験へ容易に展開することができる。

巨大なフレームワークは、その時代の技術や要求に強く依存し、 一度構築しても短期間で陳腐化する。 また、フレームワークが巨大になればなるほど、 継続的な維持、刷新、移行に必要なコストも莫大になる。

自動実験・自律実験に必要な資産を継続的に維持・蓄積し、 時代に応じて更新していくためには、 個々の機能を小さな単位で作り、 分散したオブジェクトとして緩やかに結合できることが重要である。

このようなマイクロな設計と、 分散したオブジェクトの緩やかな結合が、本プロジェクトの目的である。

●

分散システムとは？

return

スサノオの分散環境は、単純に特定の通信方式や Framework を選んで構成したものではない。 放射光施設で実際に運用されてきた複数の制御システムでは、 分散通信、デバイスサーバー、マネージメント、運用の責務をどこに持たせるかがそれぞれ異なる。 スサノオでは、それらの構成と運用を踏まえた上で、 研究室から SPring-8 の 1 BL 程度までの実験環境に必要な範囲を選択している。

SPring-8 の MADOCA/DARUMA では、 メッセージサーバーと機器制御を分離し、ノードをまたいだメッセージルーティングを含む 分散制御を共通基盤として扱うことができる。 ノード間通信そのものを制御基盤の機能として持つため、 複数のネットワークや多数の機器を横断する構成まで一つの体系で扱える。

ESRF を起源とする TANGO では、 Device / Device Class / Device Server を中心に、 デバイスを分散オブジェクトとして扱う構成が取られている。 デバイスサーバーの起動や名前解決、データベースなどのマネージメントも含め、 制御システムとして一貫した仕組みを持つ。 スサノオで用いている Device、DeviceClass、Device Server という名称や考え方も、 TANGO の影響を強く受けている。

一方、SPring-8 の BL774 では、 本格的な分散ルーティングを共通プロトコル側に持たせず、 個々のデバイスサーバーへクライアントから直接アクセスする構成を基本としている。 REST API を中心とする Web 技術を使うことで、 プロトコルそのものの開発だけでなく、導入・デバッグ・保守を含めた運用コストを小さくする方向である。

これらの違いは、単純な機能の多寡や優劣ではない。 分散制御の機能をプロトコルや Framework 側へ多く持たせれば、 メッセージルーティング、非同期通信、イベント配信、名前解決、起動管理などを 共通基盤として利用できる。 その反面、その共通基盤自体を継続して導入・運用・保守する必要がある。

逆に、個々のデバイスサーバーをできるだけ独立させ、 一般的な通信技術で直接接続する構成では、 共通基盤の機能は小さくなるが、デバイス単位で追加・交換しやすく、 小規模な実験環境を小さいまま維持しやすい。

結局は、

プロトコルを高度にするか、Framework を高度にするか、運用を高度にするか、 あるいは用途と規模を限定して共通基盤を小さくするか、という選択になる。

スサノオでは、最大でも SPring-8 の BL 単位、通常は研究室の実験環境を対象とする。 その規模では、MADOCA/DARUMA のようなノード間ルーティングをシステム全体の必須機能とするよりも、 BL774 型の独立したデバイスサーバーを基本とし、 必要な通信機能だけを用途に応じて選択する方を採っている。

つまり、 MADOCA/DARUMA や TANGO のようなフルスタック型の分散制御システムを 新たに構築することは目的としない。

その代わり、機器固有の制御を担う DeviceClass を長く利用できる基本単位とし、 通信、上位の実験シーケンス、解析、自動化などは必要に応じてその外側で組み合わせる。 共通基盤が担う責務を対象規模に応じて限定することで、 個々の機器制御資産を特定の Framework や通信方式から切り離して維持する。

ここで重要なのは、通信方式を基本単位にしないことである。 スサノオの基本単位は、特定の通信 protocol や Framework に依存しない DeviceClass である。 DeviceClass は単独でも利用でき、ネットワーク越しに利用するときだけ通信 Frame を付加する。 REST / FastAPI、gRPC、TANGO、将来の DDS などは、 DeviceClass の外側に置かれる交換可能な通信層として扱う。

この判断の背景となる分散制御モデルとノード間通信については、以下にまとめている。

  1. 機器制御における分散モデル
    中央集権型、デバイスサーバー型、本格的な分散制御、 BL774 / TANGO / MADOCA などの構成と運用上の違い
  2. 分散ノード通信の基礎
    REQ/REP、ROUTER/DEALER、PUB/SUB と、 BL774 / TANGO / MADOCA/DARUMA / ROS2 などの通信モデル

スサノオにおける分散システム

return

スサノオの基本モデルは、 BL774 と同様に、 必要なデバイスサーバーへクライアントから直接接続する サーバー・クライアント型の構成である。

通信モデルとして見ると、個々のデバイスとのやり取りは基本的に request / reply で完結する。 複数のデバイスを使う場合にも、中央のメッセージルータを必須とせず、 クライアントが必要なデバイスサーバーへそれぞれ接続する。 デバイスサーバー同士を一つの分散プロトコルで結びつけることを、 システム全体の前提にはしない。

この構成では、各デバイスサーバーがほぼ独立する。 一方、クライアント側では透過型プロキシを使うため、 利用者はネットワーク越しのデバイスであっても、 ローカルな Python オブジェクトに近い形で扱うことができる。 つまり、通信基盤を小さくしても、実験プログラム側まで低水準な通信処理を露出させる必要はない。

BL774 がメインとして採用している REST API は高速通信を目的とした方式ではない。 しかし、Web に立脚した技術体系の普及率と裾の広さ、簡便さは捨てがたい。 ライブラリ、開発環境、デバッグ手段が広く利用でき、 特定の制御 Framework の知識を持たない開発者でも扱いやすい。

モーター移動、測定条件設定、状態取得など、 通信時間が装置動作全体の支配要因にならない機器制御では、 REST API の速度よりも開発効率、可読性、保守性、一般的な技術であることの利点が大きい。 BL774 のサブセットとしての立ち位置を持つスサノオも、この考え方を基本としている。

一方で、画像転送、高頻度のデータ交換、イベント駆動など、 より高速な通信や異なる通信モデルが必要になる場合も存在する。 この領域では、MADOCA/DARUMA や TANGO で用いられてきた ZMQ / CORBA などのメッセージング技術や、PUB/SUB 型の通信が有利になる。

スサノオでは、Web 系の技術体系との親和性を保ちながら、 高速なバイナリ転送が必要な用途には gRPC を選択できる。 gRPC は Protocol Buffers を用いたバイナリ転送が可能であり、 画像転送など REST が適さない用途を補完する。 この gRPC への拡張は本家 BL774 でも行われており、BL774 対応の一つでもある。

デンソーウェーブの ORiN3 でも gRPC が採用されているように、 機器制御 I/F に一般的な RPC 技術を利用する方向は珍しいものではなくなっている。 スサノオでは REST と gRPC のどちらか一方をシステム全体の標準として固定せず、 対象となるデバイスと必要な通信速度に応じて通信 Frame を選択する。

さらに、分散環境そのものを構成する技術として DDS がある。 DDS を最初からシステムの基盤として採用する設計も一つの選択肢であり、 ROS2 はその代表的な利用例である。 ロボットを扱う以上、DDS / ROS2 との接続はスサノオでも重要になる。

ただし、スサノオは SPring-8 で利用するための BL774 互換層を持つ一方、 BL774 を含む特定の通信方式を DeviceClass の必須基盤とはしない。 DDS が適する領域では DDS / ROS2 と接続し、 高速な RPC が必要なら gRPC、通常の機器制御なら REST / FastAPI を利用する。 TANGO 環境との接続が必要な場合には TANGO Frame を利用する。

つまり、スサノオでは通信 protocol の統一そのものを目的としない。

DeviceClass
    ├─ ese774 Frame (REST / FastAPI), SPring-8互換層
    ├─ gRPC Frame, 高速通信層
    ├─ TANGO Frame, ESRFの資産を使うための層
    └─ DDS Frame, 高度なルーティングを使う, ROS2資産を使うとき

機器固有の制御と通信を分離し、 DeviceClass を長く利用する資産として残し、通信方式を用途に応じて選択・交換する。

上位の実験シーケンス、解析、自動化、AI の構成が変化しても、 機器制御そのものまで巻き込んで作り直す必要をできるだけ減らす。 これがスサノオにおける分散環境の基本的な考え方である。

●

スサノオの設計思想のまとめ

return

スサノオは、DeviceClass ベースのシンプルな構成を基本としている。

その基本単位は、特定の Framework や通信 protocol に依存しない、個別の機器制御 class である。 ある意味、スサノオそのものは Framework ですらない。

各機器制御 class は単独で利用でき、ネットワーク越しの利用が必要な場合にのみ、REST / FastAPI、gRPC、TANGO などの薄い通信層を用途に応じて付加する。 通信層は交換可能であり、機器制御 class 自体は特定の通信方式に依存しない。

この薄い通信層を介して、複数の DeviceClass をデバイスオブジェクトとして必要に応じて連携させる。 また、ロボット API のように明確な目的がある場合を除き、Framework 側で API を統一することも基本的には行わない。

●

実験用サンプルスクリプトと環境構築 docs

return (*) 研究室の学生向けのドキュメント

実験制御をするエンドユーザーにとって簡便であること。これがスサノオの究極的な目的である。 スサノオ使用者は、ロボット制御や通信の複雑なプログラムを書く必要も、理解する必要もない。 Python は多少は知っておく必要がある。

おそらく、学生にとっては cobotta やスサノオのシステムの導入より、 サーバーPC と python 環境などの環境構築が大変な障壁になる。 以下に学生の試行錯誤の記録を記す

Ohara Lab Slack Robo Channel

●

計算・解析オブジェクト

return

実験制御たるデバイスサーバー（デバイスクラス）と連携する計算・解析オブジェクトを提供する

計算・データ解析 (RMC): source

return

主に逆モンテカルロ (RMC) を用いた計算・データ解析とそのための支援ツールなど。

計算・データ解析 (MD): source

return (*) 2026/03/03 アクセス制限あり

主に古典分子動力学 (MD) を用いた計算・データ解析とそのための支援ツールなど

計算・データ解析 (MLP): source

return

主に機械学習ポテンシャル (MLP) を用いた計算・データ解析とそのための支援ツールなど

計算・データ解析 (DFT): source

return

主に密度汎関数理論 (DFT) / 第一原理 MD を用いた計算・データ解析とそのための支援ツールなど

●

過去記事

return

計算手法の基礎とその応用についての過去記事

古い記事へのリンク

return

主な開発者

  1. K.Ohara
  2. K.Kobayashi
  3. K.Watanabe
  4. R.Hinohara
  5. K.Nakada P