August 22, 2017

Raspberry Pi Zero W RTC と シャットダウン・ボタン

E314先日のブログ にも書いたが、Raspberry Pi Zero W をアクセスポイント化して、山奥とか離れ小島とか、インターネットにアクセスする方法がない場所でも、チャットや対戦ゲームやチェックリストのオリジナルなプログラムを、仲間内だけで使うような ミニサーバーを作ろうと思っている
が、大きな問題があった

Raspberry Pi Zero W には、リアルタイムクロックが無い
これは、Raspberry Pi Zero W に限らず、Raspberry Pi シリーズは全てリアルタイムクロックがない
このため、起動すると、前回シャットダウンした時刻にシステムクロックが止まったままになる
もちろん、インターネットアクセスが可能なら、即座に NTP に接続し、システムクロックを修正するのだが、そもそもインターネットアクセスができないような場所で、チャットや対戦ゲームやチェックリストをやりたいのだから、困ったしまう
もう一つの問題は、リアルタイムクロックに比べると些細だが、単独ではシャットダウンする方法がないことだ

そこで、RTC と シャットダウンするためのボタンを追加することにした
ついでながら、ステータス表示のための LED も追加した

必要な部品
秋月電子にて
・DS1307 I2Cリアルタイムクロックモジュール(RTC) 750円
・2色LED 赤・黄緑3mmクリアボディ OSRGHC3131A (10個入) 150円 : 使うのは 1個
その他
・押しボタンスイッチ
・抵抗 5.1kΩ 2個

配線
・Raspberry Pi Zero W 部品
・2pin 5V ⇔DS1307 P1 3pin Vcc
・3pin SDA1 ⇔DS1307 P1 4pin SDA
・5pin SCL1 ⇔DS1307 P1 5pin SCL
・30pin Gnd ⇔DS1307 P1 2pin Gnd
・29pin GPIO5 ⇔押しボタン
・33pin GPIO13 ⇔LED (赤) 5kΩ経由
・35pin GPIO19 ⇔LED (緑) 5kΩ経由
・30pin Gnd ⇔押しボタン・LED コモンカソード

シャットダウンプログラム
・ブログのせいで、インデントが表示されず、見にくいところ、申し訳ない

/usr/local/sbin/raspi_shutdown.sh

#!/bin/sh
count=0
b_status=0
b_count=0
flg_ping=0
while :
do
sleep 0.5s
if [ $b_status -eq 0 -o $b_status -eq 1 ]; then
case $count in
0)
echo 0 > /sys/class/gpio/gpio13/value
echo 1 > /sys/class/gpio/gpio19/value
;;
1)
if [ $flg_ping -eq 0 ]; then
ping -c 1 -W 1 google.com > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo 0 > /sys/class/gpio/gpio13/value
flg_ping=1
else
echo 1 > /sys/class/gpio/gpio13/value
fi
else
echo 0 > /sys/class/gpio/gpio13/value
fi
echo 0 > /sys/class/gpio/gpio19/value
;;
esac
elif [ $b_status -eq 2 -o $b_status -eq 3 ]; then
case $count in
0)
echo 1 > /sys/class/gpio/gpio13/value
echo 0 > /sys/class/gpio/gpio19/value
;;
1)
echo 0 > /sys/class/gpio/gpio13/value
echo 0 > /sys/class/gpio/gpio19/value
;;
esac
elif [ $b_status -eq 4 ]; then
echo 1 > /sys/class/gpio/gpio13/value
echo 0 > /sys/class/gpio/gpio19/value
fi
SHUTDOWN=$(/bin/cat /sys/class/gpio/gpio5/value)
case $b_status in
0)
if [ $SHUTDOWN = 0 ]; then
b_status=1
b_count=0
fi
;;
1)
if [ $SHUTDOWN = 0 ]; then
b_count=`expr $b_count + 1`
if [ $b_count -eq 10 ]; then
b_status=2
b_count=0
fi
else
b_status=0
b_count=0
fi
;;
2)
if [ $SHUTDOWN -ne 0 ]; then
b_status=3
b_count=0
fi
;;
3)
if [ $SHUTDOWN = 0 ]; then
b_status=4
b_count=0
else
b_count=`expr $b_count + 1`
if [ $b_count -eq 10 ]; then
b_status=0
b_count=0
fi
fi
;;
4)
if [ $SHUTDOWN = 0 ]; then
/sbin/shutdown -h now
else
b_status=0
b_count=0
fi
;;
esac
count=`expr $count + 1`
if [ $count -eq 2 ]; then
count=0
fi
done

なお、このプログラム、元々は日経LINUX 2017年2月号の記事を参考にしたのだが、日経LINUXの記事のままだと、Raspberry Pi Zero W の少ない CPU の負荷が100%になってしまうので、改良した
また、Raspberry Pi Zero W のステータス表示機能も追加している

RTC の設定

$ sudo raspi-config
<< i2cをイネーブルにする >>
$ sudo reboot

再起動

$ sudo apt-get install i2c-tools python-smbus
$ sudo modprobe rtc-ds1307
$ sudo apt-get remove fake-hwclock
$ sudo dpkg --purge fake-hwclock

/etc/rc.local のファイル末に下記を追加

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
sudo hwclock --adjust || true
sudo hwclock -s || true
echo 13 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio13/direction
echo 0 > /sys/class/gpio/gpio13/value
echo 19 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio19/direction
echo 0 > /sys/class/gpio/gpio19/value
echo 5 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio5/direction
/usr/local/sbin/raspi_shutdown.sh &
exit 0

ここで、一度、再起動

使い方

RTCモジュールについているボタン電池は、充電池なのだが、秋月電子で購入したときは、ほぼ空になっていた
起動した状態で充電できるようなので、最初は、何時間か連続で通電しておく
インターネットに接続し、NTPで時刻が正しくなっている状況で、

$ sudo hwclock -w

とやると、RTCが設定される

最初の内は、RTCの誤差が大きい(私のRTCの場合は、24時間で6秒も遅れた)
インターネットのNTPで正しい時刻にシステムクロックが設定されている時に、「$ sudo hwclock -w」を何度か繰り返しているうちに、誤差が補正される
これは、/etc/rc.local のファイルの中で、「sudo hwclock --adjust」と補正オプションが指定されているため、補正値を自動設定しているからだ
補正が正しくできるようになったら、インターネットアクセスは必要なくなる

