- It now uses the Access Token that you can get from the Twitter App’s panel
- No more inserting PIN info into a file
- No Arduino clutter in the sketch
- Simple methods for posting, retrieving, and searching tweets.

You can probably do a lot more things with this too, thanks to Twitter4j.

If you use this code in one of your projects, let me know! It is cool to see what people make.

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

Helpless Personal Robots

A deep thought, by RobotGrrl

Imagine we have determined the magical ratio between appearance, intelligence, and social knowledge for personable robots to be accepted in our society.[1] They have the ability to have a fulfilling conversation at tea time with you, they can walk, they look polished, and they can understand social norms in cultures. They are the perfect personable robots.

When these robots are rolling off the assembly line, they do not have any social intelligence. The designers of the robots decided it is better to immerse them in an environment where they can learn about the culture for their area. This decision allows for a more focussed personal robot.

A more focussed personal robot would spare no computer cycles and memory on knowledge that would not be utilized in its designated surrounding environment. Tuned to the social dynamics of the area, the robot will be able to speak the proper language and dialects and it would be aware of the historic weather patterns, for both survival purposes and conversation. Depending on how educated the area is, the robot’s style of reasoning will differ. The style of reasoning that the robot would use would effect how it converses and behaves in society. We want the robot to stand out as little as possible, thereby adapting to the environment is crucial.

In order to properly embed the robot with this customized social intelligence, they have to be trained to behave the proper way. The social intelligence cannot come pre-programmed because of the complex nature of the knowledge to be learnt. It is not a large number of facts, rather it is a pattern of behaviour that the robot must learn. In order to be trained for the patterns, the robots will learn from previous similarly tuned robots.[2]

Imagine there are a couple of robots playing the “teacher” role, and a group of robot “students”. The students have to be taught about the culture an behaviour patterns. The only way to learn this material is through repetition followed by a “quiz”, resulting in a reward or punishment[3]. Due to the pace of the robots, the complete training would only take 1-2 weeks, at most.

During this time, the robots are gaining more social intelligence, they are also becoming more aware about the ethics of the surroundings. Their reaction to this new found awareness will differ in every robot, since every robot is in a different progress towards being fully trained.

Their reaction will also depend on how strict the teacher robots are, and how flexible they are to be understanding of the robots concerns. If the teacher robots are extremely strict, and make the robot feel it is not of will[4] to be there, as if they are forced to be there. After seeing that they have to behave in a certain way, they may not be able to understand that they are also encouraged to formulate their own beliefs, we are only asking them to behave in compliance to our society. If their understanding is not complete, they will feel like there is no escape.

We want to encourage the robots to follow their own beliefs, but still act in a socially acceptable way. The teacher robots will have to be adept at predicting situations like this, in order to prevent unnecessary situations.

If there were any moment that would cause the anticipated “robot uprising”, this would be the perfect recipe for it. The robots would be aware enough about how our society works, and have their own theory about what is just or unjust. Their conflicting understanding of the world and their own beliefs, can cause extreme confusion and frustration in the robot. As we are creating complex emotional and behavioural systems that will be able to comply with our social standard, we will have to be able to be weary of the possible consequences.

How will we be able to balance the struggle between teaching the robots how to behave in society, and allowing them to be able to act by themselves? As we are teaching the robots, they are emerging from being captives of their own programs to being able to form postulations about their own beliefs. If we keep preaching our social knowledge upon them, there will be a point where the robots will feel as though they are forced to be there, and they will feel helpless.

How can the acquisition of our social knowledge not result in a feeling of helplessness for the robots? We cannot simply shut off any components, or isolate any parts of the robot, as they are integral to the development of its behaviour. Will teacher robots have enough capacity to generate a theory of mind to help the confused and frustrated student robots?

If we have human supervisors that will help the student robots, will the supervisor be able to keep up with the pace of the robots that are learning to even know when to intervene?

