OSXでの ddによる書き出し

あらかじめやっておくこと


diskutil list で書き出し先ディスクを確認する.

MBP:/ user$ diskutil list
 (略)
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.7 GB    disk3
   1:             Windows_FAT_32 boot                    62.9 MB    disk3s1
   2:                      Linux                         3.9 GB     disk3s2

外付け SDカードリーダーを使用しているが,disk3になっていた.パーティション構成から想像が付く方もいるかもしれないが,Raspberry Piである.

接続した際に自動的にマウントされるが,このまま ddを走らせてもエラーになるのでアンマウントする必要がある.

単一のパーティションを umountする diskutil unmountでも ディスクそのものを認識させなくする diskutil ejectでもなく, diskutil unmountDiskを用いること.

MBP:/ user$ diskutil unmountDisk /dev/disk3
Unmount of all volumes on disk3 was successful

ddについて


ディスク名の先頭に rを付けることにより Unbuffered Modeになる.

また bs=1m などでブロックサイズを 1m程度で設定すること.

この二つを設定しないと,とてつもなく遅くなる.

MBP:/ user$ sudo dd if=some_image_file.img of=/dev/rdisk3 bs=1m

dd中の進行状況の確認方法.

別コンソールを用意するなどして killallでシグナル INFOを送ると dd側のプロセスでログを吐く.

OSX以外では USR1らしい.

MBP:/ user$ sudo killall -INFO dd

73+0 records in
72+0 records out
75497472 bytes transferred in 11.541480 secs (6541403 bytes/sec)

もしくは Ctrl-T.別コンソールが要らないのでこっちの方がお手軽か.

書き込み完了後


マウント可能な場合は自動的にマウントされ,OSX独自の隠しファイルが作成されてしまう.

念のため消した上で,今度は diskutil ejectする.

MBP:/ user$ rm -rf /Volumes/DISK_NAME/.*
rm: "." and ".." may not be removed
MBP:/ user$ diskutil eject /dev/disk3
Disk /dev/disk3 ejected

以上.

Kinect v2,Mac OSXで動作確認

f:id:gt1000:20150508205527p:plain

次は Kinect v2.

本体は GW直前にヤフオクで入手.しかし Adapter Kitの入手が鬼門だった.
ヨドバシで買うつもりが GW突入と同時に品切れ.取り寄せになるも物流は止まる.そして今朝 Yodobashi.comで在庫の復活を確認し,予約取り置きしてもらった.

 

続きを読む

RealSense F200,Mac OSXで動作確認

f:id:gt1000:20150503160144p:plain

 

Intelの RealSense F200を入手.
Windows8.1で サンプルを動かして動確したのち,MBPで動作させた.
最低動作環境に "4th Generation Intel Core processor or higher"とあり Sandy Bridge & Ivy Bridgeでは動かないかとヒヤヒヤしたが,そんなことは無かった. 

 

参考にしたのはこのページ.

 

この人は Linuxカーネルパッチを自作した模様.Mac OS Xと書いてあるが,「今後の見通しが立った」程度で,この時点で OSXで動かしていたワケではない.ただ記事中にある "libuvc driver working with the real sense camera" というのが役に立ちそう.

 

 

なんやらうまく動かないらしいが,よしよしおじさんが見てあげよう.githubから cloneしてサンプルをビルドしてテスト.数フレーム読み込めるけど刺さる,という排他処理できてないんじゃないの?的な挙動を示したので,ソースを読んでいったところ予想通りバッファの持ち方と pthread_cond_waitの使い方の問題で刺さりうる箇所を発見.真面目に直す気は無いので単純にバッファを持たなくした (LIBUVC_NUM_TRANSFER_BUFS を 1に設定した) ら動くようになった. 

「F200@OSXで問題なく Depthを出せるようになった」というのでは世界初じゃね?

ただ RGBとのレジストレーションとかは自作する必要がありそう.

 

KiCad on OSX

まさに備忘録.

 

Cernが全力で後援しているフリーの電気/基板 CAD KiCad.

その Cernが実装した押しのけ配線というステキ機能を OSXで利用するためには,ソースコードからビルドする必要がある.だがフツーにビルドすると 二本指タッチがスケーリングにバインディングされてしまい使い物にならないという罠がある.

ソレを解決したブランチがコレ.

osx-trackpad-gestures : Code : KiCad

 


Mac OS X でオープンソース電子 CAD の KiCad をインストールする - ochalog

上記はフツーにビルドする場合だが,コレに対する差分としてのビルド手順をまとめておく.
ポイントはたったの 3つ.

ソースコードは上記ブランチから取得する.
>bzr branch lp:~gcorral/kicad/osx-trackpad-gestures