電源が入り、OSが起動すると、LEDが点滅してステータスを表示する
インターネットアクセスにアクセスできないうちは、LEDは「赤と緑が交互に点滅」になる
そのうち、インターネットアクセスが確立したら「緑だけの点滅」になる
(当然ながら、インターネットアクセスが不可能な山の中や離れ小島では、「赤と緑が交互に点滅」のままだ)
押しボタンを長押しすると、LEDは「赤だけの点滅」に変わる
ここで一度指を離し、再びボタンを押すと「赤の点灯」になり、その後、シャットダウンする

さて、今回は、ブレッドボードで回路を作ったが、次回は、ユニバーサル基板に半田付けし、小さなケースにいれて、『ミニサーバー』にする予定だ

| | Comments (0) | TrackBack (0)

August 20, 2017

Raspberry Pi Zero W ブレッドボード

E313_1Raspberry Pi Zero W だが、外部と結線するところをどうするか、悩んでいた
どうせなら、汎用的な I/F にするべきだろうが、普通の Raspberry 3などと同じにすると、表側(CPUの付いた面)側にオスのヘッダを付けることになり、そうすると、折角の専用ケースに入らなくなる
Raspberry Pi Zero 専用ケースには、裏面側に I/Fが通る穴がある
そこで、裏表逆になるが、基板裏面側に I/F 用に秋月で売っているロープロファイルピンヘッダ(オス)を半田付けすることにした

これに、やはり秋月で300円で売っている ラズベリーパイB+/A+ブレッドボード用変換基板に ロープロファイルピンソケット(メス)および、細ピンのヘッダを半田付けしたものを用意する
と、ブレッドボードに挿して、実験しやすくなる

E313_2左の写真のように、ヘッダを半田付けした Raspberry Pi Zero W は専用ケースにすっぽり入る

実は、この状態で、専用カメラが付いた状態なのだが、全く問題なく入る。
 


E313_3ケースの裏側は、このような状態

ほんの少しだけ、ヘッダピンが飛び出しているが、ロープロファイルを使っているので、あまり気にならない程度だ
 
 
 
 
 
 
 
 
 
 

E313_4最後に、ブレッドボードに付けた状態
専用ケースの中には、Raspberry Pi Zero Wと専用カメラが入った状態だ

これなら、色々と実験できる

で、実際に、これを使って実験して、作ったものは、また、次回以降に紹介予定

| | Comments (0) | TrackBack (0)

August 06, 2017

Raspberry Pi Zero W CPUの謎とカメラ

Raspberry Pi Zero Wの謎
Raspberrypi_zero_w・一番大きなチッブ(おそらくCPU等の入ったSoC)が何故かエルピーダの刻印。エルピーダってメモリでしょ?
・小さなWifii/Bluetoothと思われるチップと、プリントされたアンテナ
・裏面はパスコンの全く無い、真っ平・・・

これをTwitterで呟いたら、「Package on Package でDRAMの下にCPU SoC がある」と教えてもらった。
ネットを調べたら、ZeroではないRaspberry Piですが、分解(破壊)動画見つけた

Under The Raspberry Pi CPU: The Actual Soc / CPU

2分あたりでCPU&メモリを剝がしているが、これと同じような実装方法であろう。
しかし、凄い実装法だなぁ

ラズバイ専用カメラ

Raspberry Pi Zero Wに、アマゾンで850円で買ったカメラを付けた。何の問題もなく、写真が撮れる
1200円のラズパイゼロWと850円のカメラで、Wifi接続のWebカメラになる。

私の買ったのは、これ
アマゾン => HiLetgo OV5647 5MP カメラ OV5647 HDカメラモジュール  Raspberry Pi に対応 A/B+/2 モデルB ケーブル
ラズパイ A/B+/2 モデルB 用とあるが、Zero Wでも変換ケーブルさえあれば動く。
私が買ったときは850円だったが、今は800円だ(2017.08.06現在)

実際に送られてきたのが、これ。シンガポールから送られてきた。
Win_20170806_07_06_46_proRaspberry Pi Camera Rev. 1.3 と書いてある。
調べると、ラズパイカメラは、V1.3 が500万画素、V2.1が800万画素。V1.3 は製造中止になり、V2.1が現行品らしい。
あんまり安いんでパチモンかもしれないと思ったが、どうやら、売れ残りのV1.3の在庫処分品だったのだろう。

WifiやBluetoothが付いているものは、海外から輸入すると技適の関係で違法になる可能性があるから、海外からは買わない
でも、カメラなど、電波出さないものは、関係ないから、海外から安いのを買っちゃう・・

なお、カメラとRaspberry Pi Zero Wを結ぶケーブルは、専用ケースに付属していたもの。Raspberry Pi 2や3と比べて、カメラ用のコネクタが小さいので変換ケーブルが必要なんだが、専用ケースに付属していた。Raspberry Pi Zero W、単品では購入できず、専用ケースとのセット販売で買ったのだが、この変換ケーブルが付いていたので、役にたった。ちなみに次の写真のようにカメラを付けた状態でケースに入る。

Win_20170806_07_55_11_proで、このカメラを使って、「静止画を撮る」「動画のストリーミング」「OpenCVで画像解析」をやってみた

静止画を撮る
第43回「Raspberry Pi Zero V1.3+カメラモジュールでミニ定点カメラを作ろう!」
これで、OK!

動画のストリーミング
mjpg-streamerでraspberryPiのカメラからストリーミングをする方法
これ、Raspberry Pi 2や3用の記事と思われるが、そのままでOK!
ただし、ストリーミングは、5fpsくらいで遅いが

OpenCVで画像解析
講談社ブルーバックスの「実例で学ぶRaspberry Pi電子工作 作りながら応用力を身につける」
この本の7章の「円の抽出」と「顔検出」を試してみた。これRaspberry Pi +や2用プログラムだが、Zero Wでも上手く行った

やって気が付いたのだが、UVC規格のUSBカメラでもOpenCVで画像解析できる
ラズパイ専用カメラでも、USBカメラでも、とにかく安いカメラをRaspberry Pi Zero Wに接続して、何か面白いものを作りたいな

| | Comments (0) | TrackBack (0)

July 29, 2017

Raspberry Pi Zero Wを買った アクセスポイント化に成功

先日 (7月18日)、Raspberry Pi Zero Wが、やっと技適を取得し、販売が開始された。早速購入。7月21日に届いたので、約一週間。
その間、Rasbianのデスクトップ版やCUI版を試すが、この辺の話はネット上にも多数載っているので、特に報告することはない。