We have never created a separate sentient being before. How will we decide as to what the boundaries of such beings will be? If creating these beings would be the only way for us to further our existence, would we still do it?

Are we willing to take the risk of possible mishaps, when in return we create a sentient being that is able to provoke us to think deeper about our own existence, enhance our quality of life, and further the survival of our society[5]?

[1] Here, by “accepted”, we mean that it will be a common sight and humans will not be scared of the robots. The robots will be social accompaniments. Additionally, they will not be discriminated against because they are a robot

[2] Some hand-tuned robots would have had to be created at the beginning. This would have been a long time ago, and the number of hand-tuned robots would be so minimal compared to those that are trained by them.

[3] The robots are situated in a physical environment because of the lack of individuality that is found in simulated environments. It is the individuality that makes the robots able to empathize, thereby necessary to be the perfect personable robot.

We are assuming that the personal robots of the future still use a neural network type of architecture to learn behaviour patterns. In order to train these, the various weights of each node has to be computed. The weights only become close to the wanted value after thousands of iterations, with either a positive or negative reward after each iteration.

[4] The robots don’t necessarily have “free will” just yet, as they must be fully trained before released into society. They will be beginning to become aware of the importance of free will in our world.

[5] I originally wrote the word “evolve” here, instead of “further our survival of our society”. These robots will not be evolving from us from a biological standpoint. They are separate beings that were created from our intelligence. They will, however, be able to learn our stories, and pass them on.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Yelling Robot is a FREE Mac App that is an animated robot avatar which yells at you at regular time intervals!

The “yelling” capability is done through Mac OS’ speech synthesis Text-To-Speech (TTS) engine. It uses the “Zarvox” voice, since it is a robot.

It has a Questionaire for you to fill out, so that it can yell personalized phrases at you. It is almost like a “Mad Libs” activity, except that it actually says it out-loud through Mac’s TTS capabilities and you don’t see the complete phrases.

It is the most simplistic behavioural “robot” that you can get.

Please DOWNLOAD Yelling Robot and check it out. Leave a rating too!

I will have a video up soon, as I accidentally maxed out my Vimeo data with the BubbleBoy video, haha.

This was a quirky little Mac App that I created to share on the App Store when it is first opening. It is a fantastic day for the Mac OS, and software in general!

Happy Mac App Store Day!

DOWNLOAD YELLING ROBOT

Canada Spirit is now available on the App Store! Woot! It is a Free App, with an optional In-App upgrade. You can check it out here:

US: http://itunes.apple.com/us/app/canada-spirit/id394637853?mt=8
Canada: http://itunes.apple.com/ca/app/canada-spirit/id394637853?mt=8

The App has actually been complete for 3 months now, but there were complications along the way. It’s a long story:

For Apps that use In-App purchases, you have to have your App reviewed (without the In-App purchase capabilities) and rejected. This takes approximately 1.5 weeks. Not to mention, that you have to make the App without the In-App capabilities, which, depending on the complexity and time dedication, could be a few days. We’re already looking at 2 weeks waiting here.

Once your App is rejected, you can finally test the In-App purchase sandbox part of your App. SWEET. Add a few days for debugging. We’re up to a total of about 2.5 weeks used to be waiting here.

This is when the crazy part happened to me. For the In-App purchase, I selected the option “Canadian English” for the language. When my App moved to “In Review” (yesss finally!), they removed that language, which forced my In-App purchase to be in a “Developer Action Required” state- and thus no In-App Purchase approval. The whole point of submitting your App (without the In-App purchase capability) to be rejected was to get the In-App purchase approved.

For this, an additional 1.5 weeks were added. We’re already at 4 weeks here! >_<

Depending on how carefully you read the guidelines for the App Store, then you can be waiting about a month. That’s what happened to Canada Spirit. It got caught in the payment for hardware devices clause. This added another 1.5 weeks…

