新しい充電器
中部勢がよく使う充電器を手に入れた
実は現役中部支部会員であるにも関わらず、いまだに手を出してなかったISDT Q6 Plus 300Wをアマゾンで購入。 もっと安いところがあるかもしれないが、それはおいといて、いろいろ紹介する。
機能
- 対応バッテリーの種類
- LiHv
- LiPo
- LiIon
- LiFe
- Pb
- NiMH/Cd
- 最大セル数6セル
- バランサー端子あり
- 未接続時、充電開始時に確認あり
- 日本語対応
- UI
- センタープッシュ+コロコロ
- 短く押すと決定。
- 長押しで設定に入る。
- センタープッシュ+コロコロ
必要なもの
- コネクタ(XT60コネクタのメス)×2
- 2個同梱しているがなんかきつすぎたので、買ってきた。
- ACアダプター(秋月の12V1Aのこれ)
- 端子を切断して、プラス、マイナスどちらかを確認したうえでXT60コネクタにはんだ付け+熱収縮チューブで保護
- バッテリーにつなぐケーブル
- ケーブルはXT60コネクタにはんだ付け
- 逆側はバッテリー用のコネクタを付ける。
感想
- 音が大きかったので、設定で「低」に変更
- 画面がキレイ
- ファンの音が気になる
- 充電が何%ぐらいかがわかるのがいい。
- シリコングラフェンが使えるのは驚いた。
- スペースを取らない。
- XT60コネクタの抜き差しが固い
調整の手間を省こう
この記事はMice Advent Calendar 7日目の記事です。
全日本について
更新してなかったので、この場で。
まずは、2017年度お疲れ様でした。全日本ではクラシック競技で我々Bustersの圧倒的勝利でしたね。
自分は4位とMice系トップは守りました。U宮さんとは今年こそ、日本人が優勝取り返しましょう話していましたが、ふがいない結果・・・。これで晴れて地球人に戻させていただけたと思います。いやしかし、10/19に基板が届いてから丁度1か月で4位なので、実は相当良いのでは??
あとakoちゃんは個人的にバスター対象にしたので、来年はシーズン通して完封します。
さて、今日の記事ですが、 web系わからない人には初見バイバイです。さようなら。
パラメータ調整の手間を軽減しよう。
もう、ただただ調整がツライ。 いうことで。ツライ要因を上げる。
- 理論がいまいち
- 調整パラメータはすべてハードコーディングされているため都度、ビルド⇒書き込みが発生していた。
前者は皆努力しても無駄なので、後者を専用システム構築をして改善する。
構成
図にはデータフラッシュとか書いてあるので、RX系マイコンを前提に話をしますが、ロボット側に不揮発性メモリがあればよいです。
socket.ioは双方向通信のために使用しているのは高速な更新と、サーバーからのレスポンスを反映を容易にするためです。
Node.jsを利用した理由は環境構築がものすごく楽だから。OS依存ないし。
コンソールGUI
コンソールGUIはWebアプリで作成。どの道どんなGUIでも内部でXML使っているし、HTML5でそこらへんに転がってるサンプルを使えば、おしゃれに作れる。
ここら辺使うのはどうだろうか
フレームワークにAngular.JSなど、双方向データバインディングがあると楽です。
- Angular.JS/Angular (2+)
- React
- Vue
- Riot
jQueryは不要。以下を参照。
You might not need jQuery.
socket.ioから送信するデータの体裁
{ "type":"update", "id":123456, "name":"TIRE", "value":24.5, "descript":"タイヤ直径[mm]" }
ロボットにはid(マイコン上の書き込み先アドレス)とvalueだけ渡せばよいですが、コンソール画面上には、変数名とそれが何なのかを示すため、nameとdescriptも送信。
サーバー
今回Node.jsにはwebサーバーはいらないです。expressを使って、socket.ioサーバーと同時に建てられますが、サーバーからhtml貰う必要ないので、webリソースは全てローカルファイル参照でいいでしょう。HTTPリクエストは飛ばさないので、CORSの考慮も不要。 コンソールとの通信はsocket.ioにすべて任せます。
以下、必要なnode_modulesのインストール。
npm install --save-dev socket.io serialport
上の2ついればOKです。serialportはpython前提になります。こちらを参照。
サーバーにはコンソールGUIからリクエストしたファイルをローカルファイルに書き込む。わざわざDB立てるのももったいない上、別環境での再構築や復元が面倒です。
var fs = require('fs'); function readFile(path, success) { fs.readFile(path, 'utf8', function (err, data) { if (err) { throw err; } success(data); }); } function writeFile(path, data) { fs.writeFile(path, data, function (err) { if (err) { throw err; } }); }
コンソールGUIから来たデータをファイルに書き込んだら、いよいよシリアル通信です。 自分は以下のようにデータを送信してます。コンソールからはnameなど色々送信してますが、ロボット上での解析が面倒なので、必要なデータだけ送ります。(json-cがあればもっと複雑な形式で送信できますね。必要なのかは別として)
// {key:value} {123456:24.5}
ロボット側の処理
サーバーからの送信データは、接頭に{ 、接尾に}、Key-Valueのセパレータにコロンを使用しています。
ロボット側には接頭文字を検知したら、受信バッファを初期化、以降のコロンと接尾文字を除き、バッファに貯める。接尾を検知したら、バッファから送信データを構築します。
key(id)には4バイト以内の自然数、valueには浮動小数として認識させます。
#define MAX_BUFFER 20 typedef struct { int index; int length; char buffer[MAX_BUFFER]; } s_key; volatile s_key keys, values; void detectChar() { SCI1.SSR.BIT.RDRF = 0; // 受信フラグを解除 char recieveData = SCI1.RDR; switch (recieveData) { case '{': recieveMode = KEY; flushData(); break; case '}': recieveMode = END; applyRecieveData(recieveMode, recieveData); break; case ':': recieveMode = VALUE; break; default: applyRecieveData(recieveMode, recieveData); break; } } void applyRecieveData(char type, char data) { if (type == KEY) { pushKey(data); } else if (type == VALUE) { pushValue(data); } else if (type == END) { mapping(); } else if (type == STAY) { } } void mapping() { const char* keyBuffer = &(keys.buffer); const char* valueBuffer = &(values.buffer); long key = atoi(keyBuffer); double value = atof(valueBuffer); save(key, value); } void pushKey(char key) { if (keys.length < MAX_BUFFER) { keys.buffer[keys.length] = key; keys.length++; } } void pushValue(char val) { if (values.length < MAX_BUFFER) { values.buffer[values.length] = val; values.length++; } } void flushData() { for (char i = 0; i < MAX_BUFFER; i++) { keys.buffer[i] = values.buffer[i] = 0; } keys.index = keys.length = values.index = values.length = 0; }
かつて、CとJSのソースを1つの記事に書いたヤツがいるだろうか・・・。
画面イメージ
途中まで作ってみました。左の写真には各センサー値を表示、値を見ながら、閾値を調整するという形式にしてみました。
今後の課題。
- パラメータの調整だけではなく、テストシナリオも同様にバイナリ書き込みではなく、フラッシュからの読み出しから実行したい。
- json-cを使う。
- 大量のデータを一度に更新できるようにする。
新作構想
北信越大会終わりましたが、モチベーションが上がりません。
そこで、何を思ったか、クラシックに現実逃避すれば、少しはマシになるかもしれん。ということで、
今回はそのブループリントを書いていく。
構成
CPUや足回りについては大体決まっている。
名称 | 備考 | |
---|---|---|
CPU | RX71M | 100pin RAMの暴力 |
モーター | DCX10L | 4.5V版フランジ付き、取り付けネジ90度傾け |
吸引モーター | DCX10S | 4.5V版フランジ付き |
センサー | ST-1KL3A | 6個 取り付けは再現性向上のため、ネジ止め |
センサーLED | SFH4550 | 6個 取り付けは再現性向上のため、ネジ止め |
モータードライバ | TB6614FNG | 新規設計非推奨に指定 |
通信 | TWELITE | ワイアレスしたい。 |
ジャイロ | ICM-20602 or MPU系 | ICM系は手はんだ付けしにくいので敬遠 |
エンコーダー | AS5147P or IEH2-4096 | 後者は使わなくなった1717から奪う?・・・? |
バッテリー | Hyprion G3 180mAh(25C) or Hyprion G5 160mAh(50C)×3 | 吸引するので電源は大事。 |
吸引ファン | 外形Φ32 内径Φ16 10枚歯 高さ13.25mm | 3Dプリンタ前提 |
モーターマウント | アクリルでつくる | 3Dプリンタ前提 |
外部メモリ | MRAM | SPI前提で何か |
ギア比 | 63:19 (M0.3) | 3Dプリンタ(アクリル) + kkpmo(真鍮) |
電源 | DCDC⇒5V(2A)⇒リニアレギュレータ⇒3.3V) | ドロップ時の熱対策の結果 |
不安要素いますね。嘘情報も紛れていますが・・・。
狙い
- センサーは真横を見るようにして、探索時に壁切れをしやすくし、安定性向上
- TWELITE⇔シリアル通信(UART)で、無線&ログをリアルタイム出力
- RX71Mのデータフラッシュが使いにくいので、外部メモリに、調整したパラメータを入れる。(RX71M向けのライブラリが出たらしいので、それを見てから。決める)
- パラメータ調整はTWELITEを使って確認する
- DCX10はいずれも4.5V仕様にすることで、3セル対応する。
- ギア比は効率重視の結果。(滑らかさ次第で、POMで作り直しも視野)
懸念事項
- やる気
- 時間
個人的に時間を懸念することが珍しいと思っている。
あまり理由にならないと思っていたが、最近ガチで忙しい。
【備忘録】Edisonの環境構築
Intel Edisonの環境構築手順
- システム側の最新化は済ませておく
ネットワークの構築
開発PCに挿したモバイルスポットを使用する
Windowsのモバイルホットスポットから部屋のWifiを指定しブリッジさせ、グローバル接続も可能にさせる
固定IPの振り方
/etc/wpa_supplicant/wpa_cli-actions.sh を以下のように修正
if [ "$CMD" = "CONNECTED" ]; then kill_daemon udhcpc /var/run/udhcpc-$IFNAME.pid # udhcpc -i $IFNAME -p /var/run/udhcpc-$IFNAME.pid -S ifconfig $IFNAME 192.168.10.2 netmask 255.255.255.0 route add default gw 192.168.10.1 fi
上記の場合、モバイルホットスポットのゲートウェイのIPが
192.168.10.1
Edisonの固定IPが192.168.10.2となる
一々IPアドレスを見るのは面倒なので、名前解決 <Edison(マシーン名)の名前>.localになる ping EdisonName.local が届けばいい
今回、EdisonName=myedisonとする
Wifiの手動設定
以下のコマンドから、対話形式での設定が可能
# configure_edison --wifi
今回、モバイルホットスポットのSSIDを指定し、接続させた
登録した内容はファイルに格納される。何度もやるとスタックされていく。優先順位は先勝ち。
以下のファイルから手動で変更可能
/etc/wpa_supplicant/wpa_supplicant.conf
Sambaファイルサーバーの設定
opkg install samba
ここ を参考にし、/etc/samba/smb.conf で以下を設定
[global] security = share hosts allow = 192.168.10. # 同じネットワーク内の端末へのアクセスを許可 [hoge] comment = Comment for Windows path = /home/hoge guest ok = yes writable = yes share modes = yes force create mode = 0777 force directory mode = 0777
ユーザーも忘れず作る
useradd hoge passwd ******
Sambaはデーモン化されているため、特に再起動の必要はない(ps | grep smbで確認)
これで、Windowsから[ネットワークドライブの割り当て]で
\myedison.local\hoge
を入力すると、ユーザーが問われるので、
hogeと******を入れてあげればよい
これで、WindowsのエクスプローラーからEdisonのファイルが編集できるので、VSCodeなどのエディタを組み合わせることができる
APEC大会
負けました。
探索は走行中の最速経路導出+既知区間斜めも成功(?)。
最短は連続斜めは良かったものの、そのあとの45度ターンが入れずに全部リタイア。
原因は環境に対応できなかったこと、対応しようと調整をし過ぎて、タイヤのグリップ力が一定以下になってしまったことです。
Exiaはタイヤのグリップがなくなると、本来5m/sぐらい出せるのが、4m/sが限界ぐらいにまで落ち込みます。
速度に関してはタイヤ径が小さくなったときに、どこか余計なところが擦れてしまっているのが、直線速度については要因なのかなと。
今回、短期間でメンテも全くできない状況だったので、以下のハードトラブルが発生 * 真横センサーのエポキシ固定がは流れる(比較的マシ) * 左前センサーのエポキシ固定がはがれて、曲がってしまう(斜めの制御に問題。左側の制御を切った。) * 吸引のモーターマウントが破損、振動により色々制御できない状態になる
散々ですね。
Exiaは2017年度大会には出さないと思います。
基板の出来が悪いため、ものすごくハードウェアトラブルを抱えました。
何をしよう。。。
ともかく、やっと2016年度のシーズンが終われました。
大会会場では自分が作ったMMCルーラーやマウス用のブラウザアプリに興味を持ってもらった人がいるので、気が向いたら公開なりなんなりしたいです。
thank you for inviting me.
タンパ旅行記03/26/2017
アメリカのフロリダ州のタンパにいます。
APEC大会(Applied Power Electronics Conferenceの略)に出場するため、 25日夕方成田発の飛行機に乗って初渡米を果たしました。
自身のほどはこの後に控えている調整次第です。
今回行くまでの話を少々。
ワシントンのダレス空港を経由し、タンパ国際空港に来ました.
ダレスで乗り継ぐ際には、トランクは一旦ここで手に取って再度乗り継ぎ用のレーンに自分で乗せ換えました。 海外から来た場合は厳しいそうです。
拾ってから載せるところは少しだけ歩きます(50m?) 入国審査は意外とあっさり、質問は行き先、目的、滞在期間、一人か?とこれぐらいですね。
機内食は12時間も乗っていたので2度ありました、1つ目がチキンカツカレーorパスタ、2つ目がNoodle(焼きそば)or Omletsでした。
地味に焼きそばはうれしかったですね。
海外旅行で必須になるスマホの通信ですが、 今回日本でアクティベーションできるものを使いました。アメリカ T-Mobile SIM カード
30日間有効で、且つ、10GB、4G/LTEが使えるので、githubやnpmリポジトリが入用な俺には都合がいいツールでした。 ニコニコ動画も余裕です。
手続きは簡単で、日本でパッケージに書いてあるURLからアクティベーションのページ具体的にはここ にアクセス、必要な情報を入力して、登録してください。 日程は正確にとのことでしたが、一日ぐらい早めにやっても問題はありませんでした。
登録後メールが届けばOK。Gmailの広告側のボックスに入っていたので見落としに注意
これだけだと、電話とSMSしかできないので、キャリアのインターネットが使えるようにします。
手動でAPNを指定しました。公式(T-mobile)で指定方法が書いてありましたので、それを利用。参照URL
完了後は一応再起動しましょう。
これで日本とあまり変わらないネット環境ができましたね。 イモトのWifiもありますが、500MB/1dayは心細いですね。
新年あけましておめでとうございます。
はじめに
2日連続でブログを書いています。
明日あたり、静岡で雪でも降るのではないでしょうか
冗談は置いといて、
新年あけましておめでとうございます。
寝正月と酒を楽しんでいます。明日あたりは映画でも見に行こうかな。
私は残念ながら、年末に体力を削り、夢と希望と欲望の3日目とやらを追い求めることをしてないのですが、TLを見ていると皆さん、色々と成し遂げたようで、2016年に残したものは何もないことと思います。
新作のお話
皆さん新作の進捗はいかがでしょうか?
ここでは、新刊のことは言及しません。
2016年中に納まらなかった、新作のマイコンに関する、私の考えを述べようと思います。
まず、優先事項として
- チップの大きさ(物理)
- RAM
- 動作周波数
- 使いこなせること(ドキュメントが充実していること)
これらを優先します。 現状のRX631よりも優れいているものを使いたいですし、かといって、STM系のだと周りに私に教えてくれる人がいませんので、中々学習コストが高いと。(それについての言及もあとで)
候補は以下の通りです。
- RX631 48pin
- RX631 64pin
- RX71M 100pin LGA
- RX71M 176pin BGA
- STM32F446 64pin
入手性も考慮した結果です。
LGA,BGAについてはネタに近いですが、それでも、いずれExiaに搭載したいなとも思っています。
さて、そうなるとSTM32F446とRX631の一騎打ちになって、性能差から、STM圧勝としか見えていないのですが、都合により、Windows縛りのため、環境構築が面倒くさい。
Mice BustersのSTM使いは石油を掘りにいっている騎士王しか心当たりがないので、非常にとっかかりにくいというのが、踏み切れていない原因です。
「これとこれを使えば動くよ」的な手法で学習していたので、プラットフォームの切り替えにリスクを伴ってしまう。というのが現状ですね。
結局、「ルネサスでいいや」に落ち着いてしまうのですが、それだと、日本のメーカーが提供している製品の使い方を覚えたに過ぎないという事実からは逃げられないです。
この意見は、ルネサスをディスるよりも、それしか扱えない人にはなりたくないなという戒めです。
魚をもらうよりも釣り方を覚えたほうが意味がありますからね。
さて、どうしたものか。