その後、USBケーブルだけで Raspberry Pi Zero W をセットアップする方法と、それを使って、無線アクセスポイント・ルーター化することに成功した。この2つは一寸特殊な使い方なので、これらを紹介する。

前半:USBケーブルだけで Raspberry Pi Zero W をセットアップ
E312_1私は、母艦に Windows10マシンを使ったが、UbuntuでもMACでも使えるらしい。(Ubuntuは確認済み。MACについては、私がMACを持っていないので未確認)

まず、https://www.raspberrypi.org/downloads/raspbian/ から、2017-07-05-raspbian-jessie-lite.zipをダウンロード。
これを解凍して得た 2017-07-05-raspbian-jessie-lite.img を Win32DiskImager を使って、microSDに書き込む。
microSDは、8GB以上が推奨されているようだが、2GBでも動いた。

Windows10が microSD を識別すると boot ドライブが見つかるが、このなかに
・ssh と言う名の空ファイルを作る
・cmdline.txt を次のようにする
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether quiet init=/usr/lib/raspi-config/init_resize.sh quiet splash plymouth.ignore-serial-consoles
・config.txt の最後に下行を追加
dtoverlay=dwc2

Windows10側としては、
RPI Driver OTG:URLからドライバーをダウンロードして解凍しておく
・iTunes もしくは、Bonjour Print Services (Windows)をダウンロードしてインストしておく

最初の接続
・先ほど作った microSD を Raspberry Pi Zero W に挿入
・USBケーブルで、母艦PCとRaspberry Pi Zero Wを接続
・Windows10側のコントロールパネルのデバイスマネージャーのCOMの項目に「USBシリアルデバイス(COM6)」が増えている(COMの番号は、異なる場合があるので注意)
・「USBシリアルデバイス(COM6)」を右クリックし、ドライバーソフトウェアの更新
・「コンピューターを参照して、ドライバーソフトウェアを検索します」で、先ほどダウンロード・解凍しておいた RPI Driver をインスト
・デバイスマネジャーのネットワークアダプターに「USB EthernetRNDIS Gadget」が追加される
・しかし、エラーが出ている(どうも、1回目にエラーが出るのは、共通らしい)
2回目の接続

・Windows10 の再起動
・デバイスマネジャーのネットワークアダプターに「USB EthernetRNDIS Gadget」が追加される
・ Raspberry Pi Zero W に接続しても、今度はエラーなし

・Puttyjp.exe や TeraTerm で、raspberrypi.local を SSH 接続できる。
・デフォルトでは、IDは pi パスワードは raspberry
・このままでは、Raspberry Pi Zeroからインターネットをアクセスできない

Raspberry Pi Zeroからインターネットをアクセス

・Windows10側「コントロールパネル」「ネットワークとインターネット」「ネットワークと共有センター」
・Wifi(xxx:貴方が接続しているWifiのSSID)をクリック「プロパティ」「共有タブ」「インターネットのほかのユーザーに、このコンピューターのインターネット接続をとおしての接続を許可する」を選択
・「コントロールパネル」以下のダイアログを「OK」ボタンなどで全て消す
・しばらくすると、Raspberry Pi Zero Wからインターネットをアクセスできるようになる
・sudo apt-get install で、Apache2をインストールすると、母艦のWindows10から http://raspberrypi.local でアクセスできるようになる

後半:アクセスポイント化

これは、Raspberry Pi 3に内蔵の WiFiを使った無線LANアクセスポイント化 hostapd + isc-dhcp-server編を参考にしたが、Raspberry Pi Zero W にアレンジしている

$ sudo apt-get install hostapd isc-dhcp-server


/etc/network/interfaces を次のようにする

source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.123.234
netmask 255.255.255.0
network 192.168.123.0
broadcast 192.168.123.255
allow-hotplug wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

/etc/dhcpcd.conf を次のようにする

hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
require dhcp_server_identifier
slaac private
nohook lookup-hostname
denyinterfaces wlan0

$ sudo service dhcpcd restart
$ sudo ifdown wlan0; sudo ifup wlan0

/etc/dhcp/dhcpd.conf を次のようにする

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet 192.168.123.0 netmask 255.255.255.0 {
range 192.168.123.100 192.168.123.120;
option routers 192.168.123.234;
option broadcast-address 192.168.123.255;
option domain-name local_pi_dns;
option domain-name-servers 8.8.8.8 4.4.4.4;
default-lease-time 600;
max-lease-time 7200;
}

なお、「8.8.8.8 4.4.4.4」を「192.168.137.1」にすると、母艦 Windows10 のドメインサーバーの設定を引き継ぐようである

/etc/default/isc-dhcp-server を次のようにする
INTERFACES="wlan0"

$ sudo bash -c "zcat /usr/share/doc/hostapd/examples/hostapd.conf.gz > /etc/hostapd/hostapd.conf"

/etc/hostapd/hostapd.confは長いので、変更点のみ記す

「# driver=hostap」を「driver=nl80211」に
「ssid=test」を「ssid=WIFISSID」に
「#wpa=1」を「wpa=2」に
「#wpa_passphrase=secret passphrase」を「wpa_passphrase=PASSWORD」
(さすがに SSID と パスワードは書き換えてね)

/etc/default/hostapd を次のようにする
DAEMON_CONF="/etc/hostapd/hostapd.conf"

/etc/sysctl.conf を次のようにする
net.ipv4.ip_forward=1
net.ipv6.conf.all.disable_ipv6 = 1

/etc/rc.local を次のようにする
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
iptables-restore < /etc/iptables.ipv4.nat
exit 0

$ sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
$ sudo iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
$ sudo iptables -A FORWARD -i usb0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
$ sudo iptables -A FORWARD -i wlan0 -o usb0 -j ACCEPT
$ sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
$ sudo reboot

とやって、再起動
これで、アクセスポイント化ができた

アクセスポイント化して、どうするの?
E312_2これを説明したのが、2つ目の絵。

例えば、出先で、仲間だけでネットを組みたい場合。
図のようにアクセスすれば、Raspberry Pi Zero W にファイルサーバーを立てておけば、ファイルの共有化ができる。
ファイルサーバーが無くても、フォルダーを共有化しておけば、仲間内だけで、ファイルの共有も可能だ。
この場合、パスワードさえ破られなければ、仲間以外からファイルを守ることができる。外から中には入って来れないが、中から外をアクセスすることは可能なので、Googleでの検索やLine、メールなどは普通に使える。

