■2018-12-31
★WebIOPi
Raspberry PiでWeb Serverを稼働させ、ROBOTの操縦することにトライしている。行き着いた先は、WebIOPi。現状、PC WiFi UDP C#→RasPi Python→ESP32 C++→ROBOTで操縦しているが、Web Server化すれば、操縦のためのアプリをいちいちPCやスマホにインストールする必要がなくなり、圧倒的に利便性が増す。操縦アプリのUI・画面デザインも、htmlで自在となる。
PC or スマホWebブラウザ→RasPi index.html(WebIOPi Web Server)→RasPi Python(WebIOPi ライブラリー)→ESP32 C++→ROBOTとした。一見、面倒なように見えるが、これでROBOT自身がWebサイト化し、あらゆるスマホ、PC等のWebブラウザからROBOTの操縦やStatusの表示が出来るようになる。左上の小窓がTEST用の操縦画面である。
■2018-12-28
★ジャイロ・センサー L3G4200D
ジャイロ・センサーに、すっかりハマっている。JY901で満足な結果が得られなかったので、よりシンプルな、３軸センサーのL3G4200Dでトライした。このグラフは、静止状態のROBOTでYAW軸の積分値のドリフトを測定したもの。１０秒間キャリブレし、１０秒間積分をする、を繰り返したものである。結果は、満足できるものでは無いが、廉価なジャイロでは、この程度が限界かと思う。最初の１時間は、±２°に収まっているが、その後４０００秒にかけての、急激な変動が無ければ、マズマズだと思う。原因は不明だが、これがバイアス不安定性と言うものなのだろうか？
だいたい廉価版のMEMSジャイロの性能・素性を認識できた。やはり、FOG並みのジャイロの導入が必要だと思う。
■2018-12-23
★９軸センサー・JY901
９軸センサーJY901を搭載したROBOTで慣性航法での走行を目指している。上のグラフは、ROBOTを静止した状態で、YAW軸のジャイロ・センサーの角速度を積分し、１秒毎にプロットしたものであるが、この値の乱れでは使えない。ジャイロ・センサーには、ドリフトがあるので、長時間測定した結果から平均的なドリフト量を求め、これを使って補正をかけている。６０秒毎にキャリブレ―ションしても、大した改善にはならない。それが、以下のグラフで、６０秒間キャリブレーションのために、ドリフトを計測・平均化しそれをオフセットとし、６０秒間角速度積分をし、またキャリブレーション、のサイクルを繰り返している。ジャイロ・センサーのドリフトは、極めて気まぐれなので、期待通りには消せない。
JY901はカルマン・フィルター処理を内蔵マイコンでやっているが、YAW軸は加速度センサーでは補正できない。地磁気センサーの値を使って補正をかけているらしいが、鉄筋の建物の中では地磁気の方向は乱れていて、実験の結果使えないことを確認した。Madgwickフィルターでも、同様であった。
なので、現状、行き詰っている。ここは、超高価だが、レーザーを使ったジャイロ（or 同等品）を導入するしか、ない？？？
■2018-12-09
★RasPi Python
通過儀礼のLチカから、RasPiも早２ヶ月。製作中のROBOTに組み込み、稼働出来る状況になった。ESP32 C++←（Serial）→RasPi Python←（UDP）→PC excel VBAの構成。ハード寄りのステッピング・モーターのPWM疑似サイン波駆動などは、やはりESP32が向いている。HMIは、ゼロから作るのも手間なので、PC excel VBAを流用し、その間にRasPi Pythonを置いている。RasPiにインストールしたsambaで、PCとファイルの共有も可能となったので、Excel VBAで書いたファイルをRasPiで読み込みROBOTの走行データとして使うなど、ESP32・SPIFFSを使っていた頃より、圧倒的に自由自在となった。
■2018-11-12
★フルステップとマイクロステッピング・ドライブ
ステッピング・モーターのドライブには、何通りかの方式があるが、基本形は単純なフルステップ・ドライブである。この方式では、矩形波で駆動するので、トルクリップルによる動作音がかなり大きい（品位に欠ける）。マイクロステッピングは、疑似Sin波で駆動する。上の動画では、５度刻みの疑似Sin波をPWM化して駆動している（１５度刻みでは、粗過ぎ）。プログラムは、多少面倒になるが、材料代がかかる訳でもないので、お勧めのドライブ方式である。
■2018-11-11
★Hope Carry0 走行試験
今まで、路面条件の良い部屋の中で走行試験をしていたが、庭に出してやってみた。部屋の中では、時速10Km/h（プログラムでMax Speedを制限している）も出すと極めて短時間の走行しか出来ないが、外では比較的長い距離の走行が可能である。元々、このような遠隔操作での使い方を想定していないが、片側が自在キャスターなので、直進させるのは難である。
試験している最中に、宅急便で山形から米（つや姫）30Kgが届いたので、これを載せてのテストもしたが、インホイール・モーターのトルクは充分だと思う。
このような遠隔操作をするのであれば、直進性の改善が必要である。ジャイロ・センサーを使って、ブレを抑え込むことは、可能だと思う。
■2018-10-21
★９軸方位センサー（JY901）
走行系ROBOTには、直進性や回転角度、傾きを得るために方位センサーが必須である。地磁気センサーHMC5883LやジャイロセンサーL3GD20を使ってきたが、最近では小さな１モジュールの中に、９軸分（地磁気、ジャイロ、加速度、それぞれXYZ）入っているセンサー（JY901など）が入手可能である。しかも、モジュール内のマイコンでジャイロにはカルマン・フィルター処理も施されている。これを、入手したのでメーカーのWebサイトにあるデモ・アプリで動かしてみた。ジャイロのドリフトは、除去されているようだ。近日中にROBOTに搭載して詳細評価してみたい。
■2018-10-19
★最大積載量
Hope Carry 0の目標最大積載量は、６０Kgだがテストする荷物が身近になかった。先日、ROBOT見学のお客様が来訪して、その中の若い女子（掲載許可は頂いています）が５？Kgだったので、乗って頂いた。多少スタート時にモタついたものの、前後進、左右回転してみたが、問題無く走行した（中華インホイール・モーター凄い！）。私的には、動画を撮りたかったが、そこまではお願い出来ず、静止画で我慢、、、
■2018-10-17
★ESP32 and Pi Zero
ESP32とRaspberry Pi ZeroをSerial（それぞれのデバイスのUART Tx,Rxのクロス・接続）で接続した。これは、PiZeroをコントローラーのメイン（RTK-NaVi、画像処理等の重い処理）とし、SerialでROBOT操縦コマンド等をサブのESP32へ送るためである（モーター、センサーなどの扱いは、Arduino系が得意）。ROBOTコントロール基板に遠隔操作できるLinux PCが乗った！と言えると思う。とりあえず、工房のWindows PCからUDPで送信したROBOT制御コマンドをPiZeroで受信して、ESP32へ伝えるところまでは、成功した。今後PiZeroでは、他の処理も行う予定なので、UDP受信・Serial転送は、マルチスレッド化して、専用のスレッドで行っている。Pythonのプログラムの簡潔さには、感動する、、、
import socket
import serial
import time
import threading
def Rx():
UDP_IP = ""
UDP_PORT = 8090
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
con=serial.Serial('/dev/serial0', 115200, timeout=10)
while True:
data, addr = sock.recvfrom(1024)
con.write(data)
ThreadRx=threading.Thread(target=Rx)
ThreadRx.start()
工房PCからUDP送信して、PiZeroで受信してESP32へSerialで転送しEcho（EchoはESP32からUDPで返している）を返せるようになったので、内蔵WiFiでの簡単な到達距離実験をやったが、いつもやっている畑の片隅（距離６０ｍ程）では充分通信可能であった。また、VNCでのPiZeroの遠隔操作は、ESP32では味わえなかった新境地を感じる。新しい世界を構築できると思う。
PiZeroのGPIO Pinは、基板の逆面についていた方が使い勝手が良いと思う、今後はPin無し版を入手したい。PiZeroは、世界的に品薄状態で値段が高いが、潤沢に供給され、Targetコストの$5程度になることを期待している。
■2018-10-14
★Arduino Nano～Raspberry Pi 3B+
これまで、ROBOTに使ってきた（今後使って行く）マイコン・モジュール(ioio、ESP8266も、）だが、時代の変遷を感じる。ESP32とPi Zeroがほぼ同サイズだが、パフォーマンスはPi Zeroが圧倒している。これに、８本程度のPWMとA/Dコン入力があれば、最強なんですがねぇ。
■2018-10-12
★ステッピング・モーター的モード
インホイール・モーターは、マイコンからパルス信号で制御している。構造が、ステッピング・モーターと比較的似ている。このパルス信号をカウントすれば、何回転したかが分かる（このモーターでは、１回転９０パルス：回転角４°刻み、10/8実験のステッピングモーターでは、１回転２００パルス：回転角１．８°刻み）。タイヤの直径と回転数で走行距離を計測することが可能か、実験した。パルスのカウントにより、１０回転（９００パルス）したら停止するプログラムを作成し、動作させたのが上の動画である。回転角４°刻みで、１回転の途中も指定可能。要求精度にもよるが、まずまずの精度で、自動停止し、走行距離計測に使えると思う。
■2018-10-11
★Hope Carry 0
お客様からの、開発受託機種ですが、サイト掲載のお許しを頂き、Upしました（感謝！）。
荷物運搬用途向けで、Target仕様は60Kgの荷物の運搬。サイズは、ROBOT4の４倍、400×600㎟。従来機種は、ブラシ・モーターを使ってきたが、トルク、スピード性能向上のため、インホイール・モーター（３相ブラシレス・モーター）を採用した。モーターのコントロールは、相当面倒で、１つのモーターに１マイコン必要、２つのESP32でコントロールしている。しかしながら、モーターとしての性能（トルク、スピード）は圧倒的だと思う。また、ギアが無いので、ほぼ無音である。耐久性、信頼性のUpも期待できる。
このモーターは、３０極（S・N磁極15セット）で、１回転を15分割した刻みで制御している。従って、360÷15=24°の分解能で制御可能である。タイヤの直径は6.5インチ（165mm）なので、走行距離34.5mmの分解能で制御が可能である（ステッピング・モーターほどの分解能ではないが）。更に、細かく見て行くと、24°の刻みは更に6ステップで制御されているので、4°刻み（走行距離5.8mm）の制御が可能かも知れない。いつか、実験してみたい。
■2018-10-10
★6WD
ROBOT4は、用途によってはサイズが小さ過ぎるので、倍のサイズのROBOT4X2(300×450㎟)を製作した。更に、4WD➡6WD化し走破性能と最大積載量の向上も図った。また、シャーシー下面に取付けられたギア・モーターがむき出しだったので、Under Guardを付けた。最大積載量は、６Ｋｇ程度、100mmの階段状の段差を乗り越えられる。
■2018-10-08
★ステッピング・モーター
しばらく前に買って放置していたステッピング・モーターを回してみた。２相バイポーラ型のモーターで、Hブリッジが２個あれば回すことができる。ROBOT4の電子回路BOXのHブリッジを使い、ESP32でのテスト用スケッチを作成した。印象は、トルクが結構ある（モーターのSpecでは、30Kgf・cm、因みにROBOT4のギア・モーターは、9Kgf・cm）、スピード、回転方向の制御が自由自在、トルクもPWMで調整可能。３相ブラシレス・モーターより制御は容易である。
用途は、いろいろ考えられるが、これでタイヤを駆動し、精密な回転コントロール（このモーターのStep Angleは1.8°）を行い、屋内などのGPSが使えない環境での、走行距離算出などに使えると思う。
参考に、ステッピング・モーターの制御部分の関数は以下で、この関数をタイマーなどで、一定周期でコールすれば1.8°ずつ回る。周期を変えれば、回転スピードが制御できる。グローバル変数のP0,P1には、13,12（GPIOのNo.）が入るが、正転・反転制御は、入れ替えればＯＫ。GPIO13,12,14,27は、フルブリッジ・ドライバー(TB6643KQ)に接続されている。
//*****************************************************
//* SteppingMotor
//*****************************************************
void SteppingMotor() {
static int Mode = 0; //SteppingMotorの励磁コイルに電流を流すモード：0～3
digitalWrite(13, 0); //All Off
digitalWrite(12, 0);
digitalWrite(14, 0);
digitalWrite(27, 0);
switch (Mode) {
case 0:
digitalWrite(P0, 0); //A相正
digitalWrite(P1, 1);
digitalWrite(14, 1); //B相反
digitalWrite(27, 0);
break;
case 1:
digitalWrite(P0, 0); //A相正
digitalWrite(P1, 1);
digitalWrite(14, 0); //B相正
digitalWrite(27, 1);
break;
case 2:
digitalWrite(P0, 1); //A相反
digitalWrite(P1, 0);
digitalWrite(14, 0); //B相正
digitalWrite(27, 1);
break;
case 3:
digitalWrite(P0, 1); //A相反
digitalWrite(P1, 0);
digitalWrite(14, 1); //B相反
digitalWrite(27, 0);
break;
}
Mode++;
if (Mode == 4) Mode = 0;
}
■2018-10-05
★python vs c++
以下は、RasPi上で、ほぼ同じ動作をするpythonとc++によるプログラムである。どちらも、並列処理のスレッドを使い、PCからのUDPによるコマンド（文字列）を受信して、USB Serial接続されたArduinoへSerialで転送をするものである。しかしながら、何と！pythonの簡潔さだろう！！！
この歴然とした、圧倒的な差を見ると、pythonを使わない手はないだろう。
ハードウェア寄りの、uSecオーダーの緻密制御には、向かないと予想されるが、そういう部分は、Arduinoに任せられる。
////////////////////////////////////////
■ c++
////////////////////////////////////////
#include <stdio.h>
#include <pthread.h>
#include <sys/socket.h>
#include <cstdlib>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <string.h>
#include <unistd.h>
#include<string>
#include <stdlib.h>
#include <time.h>
#include <fcntl.h>
#include <termios.h>
#define BUFFER_SIZE 256
#define DEV_NAME "/dev/ttyUSB0" // デバイスファイル名
#define BAUD_RATE B115200 // RS232C通信ボーレート
#define BUFF_SIZE 1024 // 適当
using namespace std; // 名前空間指定
string msg="";
//Threadをコンパイルのために、仮宣言
void *Rx(void *ptr);
void serial_init(int fd);
//********************************************************************
//* main
//********************************************************************
int main() {
/* スレッド用パラメータ */
int handle;
pthread_t id;
handle = pthread_create(&id, NULL, Rx, NULL); //スレッドの起動
while(1){
printf("%s\n",msg.c_str());
usleep(500*1000);
}
}
//********************************************************************
//* Rx UDP受信スレッド
//********************************************************************
void *Rx(void *ptr){
int fd;
int i,j;
int len;
unsigned char buffer[BUFF_SIZE],in_data[BUFF_SIZE]; // データバッファ
fd = open(DEV_NAME,O_RDWR); // デバイスファイル（シリアルポート）オープン
serial_init(fd);
/* ポート番号、ソケット */
unsigned short port = 8090;
int recvSocket;
char bufferUDP[BUFFER_SIZE];
/* sockaddr_in 構造体 */
struct sockaddr_in recvSockAddr;
/* 各種パラメータ */
int status;
int numrcv;
unsigned long on = 1;
/* sockaddr_in 構造体のセット */
memset(&recvSockAddr, 0, sizeof(recvSockAddr));
recvSockAddr.sin_port = htons(port);
recvSockAddr.sin_family = AF_INET;
recvSockAddr.sin_addr.s_addr = htonl(INADDR_ANY);
/* ソケット生成 */
recvSocket = socket(AF_INET, SOCK_DGRAM, 0);
/* バインド */
status = bind(recvSocket, (const struct sockaddr *) &recvSockAddr, sizeof(recvSockAddr));
while(1){
memset(&bufferUDP[0],'\0',BUFFER_SIZE); //bufferUDP→&bufferUDP[0]の方が良い
numrcv = recvfrom(recvSocket, bufferUDP, BUFFER_SIZE, 0, NULL, NULL); //UDP受信
if(numrcv == -1) { status = close(recvSocket); break; }
msg=bufferUDP;
write(fd,msg.c_str(),strlen(msg.c_str())); //UDPで受信した文字列をシリアルに書く
}
}
//********************************************************************
//* シリアルポートの初期化
//********************************************************************
void serial_init(int fd)
{
struct termios tio;
memset(&tio,0,sizeof(tio));
tio.c_cflag = CS8 | CLOCAL | CREAD;
tio.c_cc[VTIME] = 100;
// ボーレートの設定
cfsetispeed(&tio,BAUD_RATE);
cfsetospeed(&tio,BAUD_RATE);
// デバイスに設定を行う
tcsetattr(fd,TCSANOW,&tio);
}
////////////////////////////////////////
■Python
////////////////////////////////////////
import socket
import serial
import time
import threading
def Rx():
UDP_IP = ""
UDP_PORT = 8090
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
con=serial.Serial('/dev/ttyUSB0', 115200, timeout=10)
while True:
data, addr = sock.recvfrom(1024)
print "rcvd:", data
con.write(data)
ThreadRx=threading.Thread(target=Rx)
ThreadRx.start()
■2018-10-04
★Raspberry Pi & Arduino
RasPiにArduino IDEをインストールした。見慣れた、Editorとシリアル・モニターが、RasPiのDeskTopに表示されて動作している姿には、新鮮さを感じる。これで、RasPiの周辺機器としてのArduinoの構想、の実現性を確認出来た。RasPiのDeskTopは、WiFi VNCで工房のPCからリモート操作をしているので、ワイヤレスでArduino Nanoのスケッチを編集・コンパイル・実行・Debugできる（ESP32のOTAと同等、ROBOT開発には必須機能）。
２本以上のPWMや、A/Dコンを使わない用途向けならば、RasPi単体で行ける。
■2018-10-03
★Raspberry Pi
言わずと知れた、Raspberry Pi 。やはり、これは避けては通れないモジュールである。通過儀礼の、Lチカ。こう言う小技は、Arduino系に比べると面倒だが、使い分けする構想である。メイン・コントローラにRasPi、周辺機器的部分（モーター、アクチュエータ、各種センサー周辺）にArduinoとして行く構想。最近使い始めたインホイール・モータを制御するには、最低３本のPWMが必要になるが、RasPiでは１本しかない。Arduino Nanoでは、６本使えるし、A/Dコン入力も８本ある。しかしながら、RasPiでは、大規模アプリ（Apache等）をインストールして使うことが出来る。RasPiとArduinoをUSB Serialで接続し、Linux用Arduino IDEをインストールすれば、WiFi RasPiとVNCで、OTA(ESP32で常用している）が簡単に実現できると思う。工房のPCに、VNCで遠隔RasPiのDeskTopを表示・操作出来るので、自由自在である。
■2018-09-04
★インホイール・モーター・その２
インホイール・モーターに憑りつかれ、いじり倒している。今までDCブラシ・モーターを使って来たが、このブラシレス・モーターには、魅力を感じる。
⓵スピードは、回転磁界の回転周期で、トルクは磁界の強さで制御されるので、別々にコントロール可能。
②回転は、ステーター・コイルによる回転磁界で永久磁石・ローターを回すので、半回転とか１回転とか、きめ細かいコントロールが出来る（このモータは、３０極なので、３６０÷３０÷２＝２４°刻みの制御が可能）。
③モーター、ホイールが一体なのでジョイントが不要。ROBOTへの取付けが容易かつ、耐久性Upが期待出来る。
その分、コントロールは面倒で、１つのモーターに１つのコントローラー（マイコン+ハーフブリッジ３個＋α）が必要になる（今回はESP32でやっているが、Arduino Nanoでも充分可能だと思う）。マイコンも信じられないくらい安くなり、湯水の如く使えるので、問題無い。この面倒臭さは、利点によって補って余りあると思う。
■2018-08-28
★インホイール・モーター
しばらく前に買って放置していた、中華インホイール・モーターを回してみた。ROBOT4のプラット・ホームは、大体完成したので、次のプラット・ホームを考えていて、これに使ってみたい。回す方式は何通りかあるが、120°通電（PWM矩形波駆動）でやってみた。モーターの回転子の位置によるフィードバック制御はまだなので、取り敢えず回っただけ（120°通電方式の低速回転では、トルクリップルが目立つ）。印象は、制御はかなり面倒だが、トルクは結構ありそう（ギアもないのに）。制御も、回転数・方向・トルクなど、自在にできると思う。
背景の岩通の単チャンネル・オシロは、今だ現役で、ノスタルジーを感じさせられますね。
■2018-08-02
★Fusion360
今まで、3D・CADは入門用のAutoDesk 123Dを使ってきたが、これを卒業して、Fusion360へ移行することにした。3Dプリンターを更に活用して行くには、寸法図の作成やネジ、歯車等の部品をサクッと作れることが必要で、123Dでは力不足を感じるようになった。この123Dは入門用としては、余計な機能も無く、最適だと思う。これでの経験は、Fusion360への移行に100%役立つと思う（同じAutoDeskなので、データの移行も問題ない）。
上の絵は、ROBOT4の大中小バージョンを作ることにしたので、その3Dデータを作成した。アルミ・シャーシーをレーザー加工屋に発注するのに、下の絵のような寸法図が必要で、123Dではサクッとは作れない。これが面倒な移行を促した。
■2018-07-13
★ROBOT4操縦アプリ・その２
ROBOT4の操縦アプリを刷新した。今まで、GamePad、androidスマホとPCを併用してやっていたが、GamePad、PC完結（Visual Studio 2017・C#、google map API・Java Script）とした。目指す姿は、快適な事務所や居間から（ビールを飲みながら）、過酷な現場での仕事をROBOTにやらせる、なので、PCで完結した方が使い勝手が良い。現場で、目視しながら操縦する場合にはスマホが良いと思う。
google map APIで、mapの自前カスタマイズも、できるようになったので、２枚配置し、全体像と拡大図とした。WiFiを使っているが、リピーターを使うことで1Km程度はいける目処が立っているので、ROBOT操縦・距離範囲は、今は100m程度の範囲でやっているが、大幅に拡大できると思う。
■2018-07-06、08
★WiFi到達距離テスト・その１
高利得・指向性アンテナ（WLE-HG-DA）の威力が、如何ほどのものか味見的な評価を行った。２Ｆ屋根の軒下に取付けたアンテナから、WiFi電波（しばらく使っていなかったWZR-HP-G54・2.4GHz）を発射して、どこまで到達しているかを確認した。受信側は、持ち運びの利便性が良いスマホ。結果は、入間川を越えて、対岸の堤防上の７２０ｍ地点で、マズマズの結果であった。アンテナからの視界は、あまり良くない。樹木、住宅に遮られ、遠方まで開けているのはピンポイントとなっている。スマホでの受信・電界強度は最低ラインのカスカスであった。電波の到達は、確認できたが、接続の確立はできなかった（たぶん、スマホからの電波が非力で、基地局まで到達しない）。受信側にも、基地局と同じ高利得アンテナと、ちゃんとしたWiFiリピーターを使えば、１Km程度でも、安定した通信・接続が出来る可能性を感じさせられた。次は、もう少しちゃんとした機材を揃えてやってみる気になった。
★7/8追記
電波の道筋は、樹木と建物に遮られ限定的だと解かったので、指向性アンテナのビームをその方向に向け、再度トライした。結果、７２０ｍ地点でのＷｉＦｉ接続に成功！、しかも、スマホで。スマホでの電界強度表示は、５段階の２、転送レートは５８Mbpsであり、充分な値だと思う。基地局（WZR-HP-G54）側のアンテナ利得の９ｄＢｉは、送信と同時に、受信にも効いていると実感できる（７２０ｍ彼方からの、この貧弱なスマホのWiFiを受信できるのは、驚異的）。遠方の相手側にも指向性アンテナと、リピーターを使えば、Km越えも可能だろう（私の工房の立地条件では、これ以上の距離の実験は残念ながら不可能）。
■2018-07-05
★WiFi高利得・指向性アンテナ
現状のWiFiの到達距離は、200m程である。何とか、この限界をKmオーダーまで伸ばしたいと思っている。電波法の制約の中での選択肢のひとつは、指向性アンテナ。２台のWiFi基地局を設置し、１台は本来の基地局、もう１台はリピーターとし、それぞれに高利得の指向性アンテナを搭載し、正確に対向させる。TargetのROBOTを、リピータの周辺で活動させる構想（LPWAでは、カバー距離範囲は広いが、データ転送レートが低く、目的に合わない）。写真はBuffaloのWLE-HG-DAだが、利得は9dBi（半波長ダイポール・アンテナの５倍弱、同一電界強度の到達距離は、計算上２．２倍）以上となっていて、メーカーのWebサイトによれば1Kmで40Mbpsを実現できる、とある。とりあえず１台購入、アンテナ・ポールは３Dプリンターで作成し、２Ｆ屋根軒下に取付けた。指向性・利得9dBiがどの程度のものか、評価してみたい。
■2018-07-03
★プラッター
草刈機のアタッチメントは、いろんな工夫が施されてものが出回っている。その中で、比較的評判が良いプラッターを取り付けてみた。前につけていたチップソーは、切れ味は良いものの、刃先を振らないと上手く刈り取り取れない。プラッターのうたい文句は、前進させるだけで掃除機のように刈り取れる、となっていたので試してみたくなった。早速、取り付けて庭の小さめの草を刈ってみたが、評判通りサクサクと刈り取れる。
柔らかめの草はOKだが、大きく、硬い草は苦手のようである。
■2018-06-29
★C＃ ＧａｍｅＰａｄ イベント・リスナー、ハンドラー
一晩、久々に徹夜して完成。概要は、以下。
リスナーの部分は、別class（例 public class GamePadClass）とし、ここでGamePad操作を見張り、ある条件に合致（JoyStickのX,Y値が変化、Buttonが押された、離された等）したら、メインclassの関数（ OnChangeJoystick等）を起動する。別classからメインclassの関数への橋渡しをするのが、delegate（メインclassの関数へのポインターをセットし、起動する）。Joystick変化,ButtonDown,ButtonUpの各イベント用を設定し、
public delegate void GamePadJoystickEventHandler(string JoystickName,double Value);
public delegate void GamePadButtonDownEventHandler(string ButtonName);
public delegate void GamePadButtonUpEventHandler(string ButtonName);
メインclassの中の、ハンドラー関数
public static void OnChangeJoystick(String JoystickName,double Value)
public static void OnGamePadButtonDown(String ButtonName)
public static void OnGamePadButtonUp(String ButtonName)
を起動する構成とした。こうすることで、メインclassのプログラムは、画期的にシンプルに書ける。リスナー部分は、GamePadからのRaw Dataを扱い、条件判断も多々入るので、ある程度ゴチャゴチャにならざる得ないが、ブラックボックス化できる。これで、オペレータのGamePadの操作を（上の３つのOn****～だけで）シンプルに得ることができ、APIの使い勝手は、マズマズとなった（全体コードはこちら➡参考）。
■2018-06-24
★PCでのBluetooth GamePadキーストローク読込み
今まで、GamePadのキー（ボタン、ジョイスティック）ストロークを、スマホandroidのAPIで読取り、ROBOTを操縦していた。これはこれで、便利な局面も多いが、PCの大画面を見ながら操作する時も、スマホをONにしてアプリを立上げる面倒があった。工房から、ROBOTを操縦する時は、PC(C#)で完結した方が利便性が良い。知識の宝庫ネット上に情報が乏しく、約丸１日がかりで、使えるレベルとなった。使い勝手上の完成度は？だが、一応動作する（SlimDXのインストールが必要）。
今のところ、単にジョイスティックとボタンの状態が読み込めるだけで、使い勝手はすこぶる悪い。やはり、イベント・リスナー、ハンドラ化して、GamePadの操作イベントを捉えて、ROBOT操縦コマンドを送信、としたい（Android Java のAPIは完成度が高く、そうなっている）。
//using宣言
using SlimDX.DirectInput;
//Global変数
bool SelectButton = false;
bool StartButton = false;
bool YButton = false;
bool BButton = false;
bool AButton = false;
bool XButton = false;
bool L1Button = false;
bool L2Button = false;
bool R1Button = false;
bool R2Button = false;
bool LPushButton = false;
bool RPushButton = false;
int GamePadX = 0;
int GamePadY = 0;
int GamePadZ = 0;
int GamePadRZ = 0;
int GamePadHATXY = 0;
//*****************************************************
//* GamePadイニシャライズ
//*****************************************************
private void GamePadInitialize()
{
directInputList.AddRange(directInput.GetDevices(DeviceClass.GameController, DeviceEnumerationFlags.AttachedOnly));
gamepad = new SlimDX.DirectInput.Joystick(directInput, directInputList[0].InstanceGuid); //[0]は、[1]にしないとNGの場合も（原因不明）
}
//*****************************************************
//* GamePad Status更新(10mSインタバール)
//*****************************************************
private void timer1_Tick(object sender, EventArgs e)
{
int[] hxy;
gamepad.Acquire();
gamepad.Poll();
state = this.gamepad.GetCurrentState();
bool[] buttons = state.GetButtons();
GamePadX = state.X;
GamePadY = state.Y;
GamePadZ = state.Z;
GamePadRZ = state.RotationZ;
hxy = state.GetPointOfViewControllers();
GamePadHATXY = hxy[0];
YButton = buttons[4];
BButton = buttons[1];
AButton = buttons[0];
XButton = buttons[3];
L1Button = buttons[6];
L2Button = buttons[8];
R1Button = buttons[7];
R2Button = buttons[9];
SelectButton = buttons[10];
StartButton = buttons[11];
LPushButton = buttons[13];
RPushButton = buttons[14];
gamepad.Unacquire();
}
■2018-06-1７
★ROBOT4 RTK-Navi v & google map 連携
高度な、と言えないまでも、基本的な連携動作が完成したので、TEST走行をしてみた。没頭して、C#やらJava Scriptをいじり倒していて、今はもう夜中、ヘッドライトを点けての走行となってしまった。google map らしい操作をしてみると、今までの固定エリアの簡易 map から、広い世界へ飛び出した感じを味わえる。実際には、まだWiFi LANの到達距離のしばりがある（WAN化すれば、地球の裏までいけるが、delayと、高額な通信料の問題がある、LANでKmオーダーが理想）、これを突破しないと、まだまだ、だ。
■2018-06-14
★ROBOT4 RTK-Navi 自律走行
ROBOT4は、ESP32のIO PINに余裕があるので、GPSモジュール（LEA-6T、LEA-M8Tなど）とソフトウェアの追加だけで、RTK-Navi のRoverとすることができる。
RTK-Naviは、cm級の精度を持っているが、その精度を活かしきったコントロール・ソフトが未完だったので、ブラシアップを始めた。まずは、その第一段の結果が、以下の動画である。自動芝刈り機や、草刈り機など、農業系ROBOTでは正確にGOALにたどり着くだけでなく、その途中の経路が目標ラインを正確になぞることを求められる。以下の、動画では左側の流れるTEXT表示のPdが目標ラインとのズレ（垂線距離）、distanceが目標までの距離である（単位:m）。たまに、20cm程度ズレる（推定原因は、ESP32のI2Cデッドロック防止の暫定策、Wire.reset？）ことがあるが、平均的には数cmに収まっている。STARTとGOAL座標から、直線の方程式を求め、この目には見えない数式のラインをトレースしている（なので、何Kmでもいける）。さらに磨きをかければ、相当な精度のコントロールができると思う（RTK-Naviの測位精度のおかげ）。
■2018-06-12
★自前・Google Map
C#で、自前のGoogle Mapを作成した。今までRTK Naviの実用試験は、エリア固定の簡易Mapで、工房前の走行実験場でネチコチやっていたが、より広い世間で役立たせるためには、全国津々浦々、RTK Naviと高度に連動するMapが必要になる。Google MapのAPI(Java Script）を使えるように、APIキーを取得し、Mapを表示するScriptをつくり、Visual StudioのwebBrowserに読み込ませ、実現している（相～当、面倒な作業）。これで、C#とJava Script内の関数を相互にコール（パラメータの受け渡しも）できるので、Mapを自在に操作しデータのやりとりも可能。RTK Naviで得られた緯度・経度でMapのCenterを指定し、マーカーを配置し、走行軌跡を描く、等が可能となる。Google Mapがどれだけ正確か、は？だが、RTK Navi・ROBOTの応用範囲拡大ができる。もう一つの大きな課題は、電子基準点(Base）。これが、アチコチに無いと、自前設置では利便性に欠ける（工房の基準点も、Ntripで公開しようと思う）。
★ROBOT走行実験場のAxes
google mapの操作の座標は、緯度・経度で行う。これは、地球規模の座標なので、自分の庭や畑での制御には余りに壮大過ぎる。なので、もう少しこじんまりした、mオーダー（cmオーダーの場合も）の座標系で操作するために、自分の座標系を定義し、これを地球座標に変換して操作している。
google map API(Java Script)の関数を、C#からパラメータを渡しながら起動できるようになったので、いつも使っている、ROBOT走行実験場の航空写真に、自分の座標系のグラフ軸をPLOTしてみた。これで、全国津々浦々（全地球）に、自在にLINE を引けるようになった。このLINEはmap上にあるので、mapをスクロールしたりzoomすれば、自分のProgramでお世話しなくても、google map側で連動処理される。
これを、プロットしたC#側のコードは、以下。これ以外に、C#側とJava Script側に、それぞれ送受のための簡単な関数が必要になるが、省略する。
unsafe private void axes()
{
double Xd = 0;
double Yd = 0;
double Lat = 0;
double Lng = 0;
SetLineWidth(3);
SetLineColor("#0000ff");
for (Xd = 0; Xd < 50; Xd += 10)
{
XdYdToLatLng(Xd, 0, &Lat, &Lng);
LineMove(Lat, Lng);
XdYdToLatLng(Xd, 90, &Lat, &Lng);
LineDraw(Lat, Lng);
}
for (Yd = 0; Yd < 100; Yd += 10)
{
XdYdToLatLng(0, Yd, &Lat, &Lng);
LineMove(Lat, Lng);
XdYdToLatLng(40, Yd, &Lat, &Lng);
LineDraw(Lat, Lng);
}
SetLineWidth(1);
for (Xd = 5; Xd <= 35; Xd += 10)
{
XdYdToLatLng(Xd, 0, &Lat, &Lng);
LineMove(Lat, Lng);
XdYdToLatLng(Xd, 90, &Lat, &Lng);
LineDraw(Lat, Lng);
}
for (Yd = 5; Yd < 90; Yd += 10)
{
XdYdToLatLng(0, Yd, &Lat, &Lng);
LineMove(Lat, Lng);
XdYdToLatLng(40, Yd, &Lat, &Lng);
LineDraw(Lat, Lng);
}
}
■2018-06-01
★ROBOT4 草刈り機・連続動作時間
ROBOT4には、比較的小ぶりのリチウム・イオン電池（12V 10Ah）を搭載している。これで、以前実装した草刈り機を、フル充電で、どの程度の時間、連続運転（実用性の重要な指標の１つ）できるか、評価した。結果は、以下で約３時間だった。予想より、長く持ちこたえた。
草を刈っていない無負荷状態の評価なので、実際にはこれよりも、短くなる（半分以下になると思う）。大容量のバッテリーの選択肢は、いくらでもあるが、サイズが大きくなるので、搭載するには、ROBOTシャーシーも大きくする必要がある。
■2018-05-23
★LEA-6T GPSモジュール
２年程前にAmazonで買って、放置していたGPSモジュールを引っ張り出していじってみた。当時の値段は￥3,628（今も売っていて、Amazon ￥3,829、AliExpress $21.84）で、GPS Raw Dataをはき出せるモジュールとしては、格安（LEA-M8Tは、$180もした）だと思い３個も買って、RTK-Naviの実験を一度しただけで、放置していた（これも、安物買いの、、、）。中身も見ていなかったので、ケースを開け部品配置や、配線引出しなどを調べた。開けてみたら、地磁気センサー（HMC5883L ）も内蔵していることがわかり、得した気分。u-blox u-centerで、Raw DataをUARTから2Hz、115200bpsで出力するように設定し、ROBOT4に実装して、ESP32で読み取り、PCへWiFi転送(ROBOT4にGPS Raw Data TCP Serverを実装)。ROBOT1で使っていたLEA-M8TによるBaseとRTK実験を行った。RTKはROBOT1で、さんざんネチコチしていたので、あっさりFixした。ついでに、地磁気センサーのDataも、I2Cで読み取った。面白いのは、方位の角度（0～360°）が右回りで増加では無く、左回りとなっていた。ICが基板の裏に実装されているので、こうなっているのが分かって、笑った。
この値段で、RTK-Naviが実現できるのであれば、各ROBOTに実装してもよいと思う（BaseもこのLEA-6Tでつくれば、破格値のRTK-Naviシステムが実現できますね）。
★ＲＴＫ－Ｎａｖｉ（Rover LEA-6T）走行実験
以下が、ROBOT4に搭載し走行した時の、RTK-Naviの振る舞いを確認した実験。LEA-M8Tより、若干不安定さは感じるが、充分実用に耐えると思う。また、ROBOTを停止し長時間同一地点での測位ゆらぎを確認したが、±5Cmには余裕で収まっており、こちらもマズマズの性能だと思う。
■2018-05-10
★L3GD20とL3G4200D
最近、ジャイロ・センサーにハマっていた。秋月のL3GD20モジュールが消えてしまったので、困っていたが、中華で格安（1モジュール$2.44、あり得ない！）なヤツを見つけ、発注していたのが届いた。これを実装して試験していたが、全く動かない。半日以上、ネチコチやっていたが、ひょっとしたら、これはL3G4200Dでは？と疑い、そー言えばPLLのフィルターが？。L3GD20ならば、コンデンサ１個（IC回路エンジニアが、内部回路で位相補償を頑張った？）だが、これはコンデンサ２個に抵抗１本。正に、L3G4200D用のフィルターである。試しに、I2Cのアドレスを4200Dのヤツに変えたら、見事、ピンポン。中華は格安だが、説明書が皆無なので、発注には、それなりの覚悟が必要。素性が解ったので、１０個追加発注した（EOLで入手困難になるので）。リチウム・イオン電池など、まともな物も多い。ギアド・モータなどは、歯車が異常摩耗したことがあるので、グリスアップし直して使っている。これも、L3GD20として売られていた（プルアップ、3.3Vレギュレータなど、至れり尽くせりだが）。破格値なので、覚悟すべきリスクの一つ、だと思う（機能・性能は、ほぼ同等なので偽物？と言うほどでもない）。
半日も格闘して、安物買いの銭失いに近い。
■2018-05-03
★直進性
ROBOT4号機は、ジャイロ・センサー（STのL3GD20）で直進性の補償をしている。これ無しには、路面の凹凸の影響や、モーター、タイヤ径の微妙なアンバランスで、長い走行距離の直進は不可能である。約２０ｍ程の距離でのテストでは、方位誤差０．３度程度（L3GD20の計測結果が正しいと仮定、実際にはドリフトを除去しきれていない分の±０．１～０．２度程度の誤差がある）で、ほぼ期待値レベルの結果を得た（－０．３度なので、ＲＯＢＯＴの後ろから見て、右側駆動系が左側より、やや強い）。カルマン・フィルターはやっていないが、停止時の計測結果で動的に補正し、ドリフト対策をしている。数十m程度の直進補正には、充分だと思う。また、ジャイロ・センサーで回転角速度（これを積分して角度）を測定できるので、これを使って指定角度Ｔｕｒｎのコントロールも行っている。
■2018-05-01
★GamePadでの操縦
ROBOT4号機は、GamePadで操縦している。今までのROBOTで試行錯誤した結果を取り入れているので、使い勝手は、マズマズだと思う。今後のカスタマイズのために、いくつかのKey（右側ジョイスティック、Aボタン、L1,L2,R1,R2）は、未割当てとしている。
■2018-04-25
★リチウム・バッテリー特性
時間のかかる地味な測定だが、ROBOT4号機に使っている中華・リチウムイオンバッテリー（表示容量は10Ah）の電圧低下特性・評価を行った。タイヤを浮かせ無負荷、Speed設定は最大の条件で、消費電流は約0.2A。初期値12.3Vから約8時間で10V（だいぶ遅くなるが、ここまでは実用の範囲）まで低下、その後急激に電圧低下し、8時間半で9Vを下回り、動作停止した。10Ahあるかどうかは、？だが、マズマズの性能だと思う。実使用条件（Speed 50%、地面走行）では、４時間程度は行けると思う（今度、実使用状態でモニターしてみたいが、４時間連続操作は、きつい）。
また、このような測定ではESP32からWiFi UDPでExcelへデータを送れるので、ワイヤレスのオシロの如く、効率的に評価可能である。
リチウム・イオン・バッテリー
ROBOT4号機
電圧低下特性
■2018-04-09
★草刈り・チップソー
モーター、チップソーを取り付けた。バリカンより、かなり草刈りの能力はアップしていると思う（友人から、カバーを付けないと、危ないなぁ、のご指摘、ごもっともです）。取付け金具類は、ホームセンターで入手出来る標準品だが、ROBOT本体との接続部分の隙間は、３Dプリンターで作成した部材を挿入した。強度が必要なので、充填率１００％で作成した。このような部材の作成には、３Dプリンターが威力を発揮する。
★チップソー・本番草刈り
そこそこ、実用になりそうである。地面との距離を自動計測して、チップソーの自動上下が、今後の課題。これからの季節、草が生い茂ってくるが、部屋でビールを飲みながら、遠隔操作で草刈りをするのが、開発のGOAL・夢である。
■2018-04-06
★草刈り機モーター
発注していた、中華製・草刈り機のモーターがゆうパックで届いた。この国は、爆発的に物を作り、何でも売っている。このバイタリティには敬服する。このような物は、日本製ではまず売っていない（物づくり日本のバイタリティは何処へ？）。12V 300Wと表記がある。チョット回してみたが、馬力はありそう。さて、どうやってROBOTに取り付けるか？
■2018-04-05
★工房から遠隔操縦
今までROBOTを目視しながらテストしてきたが、大体OKなので部屋（WiFiルーターからROBOTまで、５０～６０ｍ程の距離)から遠隔操縦してみた。スマホ２台装着して、刃先も見ながらやりたいところだが、WiFiで２台のカメラの動画送信は帯域的に厳しいので、前方カメラ画像を見ながら操縦した。操作性は、結構良い。
■2018-04-04
★バリカン・モニター・カメラ
バリカンの上部に、刃先をモニターするためのカメラを取り付けられるようにしている。しかしながら、バリカンの振動が激しくて、画像が超手ブレ状態。バリカンを止めて、草に狙いを定めて刈るのには、使える。
バリカンの上下調整は、走行させながら手動で行うのには無理があるが、地面には凹凸があり、必須である。やはり、ここは地面との距離を自動的に測り、自動調整にすべきだと思う。さほど、難しくないと思うので、近い内に組み込みたい。
★ドローン
今日は、近隣の同志の方に、ドローンの実飛行をデモして頂いた。かなり、興味をそそられた。
今まで、地べたを這うROBOTを手掛けてきたが、RTK・NAVI、ジャイロ・センサーを活用して制御し、空へ行くのも良いかも知れない。
空撮動画を送っていただいたので、埋め込ませて頂きました。
■2018-04-03
★草刈り機・本番テスト
だいたい出来上がったので、本番の草刈りテストをやってみた。バリカン・LOCK時の過電流保護も含め、期待通りの動作を実現出来た。このVideoはROBOTを目視しながら撮影したが、次は、カメラ動画を見ながら、部屋の中から遠隔操縦してみたい。
ROBOTに持たせるツールとして、草刈り用チップ・ソーとそれを高速回転させるモーターを発注済なので、到着したら、それも試す予定。バリカンより、更に強力だと思う。
■2018-04-02
★草刈り機・起動時ピーク電流
草刈り機・起動時のピーク電流とLOCK時の大電流が、ほぼ同じレベルである（どちらも、モーターの回転子が停止しているので、当然と言えば当然か、、、）。起動時電流は、一瞬で終わりその後は、５A弱の電流に落ち着くが、LOCK時電流は、大電流が流れ続け、モーターや、Power MOS-FETを破壊する。これを区別して、保護動作を行うために、起動時の電流のピーク値を、PWMで０～Full Powerまで、ゆっくり立ち上げることによって抑えた。起動時とLOCK時の電流差が、これで明確に区別できるようになったので、過電流検出は１０Aとした。
ユルユル立上げは、以下の関数をソフトウェア・タイマー（自作Class）を使い、100mSecインターバルで実行し、１秒かけて、０～Full Powerまで立ち上げている。
///////////////////////////////////////////////////////////////////
void KusakariOn() {
///////////////////////////////////////////////////////////////////
KusakariPower=KusakariPower+.1; //1秒で立上げ完了
ledcWrite(4, (uint32_t)(1023 * KusakariPower)); //(Ch,Value)
if(1<=KusakariPower){
TimerKusakariOn.Disable(); //立上げ完了
}
}
■2018-04-01
★花を愛でる
春爛漫、ROBOT走行実験場の周囲の花梅が満開になった。花の命は短くて、１週間ほどで、散って行く、、、
■2018-03-31
★過電流保護（Shut Down）
草刈り機は、大電流を流すモーターで、特に何かが挟まってLOCKすると、モーターが焼けたり、ドライブしているPower MOS-FETが破壊する。これを防ぐ保護回路が必須である。正常な動作では、起動時に１０～１５A程度で、その後５A弱となる。起動時、LOCK時電流の実験測定値から、瞬間的に１６A以上の電流、平均的に７A以上の電流を越えた時、保護モードに入り、回路をShut Downしている。起動時とLOCK時の大電流の区別が難しいので、PWMでユルユル立ち上げ、起動時の大電流のピークを下げる等の工夫が必要だと思う。
■2018-03-28
★Actuatorと草刈り機
ROBOT4号機（ESP32、GamePad操縦）のカスタマイズとして、Actuatorと草刈り機を、組み込んだ（そもそも、最初のROBOT1号機を作った動機は、自動草刈り機の実現だった）。これで、ただ走るだけではなく、仕事をするROBOTらしくなったと思う。明日も、春爛漫の晴れなので、草刈りテストをやってみたい。ROBOT１号機（スマホ＋ioio-OTG、パソコンKeyBoard操縦）にも、草刈り機を実装していたが、バリカン部の上下機構が無かったので、いまひとつであったが、これで性能・操作性は大幅に改善されたと思う。
■2018-03-22
★自前ユニバーサル基板・納入
発注していた自前・Fusionユニバーサル基板が納入された。リードタイムは、１０日なのでマズマズ早い。１０枚で、DHLの送料込みで＄２４．１９（基板＄４．４、送料＄１９．７９）。自前で作ったのは、他の専用基板（Fusionの10×10㎠）と縦積み実装するため。今後、試作に活用して行きたい。
■2018-03-20
★プーリー
３Dプリンターで、特殊な形状のプーリーを作成中。約７時間３０分かかる。大きさは、最も大きい径の部分で、Φ６４ｍｍである。明日、朝には完成しているはず。今まで、電子回路のケースを主に作ってきたが、こういうモノが、充分な精度と強度（フィラメントはＰＬＡ）で作成出来れば、ROBOTの様々な機構パーツを作成でき、自由度が広がると期待している。
★出来栄え
朝、起きたら出来上がっていた。３Dプリンターは、プリント時間が長いので、寝ている間に徹夜残業をさせるのが良い（人間のように、過重労働の問題にはならない）。オーバーハングとなっているので、サポート材がたくさん付けられていたが、マズマズ合格点だと思う。
このようなプーリーは、出来合いのモノを買って加工するか、旋盤を使って作るしかなかったが、３Ｄプリンター・ＰＬＡプーリーでも充分な精度・強度（充填密度を通常１０～２０％を５０％にした）があり、これで安価に自在に作れることが確認出来た。
２Ｆ・工房の扉は、床の一部が開くようになっているが、これを開閉するウィンチのプーリーとして、使っているが充分実用になっている。特殊形状としたのは、巻き上げるヒモが偏らないようにする目的（一般的な形状だと、プーリーの片側に偏って巻き上げられ、ＮＧ）だが、これも狙い通りＯＫとなった。
■2018-03-18
★ROBOT4号機
基本部分が、組み上がった。左側のGamePadで操縦する（米原子力潜水艦も、同様なXboxのコントローラで操縦されているらしい）。ROBOTから送られてくる動画（ROBOTに装着されたスマホから）をGamePadに装着したスマホに表示し、これを見ながら遠隔操縦する。送信元のスマホは、ストリーミング動画・Web Server なので、同時に複数のWebブラウザ（大画面PC等）に表示可能。ROBOTのStatus（バッテリー電圧、消費電流、スピード設定、ジャイロ方位）も、手元のスマホに併せて表示している。今後、カスタマイズをやって行く予定。やはり、アクチュエータ類を実装しないと、ただ走るだけなので、電動シリンダーや、何かのツールを実装して仕事をさせる予定。そろそろ、暖かくなってきて、雑草が伸び始めたので、久々に草刈りマシン第２号を作ってみようと思う。
■2018-03-12
★自前・ユニバーサル基板
Fusion経済サイズ（１０×１０㎠）のユニバーサル基板を発注した。ネジ穴は、他のROBOT基板等と同じ位置にしてあるので、縦方向に重ねて実装できる。基板端に、ケースから外に配線を引き出すためのコネクタを２個配置した。試作の効率化に貢献してくれることを期待している。これは、最も汎用だが、何種類か（ESP8266用、ESP32用、etc）作るのも良いかも知れない。
■2018-03-09
★ROBOT4号機・電子回路BOX
ほぼ、完成。今後、４WD・ロボット・シャーシーに搭載して、テスト走行を行う予定。企画意図の一つは、カスタマイズ化なので、何か実際に役立つ仕事をするROBOTに仕上げて行きたい（ESP32のIOポートは、半分以上空けてあるので、自由度は大きい）。
■2018-03-06
★ジャイロ・センサーによる旋回コントロール
ジャイロ・センサーをROBOTの直進性の補正に使ってきたが、センサー出力の回転・角速度（deg／Sec）を積分して回転角を求め、これを使って、Turnの制御をすれば、コントローラーのワンボタン操作で、指定の角度Turnすることができる。作成した関数は、
void TurnDeg(int Deg);
で、自在な角度指定ができるが、操縦でよく使うのは±９０度と±１８０度。これを、目視・手動操作でやると結構面倒で、行き過ぎたり足らなかったりするが、ジャイロを使えば、一発で正確にTurnできる。
★ROBOT4号機・Fusion基板
今日の午後、DHLで基板が納入された（春節とかぶったので、2/9発注→3/6納入と、約１ヶ月もかかった）。早速、部品を実装したが、２時間程度で完了した。これで、基本部分の走行系とヘッドライトON/OFF、動画撮影用スマホ充電・電源の機能を持たせている（バッテリー電圧・消費電流測定WiFi送信、過電流シャットダウン、ジャイロ・センサーを含む）。部品を片側へ寄せ、空いたスペースは、ROBOTのカスタマイズ・エリアとする構想である。ESP32のIO-PINの接続を変更（カスタマイズ・エリア側に空きIO-PINを集めた）したので、プログラムの修正を今後行う予定➡動作確認含め完了。
■2018-03-02
★Android Virus
に悩まされた。
Androidの常駐・バックグラウンドで、定期的にスマホ自身のLAN IPアドレスをudp・ブロードキャスト送信することが必要（複数のネットワーク機器、例えばコントローラーとROBOTが相手のIPアドレスを互いに知り、通信を開始する時に便利）になり、ネット情報を探す過程で、eclipseのプログラム・パッケージを見つけ、これをインポート・編集しコンパイルしたら、目的の動作をするプログラムは作成出来たが、見事、毒入り（Android.Trojan.FakeTimer.I)だった。h***://www.atmarkit.co.jp/ait/articles/0906/18/news102.html（サイト内の技術的解説は極めてまともで、参考になった。悪意はないのかも知れない。）のKitchenTimer.zipには、要注意！
２日ほど、ロスさせられた（毒排除版は完成した）。くそっ！
■2018-02-09
★ROBOT4号機
を製作中。これのコンセプトは、
①基本部分は最小限に留め、カスタマイズの自由度を持たせる。
②基本部分とは、
・ESP32(WiFi & ROBOT Control)
・モータードライバー（TB6643KQ×2）
・ジャイロ・センサー（L3GD20）
・5V 3A電源（HRD05003 DDコン）
・ヘッドライト(LED 3W)
・リチウム・イオン電池(12V 10Ah)
・4WD・ROBOTシャーシー
・動画撮影用・スマホ(ESP32が担えれば最高なのだが、、、)
・操縦用・スマホ(ROBOT動画・Status表示、Bluetooth→WiFi)
・操縦用・GamePad(Bluetooth)
KiCadで２作目となるので、少しは手慣れてきたと思う。ESP32のIOポートの使用は約半分、基板も半分はユニバーサル基板状にし、カスタマイズのエリアとした。これで、様々な用途のROBOTをサクッと作れるようになるはず。
基板は、今日Fusionへ発注したが、春節なのでたぶん、納期は遅くなると思われる。
■2018-01-31
★SPIFFS（SPI Flash File System）
ESP8266同様、ESP32でもSPIFFSが使えるようになっている。内蔵している１６MBのフラッシュメモリーの内、４MBをユーザーのファイル・システムとして使える。各種イニシャル・データをこれに書き込んで、便利に使える。例えば、WiFiルーターへの接続時に、SSIDとPASSWORDをここに書き込み、立ち上げ時に読み出して使う。プログラムの中に書き込んでしまうと、WiFi環境が変わった時に、プログラム書換えが必要となるが、このファイル・システムに書き、書換えプログラムを内蔵させておけば、APモードでESP32に接続して、簡単に書換え可能となる。また、Arduino IDEで複数のファイルをまとめてアップロードもできる。その他、様々なパラメータを書込んで活用すれば、プログラムの自由度を相当上げられる。
以下の様な感じで、実現出来る。
#include WiFi.h;
#include "FS.h"
#include SPIFFS.h;
///////////////////////////////////////////////////////////////////
void setup() {
///////////////////////////////////////////////////////////////////
.
.中略
.
WiFi.begin(ReadTextFile("SSID.txt").c_str(), ReadTextFile("PASS.txt").c_str());
.
.中略
.
}
//////////////////////////////////////////////////////////////////
void RxExecue() { //コマンドをUDPで受信して処理
//////////////////////////////////////////////////////////////////
.
.中略
.
if(SplitCommand[0]=="SetSsidPass"){ //SSID PASSのSPIFFSへの書き込み
//コマンドの例: "SetSsidPass,SSID,PASSWORD"をSplitで分解
CreateTextFile("SSID.txt",SplitCommand[1]);
CreateTextFile("PASS.txt",SplitCommand[2]);
}
.
.中略
.
｝
//////////////////////////////////////////////////////////////////
void CreateTextFile(String Fname, String Text) { //Textファイルの作成
//////////////////////////////////////////////////////////////////
File fd = SPIFFS.open("/" + Fname, "w");
if (!fd) {
Serial.println("open error");
}
fd.print(Text);
}
//////////////////////////////////////////////////////////////////
String ReadTextFile(String Fname0) { //Textファイルの読み出し
//////////////////////////////////////////////////////////////////
File fd = SPIFFS.open("/" + Fname0, "r");
String Text = fd.readStringUntil('\n');
if (!fd) {
Serial.println("open error");
}
fd.close();
return Text;
}
■2018-01-30
★ジャイロ・コントロールの走行軌跡
雪が程良く残っていたので、ジャイロ・コントロールの走行軌跡をここに残せば、その実力が実感できるのでは？と思い立ち、残雪の上を走行させてみた。距離は、約３０ｍ（時速１Km／ｈなので、１０８秒走行）ほどである。雪面での走行は、直進性を阻害する外乱が大きいが、マズマズの結果だと思う。外乱は、ほぼ打ち消しているが、走行時間が比較的長いので、ドリフトの影響が出ているようで、それをグラフの代わりに地面に残したものと言える（停止時に、オフセットを自動的に測定し、キャンセルはしている、その内、加速度センサー ＆ カルマン・フィルターにもトライしてみようと思う）。
ジャイロ・コントロールなしの単純走行では、地面のデコボコの影響と、左右のアンバランスで、芝の畑から外へ転落するほど、方位がブレるので、その効果は大きい。
★ヘッドライト
を付けたので、夜間走行をさせてみた。一つ目だが、走行には十分な明るさである。これで、２４時間移動監視に使える（そんな用途はあるのだろうか？鳥獣対策とか？）。LEDライトなので、省電力（約３W)で明るいが、色合いが今一つ。
■2018-01-25
★ジャイロ・センサーによる方位コントロール③
ジャイロ・センサーにすっかりはまった。村田ENC-03Rの圧電振動ジャイロの結果に気を良くし、ちゃんとしたZ軸を備えている、ディジタル制御のSTMのL3GD20搭載モジュールを入手し、これでのトライを進めていた。これには、結構手間取った。よ～やくマズマズの状態となったので、簡単にレポート。何に手間取ったかと言うと、Ｉ２Ｃ通信。基本的な単純動作は先達の皆様のお陰でサクっと出来たが、たまに発生する通信エラーの対処に難儀した。ROBOTの電子回路基板では、モーターをPWM駆動するのでノイズまみれとなる。Ｉ２Ｃでは、SDA,SCLのラインがノイズに非常に弱く、たまに通信エラーが発生する。このエラーが発生すると、センサーがデッドロック状態となり、これの回復は電源ON/OFFしかない（Reset機能が無い➡その後の試行錯誤で、ESP32をResetすると復旧するので、こちら側のプログラムに問題があることが判明。L3GD20には濡衣でした➡2018/03/24 ESP32のI2Cのバグと判明、取り敢えずエラー状態になったらWire.reset()で暫定的に対処➡2018/03/25 ライブラリWireの改良版で解決。作成者に感謝➡2018/07/11 まだ、何かがオカシイ。Wire.reset()にデグレ➡2018/07/17最新の更新されたライブラリで解決していることを確認。Wire.reset()は無くなった、必要もなくなった。）。配線や電源まわりのノイズ対策をし、Ｉ２Ｃのクロックを２０ＫＨｚ（その後100KHｚでもOKを確認）まで下げて、ようやく、エラーの発生は無くなった（コンデンサ・ショートし、基板を立てて実装するENC-03Rモジュールより、スマートだと思う）。今日は、もはや夜になってしまったし、外には雪が残っているので、走行実験とデータ取得は明日以降に行う予定。
これが、ジャイロ・センサー搭載の４号機の制作途上の姿（一つ目小僧のような、、、）。
■2018-01-15
★ジャイロ・センサーによる方位コントロール②
コントロールの最適化には、方位誤差を補正するフィードバック・ループのゲイン（上げるほど誤差を縮小できるが、限度を越えると発振する）や方位検出のサンプリング周期（10mSecとした）、左右モーターへのＰＷＭコントロールの調整等がある。完璧では無いが、ざっくり調整したので、庭に出して、比較的長い距離（約２０ｍ）で実験した。まずまずの結果だと思う。方位コントロール無しでは、道をはずれるほど、方位がずれる（この距離を、センサーの助け無しで、直進するのは不可能）。WiFi動画カメラ２台、ROBOTからExcelとDebugPrintへのデータ転送をしているので、WiFiの帯域がいっぱいいっぱいになり、多少動画が紙芝居的になっている。
■2018-01-13
★ジャイロ・センサーによる方位コントロール①
秋月に発注していたジャイロ・センサー（村田ENC-03R・２個搭載モジュール、￥400）が届いたので、早速実験した。まずは結果から、
やはり、この手のコントロールには、ジャイロ・センサーが圧倒的に向いている。ROBOTは、時速1Km/h程度で18秒（５ｍに相当）走行させた比較だが、コントロールなしでは、ギアド・モーターとタイヤ径のアンバランスにより、１０度の方位ずれが発生するが、コントロールありでは、0.1度のずれしか発生しない。ROBOTに線を引かせたら、定規なしで、人間業では出来ない、ビシッとした長い長い直線を引けると思う。ジャイロ・センサーは、元々このようなコントロールのために存在するので、完全に適材適所と言えると思う。しかも、磁気の影響は受けないので、大電流が流れる電子回路基板に実装しても全く問題ない（コリオリの力って一体何なのだろう？）。
これが、ジャイロ・センサー・モジュールだが、このモジュールは２軸（X,Y）のジャイロで、普通に水平に実装するとドローンのような機体を水平を保つコントロールには最適だが、今回のようにＲＯＢＯＴの直進コントロール向きではない。Z軸がないので、モジュールを立てて実装し、１軸（Z軸相当）のみ使っている。また、圧電振動ジャイロの出力にハイパス・フィルターが入っていると、単純積分で回転角が得られないので、コンデンサをショートして使用している。短時間の直進補正コントロールなので、ドリフトは無視できる（ROBOT停止時にモジュール出力ＤＣ電圧を測定・平均化し、回転角速度０の時の出力電圧を更新し、ドリフト対策をしている）。
■2018-01-10
★地磁気センサーによる方位コントロール
原発２号機に地磁気センサー（HMC5883L）を実装し、走行テストを行った。路面のデコボコや、モーター、タイヤの左右のバランスずれによって直進性は損なわれるが、これをどこまで補正できるかである。結果は、目標方位に対して±２°程度の直進性を実現できた（外乱の大小にもよるが）。芝生の上に残された、クローラの走行軌跡を見れば、その効果が実感できる。
地磁気は太陽風、フレアから地球を守ってくれている、極めて大事なものだが、微弱である。モーター駆動のROBOTでは、配線に流れる大電流によって発生する磁界によって、センサーでの検出方位に乱れが生じる。この対策として、単純だが、センサーを電子回路BOXから遠ざけて実装している。直進性を実現するだけであれば、ジャイロ・センサーの方が向いているかも知れない。近い内に、実験してみたい。
■2018-01-09
★Fusion基板ケース
久々に３Ｄプリンターを動かし、Fusion基板の経済サイズ10×10㎠のケースを作成した。今後は、このサイズを基本に、様々な電子回路を製作して行く予定。複雑なシステムは、縦方向に複数枚の基板を積んでいく構想である。Fusion基板は、格安なのでこのサイズの自前のユニバーサル基板を作る予定である。
以下は、ROBOT3号機の電子回路ＢＯＸである。
■2017-12-30
★ユニバーサル基板とFusion基板
早速、部品をマウントして組み立てた。ROBOT3号機では、ユニバーサル基板を使って製作したが、部品の位置決めと線材を使っての配線は手間暇がかかり、約３日を要したが、Fusion基板を使っての製作は、約３時間で完了した。基板面積は、ユニバーサル基板（スカスカ実装だが）の約半分である。一度作って動作させているので、一発で動いた。
■2017-12-29
★Fusion基板
Fusionに発注していた基板が出来上がり、今日到着した。予想よりかなり早い。基板の出来は、初めてKiCadで設計したので、何かが抜けているんじゃないかと心配していたが、ざっと見、キチンと出来ている。後は、部品をマウントしてちゃんと動くかどうかである。
以下が、発注から工房着までの１０日の道のり。
2017-12-29 14:35 工房着
2017-12-29 10:31:00Departed Facility in TOKYO – JAPAN
2017-12-29 10:21:00Processed at TOKYO – JAPAN
2017-12-29 09:56:00Clearance processing complete at TOKYO – JAPAN
2017-12-29 09:42:00Arrived at Sort Facility TOKYO – JAPAN
2017-12-29 09:06:00[TOKYO – JAPAN]Customs status updated
2017-12-29 08:42:00Transferred through NARITA – JAPAN
2017-12-29 00:47:00Departed Facility in HONG KONG – HONG KONG
2017-12-29 00:36:00Processed at HONG KONG – HONG KONG
2017-12-28 23:57:00Clearance processing complete at HONG KONG – HONG KONG
2017-12-28 23:49:00Arrived at Sort Facility HONG KONG – HONG KONG
2017-12-28 22:16:00[HONG KONG – HONG KONG]Customs status updated
2017-12-28 21:52:00Departed Facility in SHENZHEN – CHINA, PEOPLES REPUBLIC
2017-12-28 21:50:00Processed at SHENZHEN – CHINA, PEOPLES REPUBLIC
2017-12-28 21:47:00Clearance processing complete at SHENZHEN – CHINA, PEOPLES REPUBLIC
2017-12-28 18:52:00[SHENZHEN – CHINA, PEOPLES REPUBLIC]Clearance event
2017-12-28 18:50:00Arrived at Sort Facility SHENZHEN – CHINA, PEOPLES REPUBLIC
2017-12-28 16:37:00[SHENZHEN – CHINA, PEOPLES REPUBLIC]Shipment picked up
2017-12-28 16:06:17Your order has been shipped, we will promptly update your logistics status
2017-12-28 16:06:13Your order has been packed and will be shipped soon
2017-12-19 19:41:51Your order has been confirmed and we will start production as soon as possible
2017-12-19 18:24:27Your payment information has been confirmed, we will process your order as soon as possible
2017-12-19 18:23:55Order received
■2017-12-18
★KiCad
ここ１ケ月程、原発２号機の製作やら、CADのEagleからKiCadへの乗り換えなどに手一杯で、久々の更新。
FreeのEagleを使っていたが、基板サイズの制約（8cm×10cm）があり、Fusionでの超安基板（10cm×10cm）に対して２割減は痛いので、極めておっくうではあったが、KiCadに乗り換えた。第一印象は、相当クセがあるものの、現場の電子回路基板設計者がつくったらしさを感じさせられる、必要かつ便利な機能を備えた良質なCADである。開発者とサポートされている方々に、心から感謝します。今後は、これを活用して行きたい。以下は、ROBOT3号機（３．５号機、原発２号機も同じ）の電子回路基板である。手習い含め、１Week程かかった。
Fusion PCBへ発注したが、１０枚で基板代が$4.9（驚異的な安値！）で、送料がDHLで$18.75。
10cm角の基板に、ESP32-DevKitCをメインにHブリッジ（10Aドライブ）２つ、アクチュエータ・ドライブ（TB6643KQ）、パイロット・ランプ・ドライブ２系統、５V3ＡＤＤコン、ＩＣＣ測定回路、程度では、余裕で載せられる（余った面積には、もったいないので、ユニバーサル基板パターンを作っておいた、ESP32もだいぶ余りPINがあり、使い切っていないなぁ）。
■2017-11-06
★積層ピッチ
３Dプリンターは、電子回路のケース作成に最適である。従来は、秋月などで出来合いのものを買っていたが、基板サイズとジャストフィットでなかったり、取り付けるスイッチやパイロット・ランプの穴の加工が面倒であった。3D・CADで設計しプリントすれば、相当な精度（0.1mm）で仕上がる。写真のケースは118×124×76mm・積層ピッチ0.1mmで、およそ２４時間のプリント時間である。２つのケースを上下に並べてあるが、下が積層ピッチ0.2mm、上が0.1mmでプリントしたもので、やはり出来栄えがだいぶ違う。積層ピッチを細かくすると、逆比例でプリント時間は長くなる。従って、概略の形状確認では、積層ピッチを荒くし、仕上げでは細かくして作成している。
また、これはAmazonで￥1,980/1Kgの超安PLAフィラメントを使ったが、質の高い（値段も高い）ヤツを使えば、仕上がりは更にキレイになる。
★ESP32 OTA Debug Print
OTAは便利なので、遠隔制御ROBOTのプログラム開発に使っている。が、やはりSerial.printが使えないのでDebugには、いま一つ。ESP32はWiFiデバイス、これを使わない手はないので、ワイヤレスのDebugPrintをつくった。PC側はVB2010でつくった受信アプリで表示している。超簡単プログラムだが、思いのほか便利に使えている。
■2017-11-04
★地磁気センサー
秋月から地磁気センサー(HMC5883L)を購入した。ROBOT3.5に搭載し、走行の直線性実現に使えるかどうか試した（RTK Naviでやれば完璧だが、これは、お手軽版）。秋月サイトに掲載されている、Arduinoスケッチサンプルは、Nanoでは何の問題も無く、あっさり動いたが、ESP32へ載せるには苦労させられた。I2CのPINがArduino Nanoでは、固定PINだがESP32では、選択が可能で、
Wire.bigin(); → Wire.bigin(22,23);
のようにすれば、簡単に動くと思っていたが、これは成功しなかった。先人の方が苦労された成果がここ（開発者に感謝）にあり、これは、ESP8266用だが、この中のHMC5883L.cppのWire.bigin();を上述のように変更することによって、動作させることが出来た。部屋の中での実験では、±1度程度の走行方位の自動制御（Target方位に対して、取得した方位によって、左右のモーターへの供給電力を調整）が可能で、今後、更に実験をしてみるが、応用範囲は広いと期待している。
■2017-10-25
★リチウム・イオン・電池
以下は、ROBOTに使っている電池だが、全て中華製。破格値ではあるが、首をかしげるのは、その体積と容量の関係である。①と②は表示の容量は、ほぼ等しく10Ah、体積もそれなりに、同程度。しかしながら、③(ROBOT2に使用）は20Ahと２倍程度の容量にもかかわらず、体積は６倍以上。どこかに？がある。いつか、ちゃんと容量を測ってみたい。
因みに、最も安価な①では、ROBOT1の4WDモーターは駆動出来るものの、草刈り機をつなぐと電流制限回路がシャットダウンする。②③は、OKである。
（爆発するリスクを気にしながら、取り扱っている）
■2017-10-15
★ESP32 OTA
OTAは、ROBOTのプログラム開発時には極めて便利なツールである。何故ならば、普通、プログラム開発時には、ターゲットのROBOTは遥か彼方に存在するケースが多いからである（USBではつなげられない）。以下、操作事例をUP。プログラムに、OTAを組み込むところまでは、他サイトを参照下され。
このツールはPCのCPUパワーを切れ目なく必要とするようで、これを実行時に他に重いタスクを実行していると、エラーになるケースが多いのと、シリアル・ポート選択時にネットワーク上の仮想シリアル・ポートがなかなか、出現しないことが多い。しつこく、やっていれば（Arduino IDEの起動時に接続をトライしているようなので、再起動を繰り返す➡その後、Arduino IDE を1.8.5にしたら、一発でつながるようになった）、その内に出現し、一度出現するとずっと安定して使えるようである（実際のプログラム開発で使っているが、書き込みエラーが結構な頻度で発生する。しかし、１００ｍ先までROBOTを取りに行き、USBを接続して書き変えるよりマシで、この程度は我慢できる）。
■2017-10-10
★珍客
ROBOT3.5号機をテスト走行中、見学者が、、、
装着されたスマホで静止画を撮影（遠隔操作可能）。ROBOTを至近距離まで近づけても、警戒しない。
■2017-10-05
★ようやく、、、
PS4（CUH-ZCT2J11、タイムラグ）、GamePad（IPanda BM-707、Bluetooth勝手に切れる）、どちらも帯に長し、襷に短しだった。わたしも、かなりしつこいので、３台目(OBEST RK-GAME4th、Amazon ￥2,000)を購入。これで、ようやく期待値に届くコントローラーを手に入れた。これを、発注した動機は、Amazonの商品説明に、Bluetooth 無接続時に省電力モード、と書いてあり、無操作時でなければ、IPandaのNGを解決出来ると期待したからである。しかしながら、付属のマニュアルには、無接続時５分、無操作時１０分でOFFと書いてある。くそ～と思ったが、IpandaではNGだった左側ジョイスティックを操作しながら時間計測したが、操作さえしていれば、ずっとOFFされず（これが当たり前だが）、これならば妥当な省電力モードだと思う。
実際に、無操作でOFFされるまでの時間を測ったら６分弱だった。実害はないが、この辺が中華なんだなぁ、、、日本製ではあり得ない（仕様が１０分なら、1/1000秒まで正確に１０分にするだろう）。
これで、Bluetooth GamePadによるROBOT操縦を確立出来た（参照）！！！
■2017-10-04
★GamePad
PS4コントローラーから始まって、ずっぽりはまってしまった。しかしながら、この奥深いツールのEventは、Android Javaで全て取得出来るようになった。大体のイメージは以下で、十字キー、左右のジョイスティックは、-1～+1の座標で読み取る（十字と左スティックはKey Eventとしても読める）。それ以外のボタン、レバーは全てKey Eventとして読む。プライマリとセカンダリの２つのコードを持つKeyもある。なんで、こんなに複雑なのか？。たぶん、ゲームの操作性（互換性？）を追求して、こうなったんだと思う。これで、このツールを使ってのROBOT操縦は、自在になった気がする（Bluetoothの省電力OFFだけが、邪魔だなぁ）。PCやスマホで操縦していた頃は、どうしてもKeyBoardやパネルを見なければならないが、ジョイスティックやレバーは、ターゲットのROBOTを直視しながら、感覚的に自分の体の一部のように、扱える。
■2017-10-03
★省電力モード
先日購入した、中華コントローラー(IPanda Gamepad)の不具合に遭遇している。Bluetooth接続して５分後に自動的に切断されてしまう。付属していた貧相なマニュアルによれば、何も操作しない状態では、省電力のために自動切断される、とあるが、操作しているにも係わらず切断されているようである（Bluetooth Low Energy？）。
神は、試練を与えてくれるなぁ、、、
Net徘徊してみたら、問題は奥深げである、、、。単にコントローラーだけの問題では無い？
★大体、現象は理解
NGというより、コントローラーの仕様の問題？。このコントローラーは、省電力のためにKey操作が無い時、５分でOFFするように設計されている。しかも、左側のジョイスティック（操縦では、前後左右に割り当てるので、最も使う）ではKey操作検出していない。今まで、操作はこれで実験してきたので、操作しているにも係わらずOFFしていたのである。ジョイスティック操作に加え、Yボタンを定期的に押してやると省電力OFFしないことが、分かった。従って、原因はコントローラー内部のファームウェアにあるので、どうしようもない。ROBOT操縦には、使えない。微妙な操縦をしている時に、自分では制御できないメカニズムでOFFされたら、困る。いろんなボタンをバンバン押すゲームならば、問題は無いと思う。
目的に、合致するコントローラーを見つけられるまでの間は、信頼性を重視し、PS4コントローラー（CUH-ZCT2J11）のUSB接続で我慢。
★ROBOT3.5号機・走行動画（屋外・ROBOT搭載カメラ）
■2017-10-02
★ROBOT3.5号機 走行・操縦性能
ROBOT3.5号機は、1号機と同じシャーシーである。このシャーシーは、4つのギアド・モーターで駆動（４WD)されていて、1号機でかなり長時間の動作実績もあり、耐久性・走行性能もマズマズだと思う。監視カメラや、小型の道具、アクチュエータ、ヘッドライト、各種センサー、RTK NAVI等を搭載してカスタマイズできる。様々な用途（アチコチ移動監視、草・芝刈り、軽作業、等）、に活用できると思う。
12V20Ahのリチウム・イオン・バッテリーを、とりあえず載せているが、これで10時間程度は、連続走行できる。
■2017-10-01
★ESP32 APモード
ESP32には、自分自身がアクセス・ポイントになるモード（APモード）がある。これを使って、WiFiルーター無しにROBOTを操縦出来る。このモードでのROBOT操縦可能な距離を測った。結果は以下で、約４０ｍ程である。目視しながら、ROBOTを操縦するのであれば、充分な距離と思う。４０ｍも離れると、目視ではかなり遠く、ROBOT3号機程度の大きさでは、どちらを向いているのか分からなく距離である。ROBOTに搭載したスマホ・カメラの画像を見ながら操縦するのであれば、目的にもよるが、出来るだけ遠方まで操縦出来た方が良い。
また、アクセスポイントとして、スマホ・カメラ動画を転送可能だが、こちらの方の実用的な距離は10m程度であった。これは、距離が離れると、WiFiの転送bitレートが低下していくため、動画転送に必要な広い帯域をカバー出来なくなるためである。操縦のためのROBOTとの通信は、僅かな文字情報のやりとりだけなので、狭い帯域しか必要としない。なので、WiFiの電波の到達限界まで操縦が可能となっているようである。従って、APモードは余計な機材（WiFiルーター、ポケットWiFi等）が一切不要なので、現場での目視操縦向きと言える。
LAN（工房の環境で、操縦可能範囲は約200m）の枠を越えて、WANを使って操縦すれば、距離の制約はなくなり、地球の裏側にROBOTがあっても、操縦可能となる。WANでの操縦は、まだ実験していないので、ポケットWiFiを使って近い内に、やってみたい。
■2017-09-30
★WiFi到達距離
ROBOTを操縦可能な距離をテストした。工房からROBOTに前進、停止の繰り返しコマンドを垂れ流しにして、ROBOTを抱かかえて、それをどこまで離れて受信出来るか？の方法で確認した。ROBOTから工房へも、コマンドを受信した際にECHOで受信確認信号を送っているので、送受信の確認をしていることになる。
結果は、約208mだった。更に、遠距離まで届いている可能性もあるが、建物に遮られない条件（遮られると、もっと短距離でNG)で測定可能なのは、この地点までであった。ESP32のWiFiモジュールは、内蔵パターン・アンテナだが、マズマズの性能だと思う。
■2017-09-29
★ROBOT3.5号機
ROBOT3.5号機を作った。デザイン・見てくれは、かなり悪い。
クローラ仕様の３号機を工房の中で走行させて、プログラム開発をしていたが、走行音がやかましく我慢出来なくなったので、１号機を作った時の残骸のシャーシーに、３号機の電子回路BOXを載せた。走行はスムースで、音も許容できるレベルになった。
■2017-09-27
★タイムラグ
PS4コントローラー（CUH-ZCT2J11）をBluetooth接続（スマホはGalaxy Note SG-01G Android 5.0.1）して、ROBOT操縦するのには、致命的なタイムラグ（大体0.5秒）がある。接続した直後はこのラグが無いのだが、数秒後から発生し、そのままとなる。微妙な操作に支障（物に衝突、崖から落ちる）となるだろう。この現象は、スマホとコントローラの制御ソフトウェアの中に原因があるので、私には手が出ない。USB接続では、この問題は発生しないが、ケーブルが邪魔になる。
カスタマー・レビューだけを頼りに、ダメ元で、安い・中華製コントローラー（￥1,398）を発注してみた。今日、配達されるので到着したら早速やってみたい。
★中華コントローラー(IPanda Gamepad)
到着した。パッケージを開封し５分でBluetooth接続完了。ソフト変更全く無しでOKだった（KeyCodeはPS4と同じ）。タイムラグは全く感じない。
中華コントローラー、素晴らしい！
何台か買っておこう（３台発注、値段が￥1,458で、昨日の今日なのに、変わっているのに驚いた⇒9/30には￥1,350、為替変動反映？）。
ROBOTの操縦システムは、ターゲットのROBOTの大きさには、関係ないので、これでトラクターや重機を操縦したら爽快だと思う。
致命的なタイムラグは解決したが、実際の長時間の操縦試験・評価をするとNGポイントも出てくると思う。その時、またレポートしたい。
■2017-09-26
★Background
AndroidのBackgroundで動くプロセスにハマッていた。最近、ハマることが多い。元々、試行錯誤とは、そういうものか、、、
スマホとPS4コントローラーをBluetoothで接続し、アプリはBackgroundで走らせておき、スマホはOFFしポケットに入れて、ROBOTを操縦する構想であった。
結果は、挫折、、、
こんな風に、Serviceの継承クラスを作ってそれをMainActivity から起動させて、Backgroundのプロセスをつくると、スマホをOFFしても、動き続ける、ところまでは右往左往・ネット徘徊して実現出来た。しかしながら、ROBOT操縦する為にはKeyEvent を拾ってやらねばならない。これが、Backgroundからは普通には出来ないのである（ネチコチやれば、やる道はあるようだが、モチベーションが萎えた）。また、元気になってモチベーションが復活したら、チャレンジしたい。当面のところは、電源ONのままポケットに入れて、で我慢、、、
■2017-09-24
★PS4コントローラー
今まで、ROBOTの操縦はスマホでやっていたが、操作性の改善のために、ＰＳ４のコントローラーでの操縦の検討中。
先日、Amazonに発注していたのが届いたので、早速やってみた。
スマホにBluetoothまたはUSBで接続し、スマホからudpでROBOTに制御コマンドを送信する構想。古いスマホ(Android2.3.3)では、接続が困難なので比較的最近のスマホを使わねばならず、9/22のudpの問題にハマッていた。
スマホ単体でやっていた時は、button EventでやっていたのをkeyEventに変更するだけなので、比較的容易に実現出来る。やはり、操作性が徹底追及されたコントローラーなので、ROBOTの操縦も、圧倒的に直感的に出来るようになった。
コードは、こんな感じ、、、
//************************************************* //* onKeyDown //************************************************* @Override public boolean onKeyDown(int keyCode, KeyEvent event) { // BackBtnアクション if(keyCode==KeyEvent.KEYCODE_BACK){ System.exit(0); } final int tmp=keyCode; switch (keyCode) { case 19: SendData("forward"); break; case 20: SendData("reverse"); break; case 21: SendData("leftturn"); break; case 22: SendData("rightturn"); } handler.post(new Runnable(){ @Override public void run(){ KeyCodeView.setText("LRB="+String.format("%d",tmp)); } }); return false; } //************************************************* //* onKeyUp //************************************************* @Override public boolean onKeyUp(int keyCode, KeyEvent event) { // BackBtnアクション if(keyCode==KeyEvent.KEYCODE_BACK){ System.exit(0); } final int tmp=keyCode; if(19<=keyCode && keyCode<=22){ SendData("stop"); } handler.post(new Runnable(){ @Override public void run(){ KeyCodeView.setText("LRB="+String.format("%d",tmp)); } }); return false; }
■2017-09-22
★udp送信で、思いっきりハマッた
ROBOT3号機の操縦は、今まで中古スマホ（Android2.3.3）でやっていて、何の問題も無かった。事情があってGalaxy Note（5.0.1）に移植したら、全く動かなくなった。その原因は、Android3.0以降は、udpの送信をスレッドにしないとＮＧ（確認した範囲では、Listener経由で送信する時？）らしい。これを解決するのに、丸１日費やした（能力不足のプログラム開発とは、こんなものか、、、）。
■Android2.3.3で動いてたヤツ
//*********************************************************** //* SendData //*********************************************************** public void SendData(String SData){ sendBuffer=(""+SData).getBytes(); do{ try{ DatagramPacket sendPacket =new DatagramPacket(sendBuffer, sendBuffer.length, RobotAddress); new DatagramSocket().send(sendPacket); SendMsg=SData; }catch(IOException ex){Log.e(ex.getClass().getName(), ex.getMessage());} sleep0(10); }while(EchoOKFlag==0 ); EchoOKFlag=0; }
■Android5.0.1でよ～やく動いたヤツ(2.3.3でもOK）
//***********************************************************
//* SendData
//***********************************************************
public void SendData(String SData){
sendBuffer=(“”+SData).getBytes();
new Thread(new Runnable() {
public void run() {
do{
try{
DatagramPacket sendPacket =new DatagramPacket(sendBuffer, sendBuffer.length, RobotAddress);
new DatagramSocket().send(sendPacket);
}catch(Exception e){System.err.println(“Exception : ” + e);}
sleep0(10);
}while(EchoOKFlag==0 );
}
}).start();
SendMsg=SData;
}
■2017-09-17
★ESP32のタイマー割り込みとＯＴＡ
OTＡは、便利なので活用しつつあるが、タイマー割り込みを使っているスケッチでは、書き込みが出来ないようである。ESP32の中ではタイマー割り込みを含むスケッチが稼働中（OTA含む）なのだが、ここにスケッチを書き込もうとすると、書き込んでいる最中に、タイマー割り込みが発生してNGになると推定しているが？？？
この行をコメント行にすると、NGは解消されることは、確認した。
//VCC Read Timer Set Up
timer = timerBegin(0, 80, true);
timerAttachInterrupt(timer, &VccSend, true);
timerAlarmWrite(timer, 1000000, true);
timerAlarmEnable(timer);
OTAは、捨ててしまうには、あまりにもったいないので、あちこち徘徊して勉強し、以下のように、多少ダサイがOTAでスケッチを書き込む時だけ、タイマー割り込みを止めてやれば、OKとなる。（ESP32は、やはり開発環境がまだ成熟してないなぁ、、、。先達のお陰で解決できたのは、感謝であり、嬉しいが、私の目的は、これじゃないんで、貴重なエネルギーと時間を無駄に費やした気が、、、皆様もここに、ハマらないで、、、）
ArduinoOTA.onStart([]() {
String type;
timerEnd(timer);
timer = NULL;
if (ArduinoOTA.getCommand() == U_FLASH)
type = "sketch";
else // U_SPIFFS
type = "filesystem";
// NOTE: if updating SPIFFS this would be the place to unmount SPIFFS using SPIFFS.end()
Serial.println("Start updating " + type);
});
--- 中略 ---
//VCC Read Timer Set Up
timer = timerBegin(0, 80, true);
timerAttachInterrupt(timer, &VccSend, true);
timerAlarmWrite(timer, 1000000, true);
timerAlarmEnable(timer);
■2017-09-15
★ESP32 タイマー割り込み
タイマー割り込みは、必須の機能で、やり方は大体分かり、こんな風にやればよいようだ。しかしながら、タイマー割込みで定期的に起動される関数（下の例では、onTimer,onTimer2）の中に、WiFi系のコマンド（udp.beginPacketなど）を含むと、再起動を繰り返して、NGである。これは、バグだろうか？。定期的にudp送信したいのだが、スマートに実現出来ないなぁ（後日、知ったのは、※割り込みコンテキスト、例えばtimer(Ticker)では、TCP/IP通信などは利用できない。 なのだそーです。）。
取り合えず、WiFi系の関数を外に出して、一時しのぎしておく。
バッテリーの電圧をタイマー割り込みで、１秒毎にADC（変換精度は今一つだなぁ、変換精度のスペックは存在するのだろうか？12bitもあるのにねぇ）で測り、平均化してudpでコントローラー（PC or スマホ）に送る機能は、ダサくはあるが、実装した。
その内、問題に気付く方が増えて、解決されると思う。
私の目的は、思い描いたRobotの製作なので、これに深入りしないことにする。
（※ルネあたりが、これを凌駕するChipを作ってくれないかなぁ、、、）
/* create a hardware timer */ hw_timer_t * timer = NULL; hw_timer_t * timer2 = NULL; unsigned long t0=0; /////////////////////////////////////////////////// void setup() { /////////////////////////////////////////////////// Serial.begin(115200); /* Use 1st timer of 4 */ /* 1 tick take 1/(80MHZ/80) = 1us so we set divider 80 and count up */ timer = timerBegin(0, 80, true); timer2 = timerBegin(1, 80, true); /* Attach onTimer function to our timer */ timerAttachInterrupt(timer, &onTimer, true); timerAttachInterrupt(timer2, &onTimer2, true); /* Set alarm to call onTimer function every second 1 tick is 1us => 1 second is 1000000us */ /* Repeat the alarm (third parameter) */ timerAlarmWrite(timer, 1000000, true); timerAlarmWrite(timer2, 2000000, true); /* Start an alarm */ timerAlarmEnable(timer); timerAlarmEnable(timer2); Serial.println("start timer"); t0=millis(); } /////////////////////////////////////////////////// void loop() { /////////////////////////////////////////////////// } /////////////////////////////////////////////////// void IRAM_ATTR onTimer(){ /////////////////////////////////////////////////// Serial.println("Timer1:"+String(millis()-t0)); } /////////////////////////////////////////////////// void IRAM_ATTR onTimer2(){ /////////////////////////////////////////////////// Serial.println("Timer2:"+String(millis()-t0)); }
■2017-09-14
★ESP32 OTA (Over The Air)
あちこち調べて、使えるようになった。OTAの基本部分を含んだ、目的のスケッチを最初の１回はシリアルポートで書き込んでやる必要があるが、その後はWiFiでプログラムを書き込める様になる。スピードもシリアルより、だいぶ早い。これで、WiFi USBデバイス・サーバー無しで、遠隔でのプログラム修正・書き込みが可能となった。
しかしながら、現バージョンではシリアルモニタが使えず、Serial.printでのデバッグが出来ないのが、残念。
ロボット系のプログラム開発は、現状ではやはりデバイス・サーバーを使うのが効率が良い。ある程度プログラムの完成度が上がり、ややこしいデバッグが不要になった段階でOTAを使うのが良いかも知れない。また、完成したプログラム・IOT機器もOTAを仕込んでおけば、後からちょっとした変更もWiFiから可能になる。
直感的には、WAN経由でも行けそうな気がする、、、
これが出来たら、活用範囲も広がるかも。いつか、実験してみたい。
■2017-09-11
★ロボット３号機・ＢＡＴＴケースと電子回路ケースが出来上がった
ん～、力強くはあるが、走行音がやかましいなぁ。
電子回路のケースは、でかいが、実験機なので追加パーツなどを実装し易くしたためだ。たぶん、最終的にはこれの１／４くらいになると思う。
ＢＡＴＴはリチウム・イオンの１２Ｖ・２０Ａｈのを実装したが、この程度のロボットには大きすぎる。これしか、手持ちがなかったのでこれにしたが、サイズ・ダウンしてもよいと思う。測定してないが、たぶん通常走行では、２Ａ程度しか食ってないので１０時間走行出来る。オーバー・スペックだと思う。
■2017-09-07
★電子回路ケース
3Dプリンターは、音がやかましいので工房１Ｆに置いていたが、身近に無いと何かと作るのが、おっくうになる。そう思って、２Ｆに戻したが、やってみたら、やはり動作音に耐えきれず１Ｆに、また降ろした。机と、３Ｄプリンターは結構重いので、無駄な時間とエネルギーを費やした。
ようやくＢＡＴＴケースのプリントを始めた。明日の朝、８：００に完成する予定。
電子回路のケースの設計も終わった。上下にフタを付け、追加部品をマウントする時に、基板を外さなくても済むようにした。
■2017-09-03
★BATTケース
リチウム・イオン・バッテリーがかなり大容量（12V 20Ah)で、サイズも大きいのでロボットのシヤーシーの下面に取り付けることにした。
久々に、３Ｄプリンターで作成しようと思う。やはり、定期的にＣＡＤを使っていないと、操作を忘れる。何とか設計完了。
プリントに１７時間かかるので、明日早朝にスタートし、深夜に完成する見込み。
■2017-08-31
★ESP32のAPモードで動画転送
驚いた！ スマホからの1280×720のカメラ動画を全く余裕？で転送出来る。
これで、WiFi環境が無い場所でも、自前でロボットに装着されたスマホ・カメラ動画を転送し、それを見ながらロボットを操縦出来る目処が立った。
素晴らしい！たかだか、￥５００程度のパーツ１つで、ここまで出来るほど時代は進歩してるんだなぁ、、、
ロボット４号機は、原発でWiFiルーター持ち込みか？と考えていたが、これは不要になった。
■2017-08-30
★ロボット３号機・とりあえず、
基本的な制御コマンドだけしか組み込んでないが、とりあえず、動いた。
しばらく、これで遊べると思う。明日は、外の芝生の中を走らせてみたり、遠隔プログラム書換え・デバッグをやってみたい。
もう一つやって見たいことは、APモードでのWiFiデータ転送能力である。ESP-8266では、APモードにして、クライアントとしてスマホをつなぎこのスマホからカメラ動画を転送させようとしたが、ハングアップした。これが、出来ればWiFiのステーション無しに、スタンドアロンで動画転送と、ロボット操縦が出来る（福島原発などの現場を想定して）。←カメラ動画は、帯域を食うのでClock 80MHzでは、厳しいかも、、、
■2017-08-29
★ロボット３号機・制作中
徐々に、らしくなってきた。5V・DDコンを実装したので、これで最低限のハードウェアは揃った。あとは、WiFi系のプログラムを仕上げれば、３号機の走行が可能になるだろう。
コントローラーは、ロボット２号機のヤツを、とりあえず使う予定。ＰＣ版（VB2013)とスマホ（Java）版が既に出来上がっている。
★ロボット３号機・取り敢えずsketch
早いとこ動かしてみたかったので、見てくれには拘らず➡ロボット3号機・ESP32・取り敢えずsketchをつくってみた。これで、前進、後進、右ターン、左ターン、スピードコントロルは出来るようになったはず？。明日にでも、ロボット本体に載せ、リチウム・イオン・バッテリーを取付け実走行をやってみたい。
■2017-08-28
★ロボット３号機
ロボット３号機は、これだが、
しばらくこのシャーシー状態で放ったらかしだった。ロボット２号機が福島へ行ってしまったので、これを作り上げる気になってきた。現状、１号機はESP8266+Arduino Nano、２号機はioio-OTGで作ったので、３号機はESP32で作り始めた。ESP32を調べながらやっているが、やはりLibraryなどが発展途上だと感じる。ロボットのモーター制御にはスピードコントロールの為に、ＰＷＭは必須なのだが、
analogWrite
がまだ使えるようになっておらず
ledcSetup
ledcAttachPin
ledcWrite
の手順を踏まねばならず、タイマー割り込みの
Ticker
もまだ使えない。
timerBegin
timerAttachInterrupt
timerAlarmWrite
timerAlarmEnable
の順で、セッティングが必要となる。
SPIFFS,WevSeverも今後となる。
まぁ、しかしながらこのESP32の活用環境は未完ながら、その機能・性能の高さから、それを補って余りがある。おいおい、それらは整ってくるのは確実なので、使いながらそれを待つことにしたい。とりあえず、Hブリッジを２個つくり（TB6643KQでは、電流不足）、ESP32のDIO,PWMで制御するところまでは、出来たので近い内に３号機を走らせることが出来ると思う。
■2017-08-20
★ESP32
秋月のESP32-DevKitCが届いた。GPIOが21本、ADCが16本あるのでESP-8266より相当強力だ。まだ、Libralyやオープン・ソースは少ないが、今後に期待し今後のIOT・ロボットに使って行きたい。
やはり、まずやるのは、これでしょう。
void setup() {
// put your setup code here, to run once:
pinMode(23,OUTPUT);
}
void loop() {
// put your main code here, to run repeatedly:
digitalWrite(23,HIGH);
delay(500);
digitalWrite(23,LOW);
delay(500);
}
まぁ、動いて当然なのだが、これはやらずには済ませられない、最初の一歩、通過儀礼なので。
このESP32-DevKitCの気に入ったところは、ENとIO0をプログラム書き込み時に自動的に制御してくれるので、DIP SWでカチカチやらなくても済む点である。
Arduino IDEからプログラム書き込みを行えば、自動的にESP32を書き込みモードにしてくれ、書き込みが終了すると、実行を開始してくれる。
ロボットのプログラム開発時には、ロボットは遠隔操縦の為に遥か彼方にあるのが普通なので、この状況下でWiFi USBデバイス・サーバー(WN-DS/USなど）を使ってプログラムの書き替えと、デバッグの為のSerial.printがWiFi経由で可能になる点である。今まで、これが出来なかったので（技術不足）これが可能になったのは絶大な威力である。いちいち、プログラム修正の為に遠方までロボットを取りに行かなくても済む（ESP32のOTAで可能らしいが、現状ではコンパイル・エラー）。
OTAがちゃんと動けば、デバイス・サーバーも不要となるはず、、、
まずは、これを使ってシャーシー状態で放ったらかしの、ロボット３号機を作ってみたい。
■2017-08-20
★ハブ・モータ
・AliExpressでハブ・モーター（インホイール・モーター）なるものを見つけ、注文した。
・この国は、何でも売っているなぁ。このバイタリティには、感服する。昔は日本もこうだったのだろう。
・わたしのような、物づくり屋には嬉しいが、
・価格が＄４４．７７、送料が＄２４．５６。
・ロボット２号機が、福島原発へ行ってしまったので、２号機の弱点（Ｓｐｅｅｄが早すぎる、トルクが低い、ＳｐｅｅｄをＰＷＭで遅くすると更にトルクが落ちる、モーターとタイヤの接続部がイマイチ）を、改善するネタになるか実験してみたい。
・ブラシレス・モーターなので、これのドライブもマスター出来るだろう。
・コントローラーは買わず、ＥＳＰ－３２でやることにしたい。この方がモチベーションが上がる。
■2017-08-02
★UDPで原理的に取りこぼしの無いコマンド送受信
・UDPは早い・軽い・簡単なので、ロボットの操縦コマンド送受信に使っている。
・しかしながら、やはりたまに取りこぼしが発生する。
・これへの対策を打った。
・概要は、コントローラから送信したコマンドをロボットが受信したらECHOさせ、コントローラは自分自身の送信内容とECHOで返ってきた内容が一致するまで繰り返し、コマンドを送信する（と言っても、大体は１回で済む、時たま複数回送信する）。
・これで、取りこぼしは、原理的に排除された。
プログラム好きな方は、以下を参照下され、、、
■コントローラー側 //********************************************************* //* SendData //********************************************************* public void SendData(String SData){ //sendBuffer =str_longitude.getBytes(); sendBuffer=(""+SData).getBytes(); do{ try{ DatagramPacket sendPacket =new DatagramPacket(sendBuffer, sendBuffer.length, RobotAddress); new DatagramSocket().send(sendPacket); SendMsg=SData; }catch(IOException ex){Log.e(ex.getClass().getName(), ex.getMessage());} sleep0(10); }while(EchoOKFlag==0 ); EchoOKFlag=0; } //************************************************* //* UdpIn //************************************************* class UdpIn extends Thread{ public void run(){ //BufferedReader br = new BufferedReader( new InputStreamReader(System.in) ); //SocketAddress sockAddress;//接続してきた送信元 // 受け付けるデータバッファとUDPパケットを作成 String TempIP=""; try{ DatagramSocket recSocket =new DatagramSocket(8090); byte []buf = new byte[256]; DatagramPacket packet= new DatagramPacket(buf,buf.length); String msg=""; int len; while(true){ msg=""; recSocket.receive(packet); len = packet.getLength();//受信バイト数取得 msg =new String(buf, 0, len); ControllerMsg=msg; if(msg.equals(SendMsg)) { EchoOKFlag=1; } ■ロボット側 //************************************************* //* UdpIn //************************************************* class UdpIn extends Thread{ public void run(){ //BufferedReader br = new BufferedReader( new InputStreamReader(System.in) ); //SocketAddress sockAddress;//接続してきた送信元 // 受け付けるデータバッファとUDPパケットを作成 String TempIP=""; try{ DatagramSocket recSocket =new DatagramSocket(8090); byte []buf = new byte[256]; DatagramPacket packet= new DatagramPacket(buf,buf.length); String msg=""; int len; PreTime=System.currentTimeMillis(); //現在時刻をセット while(true){ msg=""; recSocket.receive(packet); len = packet.getLength();//受信バイト数取得 msg =new String(buf, 0, len); if(!ControllerIPAddress.equals("255.255.255.255")){ SendData(msg); //Command Echo
■2017-07-30
★福島原発へ
明日、ロボット２号機の嫁ぎ先へ様子を見に行くことになった。ちゃんと、現場で使い物になっているかどうか、確認する。手ぶらで行っても何なんで、スマホ・Robotコントローラーを手土産に持って行くことにした。元々の設計思想は、ロボットに装着されたスマホから送られてくるカメラ動画を見ながら、PCで遠隔操縦すること、になっていたが、現場の要望ではロボットを目視しながら操縦するので、ノートPCよ
りスマホの方が、お手軽である。
こんな操作画面である。
また、現場での走行テストでWiFiの電波範囲を越えた時、操縦不能のまま走行し続けてしまう（当然そうなる）、不都合の連絡があったので電波が途切れて、コントローラーからの操縦指令が届かなくなったら、ロボット自身が自動停止するようにした（ウォッチドッグもどき）。ロボットのバッテリー電圧の監視機能も追加した。
これで、便利に使えるかどうかは、現場に行ってみないと解からない。やはり、現場が大事だ。工具とノートPC（eclipse,VisualStudio）を持って行き電子回路基板とソフトの変更が出来る準備はした。
妙に、、、ワクワク感がある。
■2017-07-25
★ＬＥＤローソクの結果
実際のお祭りの灯籠に入れ込んだ、いのはな電子工房作・ＬＥＤローソクは、こんな感じで、充分従来ローソクにヒケをとらない出来栄えだった。ローソク管理を担当している村の自警団から、風で火が消えることも無く、熱で曲がることも無く、大絶賛を受けた。灯籠は全部で５０個ほどあり、今年は１０個分のＬＥＤローソクを作ったが、おだてられて、来年は残りの４０個を作ると約束をしてしまった、トホホ、、、、（おだてに弱い）。
安ＬＥＤローソクの問題は
①１パッケージのＬＥＤが、抵抗内蔵のものであり、暗いが電流増強の余地が無い。発光効率も悪そうである。➡高輝度ＬＥＤ＋電流制限抵抗に交換
②おまけで付いている、ボタン電池（ＣＲ２０３２）の寿命が、著しく短い。➡ノーブランド￥３０電池に交換
まぁ、１個４０円では文句も言えない。
結局、ガワだけ使って、中身は電池、ＬＥＤ含め全部交換した。
これが、同条件（ＬＥＤ交換後、抵抗２５．５Ω）での電池放電性能比較である。付属電池は、オマケとは言え、これで電池と言えるのか？くらい寿命が短い。さすがに、国産（Ｓｏｎｙ）の電池は素晴らしい。Ａｍａｚｏｎで購入したノーブランドの１個￥３０の電池も、値段の割には健闘していると思う。今回のＬＥＤローソクには、この安電池を採用した。スタート時にＬＥＤに流す電流は、２０ｍＡで、実用範囲としては電池の電圧が降下して１０ｍＡ程度まで減少したところまでかな？と思う。測定によれば、大体スタートから５時間くらいである。これで、パッと消えてしまう訳でもなく、しつこく１０時間たっても、光っている。ＬＥＤ電流は電池の電圧降下と共に減少して行くので、電池の電圧降下も、極めて僅かづつになって行く。恐らく、１００時間経っても、光っていると思う。５～６時間のお役目を果たした後でも、まだまだ十分な明るさで点灯している（１０個中、４個は帰還せず、たぶん灯籠についたまま）。まずまず、いのはな電子工房としての面目を立て、お祭りに貢献出来たと思う。
■2017-07-16
★ローソクとＬＥＤローソク
村のお祭りの役員を仰せつかっていて、灯籠の光源を考えている。
従来から、ローソクでやっているが、火が消えたり、熱でローソクが曲がったりで、管理に苦労している（村の消防団がやらせられている）。
折角「いのはな電子工房」のわたしが役員なので、ここはひと肌脱いでＬＥＤ化しようとしている。Amazonで、びっくり安値のLED（電池付
きで１個￥４０、たぶん中華製）を売っていたので、これを買ってみた。しかしながら、非常に暗くて使い物にならないことが判明した。２個入れても、全然ローソクの明かり（１ｃｄ）の足元にも及ばない。
ＬＥＤの電流を増やせば、明るく出来るだろうと、分解（fig.②）してみたが、抵抗も何もなく、スイッチとＬＥＤ（恐らく抵抗内蔵）と電池（CR-2032）しか無く、改造の余地が全く無い。ＬＥＤに流している電流を測ったら、僅か２．７ｍＡであった。諦めかけたが、「工房」の名がすたるので、奮起して秋月の高輝度ＬＥＤに交換することにした。こちらの標準電流は、２０ｍＡでしかも超高輝度（20ｃｄ・オレンジ色）なので１０倍以上、眩しいくらい明るいことを期待して、発注をかけた。結果を乞うご期待！！！
お祭り日は、７／２２～２３。
