Timely Factbot – Python IRC Chatbot

Posted by Erin, the RobotGrrl on Thursday, September 9th, 2010

The telling of facts while in a group setting is quite interesting. In an ideal scenario, there would be an equal amount of fact sharing by each member in the group. Usually this is not the case, as one person can know more about one subject and be very good at rattling off facts. Conversing with people like that can be difficult, as that person’s role becomes more of the fact-rambler, eventually becoming distant from the group itself. What if we could leave the fact-rambling to a robot, and let the humans do what they do best?

This might sound contradictory to everything that we have learnt so far. Are we not supposed to be fact machines, after all that we are “taught” in school to memorize equations and whatnot? That’s what books are for, you really don’t need to know any of those things, just how to apply them. Robots are good at “knowing” things, but maybe not so much applying them.

Picture this setting in an IRC chat-room (Fat Man and Circuit Girl):

Conversations like this happen regularly throughout the times that I’m actually “in” there. There’s a few topics going on at once, crazy helicopters, polarization of projectors, and CPU load. What would really be nice is if somehow ithon and I magically learned something about polarization, while we were discussing it. A timely factbot would be great!

Basically since September 1 I’ve been playing around with Python libraries for IRC chatbot connections and playing around with the natural language toolkit. A few months ago, when everything was peachy, I was thinking about projects that would be cool to fit in with an AI and HCI class. I made a conversation robot software a few years ago, but haven’t given it much time after the science fair was over. Seems like a pretty good opportunity to work on something similar using the ideas that were used in that old software!

The plan of attack so far is to first be able to tokenize the messages that are sent. From there, design a Markov approach to construct a “memory” of what is being discussed. Some magical AI will happen, then some text will be fetched from Wikipedia and sent into the chatroom.

I’m super excited for designing the Markov approach. I don’t even know anything about that very much!

The best part about this factbot in my opinion is that it will be interacted with indirectly. No crazy commands will need to be used. It will be listening and waiting for a good time to start to ramble off some facts. It probably would be beneficial to add support for messages that are sent that tell the factbot to elaborate more. I’ll keep blogging about this as I go. It’s sort of going to be like a side-hobby, I might not be able to dedicate as much time to it as I would have thought, but it will be fun anyway

Forgot to mention that I’ll probably be playing around with this factbot in #robot at comm.cslabs. Once it’s working reliably, I’ll have more faith in bringing it out into the “real world”.

Posted in: Programming, Projects.

Friday Night Robotics – CMUcam2

Posted by Erin, the RobotGrrl on Friday, February 5th, 2010

The CMUcam2 is a really cool camera for robotics made by CMU. The version that we’re using for this Matlab project (that I mentioned before) was actually used in FIRST competitions a long time ago.

The first problem we faced with this was that it requires 7.2V, in a range of 5.2V – 8.6V. What gives 7.2V?! Crazy! If you take 6 AA rechargeable batteries together, they can add up to be 7.2V exactly. (1.2V * 6 = 7.2V). Battery packs naturally don’t come in sixes, so I ended up making one:

This was actually my first time making a series battery pack. It’s in series because we want to use Ohm’s law, where the voltage is added together. Thanks to the people in the Fat Man and Circuit Girl IRC chat room, they helped me figure it out. Here’s a drawing that I made incase others too need help with this someday. Basically, connect the positive to negative over and over again! ^_^

The next step is to get the camera working. This is by far the hardest part. There’s numerous methods of communicating to the CMUcam2, all of which use RS232. Arduinos also use RS232, so at least we’re in known territory.

The CMUcam2 has a serial port, a TX/RX/Gnd line, and a TTL port. On my Mac, I tried the serial port, it didn’t work. I tried the TX/RX/Gnd line into an Arduino, it also didn’t work. I also tried to use the TTL, but it also didn’t work. I’m not really sure why nothing works on my Mac, especially since the camera works with a PC just fine.

This is where I’m at right now. No idea what to do to make the CMUcam2 work on my Mac. Do any of my blog readers have any ideas?

WOOT~~~ TWIST ENDING!! READ ON!!!

I was thinking that it would be really lame to end the blog post without some sort of screenshot of Matlab or something. So I gave the CMUcam2 another shot… I made it work!!! IT WORKS!!! IT WORKS ON MY MAC!!!!!! =) The code that I was using to test the camera is from Instructables.

So, now that it works we have things to do… like figuring out how we can get the RGB data for each pixel, and then saving that to an image. After its in an image, we can do some form of edge detection. Matlab probably has a toolbox for that. More fun later!

Google thinks that you might like this:

Posted in: Programming, Projects, School.