2008年の夏、とある広場でラジコンヘリに携帯電話を取り付けて空から動画を撮影した。そのときの空撮動画をアップしています。

ここのところ気温も涼しくなってきて機体のセッティングも落ち着き、好調にフライトしていた。上空でスタントも焦ることも減ってきて、飛ばしていて楽しい。スーパーボイジャーEではじめてロールをしてみる。軸がきれいに通ったロールをするではないか。

今日はヘリの他、電動グライダーClimb400Vをもってきたので、グライダーを飛ばす。

丘陵地の頂上付近から若干下がったフィールドであり、頂上から風下に位置するため、若干風が乱れていてフラフラしたが、たまにはグライダーでのんびり操縦を楽しむのも良い。モーターランを数回した後、首が疲れてきたので着陸させる。

空中分解

バッテリー2本目を飛ばす。若干荒れた気流の中でアイレベルホバリングでいかに定点に止めておけるか頑張る。そのご上空へ。気持ちよく決まるロールをしようと、機速を付けて袖から手前へ引っ張ってきた時に、事故は起こった。

ちょうどロールに入れようとしたところで何か黒い物体が機体から外れた！ 「ババッ」と、にぶい音。ローターに巻き込んだ。

ロールは中止。

一応、コントロールは効いている。早く降ろさなきゃ。

ん？ん？

だんだんコントロールが効かなくなって、機体は背面状態で地上に「どーん！！」

その光景はスローモーションを見ているように目に焼き付いた。 ローターブレードがちぎれて宙を舞う。。 墜ちた機体は草むらの中に消える。

上空飛行中、何かが空中分解したようだった。

墜ちたヘリの残骸を集めて、急遽「航空事故調査委員会」をひらく。（←大げさ。でも重要）

墜落地点にキャノピーが無い事がわかって、キャノピーを探す。 あったあった。飛行中に何かが外れた！と思った地点の地上辺りに墜ちていた。 ローターでザックリ割かれている。

墜落の原因：

飛行中に風圧でキャノピーが外れ、
それが、ローター、ローターヘッドに当たり、
リンケージにダメージを与え、
舵がきかなくなり、
操縦不能になり墜落。

根本原因：

整備不良。
キャノピーが外れやすい状態のままフライトしたため。

点検整備を見直さなきゃいけないなと思い知らされました。

幸いにして、地上付近に降ろす間は舵がきいていたため、 上空から思わぬところにすっ飛んでいく危険は防げた。 ラジコンヘリは殺人マシンとなりえるので、本当にこれは幸いした。 地上付近でノーコン、墜落だったため、大破は避けられた。

破損パーツ

メインローター
メインマスト
スピンドル
スタビバー
シーソー
シーソーアーム（キャノピーがあたった衝撃でか、ネジ穴もろとも吹っ飛んだらしく、見つからず）
メインギア
スキッド
キャノピー
クロスメンバー

前回の日記XOOPS Cube と PHP5, MySQL5 の相性でも書いたが、新しいバージョンのOS、PHP、MySQLでXOOPSを再構築した時に、MySQL5でのDB作成時にどつぼにはまっていた。

既に作成済みのDBの文字コードを変更する

とりあえずXOOPSの動作確認が取れた時のMySQLのデフォルトで作成した文字コードがlatin1のDBで、XOOPSの設定やコンテンツを登録したため、後になって問題が出てきた。 その問題とは、DBをバックアップ（ダンプ：mysqldump）した時に、ダンプファイルをテキストエディタで開くと、文字化けしているのである。無理矢理文字コードを変換すれば日本語で読める文字に直せるのだろうけど、今後の運用で問題となりそうなので、ujis（EUC-JP）へ変換（データマイグレーション）できないか調べてみた。 既に文字コードが latin1 で作成されたMySQLのDBを、構造と格納されているデータはそのまま、ujis（EUC-JP）に変換したいのだ。 ネットでこのようなMySQLの文字コードマイグレーションをされている方の情報を探す。 あんじーのテクニカルブログさんのサイトで、文字コードを変換する方法が紹介されていたので、この方法を試してみた。

文字コード変更の大まかな手順

１，DBをbinaryでダンプを取る。
２，ダンプファイル内のSQLでlatin1に指定されている構造部分のSQLをujisに手作業で変換する
３，ダンプファイルをujiでレストアする。

DBの文字コードをlatin1からujis(EUC-JP)に変更する手順

まず、現状のDBがどのような文字コード設定になっているかSQLを叩いて確認

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.02 sec)

フムフム。DBは確かに「latin1」で作られているみたい。

mysqldump --default-character-set=binary -u ユーザ名 DB名 --password=パスワード > ダンプの出力ファイルパス

出力されたダンプファイルをテキストエディタで開いて、charsetが指定されている箇所をlatin1からujisへ全て置換する。 次に、ujisに置換したダンプファイルからDBをレストアする。

mysql -u ユーザ名 -p DB名 --default-character-set=ujis < ダンプファイル名

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.01 sec)

alter database でキャラセットをujisに変更する。

mysql> alter database DB名 character set ujis;
Query OK, 1 row affected (0.00 sec)

構造を確認する。

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | ujis |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

databaseの文字コードがujisに変わっている。

MySQLの設定ファイル（/etc/my.cnf）の修正を行う。

[mysqld]
default-character-set=ujis
skip-character-set-client-handshake

を設定ファイルに追加して、MySQLを再起動する。

service mysqld start

再起動後のDBの構造を確認

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | ujis |
| character_set_connection | ujis |
| character_set_database | ujis |
| character_set_filesystem | binary |
| character_set_results | ujis |
| character_set_server | ujis |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

これで文字コードが latin1 だったMySQLのデータベースが、ujis(EUC-JP)のデータベースとして使用する事ができる。 これで元もとlatin1の文字コードだったDBをujis（EUC-JP）のDBへ移行する作業が完了。

PHP5では「$HTTP_SERVER_VARS」変数が使えない

PHP5では「$HTTP_SERVER_VARS」変数が使えなくなったらしい。次のサイト PHPスクリプト講座:サーバ変数についてに、

PHP5以降では「register_long_arrays」という設定値がOFFであれば$HTTP_SERVER_VARSは使えません。

とある。ただ、これはphp.iniファイルの設定で使えるようにできるとの事。php.iniの次の設定をONにすればよい。

register_long_arrays = Off　→　On

しかし、これだけではまだPHPのエラーが出てダメであった。

PHP5のPHP4互換モード

