Raspberry Pi2強制空冷

Raspberry Pi2にそれなりに重い処理をさせると熱が気になりますが、Webカメラサーバーと無線LANくらいであればヒートシンクをつけてケースに閉じ込めていても大丈夫なようです。

九州でも夏の間一度も停止することなく過ごすことが出来ました。RaspberryPiは意外と熱に強いようです。

ただ、やはりセンサー値で60℃を超えることもあるので、強制空冷を試してみました。

強制空冷と言っても、こんな感じでケースの上に8cmファンを直付しただけです。
ケースも下部に穴が開いているだけのものなので、ケースに直接風を当てることになります。

こんな雑な空冷意味がないだろうと思っていましたが、下のグラフのように10℃近く温度を下げることが出来ました。 空冷恐るべし。

この実験は秋に行ったものなので、夏場では外気温も上がり、もう少し効率は落ちるかもしれません。

ケースを殆ど密閉状態にしていても空冷できることがわかったので、基板がホコリまみれになる心配がなく、 長期的に安定稼働させられそうです。

さすがに常時回転させると気になるくらいの音が出るので、RaspberryPiからCPU温度によって回転数を制御してあげると良さそうです。

Inkscapeでグループ化した図形を変形するとtransform属性が付く

Inkscapeで作業している時に、水平半径と垂直半径を同じにしても矩形の角の丸みが同じにならない問題に悩まされました。

最初はバグかな、とも思ったのですが、XMLを見てみるとtransformという属性がグループに付いていることがわかりました。

グループ化されたオブジェクトを変形すると、transform属性がつくようです。 グループ化していることを忘れて単独の矩形を編集していたのが原因でした。

言われてみると当たり前なのですが、だいぶ悩まされてしまいました。

gitはC風に理解したらいいのかな？

gitをしばらく使ってみても、いまいちよくわからないままでした。 なんとなくスッキリしない感じでした。

でも、ふと「ポインタ」という用語を見て 「C言語風に理解できるんじゃないか？」 と考えてみると、少しだけ理解できたような気分になりました。

gitでの	C言語で言うところの
tree,commit,blob,tag等のオブジェクト	構造体の実体
ハッシュ	構造体へのポインタ値
パス("refs/heads/master"など)	構造体へのポインタへのポインタ値
ブランチ、軽量タグ	構造体へのポインタ(型変数)
HEAD	構造体へのポインタへのポインタ(型変数)
gitによる木、バージョン管理	構造体のリンクリスト

という感じではないでしょうか？ なんだか回りくどいような気もしますが…

追記1 : detached HEADの場合は直接コミットを指すようなので、HEADはvoid *型変数と言えるかもしれません。

KolourPaint

WindowsからUbuntuに移行しようと試してみたけど、戻ってしまった方も多いかと思います。 私も最初の頃はメインに使うまでにはなかなか至りませんでした。

理由は人によって様々だと思いますが、私の場合は「ペイントがない！」この一点です。

そんなあなたにこのソフト。「KolourPaint」です。

スクリーンショットを見ればきっと説明は不要だと思います。

今はWindowsでも見られないこの感じ。これぞペイント。

他にもペイント風ソフトはいくつかあるのですが、私はこれが一番しっくりきました。 Linux版ペイントをお探しの方はぜひ試してみてください。

motionが保存する動画が早回しになる

追記1 : github上に点在していたmotionの改変版がまとまりつつあるようです。今後はこちらのバージョンがメジャーになっていくものと思われます。

https://motion-project.github.io/

motionという、webカメラの画像に移動検出をかけたり、動画として保存したり、ストリーミング配信できたりする便利なソフトウェアがあります。 LinuxなどのOSで動作するのでRaspberry piで利用されることも多いようです。

しかし、debianとUbuntu上の現在のバージョン(3.2.12+git20140228-4など)には、カメラのフレームレートが高い場合、動画に保存される画像が毎秒３枚分に制限されてしまい、にもかかわらず動画のフレームレートにはカメラのフレームレートが設定されるという挙動が存在します。

この挙動の結果、カメラからの画像がほとんど保存されず、早回しの動画になってしまいます。

原因

これは、カメラのフレームレートが高速である場合に移動検出を毎秒３枚までに制限する機能の副作用によって発生しています。おそらく、設計時に意図されていたものとは異なる挙動であると考えられるので、バグの可能性があります。

対処

この問題はmotion内部の画像を保存するリングバッファーのサイズが１の場合に発生するようです。

従って/etc/motion/motion.confで、

• pre_captureを1以上
• minimum_motion_framesを2以上

のいずれかを設定することでこの挙動を抑制することができます。

また、この問題を発生させている部分を特定できたので、debian上のmotion_3.2.12+git20140228-4の場合、以下のパッチを適用することでこの挙動を抑制することができます。ただし、私の利用する範囲内での動作しか確認できていないため、他の問題を引き起こす可能性があります。

--- a/motion.c
+++ b/motion.c
@@ -1294,7 +1294,7 @@ static void *motion_loop(void *arg)
                 cnt->current_image->timestamp_tm = old_image->timestamp_tm;
                 cnt->current_image->shot = old_image->shot;
                 cnt->current_image->cent_dist = old_image->cent_dist;
-                cnt->current_image->flags = old_image->flags;
+                cnt->current_image->flags = 0;
                 cnt->current_image->location = old_image->location;
                 cnt->current_image->total_labels = old_image->total_labels;
             }

github上にはこの問題を修正した上で、さらに機能が追加されたmotionも公開されているので、そちらを利用するのも良いかもしれません。