まあ、正直、ファイルの共有くらいなら、外部のクラウドサービスを使った方が早いのだが、むしろ、Apache2やNode.jpを使って、WebSocketを駆使したチャットや対戦ゲームやチェックリストの方が効果があるだろう。
チャットや対戦ゲームやチェックリストのオリジナルなプログラムを作って、仲間内だけで使う。
この場合、山奥とか離れ小島とか、インターネットにアクセスする方法がない場所でも、(もちろんインターネットアクセスはできないが)仲間内でのチャットや対戦ゲームやチェックリストを使うことができる。

一番やってみたいのは、最後のチェックリストなんだよね。
WebSocketを駆使して、誰が何を何時何分に作業し、チェックしたのかを、メンバー全員にリアルタイムで配信して、作業効率を上げるんだ・・

2017.08.05 誤記があったので、少し修正

| | Comments (0) | TrackBack (0)

June 07, 2017

ESP-WROOM-32のBluetooth Classic SPP接続 Windowsも大丈夫!

ESP-WROOM-32のBluetooth Classic SPP接続だが、前回は、Windowsだと SPP 接続できないと書いた。が、この10日ほどの間に、GitHub の btstack が何回かアップデートされており、今日試したら、Windowsとも問題なく接続できたので、報告する。

要は、GitHub の btstack が良くなっただけで、私は何もしていない。
前回と全く同じ「patch.patch.gz」をダウンロードして、作業は次の通りする。

$ cd ~/
$ git clone https://github.com/bluekitchen/btstack.git
$ patch -p1 -d btstack < patch.patch
$ cd btstack/port/esp32/
$ ./create_examples.py
$ cd spp_counter/
$ make all
$ make flash << ESP-WROOM-32をUSB接続していれば、書き込まれる >>

これで、前回と同じく Android と接続できるだけではなく、Ubuntu も GUIでペアリングできるようになったし、Windows も接続できる。
私は、Windows 10で試したが、普通にWindows設定・デバイスの Bluetooth でペアリングした後、デバイスマネージャーで、どの COM番号に割り当てられたか確認し、Putty や TeraTerm でオープンすると「BTstack counter (数字)」が送られてくる。
(MACでの動作確認していないのは、単にMAC環境が手元にないだけのことなのは前回と同じ)

Bluetooth SPP を使ったプログラムのやり方

と、これだけでは、寂しいので、Bluetooth SPP を使ったプログラムのやり方を説明しよう。

$ cd ~/
$ git clone https://github.com/bluekitchen/btstack.git
$ patch -p1 -d btstack < patch.patch
$ cd btstack/port/esp32/
$ ./create_examples.py
<< ここまでは上と同じ >>
$ cd ~/
$ cp -rp btstack/port/esp32/spp_counter ./spp_test

さて、必要なファイルは以下の通り

spp_test
├── Makefile
├── components
│   └── btstack
│   ├── component.mk
│   ├── include
│   │   └── btstack_config.h
│   └── main.c
├── main
│   ├── component.mk
│   └── spp_counter.c <= spp_test.c にファイル名変更
└── sdkconfig

・ spp_test/Makefile に2箇所ある「spp_counter」を「spp_test」に変更
・ spp_test/main/spp_test.c に2箇所ある「spp_counter」を「spp_test」に変更
・ spp_test/components/btstack/component.mkの「BTSTACK_ROOT := ../../../btstack」に

本当は、BTSTACK_ROOTを絶対パスで指定したいのだけど、何故か相対パスでしか動かなかった。絶対パスで設定する方法を知っている人がいたら、教えてください。

後は、make して、書き込むだけ。

$ cd spp_test/
$ make all
$ make flash << ESP-WROOM-32をUSB接続していれば、書き込まれる >>

さて、プログラム本体は、spp_test/main/spp_counter.c で、データを送信している部分は、 rfcomm_send(rfcomm_channel_id, (uint8_t*) lineBuffer, strlen(lineBuffer)); だ。

まあ、想像が付くと思うが、rfcomm_channel_id がSPPドライバ番号で、続いてバッファのポインタと送信バイト数だ。戻り値が「0」なら正常に送信できた事になる。
試してみたら、バッファの中はテキストだけではなく、バイナリーでも問題なく、rfcomm_send() の戻り値が「0」以外のときは、バッファの中身が一切送られていないだけだ。
送る時間間隔を短くし、バンバン連続して送ったら、最大25kバイト/秒で送ることができた。

受信の方は、「case RFCOMM_DATA_PACKET:」あたりらしいのだが、まだ試したことはない。
誰か、確認したら、教えてください。

と言うわけで、ESP-WROOM-32 の Bluetooth Classic SPP接続も使えそうになってきた。
これからが楽しみである。

| | Comments (0) | TrackBack (0)

May 28, 2017

ESP-WROOM-32のBluetooth Classic SPP接続に成功

GitHubのbtstackが進んでいて、ESP-WROOM-32のBluetooth Classic SPP接続に成功したので、報告する。
前回(4月25日)の時点では、接続後わずか数秒でアボートしていたが、今回は、200kpbs (もしくは250kpbs)と言う高速で安定して通信できるようになった。

ESP-WROOM-32には、3つの無線通信機能がある
・Wifi
・Bluetooth Classic
・Bluetooth Low Energy (BLE)

この内、Wifiは、無線LANそのものなので判りやすいが、Bluetooth Classic と BLE の違いが判り難い。
Bluetooth Classic は、Bluetooth 3.0以前から存在するプロトコルで、どちらかと言えば高速性を目指したもので、BLEは、Bluetooth 4.0で新設されたプロトコルで、高速性よりも低消費電力性を目指したものだ。
Bluetooth 4.0以降は、Bluetooth ClassicもBLEも包含した規格なので、ややこしい。

Wifi、Bluetooth Classic、BLEの特徴を整理すると、おおよそ、次のようになる。
・Wifi:無線LAN 周辺機と言うよりネットワークとしての接続方法。伝送速度は数Mbps以上と高速
・Bluetooth Classic 周辺機器用プロトコル。特にSPPは接続が簡単。速度は実効的に200kpbs程度
・BLE 低消費電力。周辺機器用。速度は実効的に5kbsp程度で遅い。親機専用に個別アプリを作る必要がある。