ネットで情報収集していると、PHP5をPHP4として動作させる設定があるみたい。

PHP 5には、PHP 4（Zend Engine 1）との互換性を保つための設定ディレクティブが用意されている。下記のディレクティブをphp.iniに挿入すると、PHP 5はZend Engine 1（PHP 4）互換モードで動作する。

zend.ze1_compatibility_mode On

この設定で、XOOPSが動くようになるか？と思ったが、結局これも動かなかった。 最終的にはPHP5で古いXOOPSを動かすのは諦めた。

XOOPS動作に必要なMySQL5の文字コード指定

そこで、PHP5とMySQL5で動作するXOOPS Cubeに入れ替える事にした。 動作環境 | XoopsCubeのサイトには、「PHP5以上であっても問題なく動作する。」と書かれているので、最新版をDLする。この時の最新版バージョンは　「XOOPS Cube Legacy 2.1.5」 MySQLに関しては特に何も気にせず適当にDBを作成した。適当というのは、文字コードの指定など特にせず、デフォルトで作った。ということ。 XOOPS Cubeの初期設定も問題なく完了。いざ出来上がったサイトにアクセスしてみると、メニューなどの文字が「??????」と表示される。テンプレートに書かれている文字は問題なく表示されている。どうもDBから取得している文字の文字コードが怪しい。

ネット上には同じような問題が起こっている方がいらっしゃって、Xoops Cube文字化け解消！には

原因は単純でMySQLのCHARACTER SETでした。だってー、CentOSに入ってるMySQLのdefault CHARACTER SETってlatin1なんだもん、、、cp1252 West European [ latin1_swedish_ci ]ってなんだよー。

とのこと。デフォルトの文字コードはujis（EUC-JP）でもなく、UTF-8でもないんだって。でもってなんでlatin1なんだ！？と思ってしまった。 DBを作成する時に、次のように文字コードをujis（EUC-JP）で指定してあげる必要がある。とのこと。

create database db_name CHARACTER SET ujis;

そこで、DBの作り直しから。

PHP5とMySQL5で動作するXOOPSのバージョン

DBの環境は揃った。同じようにXOOPS Cubeの初期セットアップを行い、問題なく完了。 とりあえず文字化けは直ったが、管理機能を使用しようとしても画面に管理項目が表示されない。（メニュー一覧は表示されているのだが）

最新のソースがいけないのか、XOOPS Cube Legacyにある旧安定番 XOOPS 2.0.16a JP をインストール。（文字コードはEUC） このバージョンだと問題なく動いた。 最終的にPHPとMySQL、XOOPS Cubeの組み合わせは次のようなバージョンの組み合わせとなった。

CentOS 5.1
PHP 5.1.6
MySQL 5.0.45 （ujisの設定で使用）
Xoops 　XOOPS 2.0.16a JP

これまでDBといえばPostgresqlをメインに使用してきたためMySQLの使い方は特に知らなかった。というか知らなくて済んだ。またxoopsをPostgresqlで使っていたのだが拡張性に優れず、いろいろ問題に直面していたため、本来のMySQLに戻す事にした。

Postgressqlは仕事でもよく使っていたので、結構細かい事もわかるのだが、MySQLについては知識が浅い。とりあえずMySQLを使う為に必要な情報をメモ書きする。

MySQLの起動

service mysqld { start | stop | restart | status }

MySQLのデータ格納パス

デフォルトのMySQLのデータ格納パスは

/var/lib/mysql

初期状態からのrootパスワードの変更

初めてMySQLを起動すると、いろいろなものが初期化される。MySQLを操作する管理ユーザー root　のパスワードも初期状態では設定されていないようなので、rootにパスワードを付与する

/usr/bin/mysqladmin -u root password 'パスワード'

ログイン（パスワード要求）

rootでMySQLにログインする。（この場合はDB指定無し）

mysql -u root -p

DBの作成

とりあえずデータベースを作成してみる。mysqlにログイン後に次のSQLを実行する。
データベースの文字コードを指定したい場合は“CHARACTER SET ujis”のようにCHARACTER SET XXXXと付ける。ちなみにこの例の場合、 "ujis" はEUC-JPを指定している。

create database DB名 CHARACTER SET ujis;

MySQL5のデフォルト文字コードは latin1。今回使おうとしているxoopsの文字コードはEUC-JPなため、ujisを指定して作ってみた。ここは各自、自分の環境に合わせて頂きたい。

ユーザーの作成とデータベースへのアクセス権限付与

rootユーザのみでもデータベース操作は可能だが、rootでDBを操作させるのはセキュリティ的に危険。故に指定したDBのみ操作可能なユーザーを作成する。

grant all privileges on DB名.* to ユーザー名@localhost identified by 'パスワード' with grant option;

MySQLのバックアップ

/usr/bin/mysqldump DB名 -u ユーザー名 -pパスワード -x > バックアップファイル名

※この時、-pの後にスペースは入れない

BINDを9.3.4にバージョンアップした時の話。
BIND9.3.4インストール後、namedが起動できないワナに陥った。

rndc.key作成したりゾーンファイルを配置後、service コマンドを使ってnamedを起動してみると「失敗」する。

BIND UDPクエリソースポートのランダム化

named起動時にログに何かはき出されていないか、syslogを観察してみる。

Aug 18 23:37:27 wnsvr named[18965]: /etc/named.conf:38: using specific query-source port suppresses port randomization and can be insecure.
Aug 18 23:37:27 wnsvr named[18965]: command channel listening on 127.0.0.1#953

と出ていた。このエラーメッセージを元に、ネットで調べていると
http://www.jp.debian.org/security/2008/dsa-1603　に情報があった。

この更新では Debian の BIND 9 パッケージに推奨された対応策 (UDP クエリソースポートのランダム化) を実装しました。この変更は攻撃者が推定しなければならない探索空間のサイズを、後方互換性を守る形で拡大し、攻撃の成功を困難にします。
：
このようなメッセージが吐かれている場合、設定から対象となる行を削除するか、記載されているポート番号を "*" に置き換えてください (例えば、 "port 53" を "port *" に書き換える)。

との事で、うちのサーバのOSはDebianではないが、同様の対応は入っていると思われた。named.confファイルには

query-source address * port 53;

と53ポートを指定していたのだが、この指定が良くなかったようだ。指示されたようにnamed.ｃｏｎｆを書き換えて再起動してみる。しかし、syslogには特にエラーは出なくなったが、まだ「失敗」となって起動できない。
namedのログを別にはき出す設定にしているので、そちらを観察してみる。そうすると

