FNR – Robot Mesh Network: Intro & Node 1

Posted by Erin, the RobotGrrl on Sunday, September 19th, 2010

I’m trying to create a network for my robots to communicate through and interact with the outside world to have some new behaviours emerge. Each robot will be able to read and transmit messages. The robots will be given basic instructions for things to listen to and eventually some behavioural AI to link previous commands together. The idea is to have robots talking to each other, informing one another of different sensor readings, thereby creating a shared knowledge of the environment that the robots are in.

In a military robots example, a UAV could be observing the environment below and an autonomous rover analyzing some LIDAR sensor data of its ahead of it. With some mapping algorithms applied and communication between the two robots, a rescue mission could be planned and executed very quickly. It’s all about networking the robots and making them talk together in “words” they understand.

Last Friday I worked on getting Twitter integrated with Processing. This weekend I added on to that existing work by trimming down the tweet string, and having it transmitted to an Arduino which broadcasted the message through the XBee to the other devices.

There are currently three devices on the network right now:
Node 0: Transmitter from the computer
Node 1: RoboGlyphs
and a Watchdog, which doesn’t transfer data, only reads what is being sent out.

Here is a video of a broad and basic explanation of everything so far:

The transmitter node serves as the main point of communication of the internet to the devices, and vice versa. It’s using an Arduino with an XBee attached to it. Right now its main purpose is to send out the tweet that it receives from the Processing sketch.

The transmitter node looks like this:

Which is attached to the computer running a Processing sketch:

The Processing sketch is connected to Twitter, and searches for tweets that are to @RobotGrrlsBots. The connection is through OAuth, since IP rate limiting for feeds resets less often, as far as I have observed. It sends the most recent tweet to the transmitter node.

The RoboGlyph node receives the tweet, and does what the command says. The command has to be formatted in the way of this:

If it is received OK, which is usually is, then it will display it! The process that the RoboGlyphs follow is that it fades in the colours, then it waits for a command. Once it receives a command, the colours will fade out.

This is what the RoboGlyphs node looks like:

And this is it working!

Pretty cool. The RoboGlyphs could use a tune up though by using one of the TLC594 16 bit PWM out chips. Right now the green LEDs don’t use PWM, so it makes the animation look choppy.

The Watchdog watches all of the data that is being transmitted and shows it on the screen. This is what it looks like:

It’s useful to try to debug some things. While making everything I was having trouble with the New Soft Serial library and Arduino 0019.

Next time I will be working on getting data transported back from the RoboGlyphs and sending a tweet. From there, it will be about adapting that code to all of the other robots too. This is just the start!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. GO OPEN SOURCE!

Posted in: Programming, Projects, Robot.

Processing + Arduino + Twitter + OAuth

Posted by Erin, the RobotGrrl on Wednesday, September 15th, 2010

WARNING: There’s a newer version of this code here: “Simple Processing Twitter”!

People who devise these spectacular security protocols and stuff really make it complicated to communicate to cool social networking sites. Yesterday I got carried away and ended up making a Processing sketch that could successfully connect to Twitter through its OAuth method. This is primarily for a project where Tweets are read, sent into Processing, which are then sent to the Arduino, which then broadcasts the message through its Xbee, and then the other robots pick up on the message. If the message is addressed to them, then they will parse it and do what it says. The first step though was to try and get the OAuth to work. Below is the link to the Processing code and some steps that I took that may help others.

1. Set up a Twitter application

Here is a screenshot of the settings that I used:

2. Open up the code and fill in the OAuth consumer information (line 131)

3. Uncomment the initTwitter() method call (and comment out the other twitter method calls) in void setup()

4. Open the sketch’s folder (keyboard shortcut: command-K). Open up url.text and go to that website. Copy the pin.

5. Enter the pin in pin.txt and press enter. For some reason there has to be a new line at the end, otherwise it won’t work

6. The code should now give you the access token and secret that you need. This should also be in tokens.txt now.

7. Take the tokens and put them into the code (line 238)

8. Comment out initTwitter() method call, uncomment connectTwitter(). You can also uncomment getSearchTweets too!