Bluetooth Classic SPP は、昔からあるプロトコルで、親機のターミナルソフトからシリアル通信できるように接続が簡単なため、良く使われてきた。ただし速度が早い分、消費電力も大きい。
一方、BLEは、新しい規格のため、Androidなら4.3以降、Windowsなら8以降でないと使えないし、親機側にいちいち専用個別アプリを作る必要があって、面倒。その代わり、低速だけど低消費電力のためボタン電池で何ヶ月も使えると言うメリットもある。

私も含めて、自作派としては、馴染みのある Bluetooth ClassicのSPP が、ESP-WROOM-32の無線通信機能の中で、最も使うことができずにいたのが、今回のbtstackで使えるようになったのが、嬉しいところだ。

さて、肝心の使い方だが、、Ubuntu 16.04 上でesp-idfが既にインストールされてるものとして、説明する。
(この辺、前回前々回の記事を参考して欲しい)
また、パッチも作った。「patch.patch.gz」をダウンロード
作業は次の通り

$ git clone https://github.com/bluekitchen/btstack.git
$ patch -p1 -d btstack < patch.patch
$ cd btstack/port/esp32/
$ ./create_examples.py
$ cd spp_counter/
$ make all
$ make flash << ESP-WROOM-32をUSB接続していれば、書き込まれる >>

これで、例えば Android なら、普通にBluetoothペアリングした後、「BT Simple Terminal」などでオープンすれば、一秒ごとに「BTstack counter (数字)」が送られてくる。(私が試したのは、Android7.0 スマホだが、Android4.2以前のスマホでも接続できるはずだ)

Ubuntuなら、前回と同じようにCUIでペアリングする(GUIでペアリングしていけないのは前回と同じ)
$ sudo rfcomm bind 0 XX:XX:XX:XX:XX:XX
$ sudo chnod 666 /dev/rfcomm0
$ kermit
> set line /dev/rfcomm0
> c
とやると、「BTstack counter (数字)」が送られてくる。(今回は安定して長時間送られてくる)

Windows10の場合、ペアリングまでうまく行くのだが、ターミナルソフトで仮想COMポートを開くとエラーになると言う不具合が残っている。

Ubuntuを親機として、「BTstack counter (数字)」の代わりに大量にデータを送るプログラムを作ったら、毎秒約25kバイトの安定した通信に成功した。毎秒25kバイトは、1バイトは8ビットなので、200kbpsなのか、仮想的なシリアル通信とすると、スタートビットとストップビットを足して1バイトを10ビットとして250kpbsと計算するのかは、わからないが、とにかく、「毎秒約25kバイトの安定した通信」を確認できたことは間違いない。200kbpsだろうが、250kpbsだろうが、Bluetooth Classic SPP接続としては、ほぼ上限値なので、大成功と言えよう。

WindowsでのSPP通信が未だできていなので、完全ではないが、AndroidとUbuntuとの通信実験に成功したので、報告した次第である。
(MACと実験していないのは、単にMAC環境が手元にないだけのことである)

| | Comments (0) | TrackBack (0)

April 25, 2017

ESP-WROOM-32のBluetooth Classic接続に一部成功

E309ESP-WROOM-32のBluetooth Classic接続に一部成功したので報告する。
GitHubのbtstackにESP32対応のブランチがある事を発見した。

やり方だが、まず、Ubuntu 16.04 上でesp-idfが既にインストールされてるものとして、説明する。
もちろん、Ubuntu 16.04 は、Bluetooth内蔵、またはBluetooth USBドングルを持っているものとする。

適当なディレクトリで下記を実行する。
$ git clone https://github.com/bluekitchen/btstack.git
$ cd btstack
$ git checkout -b esp32-freertos origin/esp32-freertos
$ cd port/esp32/
$ ./create_examples.py
$ cd spp_counter
ここで sdkconfig を下記の diff を参考に変更する
$ diff sdkconfig sdkconfig.org
32,33c32,33
< CONFIG_ESPTOOLPY_PORT="/dev/ttyUSB0"
< CONFIG_ESPTOOLPY_BAUD_115200B=y
---
> CONFIG_ESPTOOLPY_PORT="/dev/tty.usbserial-DN02B3PF"
> # CONFIG_ESPTOOLPY_BAUD_115200B is not set
37,40c37,40
< # CONFIG_ESPTOOLPY_BAUD_OTHER is not set
< CONFIG_ESPTOOLPY_BAUD_OTHER_VAL=115200
< CONFIG_ESPTOOLPY_BAUD=115200
< CONFIG_ESPTOOLPY_COMPRESSED=y
---
> CONFIG_ESPTOOLPY_BAUD_OTHER=y
> CONFIG_ESPTOOLPY_BAUD_OTHER_VAL=1000000
> CONFIG_ESPTOOLPY_BAUD=1000000
> # CONFIG_ESPTOOLPY_COMPRESSED is not set
ここで、EPS-WROOM-32をUSB接続し、BOOTボタンを押しながら、リセットボタン(ENボタン)を押す
$ make all
$ make flash
プログラムを書き込んだ後、kermit等のターミナルソフトで/dev/ttyUSB0 を速度 115200 で接続して、もう一度リセットボタンを押す

注意すべきは、ここでデスクトップ右上のBluetoothマークをクリックすると、EPS-WROOM-32 が見えるのだが、GUIではペアリングしない事だ。GUIでペアリングすると、以降の接続とテキスト伝送ができないので、GUIでペアリングしてしまった場合はペアリングを解除する。GUIからは、ESP-WROOM-32のBluetoothのBDアドレスを記録するにとどめる。

次にCUIでペアリングする
$ sudo rfcomm bind 0 XX:XX:XX:XX:XX:XX
$ sudo chnod 666 /dev/rfcomm0
もう一つ kermit を起動する
$ kermit
> set line /dev/rfcomm0
> c
とやると、上手くすると、
BTstack counter 0001
BTstack counter 0002
と言うように、SPP 接続してテキストが送られてくる
残念ながら、上手く行っても2行か3行で、ESP-WROOM-32側のプログラムはコアダンプしてしまう。運が悪ければ、接続する以前にコアダンプする。
コアダンプした様子は、/dev/ttyUSB0に接続したKermitでモニターできる。
諦めずに何度も試すと、上手く行くこともあるだろう。