19-Aug-2008 00:03:24.887 general: debug 1: now using logging configuration from config file
19-Aug-2008 00:03:24.887 general: critical: couldn't open pid file '/var/run/named/named.pid': Permission denied
19-Aug-2008 00:03:24.887 general: critical: exiting (due to early fatal error)

と、今度はアクセス権の問題がわざわいしていたようだ。
ただ、ディレクトリ /var/run/named/ のパーミッションを見直しても現象は変わらず、何がいけないか？？と悩んでいたが、chrootしている事を思い出す。
ディレクトリ /var/named/chroot/var/run/named/ のアクセス権を見直して、無事起動できた。
　 ]]> http://www.wingnotes.net/linux_server/bind934.html http://www.wingnotes.net/linux_server/bind934.html BIND Linuxサーバー BIND DNS Linux named Tue, 02 Sep 2008 18:05:05 +0900 Windows環境からLinuxのファイルシステムにアクセスするにはsambaを使用すれば実現できる。 逆にLinuxからWindows上の共有フォルダにアクセスするにはどうしたらよいか？

調べてみたら次の方法がある事がわかった。

①mountをつかう
②smbmountをつかう

mountでWindows共有にアクセスする

１、マウントポイントを作成する
　　※以下の場合では /mnt/win_share

２、mountコマンドでWindows共有フォルダにマウントする。
　　※以下の場合では、Windowsの共有フォルダshareに対してマウントしている。
　　　文字コード（cp932やutf8）は適宜環境に合わせる。

mount -t cifs -o username=common,codepage=cp932,iocharset=utf8 //windowsサーバ名（またはIPアドレス）/share /mnt/win_share

smbmountでWindows共有にアクセスする

Linuxにsambaをインストールしている場合は、smbmountという便利なコマンドが使える。
Windows共有フォルダにアクセスする時のユーザーを指定する事ができる。

smbmount //Windowsサーバ名（またはIPアドレス）/share /mnt/win_share/ -o username=administrator

注）ソースからsambaをインストールした場合、インストール時に --with-smbmount オプションを付けてコンパイルする必要あり。

そのほか様々なオプションがあるので、こちらを参考に。 http://www.samba.gr.jp/project/translation/3.0/htmldocs/smbmount.8.html

そうしょっちゅう行うものではないが、OSインストール時に毎回ネットから情報を収集して作業するのも面倒くさくなってきたので、備忘録的にWebにメモっておく。ここではインストールCDをisoから作成し、インストール、インストール後の各種設定を快適に行うための環境設定メモを記載している。

インストールしたOSの種類とバージョン

OS：CentOS バージョン5.2

LinuxインストールCDを作成する

CentOSのサイトからインストールCDのイメージ（isoイメージ）をダウンロードし、インストールCDを作成する。
CDを使用してのインストールに必要なISOイメージは
  CentOS-(バージョン番号)-i386-bin-1of6.iso
   ：
  CentOS-(バージョン番号)-i386-bin-6of6.iso
の6つ（6CD）を用意。
※インストール時に選択するモジュールによっては使用しないCDもある。

＜参考情報＞
Creator Classic で ISO イメージファイルから書き込む方法
http://www2.roxio.jp/support/faq/ecdc/E_F70040.html

CentOSをインストールする

ファイアウォール

インストール時にとりあえず次のポートの通信を許可する。
  ・http 　　　　　　webサーバへのアクセスに使用
  ・ftp 　　　　FTP通信に使用
  ・samba(smb) 　Windowsファイル共有に使用
  ・ssh 　　　　　　ターミナル接続に使用
  ・vncserver 　　　　　リモートアクセスに使用
  ・smtp 　　　　　　メール送信に使用

＜参考情報＞
Linuxのファイアウォールは「iptables」というプログラムで動作する。
インストール完了後に再度ファイアーウォールの見直しを行う。
http://penguin.nakayosi.jp/linux/iptables.html

CentOSインストール完了後のサービスの設定

次のサービスを使えるように基本的な設定を行う。
  ・sshd
  ・vncserver
  ・samba(smb)

sshd

rootのログインを制限する・指定したユーザー以外のログをンを禁止するには次の設定ファイルを編集する。
   /etc/ssh/sshd_config

PermitRootLogin no
AllowUsers ユーザ名

sshdを再起動する。

vncserver

何かと便利なデスクトップGNOMEのツールを使用したいので、GUIのリモート作業ができるようにvncserverの環境を構築する。
1,設定ファイルを編集する。
  /etc/ssh/sshd_config

$geometry = "1024x768";
$depth = 16;

2,vnc接続許可ユーザの設定を行う
  /etc/sysconfig/vncservers

VNCSERVERS="1:ユーザー名"
VNCSERVERARGS[1]="-geometry 1024x756 -nolisten tcp -nohttpd"

3,vnc接続許可ユーザファイルの作成
作成したいユーザでログインする。

su xxxxxx
パスワード：

次のコマンドを打つ
vncserver

vnc接続用パスワードを入力する。

4,xwindow(gnome)が起動するように設定する。
/home/ユーザ名/.vnc/xstartup を編集する。

#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &

上記2行の先頭に#を付けて、コメントアウトする。

exec gnome-session &

