検索:
AnacondaでPythonの仮想環境を構築する

Pythonでの開発において、Pythonのバージョン、インストールされているライブラリの種類・ライブラリのバージョンの状態をまとめて「環境」と呼びます。Pythonを実行するには環境の構築が必要です。

仮想環境とは

Pythonに限った話ではありませんが、プログラムを作成する際、「このライブラリのこのバージョンはPythonのこのバージョンにしか対応していない」のようなことがよくあります。
また、ライブラリをアップデートすることで以前作ったプログラムが動かなくなってしまったら困ります。

そこで「仮想環境」と言われる所望のパッケージの所望のバージョンをインストールした環境を用意し、環境を切り替えることで、簡単に実行できる環境を構築することができます。

ここではAnacondaを使用した仮想環境の構築につて紹介します。

仮想環境の生成

実際に仮想環境を作成してみます。
Windows PowerShell や Anaconda Powershell Prompt で下記のコマンドを実行してください。

PowerShell
conda create -n vir_env1 python=3.11.4

ここでは「vir_env1」という名前の仮想環境を構築しています。

仮想環境が正しく作成されたか、下記コマンドで確認します。

PowerShell
conda info -e

コマンドを打つと、下記のような結果が出力されます。

PowerShell
 base               *  C:\ProgramData\anaconda3 
 vir_env1              C:\Users\Users\.conda\envs\vir_env1

base 環境の他に、「vir_env1」が生成されていることが確認できます。

仮想環境の切り替え

仮想環境は activate/deactivate して切り替えます。
仮想環境「vir_env1」をactivateする方法は下記になります

PowerShell
conda activate vir_env1

コマンドを実行すると、「vir_env1」の仮想環境がアクティベートされます。

念のため「conda info -e」を実行すると、下記のように仮想環境が切り替えられたことを確認できます。

PowerShell
 base                  C:\ProgramData\anaconda3 
 vir_env1           *  C:\Users\Users\.conda\envs\vir_env1

「*」印が、有効になっている仮想環境を示しています。
Anaconda Powershell Prompt を使っている場合、コマンドラインの左端の表記が(base)から(vir_env1)に変わっているかで、環境の切り替えを確認することもできます。

OpenCVとPythonで硬貨を検出してみた

OpenCVをPythonで走らせてコインの認識を行ってみました。

まずはカメラの映像をライブでウィンドウにキャプチャします。

Python
import cv2

# カメラを開く
cap = cv2.VideoCapture(1)

while True:

    # 画像をキャプチャする
    ret, frame = cap.read() #カメラ動画
    
    # 画像の表示
    cv2.imshow("Image", frame)
    
    # `q`キーを押すとループを終了する
    if cv2.waitKey(1) == ord('q'):
        break

# カメラを閉じる
cap.release()

# すべてのウィンドウを閉じる
cv2.destroyAllWindows()

実行結果がこちら↓↓

接続するカメラが違う場合は、4行目の関数の閾値の数字を変えてみてください。これでUSBカメラの映像をライブで取り込めるようになりました。

次に Hough 関数を使って円を検出してみます。

Python
import cv2
import numpy as np

# カメラを開く
cap = cv2.VideoCapture(1)

#フォントの指定
fontType = cv2.FONT_HERSHEY_DUPLEX

while True:

    # 画像をキャプチャする
    ret, frame = cap.read() #カメラ動画

    # グレースケール画像の生成
    image_gray = cv2.cvtColor(frame,cv2.COLOR_BGR2GRAY)

    #==============================================
    # Cannyでエッジ検出処理
    canny_gray = cv2.Canny(image_gray,100,200)
    cimg = canny_gray

    j = 0
    
    # hough関数
    circles = cv2.HoughCircles(cimg, cv2.HOUGH_GRADIENT, 1, 20, param1 = 120, param2 = 15, minRadius = 10,maxRadius = 30)
        # param1 : canny()エッジ検出器に渡される2つの閾値のうち、大きいほうの閾値0
        # param2 : 円の中心を検出する際の投票数の閾値。小さくなるほど、誤検出が起こる可能性がある。
        # minRadius : 検出する円の最小値
        # maxRadius : 検出する円の最大値

    #検出された際に動くようにする。
    if circles is not None and len(circles) > 0:

        #型をfloat32からunit16に変更。
        circles = np.uint16(np.around(circles))
        
        for i in circles[0,:]:
            # 外側の円を描く
            cv2.circle(frame,(i[0], i[1]), i[2], (0, 191, 255), 2)
            # 中心の円を描く
            cv2.circle(frame,(i[0], i[1]), 2, (255, 255, 0), 2)
            # 円の数を数える
            j = j + 1

    #円の合計数を表示
    cv2.putText(frame,'Total :'+str(j), (30,30), fontType, 1, (0, 0, 0), 1, cv2.LINE_AA)

    #==============================================

    # 画像の表示
    cv2.imshow("Image", frame)
 
  # `s`キーを押すと画像を保存する
   if cv2.waitKey(1) == ord('s'):
        #結果の書き込み
        cv2.imwrite('image1.jpg',frame)   
  
    # `q`キーを押すとループを終了する
    if cv2.waitKey(1) == ord('q'):
        break