このように、まだまだ、ESP-WROOM-32の Blutooth Classic の SPP 接続は不完全かつ不安定な状態で実用には程遠い。
しかし、少なくとも ESP-WROOM-32が短時間であっても曲がりなりにも Blutooth Classic 接続ができたことが重要であると思ったので、ここに報告した。
GitHubのbtstackも進歩が速いので、放っておいてもいずれは解決するかもしれないが、この書き込みが何かの役に立って解決の糸口が見つかるようになれば、幸いである。


| | Comments (2) | TrackBack (0)

February 24, 2014

トラ技ARMライタをUbuntuのOpenOCDで使う(プラス パッチ)

E292トランジスタ技術2014年3月号に付いている『トラ技ARMライタ(写真左)』を Ubuntu の OpenOCD で使い、自作のSTM32F4基板(写真右)に接続する事に成功した。
この時、僅かではあるが、OpenOCD のバグを見つけたので、その報告も行う。

私の Ubuntu は、12.04 で、この上で OpenOCD を CMSIS-DAP 対応にビルドする。

$ sudo apt-get install libtool libudev-dev autoconf libusb-dev libusb-1.0-0-dev
$ git clone http://github.com/signal11/hidapi.git
$ cd hidapi/
$ ./bootstrap
$ ./configure
$ make
$ sudo make install
$ sudo ln -s /usr/local/lib/libhidapi-hidraw.so.0 /usr/lib/libhidapi-hidraw.so.0
$ sudo vim.tiny /etc/udev/rules.d/99-hidraw-permissions.rules
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev"
を追加。
$ cd ..
$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
$ cd openocd/
ハッシュは『6c74255ee2569bf2748ecbbd252e2a91bbce6644』だった。
$ ./bootstrap
$ ./configure --enable-maintainer-mode --enable-cmsis-dap --enable-hidapi-libusb
$ make
$ sudo make install

トラ技ARMライタとSTM32F4とは SWDIO、SWCLK、NRESET、GNDを接続。

/usr/local/share/openocd/scripts/target/stm32f4x.cfgの 38行目の「 jtag_ntrst_delay 100」をコメントアウトし、STM32F4の電源を入れた状態で、下記コマンドで、OpenOCDが起動する。