と1行記述し、vnc接続時にxwindow(gnome）が起動するように指定する。

5,vncserverを再起動する。

samba(smb)

1,linux上のファイルにWindows共有でアクセスするユーザー作成する。

smbpasswd -a ユーザー名
パスワード：

2,共有の設定・共有させるディレクトリを指定する
  /etc/samba/smb.conf

ワークグループ名やアクセスを許可するネットワークを指定する

workgroup=ワークグループ名
hosts allow = 192.168.10. 127.

LinuxとWindowsの文字コードの変換設定を追記する

dos charset = CP932
unix charset = UTF8
display charset = UTF8

共有するLinux上のディレクトリを指定する。

[public] #セクション名（任意）
　　　comment = public directory
　　　path = /var/public
　　　valid users = 接続許可するsmbユーザ名
#　　invalid users = 接続拒否するsmbユーザ名
#　　guest ok = ok
#　　only guest = ok
#　　public = yes
#　　browseable = yes
　　 writable = yes
　　 printable = no

3,smbを起動する。

先日の日記「HDD（ハードディスク）の寿命か」にも書いたが、SMARTを使ってHDD（ハードディスク）の温度を取得できる事がわかった。データが取れるという事はこのデータをもとにMRTGでグラフにできるはず。普段からHDDがどのくらいの温度環境にいるのかわかったらいいなぁ。と思いネットで調べてみた。

ハードディスクの温度を取得する

まず、MRTGでグラフのソースとなるHDDの温度を返すシェル（バッチ）を作成する。これはsmartコマンドの結果から'Temperature'の値を抽出するバッチ。うちのサーバー環境に合わせて2つ搭載されているHDDの温度を取るコマンドを2行書いた。このコマンドはこのサイト備忘録::Naka MRTGでCPU温度とHDD温度もグラフ化を参考にさせて頂いた。

#/bin/sh /usr/sbin/smartctl -A /dev/hda | grep Temperature | awk '{print $10}' /usr/sbin/smartctl -A /dev/hdb | grep Temperature | awk '{print $10}'

適当にファイル名を付け（私の環境ではhdd_temp.sh）て保存。正しく温度を返すかこのシェルを実行してみる。

[root@xxxx mrtg]# ./hdd_temp.sh 55 51 [root@xxxx mrtg]#

55℃と51℃を返した。コマンドはOK。でもハードディスクの温度55℃は高いなー。。。

MRTGの設定

次にこのシェルの結果を基データとしてMRTGでグラフ化して表示させる。MRTGの設定ファイル /etc/mrtg/mrtg.cfg に、このデータをグラフ化する設定を追記。

### HDD Temperature ### Target[hddtemp]: `/etc/mrtg/hdd_temp.sh` MaxBytes[hddtemp]:100 Unscaled[hddtemp]:dwmy Options[hddtemp]: gauge, growright, noinfo , nopercent Title[hddtemp]: HDD Temperature PageTop[hddtemp]: >H1&st;HDD Temperature Green:hda Blue:hdb>/H1< ShortLegend[hddtemp]: (Celsius) YLegend[hddtemp]: HDD Temperature(Celsius) LegendI[hddtemp]: hda LegendO[hddtemp]: hdb Legend1[hddtemp]: hda(Celsius)

この設定では“Target[hddtemp]: `/etc/mrtg/hdd_temp.sh`”でHDD温度を取得している。次のコマンドを実行してグラフが作成されるか動作確認を行う。

[root@xxxx mrtg]# /etc/mrtg/mrtg.sh

特にエラーがでなかった。実際にHTMLとグラフが作成されているかサイトにアクセスする。HTMLのファイル名はhddtemp.htmlで出力されているはずなので、URL直打ちで確認。正常に出力されていた。

indexmakerでMRTGのTOPページを作成する

最後に、MRTGのサマリページ（index.html）に今回追加したHDD温度のグラフを追加する。MRTGにはmakeindexというperlで書かれたindexを作成してくれるツールが用意されている。このコマンドの使い方を忘れてしまったので、ネットで調査。ここのサイトMRTGのインデックスページ作成 （indexmaker）を参考にさせてもらった。私の環境の場合は次のコマンドを使用した。

indexmaker /etc/mrtg/mrtg.cfg > /var/www/xxxx/mrtg/index.html

車にラジコンヘリコプターを積んで旅に出た。その旅先の天竜川河川敷にてスーパーボイジャーE（4セル）を飛ばしてた。ここのところ毎日真夏日で昼間に飛ばすと体が持たない。朝6時に河川敷に向かう。さすがに朝6時は誰もいなかったので周りを気にせずラジコンヘリコプターを飛ばす事ができた。

空撮動画【天竜川編編】

これまでの自分の撮影した空撮映像を見ていて、空撮をする場合は相当なめらかに操縦しないと目が回る映像になってしまうので、できる限りおとなしめに飛ばしてみた。

とはいえなめらかに操縦するのは難しいですね。フライト中、機体の姿勢を見失って焦りました。そこの箇所の画像が乱れてます。

サーバーから次のような異常を知らせるメールが届いた。

Subject: SMART error (CurrentPendingSector) detected on host: wnsvr.wingnotes.net This email was generated by the smartd daemon running on: host name: wnsvr.wingnotes.net DNS domain: wingnotes.net NIS domain: (none) The following warning/error was logged by the smartd daemon: Device: /dev/hda, 61 Currently unreadable (pending) sectors For details see host's SYSLOG (default: /var/log/messages). You can also use the smartctl utility for further investigation . No additional email messages about this problem will be sent.

半年前の日記サーバーのHDDから異音にも書いた。その後しばらく異音は落ち着いていたがとうとう寿命が来たのかもしれない。いろいろネットで情報を探していたら、smartctl コマンドでHDDの状態を調べる事ができるらしい。 そもそも、SMARTDというデーモン稼働していることで、HDDの異常を検知すると管理者にメール連絡してくれる。SMARTに対応しているHDDである事が前提との事。

SMARTとは

そもそもSMARTとは？

「S.M.A.R.T.」（Self-Monitoring, Analysis and Reporting Technology System)

というんだって。IDE Harddisk の故障・不具合を事前に検査し、故障の前触れを察知する技術。ハードウェアとソフトウェアの組み合わせで実現している機能のようだ。Linux上ではSMARTDというデーモンがそのソフトウェアにあたる（？）。 HDDの状態を調べるために、コマンド smartctl を実行してみた。

# smartctl -a /dev/hda

=== START OF INFORMATION SECTION === Device Model: ST340810A Serial Number: 6FB2210N Firmware Version: 3.60 User Capacity: 40,020,664,320 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Fri Jul 4 01:17:22 2008 JST SMART support is: Available - device has SMART capability. SMART support is: Enabled （中略） Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 061 051 025 Pre-fail Always - 69989819 3 Spin_Up_Time 0x0003 098 098 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 177 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 1 7 Seek_Error_Rate 0x000f 073 060 030 Pre-fail Always - 133933183465 9 Power_On_Hours 0x0032 062 062 000 Old_age Always - 33675 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 364 194 Temperature_Celsius 0x0022 046 051 000 Old_age Always - 46 195 Hardware_ECC_Recovered 0x001a 100 253 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 095 095 000 Old_age Always - 61 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 181 000 Old_age Always - 1825 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0

さて、いろいろな情報が出力されているが、それぞれのATTRIBUTE（属性）が何を意味しているのか、よくわからない。 ネット探していたら smartmontoolsで取得できるSMART情報一覧 という何ともすばらしいサイトを見つけた！ そのなかでHDDがこれだけのログを取っていたんだという事に驚いた。 起動回数　177回や 稼働時間　33675H→4年弱稼働している 温度　　　　46℃ ふむふむ。 SMART情報一覧ページのクリティカル度の高いヤバいエラーをみると 　・Reallocated_Sector_Ct 　・Current_Pending_Sector あぁ、、、出てますね。。。。 そのほか、Seek_Error_Rate が 133933183465 と飛び抜けている。 これは早急にHDD交換した方がよいな。

