NHK学生ロボコン、1次ビデオ審査通過!!!

お久しぶりです。前代表三鍵です。

 

12月の記事でNHK学生ロボコンへの出場を目指して活動していることをご報告しましたが、この度、慶應義塾大学ロボット技術研究会は無事1次ビデオ審査を通過いたしました!!!

全てが順調に予定通り進んでいるわけではありませんが、サークルメンバーたちは皆、日々誠心誠意活動しています。これからも応援いただけたらと思っています。

またロボコン活動にあたり、

 

ミスミグループ本社様

ROHM様

マブチモーター様

(順不同)

からご支援していただいています。慢性的に資金不足に苛まれている弊団体の現状において、このような企業様からご支援いただけることに大変感謝しております。あらためてお礼申し上げます。

 

 

現在は2次ビデオ審査に向けて鋭意活動中です。また報告することができ次第ブログでお知らせします。

それでは!!

広告

マブチモーター様からモータを頂きました

NHKロボコン用の支援としてマブチモーター様からギヤードモータを8つ(RS-385PH*4、RS-555VC*4)頂きました。ありがとうございます。

両軸仕様なのでロータリエンコーダ周り等小型化できそうです。NHKロボコンの機体の改良に活用していきます。

最後になりますが我々慶應義塾大学ロボット技術研究会は引き続きNHKロボコン等の各種ロボコン出場のための支援を募集しています。どのような形であれ支援を考えているという方がいらっしゃいましたら以下のメールアドレス(スパム対策のため画像でアドレスを表示しています)、或いは当ブログのコメント欄まで連絡をお願いします。

慶應義塾の4文字

この記事は慶應ロ技研アドベントカレンダー25日目です。

24日目|また来年→

お久しぶりです!今年の10月にロ技研代表をishtarmk2君に継いでほっと一安心したのもつかの間、NHKロボコンへの参加活動も始まりまだまだロ技研してる三鍵です。

今日はアドベントカレンダーの最終日、クリスマスですね!(といっても実際のアドベントカレンダーは24日までが多いそうです。この間チョコの入った実物のアドベントカレンダーを後輩のkeitakatz君が持ってきてくれて、自分の担当記事の日を開けて食べようという話になったのですが、残念ながら25日はありませんでした。)

そんな話はさておき、今年のアドベントカレンダーで何を書こうか悩んだ結果、とりあえず今年の振り返りを書くことにしました!

去年の記事投稿で学んだことの一つとして、技術的な話と振り返り等の関連のない話を一つの記事にまとめても伸びにくく需要のない記事を生成してしまうということを学んだので今回は分けようと思います。

 

さて、今年の振り返りですが、なんといってもNHKロボコンへの参加に向けての活動を開始したのが大きいですね。去年の僕の記事で、ロ技研はメンバー共通の活動目的がないためまとめるのが難しい、なにか大きなプロジェクトを成そうとしたらそれに関わらない(関わりたくない)人も含めて全員が負担を強いられることになってしまうといった話を述べましたが、まさにそういった現状になってしまいました。。。ロ技研はNHKロボコンへの参加のみを目的としたサークルではないですが、ロボコン活動は資金的にも人員的にも多くを割かなくては成り立たないプロジェクトでもあります。NHKロボコンに関わってるメンバーは当然ですが、関わっていないロ技研メンバーにも一部負担増となってしまいました。

しかし、ある意味ロ技研というサークルの形態が新しくなるいい機会と捉えることもできるので、今後代表のishtarmk2君や副代表に就任したkoke688君には頑張ってもらいたいです。目指せ新入生100人。

 

 

ロボコン活動でサークルに費やす時間が増すと、必然的に慶應義塾大学ロボット技術研究会というサークルを相対的な視点から見る機会も増えます。NHKロボコン常連大学と比べて弊団体もそういった環境ほしいなーといったことも当然出てきたりします。

「我々には工業の2文字があります!」

という言葉は今年のNHKロボコンの決勝で、東京大学を降して初優勝を決めた東京工業大学の選手が語ったものですが、最近、慶應義塾大学には”工業”の2文字も、当然”東京”の2文字もないんだなーと実感する機会が偶にあります。でも、そんな環境だからこそのやりがいもあるように思っています。この環境下での一つ一つの活動の積み重ねの先で、ロ技研として慶應義塾の4文字に新たな意味合いを見出していけたらいいなと思っています。

 

記事の構成を何も考えずに適当にタイトルを付けてしまったために、まとまりのない内容になってしまいましたね。取り合えずロ技研は現在、1次ビデオ審査に向けて目下活動中です!今後も活動報告等はブログで更新していきますので応援よろしくお願いします!!

それでは!Merry Christmas!!

 

 

Listで遊ぶ