$ openocd -c "interface cmsis-dap" -f /usr/local/share/openocd/scripts/target/stm32f4x.cfg
Open On-Chip Debugger 0.8.0-dev-00350-g6c74255 (2014-02-19-22:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 1 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : IDCODE 0x2ba01477
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

これで、6割方は上手く行く。と言うのも、私が持つ3台の Ubuntu 12.04マシンのうち、1台が下記の様にコアダンプして異常終了するのだ。

$ src/openocd -c "interface cmsis-dap" -f /usr/local/share/openocd/scripts/target/kl25.cfg
Open On-Chip Debugger 0.8.0-dev-00350-g6c74255 (2014-02-24-20:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
Segmentation fault (コアダンプ)

このマシンは、、CPUがAMD Athlon64X2 4200+ 2.2GHz、マザーボードがMSI K9N6PGM2-V と言う古い古い構成。ハードウエアの内どの部分が悪いかは不明だが、OpenOCDのソースコードの「openocd/src/jtag/drivers/cmsis_dap_usb.c」の176行目を
if ((0 == cmsis_dap_vid[0]) && wcsstr(cur_dev->product_string, L"CMSIS-DAP")) {
から
if ((0 == cmsis_dap_vid[0]) && (NULL != cur_dev->product_string) && wcsstr(cur_dev->product_string, L"CMSIS-DAP")) {
に変更して、ビルドし直すと、問題が解決する。
上記の行、たぶん、バグだと思うので、正式のOpenOCDに反映してもらうように働きかけようかな・・・とも考えている。

| | Comments (0) | TrackBack (0)

November 17, 2013

デジタルオーディオプレーヤー・リファレンスモデル

E2891ここ1ヶ月ほど、暇を見つけてはコツコツと写真のような『デジタルオーディオプレーヤー・リファレンスモデル』を作っていて、昨日の土曜日にやっと音が鳴るようになった。

なぜ、こんな『デジタルオーディオプレーヤー・リファレンスモデル』と言う大層な名前のオーディオプレーヤーを作ったかと言うと、コミケにも出品したポータブル型のデジタルオーディオプレーヤーのさらなる性能向上を目指したからだ。

『ポータブル型のオーディオプレーヤー』は、その名の通り持ち運びに便利なように小型軽量に作っている。そのため、工作や回路変更が難しい。例えば、音を良くするための実験として、ローパスフィルターの特性周波数を変更するためにコンデンサーを交換するが、何回も繰り返すとプリント基板のパターンが剥がれてしまう。また、そもそもローパスフィルターの次数を変えることなど大幅な回路変更を伴う実験などはできない。

そこで、多少大きくても良いから、色々な実験ができるオーディオプレーヤーを別に作り、そこで実験して得たデータを使って、次回作の『ポータブル型のオーディオプレーヤー』の設計に反映しようと考えた。この実験のためのシステムが『デジタルオーディオプレーヤー・リファレンスモデル』である。

E2892『デジタルオーディオプレーヤー・リファレンスモデル』は左のようなブロック図になっている。『ポータブル型のオーディオプレーヤー』は、電源に単一のバッテリーを使っており、これがノイズの混入などの音質劣化を招いていた。このため、『デジタルオーディオプレーヤー・リファレンスモデル』では、独立電源としている。図のうち 3.3V電源のみがデジタル回路用で、5V電源は DAC のアナログ部専用電源、±9V電源が純粋なアナログ用電源だ。

ローパスフィルターやヘッドホンアンプ部は、それぞれ独立したモジュールとして、今後色々な回路を試せるようにしている。
特に、クロック部も独立したモジュールとしている。今までは、音源用のサンプリング周波数は、CPUである STM32F4の内部のPLLで、CPU駆動用クロックから作っていた。音源用のサンプリング周波数に PLL を使うとジッタを発生するため、音質が劣化すると言われている。今後、専用周波数のTCXOを使い、ジッタのないクロックを使って音質が向上するかの実験も行うつもりだ。

このように、『デジタルオーディオプレーヤー・リファレンスモデル』は、いままでのポータブル型では試せなかった贅沢な回路の実験を行うので、ずっと音は良くなるはずだ。

だが、『デジタルオーディオプレーヤー・リファレンスモデル』、本来、高音質を狙うオーディオでは、やってはいけない事をやっている。
その1つが、回路が過度に分割されていることだ。本当なら、CPU部とクロック部を同じ基板、ローパスフィルターとヘッドホンアンプを同じ基板にすべきだ。その方がモジュール間の結線が短くて、ノイズや音質劣化が少なくて済む。

もう一つは、モジュール間の結線が無駄に長く、コネクタを使って接続していることだ。結線が長いのは、今後、モジュールを交換する時の余裕をみているからで、コネクタを使っているのもモジュール交換するためである。本来、結線は必要最小限の長さにし、コネクタを用いずに直接基板に半田付けする方が音質劣化にならないことは言うまでもない。

このように実験しやすい様にモジュール化したため、多少の問題はあるとは思うが、少なくとも『ポータブル型のオーディオプレーヤー』よりは、良い音になるはずだ。

しかし、『デジタルオーディオプレーヤー・リファレンスモデル』は、昨日やっと最低限の機能である『音楽が演奏できる』ようになったばかりであり、性能的には、まだまだである。クロック部は未だ手付かずで、現状は、サンプル周波数はCPUの内部PLLを使っている。ローパスフィルターは、パッシブのCRフィルターで間に合わせた。ヘッドホンアンプは、CQ出版 の「OPアンプMUSESで作る高音質ヘッドホンアンプ」に掲載されている回路を、そのまま使っている。

特に酷いのは電源部で、 3.3Vだけはレギュレーターで安定化しているが、その他の電源は安定化もせず、ダイオードブリッジの出力にコンデンサーを付けただけだ。

このため、ハム・ノイズが酷い。その上、濁ったような乱れた音に歪んでいる。
早い話が、まだ『ポータブル型のオーディオプレーヤー』より音が悪い。

まあ、一ヶ月くらい、あっちこっち弄ったら、『ポータブル型のオーディオプレーヤー』と同じくらいの音になるだろう。その後は『ポータブル型のオーディオプレーヤー』より良い音になるに違いない。

ある程度、音が良くなったら、試したいことは山ほどある。
・既に言ったように、ジッタの無いクロックだと音は良くなるか?
・音響用の高価なコンデンサーや抵抗だと、本当に音は良くなるか?
・ローパスフィルターの特性周波数や次数は音にどう影響するか?
・OPアンプの種類で、音は違ってくるか?
などなどなどだ。

ある程度、実験が進んだら、また報告する・・


| | Comments (0) | TrackBack (0)

September 13, 2013

MAKERS 読了

E287クリス・アンダーソン著 MAKERS 〜21世紀の産業革命が始まる〜 を読んだ。私が「コミケ報告 〜その3」の中で言いたかった「個人によるモノ作り」と同じような事を分厚い書籍にしたもの。日本語訳は昨年10月に出版されている。

実は、コミケ開催以前に、今回の私のコミケ参加の目的は「コミケにおける個人によるモノ作り」の実情調査だと周囲の人には話しており、それを聞いた一人が「野田さんと同じような考えをまとめた本があるので、是非読むべきだ」と指摘を受けていた。その人から話を聞く分には、確かに私が考えているのと同じような内容の本だと思えた。しかし、コミケにおける実情調査の前に、その本を読むと先入観を持ってしまう可能性があったので、コミケが終り、その結果を「コミケ報告 〜その3」にまとめるまで本を読むのをひかえていた。従って、「コミケ報告 〜その3」の内容は、MAKERSを読む以前の 完全に私のオリジナルの考えである。

さて、MAKERSを読むと、「コミケ報告 その3」で指摘していた「ミッシングリンク」つまり「個人によるモノ作りが日本全体の技術向上に繋がることは疑い無いが、大金を儲ける事も、雇用を生み日本経済を支えるところまでは私には未だ方法が判らない」と言う部分に関して、かなり楽観的な事が書いてあった。しかし、MAKERSは、アメリカ中心の考え方であり、欧米が「個人開発」と言う頭脳中心の発展をする一方、中国を始めとするアジア諸国が「生産」と言う肉体労働(?)と言う格差を利用することを暗に示しているが、アジア諸国の一角である日本の場合、この考えが通用するか甚だ疑問である。
その他、キックスタートなど、初期の資金調達に必要な仕組みなどを詳細に説明してあり、さすがに「ワイヤード」の編集長を務めるだけあって、情報収集と読みやすい文章は、私は足元にも及ばない。

しかし、その一方、私がモノ作りに必要かつ重要だと思う項目が3つ抜けていた。それは、以下の3つだ。
1) 設計
2) インテグレーション
3) 作品としての評価

著者であるクリス・アンダーソンは、この3つの項目が重要であることを見抜いていないのか、それとも「MAKERS」で書いていないだけのかは判らない。彼の生い立ち(職人である祖父の元でモノ作りを学んだ少年時代など)や その後を見ると「設計」と「インテグレーション」を知らずに居るとは思えない。が、一方、「設計」についてはバート・ルタンの実例やローカルモーターズの場合には既存の構造をそのまま使う例を出してはいるものの、「MAKERS」の記述だけでは天才や以前からのプロとしての経験によってのみしか「設計」ができない事になってしまう。
残りの「インテグレーション」と「作品としての評価」については、「MAKERS」に少なくとも私が重要だと思える事について記述は無かった。

さて、私が重要視していると言う「1) 設計」「2) インテグレーション」「3) 作品としての評価」だが、いきなり3つの言葉を並べられても、読者は困惑してしまうだろう。特に私が使う「設計」と一般の人がイメージする「設計」では異なるため、誤解される恐れがある。

一般的に「設計=デザイン」と言う言葉から、どう言った事を連想するだろうか?
「形状・装飾デザイン=スタイリングや装飾を設計・デザインする」事だろうか?
それとも「製造設計=製造に必要な図面や回路図をCADや製図機を用いて描く」事だろうか?

「設計」には、大きく分けて「機能・性能設計」と「形状・装飾デザイン」と「製造設計」の3つが在る。この3つの内、後の2つが一般的にイメージされる「設計」だ。じゃあ、「機能・性能設計」は、ほとんど認知されていない。

ちょっと極端な例で、3つの設計の違いを説明しよう。
「二輪車が存在しない」世界を想像して欲しい。自転車もオートバイも無い世界だ。自動車は全て4つ以上の車輪を持っている。
この世界で、新しい自動車を作ることになった。ネット上でチャットなどを使って、新しい自動車作りについて議論する。
この時、「格好良いデザインにしようよ。流線型にして、先端は尖らせて・・」と言うのが「形状・装飾デザイン」だ。
次に「判った。それじゃ、僕がCADで図面を描くよ。その図面をネットで業者に送ったら、すぐに製造できるような図面をね」と言うのが「製造設計」だ。