Windows版SMART（フリーツール）

さて、今回SMARTについていろいろ調べていたら、フリーのWindows版SMARTツールがもるようですね。 早速ダウンロードしてWinマシンに入れてみました。HDDの管理に結構使えそうです。 Win版フリーのSMART診断ツール HDD Health 日本語化　RiKu's On-Line

ガソリンが7月（もう明日！）に7～10円/リットルも値上がるので、6月末日の今日、仕事から帰宅後に急いでガソリンスタンドに車を回した。タンク1/3程度しか空いていなかったが、それでも20リットルは入る。10円値上がったら、200円の差。マックのプレミアムローストコーヒーが2杯飲める。2日分の息抜きだ。

いつも入れている大通り沿いのスタンドに向かうと、24時間営業のはずのスタンドが照明を落としている。入り口は三角コーンで封鎖されている。店員はふらふらしているのだが、7月の値段切替の混乱を防ぐために早めに締めたのか？？真相はわからないが開いていないのでは仕方がない。一本奥の通りのあまり客の入らないスタンドへ向かった。普段、ガソリンの値段は大通り沿いのスタンドの1～2円高いのだが、今入れないと10円の差になってしまうかも知れない。ということでそこで入れる事にした。

いつもはガラガラのスタンドだが、今日は違った。 行列ができるほどではなかったが、スタンド内は車で満たされていた。

さて、肝心の値上げ前6月末日のガソリンの値段は

【看板の掲示】
  ハイオク177円/リットル
【実際支払った額】
  スタンド提携のキャッシュカードで入れたためか、実際は174円/リットルだった。

ラジコンメーカー関連

JR（日本遠隔制御）

スーパーボイジャーEのページ（JRサイト内）

ハイテックマルチプレックスジャパン

クラフトるうむ

個人サイトリンク

ラジコン中毒者のページ

ラジコンの使えるリンク集

R/C Net Surfing Navigator

オンラインショップ

リトルベランカ

遊はうす

フタバ産業オンライン

RCNAVI Web Shop

書籍・参考資料

気になる広告リンク （スポンサードリンク）

プライマリDNSは自宅サーバで、セカンダリDNSはXNAMEを利用することにしていた。プライマリDNSがとりあえず機能していたため、セカンダリDNSとして使用していたXNAMEとの連携ができていない事を把握していながら、しばらく放置していた。

XNAMEと連携できていない「not available」

どのような症状だったかというと、xnameのコントロールパネル上（右上図）に

wingnotes.net (S)    Logs
    ns0.xname.org.    not available    zone content
    ns1.xname.org.    not available    zone content
    xxx.xxx.xxx.xxx    not available    zone content

「not available」となっていてxnameにゾーン転送が行われていない模様。

xnameのコントロールパネル[zone content]で、ゾーン情報を確認しようとしても、xnameから自宅サーバのDNSにアクセスができていないようだ。（↓）

Zone content for wingnotes.net on server xxx.xxx.xxx.xxx
; <<>> DiG 9.3.4 <<>> axfr wingnotes.net @xxx.xxx.xxx.xxx
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached

xnameと連携できない原因究明＆対策

原因を推測する。
①ルーターのフォーワード設定に不備がある
②ファイアーウォールで通信がブロックされている
③BINDがゾーン転送できていない

tailコマンドを使って、bindのログを監視する。
XNAMEのコントロールパネルから「zone content」をクリックしてもBINDのログは何の変化も無し。うちのルータ（Gateway）ではUDP 53ポートへのアクセスがDNSサーバーにフォワードされる設定になっている。まず関係ないと思いながらもルーター（Gateway）にTCP 53ポートもフォワードするように設定を追加。UDP 53ポートは元もとアクセス許可済み（①の対策）
さらにDNSサーバーのファイアーウォール（iptables）にTCP 53ポートへのアクセスおよび送出を許可する（②の対策）

そしてもう一度XNAMEのコントロールパネルから「not available」をクリックしてみた。すると BINDのログに次のように出た。

Jun 29 16:25:15.520 queries: info: client 92.243.14.172#33204: query:
wingnotes.net IN AXFR Jun 29 16:25:15.520 security: error: client 92.243.14.172#33204: zone transfer
'wingnotes.net/IN' denied

おおっ！プライマリのDNS（BIND）が反応している。ただし、ゾーン転送は denied （＝拒否された）と出ている。拒否しているクライアントIPアドレス 92.243.14.172 は何なのだろうか。調べてみると www.xname.org の様だ。XNAMEの管理画面を動かしているWebサーバーのようである。
それまでBINDの設定ファイル named.conf でセカンダリDNSにゾーン転送を許可しているのは
・ns0.xname.org　（195.234.42.1）
・ns1.xname.org　（87.98.164.164）
の二つであった（2008.6.29時点）。

とりあえず named.conf の転送設定「allow-transfer」に www.xname.org （92.243.14.172） を追加する。（↓）

zone "wingnotes.net" IN {
    type master;
    notify yes;
    file "wingnotes.net.zone";
    allow-transfer {
        195.234.42.1; /* ns0.xname.org */
        87.98.164.164; /* ns1.xname.org */
        92.243.14.172; /* www.xname.org */
    };
};

DNSとプロトコル「TCP」

XNAMEのコントロールパネルの「zone content」の結果には「; <<>> DiG 9.3.4 <<>> axfr wingnotes.net @xxx.xxx.xxx.xxx」と出ているので、www.xname.org上ではDigコマンドがたたかれているようだ。DiGコマンドはプロトコルTCPを使うのか？？DNSはTCPでもレスポンスを返すのか？？ ここで、ルータのフォワードにTCP 53ポートを追加した事でアクセスできるようになったのはなぜだろう？管理人は「DNSはUDPポートを使う」と思いこんでいた。

ネットで情報を探すと仙石浩明の日記の記事には、

DNS問合わせというと、ネームサーバの UDP/IP の 53番ポートへ問合わせるのが一般的であり、 TCP/IP の 53番ポートはゾーン転送のみに使われることが多い。しかし RFC (RFC1035 および RFC2136) 上は TCP も、UDP と同様、通常の問合わせにも利用することができることになっているし、多くのネームサーバでそのような実装になっている。