# カメラを閉じる
cap.release()

# すべてのウィンドウを閉じる
cv2.destroyAllWindows()

実行結果がこちら↓↓

これで円形状のものを検出し、数をカウントできるようになりました。

慣性モーメントを分かりやすく説明してみた

PR

「慣性モーメント(イナーシャ)」とは

<抽象度★★★★★>

物体の「回りにくさ」「止まりにくさ」を表す値です。


<抽象度★★★★☆>

直動系の超有名な方程式(ニュートンの運動の法則)
$$ F=ma =m \ddot x$$

[N] = [kg] [m/s2]

を回転系に直すと

$$ \tau =Ja= J \ddot \theta $$

[Nm] = [kg・m2] [rad/s2]

となり、ここに出てくる「J」が「慣性モーメント[kg・m2]」です。

すなわち、回転系における「重さ」を示す値と言えます。


<抽象度★★★☆☆>

機械設計において、慣性モーメントはモータの容量を計算する際に必要になります。

台形の速度プロファイルで回転体の位置決めをする場合、「角加速度」に「慣性モーメント」をかけると、モータに必要なトルクが分かります。(摩擦などの負荷トルクは無視しています)

慣性モーメントが大きいと必要なトルクが大きくなり、慣性モーメントが小さいと必要なトルクが小さくなることが分かります。


<抽象度★★☆☆☆>

下図のような質点mの回転を考えます。

この時、中心軸周りの回転の慣性モーメントは、

$$ J = mr^2 $$

で表されます。

ここで重要なのは、回転半径 \( r \) が大きいほど慣性モーメントが \( r^2 \) に比例して大きくなる点です。

つまり、同じ質量の物体でも、回転軸から遠い位置に質量があるほど「回しにくく・止めにくく」なります。

複数の質点がある場合は、それぞれの寄与を足し合わせます。

$$ J = \sum_i m_i r_i^2 $$


【円柱(ソリッドシャフト)の慣性モーメント】

実際の機械部品は質点ではなく体積を持つ物体です。均質な円柱(半径 \( R \)、質量 \( M \))の中心軸周りの慣性モーメントは、上の式を積分することで求められ、

$$ J = \frac{1}{2}MR^2 $$

となります。

たとえば、モータシャフトに取り付けるプーリーやフライホイールを設計する際は、この式を使って慣性モーメントを見積もります。

$$ J = \frac{1}{2}MR^2 = \frac{1}{2} \times \rho \times \pi R^2 L \times R^2 = \frac{\rho \pi L R^4}{2} $$

(\( \rho \):密度、\( L \):長さ)

半径 \( R \) が2倍になると慣性モーメントは 16倍(\( R^4 \) に比例)になるため、外径を大きくする際は注意が必要です。


【中空円筒(パイプ形状)の慣性モーメント】

内径 \( R_1 \)、外径 \( R_2 \) の中空円筒の場合は、

$$ J = \frac{1}{2}M(R_1^2 + R_2^2) $$

となります。

同じ質量でも中空にすることで外径を大きく取れるため、剛性を保ちながら慣性モーメントを効率よく増やしたい(フライホイール)場合や、逆に軽量化しながら慣性を抑えたい(高速回転ローラー)場合に活用されます。

これらの基本形状の慣性モーメントを組み合わせることで、複雑な機械部品の慣性モーメントも計算できます。


<抽象度★☆☆☆☆>

【実際の設計例:モータ選定での慣性モーメント計算】

例として、ステンレス製のローラー(円柱)をサーボモータで回転させる場合を考えます。

  • 材質:ステンレス(密度 \( \rho = 7900 \, \mathrm{kg/m^3} \))
  • 外径:\( \phi 100 \, \mathrm{mm} \)(半径 \( R = 0.05 \, \mathrm{m} \))
  • 長さ:\( L = 200 \, \mathrm{mm} = 0.2 \, \mathrm{m} \)

① ローラーの質量を求める