とまあ、こんな感じで進むかも知れない。
スケッチや図面と言った画像も入るかも知れないが、基本的にはネット上のテキストのやり取りで設計が進む。

しかし、誰かが「なんで車輪が4つもあるんだ? 2つにできたら良いのに」と言い出したらどうだろう?
「そんなもの倒れるに決まっているだろう。できるわけない」で終わってしまうのが想像できる。

だが、実際には2つの車輪で倒れずに走行できる。
この技術的ギャップを埋めるのが、「機能・性能設計」だ。
「MAKERS」の中では、バート・ルタンが「カナード=先尾翼機」を作ったところにあたる。「MAKERS」では例は示しても、これを新しい「個人的なモノ作り」で具体的にどう行うかの説明はない。
私は、このような「イノベーティブな機能・性能設計」の解決法を全く持っていないわけではないが、まだ試行段階だ。いずれ、もう少しまとまったら、ブログでも書きたい。

次の「インテグレーション」だが、この言葉自体初めて聞く人も多いかもしれない。「外部業者で作ったものを組み合わせて構築し、最終的に動くものを創り上げる事」だ。
実は、「インテグレーション」は、人工衛星を作る時の用語で、一般的な日本語で言うと「統合」とか「組立・整合性試験」とか、そう云うイメージのものだが、あまり適当ではないので、ここでは「インテグレーション」を使わせてもらう。
ネット経由で海外の業者に発注したモノが製造され送られてきたものが、設計通りにできていても、それらを組み合わせてちゃんと動くと思ったら大間違いだ。
多くの場合、「設計図通り」に動かない。
むしろ、全く新しいモノを作る場合、一発目から「設計図通りに作ったら、動作する」ような設計図を描ける人は、まずいない。

製造されたものを組み合わせる。この時、単体での試験を行い、想定通りの機能・性能を満足していることを確認しては、次のモノと組み合わせていく。個々の機器が単体で機能性能を満足しても組み合わせると動作しないことが極めて多い。このような場合に、それぞれの問題を、可能ならその場で解決して組み上げていき、最終的に全て組み合わせて動くようにする、これが「インテグレーション」だ。

「インテグレーション」の過程で出てくる不具合は、その場で対処療法的に対処される一方、製造の元になった設計図等に反映し、次のサイクルでの再発を防ぐ。このように一通り機能するようにしたのち、再び、設計に戻り、改良された設計で再製造・インテグレーションを繰り返す。
このようなサイクルを何回か繰り返したのち、「設計図通りに製造したら機能するモノ」ができる。私のオーディオプレーヤでも、プリント基板を起こした時点から3サイクル、その前のユニバーサル基板での試作を加えると4サイクル回している。データロガーの場合は、それぞれ、2サイクル・3サイクルだ。
「インテグレーション」の言葉は知らなくても、モノ作りをするものなら、誰もが行なっている極めて重要な工程である。

「設計」と「インテグレーション」は表裏一体のところがある。
私の技術者としての経験から言うと「インテグレーション」を先に覚え、その後「設計」を知った。これが一般的なのかは判らないが、いずれにしろ、この2つがモノ作りに必須であることは間違いない。

最後の「作品としての評価」は、少し異質だ。
「作品としての評価」は、私の「コミケ報告 その3」のブログで、「機能作品してのアート性」として強調していた部分である。要は、「私の作ったオーディオプレーヤのアート性は実際に聞いてみなければ判らない」と言うことだ。

書籍「MAKERS」の中で、個人的なモノ作りをする人が、多くの人に理解してもらうには、ネット上でのプレゼンテーションすなわち、テキストや画像、動画を使って如何にアピールするかが重要であると言う事が、直接的ではないにせよ、間接的に書いてある。しかし、これは投資家や経営者、評論家サイドから見た技術者への要求であり、技術者から見れば無理難題だ。

私のオーディオプレーヤを例にさせてもらうと、どんなに言葉で説明しても、その音の本当の伝わらない。動画にしても同じだ。私のオーディオプレーヤの音を録音して、それをYoutubeにアップしても、その動画から聞こえる音は、あなたの持っているパソコンに付いているスピーカーなりイヤホンの音であり、私のオーディオプレーヤの音ではない。

ネットでアピールするために、テキストや写真、動画にすることは、結局大なり小なり偽りが含まれる。偽りのアピールは偽りの連鎖を産んで、本質から離れていく。個人的なモノ作りをする人の中には、本質から離れた偽りのアピールに嫌気がさし、作ったものの本質を訴えたいと思っている人が少数でも確実にいる。

また、モノ作りが得意な人は、必ずしもアピール上手ではない。いやむしろアピールが苦手な人、口下手な人が多いのではないか?
一人の人間が持つ能力には限界がある。本当にモノ作りができる人よりアピールの上手い人が作ったモノの方が受け入れられやすい。
「ろくにモノ作りもできないのに、口ばかり上手い奴ばかりがなんで受けるんだ?」と思った人も多いだろう。
大企業によるモノ作りの場合、モノを作る技術者とは別にアピール上手な人を専門においていた。それが「営業」だったり「広報」だったりする。モノ作り専門の技術者は、本質的に良いものを作るのではなく、「営業」や「広報」がアピールしやすいものを優先的に作らされてきた。それに嫌気がさして「個人的なモノ作り」をしたいと思った人もいるはずだ。
にもかかわらず、「個人的なモノ作り」もまたネット上での「アピール」が優先されるとなると、本末転倒である。

コミケのように、多くの人に「実際に音を聞いてもらう」ことは貴重な機会だ。これは、オーディオプレーヤに限らず、機能するモノを作るのなら、共通して同じで、どうやっても、テキストや写真、動画で伝わらない「機能」がある。
Makeフェアーも、コミケと同じように実際に「機能」を見てもらう良い機会となり得る。しかし、「MAKERS」でのMakeフェアーの扱いが思いの外少なかったので、気になった。

また、長文になってしまった。
「イノベーティブな機能・性能設計」や「インテグレーション」「評価」については、別の機会に詳しく書きたいと思う。

| | Comments (0) | TrackBack (0)

より以前の記事一覧