と書いてあった。ゾーン転送はTCPを使う事があり、さらに通常のDNS問い合わせもTCPでもOKという事らしい。これまでうちのサーバーではTCP 53ポートを完全にブロックしていた。これがXNAMEとDNS連携取れなかった原因だったらしい。

xnameへゾーン転送できた

NAMEDを再起動する。
しばらくログを見ていると、、、

Jun 29 18:32:57.918 queries: info: client 92.243.14.172#36434: query:
wingnotes.net IN AXFR Jun 29 18:32:57.918 xfer-out: info: client 92.243.14.172#36434: transfer of 'wingnotes.net/IN': AXFR started

と「www.xname.org」へゾーン転送されている模様。（↑）
さらに「ns0.xname.org」へのゾーン転送も確認できた。（↓）

Jun 29 16:36:38.399 queries: info: client 195.234.42.1#63154: query: wingnotes.net IN AXFR
Jun 29 16:36:38.399 xfer-out: info: client 195.234.42.1#63154: transfer of 'wingnotes.net/IN': AXFR started

XNAMEのコントロールパネルで[zone content]で、ns0.xname.orgのゾーン転送状態を確認すると、きちんと転送されていた。（↓）

Zone content for wingnotes.net on server ns0.xname.org.
; <<>> DiG 9.3.4 <<>> axfr wingnotes.net @ns0.xname.org.
; (1 server found)
;; global options: printcmd
wingnotes.net. 86400 IN SOA ns1.wingnotes.net. xxxxxx.xxxxx.xxxxx.
2008051303 3600 1800 864000 3600
wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
wingnotes.net. 86400 IN NS ns0.xname.org.
wingnotes.net. 86400 IN NS ns1.xname.org.
wingnotes.net. 86400 IN NS ns1.wingnotes.net.
wingnotes.net. 86400 IN NS ns2.xname.org.
ftp.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
mail.wingnotes.net. 86400 IN MX 10 mail.wingnotes.net.
mail.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
ns1.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
wnsvr.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
www.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
wingnotes.net. 86400 IN SOA ns1.wingnotes.net. xxxxxx.xxxxx.xxxxx.
2008051303 3600 1800 864000 3600
;; Query time: 7 msec
;; SERVER: 195.234.42.1#53(195.234.42.1)
;; WHEN: Sun Jun 29 14:35:09 2008
;; XFR size: 14 records (messages 1)

うーん、DNSって奥深い。しかも少々間違った設定のままでも不具合無いように動いてしまうから怖い。

2008/6/22

「おやじ倶楽部」さんの初心者ＲＣヘリコプター室内練習会に参加させてもらいました。今回おじゃまさせて頂いた講習会は認定トレーナーの指導が受けられる練習会でした。独学では成長にはっきり差が出るラジコンヘリコプター、このような講習会を定期的に実施している「おやじ倶楽部」さんの活動は、ラジコンヘリコプターの裾野を広げられるすばらしい活動であると思っています。

RCヘリコプター初心者講習会の風景動画

トレーナーコードを使用した練習風景を撮影しました。コントロールを失った時など、トレーナーに操縦を替わってもらう事ができます。機体を壊す事が少なくなり、思いっきり練習ができます。

• mv2avi
• XMPEG

• かんたん換太郎 for iriver
• mencoder

mencoder.exe -vf scale=128:96 -ofps 15 -ovc lavc -lavcopts vbitrate=384:vmax_b_frames=0 -ffourcc XVID -srate 44100 -oac mp3lame -lameopts cbr=128 -o <出力ファイル名> <ソースファイル名>

2008/5/5～2008/5/6

今年のゴールデンウィークは友人と房総の千倉へキャンプしに行ってきた。みかん農園のおっちゃんが片手間でキャンプサイトを貸し出している様な、なんともアットホーム（？）なキャンプ場だった。みかんや絞りたての牛乳を、ほら食え、やれ飲めと差し出してくれる、心温まるキャンプ場だった。その農園の中のちょっとはずれのスペースを借りてそこをサイトとした。友人がアウトドアのプロ（？）から借りてきた、間欠自動ローテートロースター（勝手に命名　笑　すみません）がキャンプを盛り上げる！他のキャンパー達の目にも止まり、人気者だった。一点を焼きすぎず、かつほどよく焼き目が付いたらタイマーで回転する優れもの。タイマー機能を改造して追加したらしい。

さて、ちょうどヘリの離着陸できるスペースがあったのでスーパーボイジャーEを飛ばしてみた。すぐ脇は雑木林で目の前はみかん畑。大きく飛ばす事はできない空間だったが、とりあえず飛ばしてみた。

空撮動画【キャンプ編】

例のごとく、今回もスーパーボイジャーEに携帯電話を取り付けて撮影してみました。

2008/5/4 保土ヶ谷まちづくり工房主催の屋外練習会に誘って頂きいた。これからラジコンヘリの操縦技術を高めようという方々やラジコンヘリで空撮や農薬散布をお仕事にされている大ベテランの方と一緒に飛ばす事ができ、大変有意義な練習会でした。

千葉高滝飛行場への道中、史上空前の大渋滞、（首都高とアクアラインの上に7時間！）には参った。故に飛行場の滞在時間は短い時間ではあったが、それ以上に練習会は楽しかった。感謝です。

空撮動画【練習会編】

例のごとく、今回もスーパーボイジャーEに携帯電話を取り付けて撮影してみました。

なぜこんなに急いで修理したかというと、明日、保土ヶ谷まちづくり工房さん主催の「ラジコン模型ヘリ 屋外練習会」というイベントに、ほんの1週間ほど前に知り合いになった同理事の方の計らいで誘って頂けた。ありがとうございます。Fineclub Consultingさん！

注文していた修理部品が練習会の前日の今日届き、明日の練習会に臨むため一気に修理した。駆動部分のほとんどの部品を交換しなければならないほどの大破だったため、オーバーホールと言っていいほどの大修理だった。当然調整やセッティングもイチからやり直し。ようやく一通りの設定が完了。あとは現地での調整。明日が楽しみである。

充放電をチャージャーを使って3回ほど行い、フライトに1回使用したリポバッテリー「VISLERO V2」。まだバッテリーの本調子が出ていないのか、それともそもそもの特性なのかわからないが、バッテリー容量は十分残っているにもかかわらず、飛行中にESCがパワーダウンを起こした。