Hopefully those steps worked for you. It’s not totally automatic, with the whole copying and pasting of the tokens, but it seems to be the quickest and easiest way to get this done with Processing. Luckily you don’t have to do those steps all the time! Since it’s open source, maybe someone can improve on it! If you find any bugs or have improvements, be sure to leave a comment or notify me! Happy tweeting!

This is the screenie when it worked! Woohoo!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. GO OPEN SOURCE!

Posted in: Programming, Projects.

FNR – Yoda Bot & TSL235R

Posted by Erin, the RobotGrrl on Sunday, September 12th, 2010

One of the sensors that would be cool on Yoda Bot would be a colour sensor, or something like that. I had this TSL235R sensor handy from a recent purchase at RobotShop. Its primary function is to convert light to a frequency value. Last week I soldered it all together, and managed to get the code to report some values back. This week I worked more with the sensor values, trying to determine if the sensor actually can detect colour through some light shining and deduction.

In order to figure this out, I devised a simple little experiment, employing the scientific method. I hypothesized that the sensor could be able to report different values back for different colours underneath of it. There were four colour (or three colours and one shade) options used:

Each piece of construction paper would be placed underneath the sensor unit of the robot: (The below photo doesn’t show the right configuration, the construction paper was aligned better in the experiment)

For 100 iterations each, measurements would be recorded for white, red, green, blue, and no light on from the RGB LED beside the sensor. The RGB LED is surrounded by some black foam, so it doesn’t leak into the sensor. Also, since it is a mixture of red, green, and blue that makes the white colour, it was more of a shade of violet or light blue.

I put the results into google docs, and whipped up some graphs. It was very clear that the white shining colour provided the largest difference in values between the sheets. Here are the values for the different colours of paper given the white light:

The values are close, but there is a difference somehow. Click here to check out the spreadsheet. The unit of measurement for the values is uWatt/cm2, but I have no idea if that is correct or not. The function is in the code. I’m surprised that the other colours didn’t exhibit more different values for different colours of paper, for some reason I thought that might help. It would be interesting to do this on a more shiny or reflective surface! Also, adding foam on the side that doesn’t have foam (refer to photos above) might help too.

It will be really cool to make the optimizations, see if there is a value difference, then create some calibration code and test it out. I’m thinking that the predicted colour can be displayed on Yoda’s pirana LED on its hand. It would be cool to surround the Yoda bot with coloured squares, and have it do different actions. Eventually this could be used as some sort of localization technique that will communicate to the other robots as well.

The code used is below. It’s a good resource to get the TSL235R working with the Arduino! For anyone else reading this who has one of these sensors, you have to attach a 0.1uF capacitor between Gnd and +5V. It reduces noise from the sensor. I was confused about that at first too, but the datasheet says so, and one of the posts on the Arduino forums also says to.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. GO OPEN SOURCE!

Posted in: Programming, Projects, Robot.

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.

Movable Graph – s7graphview

Posted by Erin, the RobotGrrl on Monday, September 6th, 2010

One of the pitfalls of core-plot is that it is hideous to try to interact with. Panning back and forth on the graph slows to a crawl. Zooming requires scaling down the whole graph, and is probably over-complicating the process. Plus, you can’t really add a title to the graph. In HS the teachers purposely take off “5 points” if you don’t have a title to the graph! I really want to do a good deed and help improve the graphing on iOS devices.

The s7graphview framework is really lightweight and does what it has to. Only problem is that it can’t pan or zoom. I took a look at the code and managed to move variables around to the right places to make it work. Check out the video:

You can see a few bugs though, especially with the axis lines. Once those are fixed, I’ll be using this new graph framework in KiloWhatt and then releasing the updated graphing framework open source! With some sample code for iPad and iPhone too.

Hopefully this will make graphing on iOS easier for everyone. In a couple of weeks I can’t wait to see more graphs!

Posted in: iPhone, Projects.

CRAZY stars on App Store! :)

Posted by Erin, the RobotGrrl on Friday, September 3rd, 2010

CRAZY stars is now finally on the App Store. If you have an iPad, go to itunes.com/apps/crazystars to play with the free App! ^_^

If there’s 1,200 downloads in 3 weeks, it will be released Open Source!

Enjoy! Let me know what you think of CRAZY stars!

Posted in: iPhone, Projects.