ホーム » 2014 » 12月

月別アーカイブ: 12月 2014

2014年12月
« 11月   1月 »
 123456
78910111213
14151617181920
21222324252627
28293031  

最近の投稿(電子情報)

アーカイブ

カテゴリー

2014年12月28日(第404回)

  • まるよし Train Pops ~ 国語と遊ぼう! 第85便 「主題」 後編
  • クリスマスの話
  • 年末の過ごし方
  • 今年1年を振り返って

担当:松島(3C)、山野(3C)、植村(1E・MC)、小藤(1B)、西(教員)

知的財産の講演会

知っておくべき知的財産の基本と、その企業活動の実際

1412241609_320x174.jpg

2014年12月21日(第403回)

  • まるよし Train Pops ~ 国語と遊ぼう! 第84便 「主題」 前編
  • キャンパスプロジェクト報告会について
  • クリスマスの話
  • 推薦入試対策

ゲスト:富山高専 五味先生

担当:山野(3C)、川崎(1EI・MC)、植村(1E)、西(教員)

moodleサーバの SSL 鍵の更新

恒例の SSL 鍵の更新の連絡が届いたので、更新作業を行った。

# 単なる作業メモです。

2014年12月14日(第402回)

  • まるよし Train Pops ~ 国語と遊ぼう! 第83便 「忠臣蔵」
  • 高専カンファレンス福井2について
  • 中間テストの結果

担当:松島(3C)、田嶋(2C・MC)、田中(1B)、小藤(1B)、西(教員)

Droboはやっぱり便利

Drobo S を使っているけど、HDDが故障ということで、 5機のHDDのうちの1つを交換。 前回故障したときも最上段HDDだったので、マスター的に 利用する設定なのだろうか…

部屋には、以前使っていた"Tera Station"もあるけど、 HDDの故障があっても、基本は無駄に高価なメーカの HDDを買わないとダメだし、そろそろHDDの容量を増やしたい と思ったら、全HDDを交換しないとダメなので、使い勝手が悪い。

でもDroboなら、故障ついでに1サイズ上のHDDに交換すれば 容量を随時増やせるし、同じメーカー/同サイズのHDDを買っておく必要もない。 しかも、交換する時も"普通のHDD"を買って、壊れたのを抜いて 新しいのを刺すだけ。その時だけ、再構築をするから一時的に "read only"にはなるけど、数時間後には通常利用ができるようになる。

# 家の外付けもDroboにするかな…

サーバの削除パッケージの掃除

自分で管理しているサーバは、殆どが Debian だけど、 パッケージ整合性チェックなどが安心して使うことができ、 長らく使うため、時としてお掃除も必要。

dpkg -l を実行すると、廃棄 rc マーク付きのパッケージが 大量に表示される。時々、以下のコマンドでパッケージ残骸を お掃除しなければ。

(( rcマーク付きをパージ ))
# aptitude purge `dpkg -l | grep ^rc | awk '{print $2}'`
(( 孤児パッケージのうち libで始まるライブラリは消す ))
# aptitude purge `deborphan | grep ^lib`

2014年12月7日(第401回)

高専ライブ400回突破記念放送!
これまでの高専ライブの歴史をクイズ形式で振り返りました。
高専ライブの歴代MCの皆さんからメッセージをいただきました。ありがとうございました。

  • まるよし Train Pops ~ 国語と遊ぼう! 第82便 「手紙 Part2」

担当:松島(3C・MC)、山野(3C)、森山(1M)、小藤(1B)、西(教員)

DTNネットワークに参加

先日のプロコンで、課題部門の作品(WT)に興味をもってくれた スペースタイムエンジニアリングさんの紹介で、DTN(遅延耐性ネットワーク) のワークショップに参加。災害時のネットワークを意識した 様々な発表があった。 以下、実験中で公式発表でないものもあるので、キーワードだけ抜粋。

オフローディング:災害時のネットワークでは、混雑して使えない時は、 (a)時間的(空いてる時に送る)、 (b)空間的(つながる場所に移動して送る)、 (c)通信経路的(WiFi,3G,LTEなど通信路を切換えて送る)

蓄積運搬型のデータ伝送:FireChatなどのすれ違い時にデータを蓄積 運搬するデータ伝送では、端末密度の違いに応じて送り方を変えないと、 無駄なネットワーク通信が発生する。 高密度の場所では、広範囲の交信履歴のある効用値の高いものに送る。 低密度の場所では、区別せずに送る。 GPS情報で有効なすれ違いができた場所を記憶するとどうかな?

蓄積運搬型で、過密度の場所ですれ違いする場合には、マルチキャストや ブロードキャストで配信できないか?

南紀白浜で、被災時のネットワークがどうなるか、人や車の動きを考慮 したネットワーク状況をシミュレーション。観光地であれば、 旅行者2万人、住人1万人程度の想定が必要。 被災時には、メッシュネットワーク構築が重要。ルータにユーザ通信用、 WiFiメッシュネット構築用の2系統を付けて、平常時はFree WiFiスポット で災害時にWiFiスポット間通信でメッシュネットを構築させたい…

災害時にメッシュネットを効率よく構築したい。自律ロボットが、 ZigBeeのAPをばらまいてメッシュネットを構築させたい。 電波強度が限界に近づくと2つ目のZigBeeのAPを落としていく。 直進しながら距離を稼ぐメッシュネット構築。 または、自律ロボットがAPとなり、隣接APと電波強度がギリギリに なるまで、拡散移動し、面積的な広範囲のメッシュネット構築。

すれ違い通信時に端末の軌跡情報を元に、通行不能場所を推定できないか?

すれ違い通信でBLEでは、送れる情報が少ない。WiFiを併用して通信量を増やしたい。 BLEでWiFiのSSID等の情報を送って、その後はWiFiをDirect通信に 切り替えて、大量通信を行う。WiFiのDirect通信切換えにかかる時間が問題。

StarBEDの活用事例として、災害時ICT検証のプラットフォームNERVF。 若狭湾周辺の災害時ICT挙動シミュレーションに取組中。

災害時に人の存在情報のセンシングができないか? スマートフォンの加速度&音情報で混雑検出ができないか? 群衆を撮影したツイート画像から、混雑情報を検出できないか? 背景差分法で、同一背景でなくても、特徴量検出で対応箇所をマッピング してから、背景差分を行えば若干の撮影位置の違いがあっても、 背景差分法ができる。 風景写真でオプティカルフローを求めると地表面が求まるので、 地表高を考慮すれば、誤情報をrejectできるはず。