おはようございます。mt_caretです。

この記事は慶應ロ技研 Advent Calendar 2017 23日目の記事です。遅刻しました。

(追記)空きがあったのでHaskell (その4) Advent Calendar 2017 20日目の記事としてもねじ込みます。

ロボット技術研究会のアドベントカレンダーということでHaskellについての記事です。元々「不変な世界への憧憬」と銘打ってあれこれImmutabilityとそれにまつわるデータ構造に言及しようと思っていましたが、間に合いませんでした。それならとアルゴリズムやらCSっぽいものやらをいくつかHaskellで実装し始めましたが、こちらも間に合いませんでした。他にいいネタも浮かばいのでListでも実装してみましょう。

※このファイルはLiterate Haskellで書かれているのでそのままコンパイル可能です。

型クラスのインスタンスは型シグネチャがあった方が個人的に書きやすいので InstanceSigsを有効にした上で必要なものをimportします。

{-# LANGUAGE InstanceSigs #-}
module List where

import Data.Monoid ((<>))

まずはListの定義です。リストの最後を表すNilと、リストの先頭要素・残りを持つ Consがリストであると定義します(単方向リスト)。例えば1, 2, 3を要素に持つリストを作るにはCons 1 (Cons 2 (Cons 3 Nil))という風にすればいいわけです。

data List a
    = Nil
    | Cons a (List a)
    deriving Show

次にListMonoid型クラスのインスタンスを書きましょう。

instance Monoid (List a) where

モノイドは単位元を持ち結合律を満たす代数的構造です。 Haskellではモノイドの結合操作をmappendあるいは(<>)で表し次の法則が成り立つことが想定されます。

  • 単位元の存在 mempty <> x = x <> mempty = x
  • 結合律 x <> (y <> z) = (x <> y) <> z
  • mconcat = foldr mappend mempty

ここで、結合操作をリスト同士の結合と考えると全ての法則に従いそうです。するとリストの単位元として自然なのは中身が空なリストであるNilですね。

 mempty :: List a
 mempty = Nil

結合操作はリスト同士の結合と書くと、自然と単位元がパターンマッチに出てきます。

 mappend :: List a -> List a -> List a
 mappend Nil bs = bs
 mappend as Nil = as
 mappend (Cons a as) bs = Cons a (as <> bs)

今度はListFunctor型クラスのインスタンスです。

instance Functor List where

HaskellのFunctorに対応するものは関手(functor)と呼ばれ圏から圏への対応付けです。 a -> bな任意の関数fFunctor f => f a -> f bに変換/対応fmapさせます。この時fmapは次の法則に従うように定義する必要があります。

  • fmap id = id
  • fmap (f . g) = fmap f . fmap g

fを各要素に適用するのがリストのFunctorとして自然そうです。ここで、空リストNilのときはfの適用のしようがないのでNilを返していますが法則を満たすためにはこれ以外の挙動はありえない、ということは直感的かと思います。

 fmap :: (a -> b) -> List a -> List b
 fmap _ Nil = Nil
 fmap f (Cons x xs) = Cons (f x) (f <$> xs)
instance Applicative List where

今回はApplicativeの説明を省きます。(c.f. Applicative Programming with Effects

 pure :: a -> List a
 pure x = Cons x Nil

 (<*>) :: List (a -> b) -> List a -> List b
 (Cons f fs) <*> (Cons a as) = Cons (f a) (fs <*> as)
instance Monad List where

いよいよモナドです。モナドの説明はインターネットに無数に転がっているので省くとして(c.f. monad tutorial fallacyHaskellではおおよそ次のように定義されています。

class Applicative m => Monad m where
  return :: a -> m a
  return = pure
  (>>=) :: m a -> (a -> m b) -> m b
  (>>) :: m a -> m b -> m b
  m >> n = m >>= \_ -> n

returnApplicativepureと同じ操作なのでpureで定義されており、 (>>)(>>=)で定義できるのでApplicativeがあれば(>>=)さえ定義すればモナドが得られます。FunctorfmapMonad(>>=)を比べるとa -> ba -> m bになっていることが分かります。何も考えずに fmap (f :: a -> m b) (x :: m a)をしてしまうとm (m a)となりmが二重になってしまいます。(>>=)の本質は型の特性を上手く利用しm (m a)m aに変換できるような対応付けと解釈できます。(ちなみにm (m a) -> m ajoinと呼ばれておりこれで(>>=)を定義することもできます。)

Monadが満たすべき法則は次の3つです。

  • 左単位元 return a >>= f = f a
  • 右単位元 m >>= return = m
  • 結合律 (m >>= f) >>= g = m >>= (\x -> f x >>= g)

どれもそれはそう、といった感じですね。

 (>>=) :: List a -> (a -> List b) -> List b

前述の通りfmap (f :: a -> List b)をするとList (List b)が得られます。リストのリストをただのリストにするにはどうすればよいのでしょうか。リスト同士を結合するのが自然なのではないか、という考えが浮かびます。結合はMonoid型クラスのインスタンスで既に定義しているのでそれを使いましょう。

 Nil >>= _ = Nil
 (Cons x xs) >>= f = f x <> (xs >>= f)

これでListMonoidFunctorApplicativeMonadインスタンスを定義できました。

最後にリストモナドで少し遊んでから終わりましょう。Haskellのモナドは特別扱いされており、do構文という糖衣構文があります。

main =
    putStrLn "Tell me your name!" >>
    getLine >>= \name ->
    putStrLn ("Hi, " ++ name)

do構文を使うと、上記のようなコードを次のように記述することができます。

main' = do
    putStrLn "Tell me your name!"
    name <- getLine
    putStrLn ("Hi, " ++ name)

ここでputStrLnString -> IO ()getLineIO StringIOはモナドです。 name <- getLineに注目するとこのIO StringStringに変換している処理は getLine >>= \line ->に対応していることがわかります。(>>=)は任意のモナドで使えるので<-をリストで使うとどうなるか見てみましょう。

list1 :: List (Bool, Bool)
list1 = do
    b1 <- Cons True (Cons False Nil)
    b2 <- Cons True (Cons False Nil)
    return (b1, b2)
ghci> list1
Cons (True,True) (Cons (True,False) (Cons (False,True) (Cons (False,False) Nil)))

TrueFalseの組の全通りの組み合わせが得られました。なぜこれが得られるか分からなかったらdo構文の元となるコードに直してみた上でList(>>=)の定義と突き合わせて考えてみましょう。

さて、Listモナドを活用すると綺麗に非決定性計算のシミュレーションを行うことができます。今回は簡単のためNP完全であることで有名な充足可能性問題(SAT) を解くことにします。適当な命題論理式fを次のように立てます。

f :: Bool -> Bool -> Bool -> Bool
f b1 b2 b3 = (not b1 && b2 && b3) || (b1 && not b2 && b3)

fが真になるような(b1, b2, b3)は次のように得られます。

list2 :: List (Bool, Bool, Bool)
list2 = do
    b1 <- Cons True (Cons False Nil)
    b2 <- Cons True (Cons False Nil)
    b3 <- Cons True (Cons False Nil)
    if f b1 b2 b3 then return (b1, b2, b3) else Nil
ghci> list2
Cons (True,False,True) (Cons (False,True,True) Nil)
solve :: List a -> String
solve Nil = "No"
solve (Cons _ _) = "Yes"
ghci> solve list2
"Yes"

参考文献

世界を記述する、エッシャーのタイリング【C++とQtでGUIプログラミング】

この記事は慶應ロ技研 Advent Calendar 2017の24日目の記事です。

23日目:Listで遊ぶ||25日目:慶應義塾の4文字

 

こんにちは。日吉図書館の閲覧席にて大声でレストランの電話予約をする輩を見て、嗚呼彼は世界の思惑にまんまと乗せられてしまっているのだなぁと憐れみの念を覚えました運慶です。私を置き去りにして今年も経済は順調に回っているようですね、ふふふ…(暗黒微笑)(ダークマター)

概要

さて、私は去年のアドヴェントカレンダーで何の役にも立たないクソ記事を生成してしまったので、今年こそは技術的なお役立ち記事を書いてやるぞと考えていたのですが、今年のロ技研のアドヴェント記事には既にためになる技術系記事が沢山出ていて、完璧すぎてむしろ一日ぐらいクソみたいな記事を挟んでもいいのではないかと思われるので(勝手な判断)、私のロ技研部員としての秋学期の個人研究の成果について書こうかなと思います。去年と違ってちゃんと技術的な話もするのでどうか許して…。

私は秋学期中、個人研究と称してプログラミングをやっていました。ただ、コンピュータ部に所属していた中学生の頃に、(部なのにあまり教育してもらえなかったので)プログラミング言語を独学で文法からきちっと学ぼうとして挫折したことがあり、再び正攻法で学んでいくことに大きな不安があったので、言語の学習はそんなに真面目にやり直さずに、とにかく作りたい作品をいきなり作り始めることにしました。

目標にしたのは、「画家エッシャーのタイリング系の作品を楽に生成できるソフト」の製作です。「エッシャーのタイリング系の作品」とは、下記リンク先のページにあるような、平面を単一または複数種類のタイルで埋め尽くした感じの版画群です。

M.C. Escher – Image Categories – Symmetry

(本当はこの記事に直接画像を埋め込みたいのですが、エッシャーの作品はまだ権利が放棄されてないみたいなので出来ません。申し訳ありません。是非リンク先の画像を見てみて下さい)

結論から言うと、タイリングっぽく見える画像を生成するための最低限の機能を有するそれっぽいソフトが製作できました。この記事では、今回作ったソフトの話をします。途中何度も文法の不理解による大幅な停滞や課題や試験などによる中断があったりしたり、そもそも製作者自身のおつむがかなり弱かったりするので、ソフト自体のクオリティーは期待しないで下さい()

この記事ではエッシャーについての話もしたいとは思いますが、技術の話から遠ざかってしまうので、ソフトの話が終わった後の「おまけ」として少しだけつけることにします。エッシャーに興味を抱いてくれた方は「おまけ」も斜め読みして下されば幸いです。 続きを読む

ロ技研の1年を振り返って

”今年ももう残り10日を切りました”というニュースを聞いて、”あー、もう今年も終わるんだな”と哀愁に浸り、残り2日に迫ったクリスマスも1人でレポートを書くのかと思うと寂寥感が自分の心を逼迫し、孤独感が否めないこの頃でありますが、この時期になりましたので、この1年間を振り返りたいなと思ったので、ここに主観的にロ技研の感想を書く次第であります。

自分は、高校まで野球一筋で、男子校出身というのもあり、まあふつーの体育会系でして、パソコン音痴で、持久走しか取り柄のない人生を歩んできたわけですが、大学になったら新しいことしたいなーと思ってたのと、ロボットとか面白そうだなと思い、こんな軽い気持ちで入部したというのが本音ですな。

 

m氏と同席になり、m氏はすぐに酔っていて、非常にお酒が弱ーーいということを知り(ディスりではありません笑)、このサークルは安全なサークル!?だと思った4月の新歓、そして、新入部員3人位でチームを組んだ部内大会、そこでは、マイコンを使ったプログラムによる制御を学び、ライン上に車が走るように皆で頑張りました。そしてその部内大会後には、新入生の山場であるF^3RCに向かって、ヒーヒー言いながら頑張りました。自分はCADを用いて、機体の制作を担当しました。いざやってみると、材料が部室にないんかい、CADでエラーがオンパレードすんのかーいと、うまくいかないこともありました。けれど、みんな必死になって頑張っていたので自分も頑張ろうと思ってなんとか食らいつき、機体を8月中にはつくりました。電装とかプログラミングは他の人に任せましたが、無事に、大会前に完成!?しました。結果は、1引き分けで1敗になり、負けた直接的な原因が自分にあったので申し訳無さを感じたんですが、このロボット製作が自分にとっていい経験になったなーと感じた夏休みになり、暇で暇で死にそ―って言う友達よりは、有意義な夏を過ごしたなーと自負してます。

 

そして、9月からは、全体のミーティングでNHKロボコンに向けて頑張ろうって言う結論になりました。実際自分は、全然スキルが無いので、できることは少ないですけど、今日も先輩たちの手伝いをし、わーいわーいと言いながら、作業して、家でご飯を作って、今急ピッチでブログを書いているところであります。

振り返ってみると、予想以上に大変で、でもアットホームでかつ自由!?なサークルで、居心地がよいサークルだなーと思いました。今日も、アルミを吸い込んで元気になりました。目の前の世界の設定が違って見えます。

あと、1分しかないので、最後に一言言わせて下さい。

大変だなんだと文句言ってますけど、ロ技研に感謝してます!!

 

 

 

 

エンコーダの話2

こんばんは。koke688今日です。アドベントカレンダー21日目です。僕はアドベントカレンダー2度目の登場です。

huhiehefuhiの記事日吉 ⇄矢上を5往復しましたにあるように心理的時間と物理的時間の狭間に彷徨い21日中に投稿できるのか不安です(現在時刻23.30)

前回はエンコーダの主に使い方に関する記事を書きました。ロータリーエンコーダの話

エンコーダで得られた情報をもとに位置推定を行う記事を先輩が書かれています。エンコーダーを使って絵を描きたかった…話

他にもエンコーダでモータの回転数を逐一読み取り、フィードバック制御に生かすことができます。

エンコーダフィードバック制御

このグラフはエンコーダのカウント数を縦軸、横軸が時間(0.01s)を表しています。

エンコーダのカウント数が1500になる位置で(モータで動かしている)アームを維持させることを目標にしています。

具体的にはモータの出力 = 比例定数×(1500 ‐ エンコーダの回転数)としてモータの出力、回転方向を変えてうえの制御を実現させています。

今は目標カウント数と現在のカウント数の差のみを用いて制御しています。

今後PID制御の勉強をしてよりいい制御ができるようにしたいです。