wxwidgetsのビルドスクリプトを実行する前にパッチを当てる
> cd wx-src
> patch -p0 < ../kicad/patches/wxwidgets-3.0.0_macosx_scrolledwindow.patch
> patch -p0 < ../kicad/patches/wxwidgets-3.0.0_macosx_magnify_event.patch

・本体の CMake時に Defineを追加する
 -DUSE_OSX_MAGNIFY_EVENT=ON

 

 

GoogleEarthでGPSトラックを表示させるテクニックについて

  • 高度プロファイルを表示しておく.これにより左上のトラックバーとは無関係にトラックの入と出が管理できる.
  • Shift (平行移動/パンチルト切り替え)+Option(通常速度/低速切り替え)(WindowsならAlt)+方向キーでスローなパンチルトが可能.

リチウムイオン電池の内部抵抗

GoPro4

 純正 165.1mΩ@4.28V

 Wasabi1 194.0mΩ@4.29V

 Wasabi2 191.4mΩ@4.28V

GoPro3

 純正 135.5mΩ@4.23V

 Wasabi1 188.4mΩ@4.23V

 Wasabi2 340.7mΩ@4.23V

NP-BX1

 純正2 161.5mΩ@4.18V

 

Turnigy LiFe

 65.92mΩ@11.04V

噴火はしませんでした

12/28(日)深夜〜 12/31(水)

 今シーズンの蔵王は主催者長男の部活の関係で年末となった.というかそろそろ遠慮すべきな気もするが,昨年から次男も参加するようになり,そちらに意識を傾けざるを得ないのに対して,糸の切れたタコのようにすっ飛んでいく長男を確保する人員は必要なのである.

 今年のネタはマルチカムである.メインの GoPro4は自撮り棒ストック,GoPro3はキャップにクリップマウントで AS100Vはブーツの甲付近のビンディングにクリップマウント.で,結論から言うと「動画」はストックかスタビライザを使わない場合,撮りっぱなしの画だと全くといって良いほど役に立たない.静止状態ならまぁ使えるが,ソレもヘッドマウントはまだしも,という話であってボードマウントは明後日の方向を向いていることが多い.ということで,敢えてタイムラスプにしてみた.

 AS100Vは最小インターバルが 1secであるが (GoProは 0.5sec),1920x1080で撮れるので (というかこの解像度に固定されるので) 容量的には非常に都合が良いシステムである.バッテリーも満タン時の撮りっぱなしで 3時間は持ち,スペアバッテリーと併せて 6時間分 21600枚を 1.5MBで撮影しても 32GBに収まる計算である (実際には 1MBを切る).

 それに対して GoProは解像度が 2560x1920で,平均 2.5MBほどであるのでややあふれてしまううえにバッテリーのもちが若干悪い.そもそももちが悪い Wasabiのスペア 2個と併せて 3個体勢で回して 6時間くらいだろうか.

 ちなみに 21600枚を 30fpsにかけると720秒,12分となる.実際には 15fpsくらいで敢えてカクカク感を出した方が良いシーンもあることを追記しておく.

 

実験:自室 (室温約20度)で 2560x1920@1secの撮りっぱなし.

1.4.27V出ていた Wasabi@GoPro3

  8446枚 (25.14 GB,平均 3MB) → 3.67V

 一応 2時間以上もった.解像度はそのまま使うには微妙だが,完全静止状態であればパンニングができる.どちらかというと GoProはそっち向きの機材と考えるべきかもしれない.

2.4.27V出ていた 純正@GoPro3

  9451枚 (22.14 GB,平均 2.40MB) → 3.555V

 2時間半ちょい.Wasabiと比較して電圧が低いところまで使える,ということは内部抵抗が低いと思われる.やっぱ抵抗計買うか.

3.4.29V出ていた Wasabi@GoPro4

  7257枚 (17.21 GB,平均 2.42MB) → 3.419V

 ギリギリ 2時間もった.しかし,そもそも GoPro4でタイムラスプをしようとは思わない.

4.4.29V出ていた 純正@GoPro4

  8122枚 (18.32 GB,平均 2.31MB) → 3.373V

 2時間以上もった.GoPro4は電池電圧が 3.8Vで,終端電圧も低いところまで使えるようになっている.消費電力自体は間違いなく増えているだろうが,低電圧なシステムで電流を絞り出して電力を稼ぐタイプのようだ.バッテリーにはキツいシステムである.

5.4.18V出ていた 純正NP-BX1@AS100V

  13820枚 (7.73 GB,平均 586KB) → 3.160V

 3時間50分で 8GB未満という燃費の良さ.

で,コレがなんの役に立つのか,まだよく分からない.