福島に於いて桜並木をスーパーボイジャーEで空撮していた時、上空を走らせ遠くでUターンしたあたりでESCがパワーダウンを起こし、足もとの悪い田んぼの中にスーパーボイジャーEは墜落、大破させてしまった。ESCがパワーダウンした原因はこのバッテリーの電圧降下と思われる。その後、このバッテリーを放電器にかけて残容量をチェックすると1800mAhほど放電された。まだまだ容量は残っていたのだ。と言う事は何らかの理由によってフライト中に内部抵抗が高まったりして、電圧降下したのではないかと予想できる。またパワーダウンを起こした時のフライト時間は6分を経過したあたりで、時間的にも余裕が残っていたはず。マイナーブランドの品質を疑わざるを得ない結果となってしまった。

VISLERO V2 の様子見

今回のパワーダウンは充電管理ができていなかったなどの一時的な不調も考えられるので、このバッテリーの特性を把握できるまでは、いざという時にすぐ対応できる範囲でフライトさせた方がよさそうである。フライト時間の計測は必須で、5分以上経過したら注意するように心がけようと思う。

ESCのパワーダウンもパワーダウンし始めたら予想以上に早く低下するため、上空でパワーダウンが起こった場合はオートローテーションに入れた方が無事に回収できる確率は高いと思われる。（腕があれば…）

4月の下旬、福島県の夏井川にある千本桜がちょうど満開を迎えた。今シーズンの桜を見納めようと福島まで足を運んだ。ラジコンヘリコプター スーパーボイジャーEと一緒に。。。

ラジコンヘリコプターと携帯電話のカメラで空撮に挑戦を始めて2回目の空撮。前回の「スーパーボイジャーEで動画空撮 【（いろいろ）失敗編】」では、カメラのレンズの向きが下向きすぎて地面ばかり撮っていたので、今回は前回より正面を向くようにセッティングした。しかし撮影した動画を見ると、それでもレンズは下向きで、良いアングルの風景を撮影できなかったのが残念。

空撮動画【福島 夏井川 千本桜編】

今回の空撮動画を上げています。機載カメラ（携帯電話）から撮影した動画と、それを地上から撮影した動画を編集してみました。アングルがイマイチです。

さて、スピンドル交換でヘッドを分解すると、スラストベアリングやカラーがバラバラになるので、組み直す時に向きや順番に注意しなければならない。備忘録としてスピンドルとベアリング、カラーの組付けメモを載せておく。

スーパーボイジャーEと携帯電話のカメラで空撮する準備を進めてきたが、ようやく外で飛ばせる機会が来た。合わせて、先日購入したリポバッテリーVISLERO V2を試す機会でもあった。

まず、機体に携帯電話をセット。電源を入れムービーモードでスタンバイ。次にプロポの電源を入れバッテリーをESCに接続する。ESCのスイッチを入れサーボの動作を確認。いつも通り。問題なし。VISLEROのリポは厚みが若干ありキャノピーにあたってしまう。バッテリーはキャノピーで少し押される感じだが、それほどきついわけではなかったので良しとした。

空撮開始

さて、フライト開始。
携帯電話（カメラ）とステーで重量は約1割増し。さすがにカメラ無しの時と比べると重たそうに飛んでいる。でも余裕が無いわけではないのでそれほど気にせず飛ばす事ができた。後になって思ったのだが、カメラの取り付けアングルはフライト中にちょくちょく確認すれば良かった。最後の最後までアングルを確認しなかったため、かなり下向きにで終始撮影。見ていてもたまにしか景色が写らず、ほとんど田んぼの土ばかりで面白みのない動画になってしまった。

最初のうちはホバリングメインでゆっくり飛ばしてみた。後半には上空を走らせてみた。何らかのGが加わった際、折りたたみ式の携帯電話が閉まりかけてしまった。なので、後半はローターの回転と空ばかりが写っている。これに気付き、携帯電話の姿勢を直すために一度着陸。

着地失敗

この時にフライトをやめておけば良かった。すでにこの時点で9分近く飛んでいてバッテリーはかなり少なくなっていた。調子に乗ってさらに飛ばしていたら、とうとうESC（スピードコントローラ）がスローダウン。バッテリーの過放電を防ぐために、ある一定のバッテリー電圧を下回ると出力が徐々に押さえられ、飛ばなくなってくるので操縦者に伝わる仕組みである。これがギリギリまで把握できず、突然機体の高度が落ち始めた。あいにく、地上付近だったので大破は免れたが、田んぼのあぜ道の端に下りてしまい着地失敗。この瞬間がしっかりとカメラに収まっている。あぁ、恥ずかしや。。。

破損状況

軟着陸失敗であったためそれほど被害は被らなかった。破損箇所はメインローターとスタビライザーバー。メインローターの後縁の一部グラスに小さな亀裂が入り、剥がれかけている。瞬間を流せば再帰するか？？と言った感じ。スタビライザーバーは大きくひん曲がった。これは要交換。念のためスピンドルも交換しなくてはならないだろう。あぁ、一度降ろしたときにバッテリーを変えておけばよかった。

空撮動画【（いろいろ）失敗編】

今回の空撮動画を上げています。機載カメラ（携帯電話）から撮影した動画と、それを地上から撮影した動画を編集してみました。着地失敗の瞬間も写っています。

WALKERA HM-4#3のモータが1フライトで相当発熱するため、ヒートシンクを取り寄せた。このヒートシンクの重さは多分1mg。“多分”というのは、計測に使った秤の単位が１グラムオーダーで、1gと0gを行った来たりしていたため。

実際にヒートシンクを取り付けてバッテリー1本分飛ばした後にヒートシンクに触れてみると、やはり相当熱い。実際に温度を計測してみると60℃を超えていた。ヒートシンクの有無にかかわらず小指の頭ほどの小さなモーターがこれだけ発熱しており、例えヒートシンクを付けたことにより放熱性が良くなっていたとしても、モーターへの負担軽減は雀の涙かもしれないと思ってしまった。

もう少し、定格容量の大きいモーターを積んでも良かったのかも知れない。その代わりと言っては何だが、テールモーターは人肌に暖かくなる程度で、それほど負荷がかかっているようには思えない。メインモーターを3つ積み替えた今も、当初からのテールモーターは問題なく回ってくれている。

メーカー名は「Danlions International Co., Ltd」

サイトには

PULSO & VISLERO are both the trademarks of Danlions.

とあり、この「VISLERO」はリポのブランド名の模様。中国・上海にあるメーカーのようである。

「Danlions International Co., Ltd」のサイトのURLは次の通り。