$$ M = \rho \pi R^2 L = 7900 \times \pi \times 0.05^2 \times 0.2 \approx 12.4 \, \mathrm{kg} $$

② ローラーの慣性モーメントを求める

$$ J = \frac{1}{2}MR^2 = \frac{1}{2} \times 12.4 \times 0.05^2 \approx 1.55 \times 10^{-2} \, \mathrm{kg \cdot m^2} $$

③ 必要トルクを求める

台形の速度プロファイルで、0.1秒で100 rpm まで加速したい場合:

$$ \omega = 100 \, \mathrm{rpm} = \frac{100 \times 2\pi}{60} \approx 10.5 \, \mathrm{rad/s} $$

$$ \dot{\omega} = \frac{10.5}{0.1} = 105 \, \mathrm{rad/s^2} $$

$$ \tau = J \dot{\omega} = 1.55 \times 10^{-2} \times 105 \approx 1.63 \, \mathrm{Nm} $$

モータの定格トルクがこの値を上回るものを選定すればOKです(実際には摩擦トルクや安全率も加味します)。


【設計のポイント:イナーシャ比】

モータ選定では慣性モーメントの絶対値だけでなく、モータ自身の慣性モーメント \( J_M \) に対する負荷側の慣性モーメント \( J_L \) の比(イナーシャ比)も重要です。

$$ \text{イナーシャ比} = \frac{J_L}{J_M} $$

イナーシャ比が大きすぎると、モータが負荷をうまく制御できず発振や整定時間の悪化につながります。一般的なサーボシステムでは、メーカー推奨のイナーシャ比(目安:30倍以下)に収めることが推奨されています。

イナーシャ比が大きくなる場合の対策としては、以下が挙げられます。

  • ローラーの外径を小さくする(\( J \) は \( R^4 \) に比例するため効果大)
  • 中空構造にして質量を減らす
  • 減速機を挟む(減速比 \( n \) の2乗分だけ負荷慣性をモータ側から見て小さくできる)

減速機を挟んだ場合、モータ軸から見た負荷の慣性モーメントは

$$ J_L’ = \frac{J_L}{n^2} $$

となり減速比の2乗に比例するため、イナーシャ比の改善に非常に有効です。


もう一歩踏み込んでモータの設計原理を知りたい実務者のかたはこちらの書籍がおススメです

「入門 モータ設計」(森本雅之 著)

https://amzn.to/3T9Jdim

慣性モーメントについて詳しく知りたいかたはこちらの書籍がおススメです

設計者のための慣性モ-メント設計計算 (川北 和明 , 藤 智亮 著)

https://amzn.to/4pAh0gU

本記事はアフィリエイトリンクを含みます。

バイラテラル制御とは?モータで触覚を伝送する技術をわかりやすく解説

バイラテラル制御[1] とは、ひと言で言うと「モータを使って触覚を伝送する技術」です。

人が与える作用力と、物体から返ってる反作用力をそれぞれモータ(またはセンサ)で測定できるようにしておきます。

その上で、測定した作用力を物体側へ、反作用力を人側へ送り、各モータで出力します。

ざっくり言うと、このようにして触覚をモータ間で伝達する事ができます。

(厳密にはモード空間での制御が必要ですが、ここでは簡単にイメージのみ説明します。)

バイラテラル制御の面白いところは、触覚情報が、文字通り「情報」になっているため、簡単に加工する事ができるところです。

〈遠隔操作〉

触覚情報を遠隔地に伝送すれば、遠隔操作が可能になります。

〈スケーリング〉

人の力を増幅すれば、テコの原理を扱うように、大きな力で物体を操作する事ができます。

逆に、人の力を減少させて伝えれば、微細で繊細な物体を安全に取り扱うことができます。

〈保存・再現〉

人の与えた作用力をデータとして保存しておけば、CDに音楽を保存して再生するかのように、人間の動作を再現できます。

このように、バイラテラル制御を用いれば、モータを利用したアプリケーションの幅が広がります。

[1] W. Iida and K. Ohnishi, “Reproducibility and operationality in bilateral teleoperation,” The 8th IEEE International Workshop on Advanced Motion Control, 2004. AMC ’04., 2004, pp. 217-222, doi: 10.1109/AMC.2004.1297669.

https://ieeexplore.ieee.org/document/1297669

抽象化の実践方法「Why」と「How」の使い分け(vol.2)

PR

前回、『具体 ⇒ 抽象 ⇒ 具体』という『縦』の移動を行うことが、質の良いアウトプットを出すために重要という話をしました。
でも、縦に移動しろと言われてもどうやってやればいいんですか?って方のために、『具体 ⇒ 抽象 ⇒ 具体』の縦移動を行うための考え方[1]を紹介したいと思います。