Once the App was resubmitted, the In-App purchase language options changed AGAIN. Luckily though this time the App Store review team actually contacted me and I was able to fix the In-App without having to go to the back of the line. YAY!

You have to have a lot of dedication to survive the App Store review process. Canada Spirit went through 6 weeks of poking and prodding just to get to you guys, so I hope you enjoy it Post your screenshots of whatever photos you decorate on Flickr so that we can see them!

Also, sharing this story isn’t meant to be against the App Store at all. I still enjoy the App Store as a consumer and developer! It is to cast some awareness on the time investment you will have to make if you want to do some In-App purchases!

To be honest, MANOI hasn’t been powered up since May. There were a few tune ups that were needed. This included a few hours of debugging in order to determine that the TX and RX wires got swapped that were going to the SSC-32. The SSC-32 was also having some power problems, so I added in a new switch:

The XBee is going to fit in behind the SSC-32, above the gyro and accelerometer sensor. You can see a part of it here:

Once this was all set, I started to communicate to MANOI through IRC.

Here’s a video of an explanation and demonstration:

The IRC bot runs from a Python script. The initial code that I used was from Cmd-c && Cmd-v (cool blog name!). They use the pyserial and irclib libraries. There are specific commands that will trigger certain events. The commands are actually the function definitions, it is all done through the magic of this line of code:

The first command that I started out with was to read the force sensitive resistor on MANOI’s hand (kudos to Krafter for donating the FSR)! This is what the function looks like in Python:

This is how it gets parsed into MANOI’s Arduino brain:

BTW, this is how we are reading in the Serial data. It’s a pretty fail-safe way of doing it, especially as it is wrapped in the infinite loop. It makes sure that you don’t miss any data!

It’s pretty cool to see it working! For triggering dance moves, it is a basic command called danceCmd. The user then feeds in some argument that lets the Arduino know which one you want. For these examples, I used the argument BAJNGL. It stands for “Both Arm Jingle”, but saying it phonetically is pretty funny too *bajingle*!

Python:

Arduino:

But here is where the problem starts! Even though the commands that are sent to move the servos on the SSC-32 are attached to Serial2, they still go into the Serial output buffer. This means that when the Python script wants to read four bytes to see if the Arduino responded to the command, it gets the first four bytes of the motion command that are being sent to the SSC-32. It’s confusing because… why would Serial2 be going into just Serial? It’s really weird.

When I try to clear the buffer through Python, it messes up the way the function is handled. In Arduino, you can’t flush the output buffer, only the input buffer. However, I think that you used to be able to flush the output buffer, as I found an excerpt of a book that said that flush had two boolean values fed into it, for input and output. I think it will turn out to be a simple timing process thing for flushing the buffers from Python.

Once I figure that out, I can add on the XBee to MANOI and test it through wireless communication! I also have a ChronoDot that I can add on to MANOI as well, so that it knows what time it is. I kind of destroyed the circuitry for the RoboGlyphs when I tried to use a TLC594 with RGB LEDs. The TLC594 controls the PWM of the LEDs by connecting them to ground. It’s basically reverse of what you normally do. Common cathode RGB LEDs can’t work with this, only common anode. Once I save up enough moneys to buy an Arduino UNO Mega, then MANOI will receive that, and the RoboGlyphs will receive MANOI’s older Arduino MEGA. The RoboGlyph’s Sanguino can be used for BubbleBoy. That leaves two normal Arduino boards and one Boarduino left to be used for TECHNOROBOT and for the Transmitter and Receiver. The Yoda Rampage Robot already has an on-board Arduino on it.

Here’s the link to the Arduino code:

Here’s the link to the Python code:

Thanks to comm.cslabs’s IRC channel for being to withstand the numerous tests on MANOI and IRC bot. Glad I haven’t crashed it yet!

Here’s a photo of some pretty leaves at sunset being hidden by some technology (a telephone and power pole).

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

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!

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!

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!

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”.

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!