http://danlions.com/index.html

VISLEROのバランスコネクターは、サンダーパワーやマルチプレックス、フライトパワーのリポに付いているバランスコネクターと形状が違うコネクターが付いているため、マルチプレックスLN-6015 EQUにバランスコネクターを使用した充放電はそのままではできない。

そこで、変換コネクターをネットで探してみた。ネットにはそれらしきコネクターは見つかるのだが、コネクターの規格があっているか確証が付かず、間違って購入するのは避けたくてネットでの購入は見送った。

バランスコネクター探し

リトルベランカさんで、サンダーパワーのバッテリーに付いているバランスコネクターと同じ形状のコネクタを見つけた。同じ規格のコネクターを使用しているフライトパワーの物。（画像はリトルベランカさんのサイトにリンクされています）これは簡単な工作が必要。 変換コネクターがあれば加工しなくてすむので一番良かったが、リトルベランカさんにはそのようなアイテムはなかった。

購入したのはフライトパワーのバランス端子（4セル～5セル用）で、リード線が6本あるもの。しかしVISLEROのバランスコネクターはリード線が5本。4セルなので各セル間から5本出るのは理解できる。ではサンダーパワーの4セルのバッテリーからはバランスリード線が6本出ていて、この6本目は何なのか？テスターで調べてみると5本目と6本目は電圧が同位であった。5本目と6本目は同じセルから出てきている線のようだ。

リトルベランカの店長さんに確認したところ、4セルなら6本目の線は無いものとして扱って構わないと確認できたので、6本目はコネクターから外しておく事にした。

バランスコネクター付け替え作業

さて、購入したバランスコネクター端子を付け替える作業を始める。

作業はVISLEROに元々付いているバランスコネクターのリード線を1本1本切って、付け替えるだけなので難しい事はない。元々のバランスコネクターにも、今回用意した交換するコネクターにもそれぞれ黒いリード線が1本だけある。マイナス端子からのリード線で、これが基準になる。あとは順番を間違わないように、2本目、3本目…と繋ぎ変えていく。短絡（ショート）させないように、必ず一本ずつ作業を行い、導線が剥き出た箇所は絶縁のシュリンクチューブをかぶせていく。

5本（4セルなので）の付け替えが完了したら、最後にバランスコネクター端子のマイナス端子との電位差を計測しておく。黒リード線を基準（0V）として、3.7V、7.4V、11.1V、14.8Vあたりを順に示せば、結線は間違っていない。その際、テスターの端子を短絡させないように、十分注意する。

VISLERO V2 という格安リポ(LiPo)バッテリーを入手。このリポはスーパーボイジャーE（4セル）に使うバッテリーとして購入。「VISLERO」というメーカーはこれまで聞いた事がないメーカー。ネットでこのメーカーの情報を探しても、メーカのサイトは見つからなかった。はたしてどこの国のメーカーなんだろうか。

バッテリーに貼られているラベルには

VISLERO V2
14.8V 4S1P 3300mAh 20C

とある。バランスコネクター付き。ただし、サンダーパワーやマルチプレックス、フライトパワーの各バランスコネクターとは異なる形状。そのままでは管理人が使用している充電器 マルチプレックスLN-6015 EQUには使えないので、コネクターを付け替える、もしくは変換コネクターを用意する必要がある。バランスコネクターの付け替えについては追ってアップします。

ほぼ同じ容量のTHUNDER POWER のリポバッテリーと重量を比べてみた。コネクターを付ける前の比較なので正確な比較ではないが、VISLEROは356g。THUNDER POWER は346g。10gほど重たかった。サイズはほぼサンダーパワーと同じ。VISLEROは、厚手の両面テープで各セルが張り合わされているようで、厚さが1～2ミリ厚い。

スーパーボイジャーEに自作した携帯電話ステーを取り付け、携帯電話のカメラでどのような動画が撮影されるかテストしてみた。そのときの動画を定点カメラと合わせて撮影したので、サイトで公開しています。部屋の中でのフライトだったので、危なっかしくてまともに飛ばせていません。

このテスト撮影では携帯電話のカメラが、ラジコン電波やラジコンヘリの振動の影響を受けないか？を確認したかった。テスト撮影の結果を見てみると、ハードランディングした時の画像のブレは仕方ないとして、振動がひどいとか動画にノイズが入るとなどの悪影響はほとんどなさそうである。

テスト撮影した動画

屋外で機体に取り付けた携帯カメラで動画を撮影してみたら、どのような動画が撮れるか楽しみである。

ホームセンターでほどよい材料を物色して、使えそうなパーツを購入。基本的にはビス止めのみで組み立て完了。構造は至って単純です。ナットのゆるみ止めにボルトにはネジロック剤塗布した。ケータイを挟み込む面にはスポンジゴムを貼り付けている。振動の吸収をもくろんでいるが、はたしてどれだけ振動を吸収できるか。ステーだけの重量は43g。これにケータイの重量124gが加わるので、167gの重量増加。結構な重量になった。果たして飛ぶだろうか。。。

空撮ステーの取り付け

組上がったステーを機体に取り付けてみる。機体の取り付け部分はノブ付きボルトにして、工具が無くとも手だけで締められるようにした。実際にこのステーにケータイをセットしてみたところ、ケータイをつかむ位置が下の方となるため、ケータイの重心がかなり上になってしまい、ぐらつく事が判明。輪ゴムを使ってケータイを押さえれば、ある程度ぐらつきは押さえられそうである。

設計というと大げさであるが、機体をぐるぐる回しながら取り付け出来そうなところがないか眺めながら、機体のどこに、どのようにカメラを据え付けるか考えてた。

バッテリホルダーが有力ではあったが、キャノピーは切り抜きたくなかったので機体サイドに保持する方法にした。

手書きの見にくい図で恐縮だが、右図のように取り付けようかと考えている。スーパーボイジャーEのフレーム最下部、ちょうどマストの下辺りに幅22ミリほどのスリットが空いている。ここにステーとなる金属のプレートを差し込み、下から樹脂のプレートで挟んで固定しようと言うモノ。

マストのほぼ下なので、前後の重心はそれほど変化はしなくて済むと思われる。左右はドリフト相殺に働く（厳密には違うが）、機体右側にカメラを配置する設計。

幅を調節出来るコの字のアーム（この辺りはカー用品を探したら適当な物が見つかりそう）でケータイを保持する。コの字のアームとステーは撮影方向（上下）が調整出来るようになっている。

適当な材料を見つけに、