具体 ⇒ 抽象(抽象化)=『Why』を問う

まずは『具体 ⇒ 抽象』の抽象化フェーズです。抽象化するには『Why(なぜ)』を問います。

例えば、あなたが新製品開発プロジェクトのメンバーで、上司から、ステッピングモータ1軸・ボールねじ・直動ガイドを組み合わせたようなあるユニットの詳細設計を任されたとします。
ここで、上司から与えられた構成を何の疑いもなくそのまま採用し、設計してしまうのは三流の設計者のやることだと思います。
優秀な設計者は必ず設計時に『具体 ⇒ 抽象』(抽象化)を行います。
<第一段階の抽象化>
・なぜボールねじを使うのか?その他の直動変換ではダメか?
・なぜステッピングモータを使うのか?その他のアクチュエータではダメか?
などです。

そして上記を考えてくと、その過程で必ずこの設計に求められている要求仕様にスポットが当たります。
<第二段階の抽象化>
・なぜこのようなスペックを求められているのか?(スピードや精度)
・なぜこのようなスペースの制約があるか?
実は絶対的な制約と思われていたことも、ある条件下では制約でなくなったりする場合もあります。そういった部分も紐解いていかないと、製品全体として良いものは作れません。
そのためには、上司だけでなく、他の設計者や営業などの他部署との関わりも出てくるため、主体的な姿勢が必要になります。
すなわち、部分最適でなく全体最適を目指した相互コミュニケーションが必要になります。

上記を考えていくと、さらに上位の視点まで視野が広がります。
<第三段階の抽象化>
・なぜこのユニットが必要なのか?
・そもそも使用するお客様は何を求めているか?

このように、なぜを問い続けることで抽象化が進み、より上位の視点で自分の仕事を捉えることができます。
このような姿勢は、トヨタの「なぜなぜ5回」や、ホンダの「A00」と本質的には同じであり、抽象化がとても重要なことであることを物語っています。


上記は製品開発の例ですが、他の例も下記に示します。

<製品企画段階の例>
お客様の「顕在ニーズ」から「潜在ニーズ」を探るフェーズがまさに抽象化が必要なフェーズだと思います。
お客様の生の声にただ従ってしまうと、本当に良い製品のコンセプトは作れません。なぜお客様はそう言っているのか。Whyを問いましょう。

<流用設計の例>
過去の設計者がなぜそのように設計したのか。Whyを問いましょう。Whyを問うことで設計意図が見えてきます。過去の設計者(生み出した世代)の人たちの意図を汲み取っていかないと、何も根本的に変えられない小手先の変化しか生み出せない設計者になってしまいます。

抽象 ⇒ 具体(具体化)=『How』を問う

Whyを突き詰めて問題を抽象化できたら、次にその解決策を考えるために具体化を行います。具体化には『How(どのように)』を問います。
抽象化する前とした後では、Howの選択肢(自由度)がとても広がっていることが分かると思います。景色が広がるため、本当に良い手段も見つけられる可能性が高まります。具体から具体は見えにくいのですが、抽象から具体は見やすいのです。地上からは隣町の様子は見えませんが、空からは見ることができます。
具体化には、ピラミッドの横軸(知識の幅)が必要になります。知識の幅が狭いと、せっかく広い景色が見えたにもかかわらず、良い解にたどり着けません。
新製品開発の場合であれば、プロジェクトメンバーで抽象的な視点を共有したうえで、メンバーで議論することがとても重要だと思います。ここで担当者が自分の知識の幅でしか物事を考えられないと、製品としての可能性を狭めることになってしまいます。
自分なりによく考えたつもりでも、他のメンバーから意見をもらい「痛いところを突かれた」と思うことはよくあるかと思います。その瞬間は製品開発において大きなターニングポイントだと思います。その時の初動が、後に大きな差を生む場合もあります。
意地をはらず、真摯に他のメンバーの意見を受け入れ、自分なりに解釈し、最終的には自分なりに新たな答えを見つけることで、本当に良い開発ができるのだと思います。

<参考文献>

[1] 「具体 ⇔ 抽象」トレーニング、細谷功 著、PHP研究所

https://amzn.to/4b3OXQL

本記事はアフィリエイトリンクを含みます。

抽象化とは?「具体⇔抽象」の思考法をビジネス視点で解説(vol.1)

PR

そもそも抽象化とは?

上の図は、知の発展を表現した図です[1]
「横軸」の拡大は、知識の「量的」な拡大を意味しています。
「縦軸」は「抽象度」を示しています。上に行くほど「抽象的」、下に行くほど「具体的」な情報であることを意味しています。
例えば、小学生が漢字を勉強する場合、覚えた漢字の数だけ情報量が増えるため、三角形が横軸に広がります。ですが、ただひたすらに覚えるだけでは三角形は横にしか広がりません。
ここで、「さんずい」は水に関係するものであるなど、漢字にはある法則があることに気が付くと、情報を抽象化でき、三角形が縦方向に広がります。

漢字の学習の例


このように、抽象化とは「情報と情報の関係性」に着目し、その共通項・法則を発見することであり、縦方向に三角形を広げることで、具体の世界を俯瞰して眺めることのできる「鳥の目」を得ることができます。縦方向に成長できると、具体の世界の見通しが格段に良くなり、発想が豊かになります。みなさんにもそのような実感をした経験があるのではないでしょうか。

ここでは、抽象化とは何なのかを哲学していきたいと思います。
(哲学≒抽象化であるので、抽象化を抽象化していくということかもしれません。)

大事なのは縦の移動

ここで問題解決の3パターン[1]を見てみます

左の図は、具体病の人の問題解決です。
実際に起きていることに目が行き、そこに対する断片的な処置を施します。

真ん中の図は、抽象病の人の問題解決です。
机上で考えているだけで具体的な行動に落とし込めません。

右の図が、問題解決のあるべき姿です。
縦の移動を行うことで、起きた事象から根本原因に立ち返って対処できます。

新しい製品の開発を考えてみると・・・
・具体病(左):過去の設計資産に基づいて、ちょっと変更した設計を行う。(チェンジニアリング)
・抽象病(中):コンセプトだけ出して、具体的な設計に落とし込めない。(机上の空論)
・縦移動(右):顕在化した課題から潜在的な課題を導き、根本対策を施した設計をする。(イノベーション)

といったように、縦の移動を行うことで、良い製品の開発を行うことができます。

このように、具体的・抽象的であること自体ではなく、具体 ⇒ 抽象 ⇒ 具体の移動を行うことが重要で、質の良いアウトプットを出すために必要なのです。

<参考文献>

[1] 「具体 ⇔ 抽象」トレーニング、細谷功 著、PHP研究所

https://amzn.to/4b3OXQL

本記事はアフィリエイトリンクを含みます。

クロソイド曲線とは?曲率が一定に変化する曲線の仕組みを解説

ここでは、クロソイド曲線の紹介をします。

クロソイド曲線は「曲率の変化」が一定な曲線のことです。
曲率 (curvature) とは、曲線の曲がり具合を示す値であり、曲率を一定にしたまま線を伸ばしていくと円になります。その円の半径を「曲率半径」といい、曲率の逆数になります。

円の曲線の長さ\(q\)と接線ベクトルの角度\(\phi\)の関係を式に表すと以下になります。
$$ \phi=\phi_0+c_1 q $$
\(\phi_0\)は接線ベクトルの角度の初期値です。
ここで曲率\(c_v\)は、\(\phi\)を\(q\)で微分した値であり、円の場合は、
$$ c_v=c_1 = const. $$
となることが分かります。

曲率を曲線の長さに対して一定に変化させていったものがクロソイドで、その曲線の長さ\(q\)と接線ベクトルの角度\(\phi\)の関係は下記になります。
$$ \phi=\phi_0+c_1 q + c_2 q^2$$

円の場合と同様に、\(\phi\)を\(q\)で微分すると、
$$ c_v=c_1 + \frac{1}{2}c_2 q$$
となり、曲線の長さに対して一定の割合で変化していることが分かります。


ここで、わかりやすい例として、車で考えてみたいと思います。
曲線を車の通った道だとすると、曲率はハンドルの傾き(回した量)と同じになります。
ハンドルを一定の傾きで固定した状態で走れば、車の通る道は円を描きます。

車が走った距離に応じて、ハンドルを一定の速度で回していったときに車の通った道が描く曲線がクロソイドになります。

ハンドルを急に切る必要がないため、高速道路の出入り口の曲線の設計などに用いられているそうです。

クロソイド曲線に関して、詳しくはこちらの論文に記載しています。

I. Takeuchi and S. Katsura, “Interpolation of a Clothoid Curve Based on Iterative True-Value Prediction Considering the Discretization Error,” in IEEE Transactions on Industrial Informatics, vol. 14, no. 11, pp. 5156-5166, Nov. 2018, doi: 10.1109/TII.2018.2797925.

https://ieeexplore.ieee.org/document/8269384