Posts Tagged ‘COSI’
Simple Processing Twitter
I created a really simple Processing and Twitter sketch to help a friend a few nights ago ^_^ It is based off of this previous code from the blog post “Processing + Arduino + Twitter + OAuth”. Here’s what changed:
- 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.
Or view it on Github
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
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!
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!
Canada Spirit!
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!
FNR – Robot Mesh Network: MANOI & IRC
Using Twitter as a means of communication between the outside world and my robots isn’t a very reliable solution. Sometimes the website is down, and they don’t return search results in a timely manner. There were a few other options that I through around, like using gchat or IRC. IRC seems pretty fun, plus I have already done some playing around with it through the factbot idea.
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:
Mesh Robots – MANOI & IRC from RobotGrrl on Vimeo.
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:
-
getModuleCallables()[cmd[0]](self.arduino)
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:
-
def readFSR(arduino):
-
print "MANOI Read FSR"
-
arduino.send(‘*’)
-
arduino.send(‘FSR’)
-
arduino.send(‘*’)
-
return arduino.read(4)
This is how it gets parsed into MANOI’s Arduino brain:
-
if(newByte == ‘*’) {
-
-
byte byteIn = 0;
-
-
// Getting the command details
-
while (byteIn != ‘*’) {
-
byteIn = nextByte();
-
msg[it] = byteIn;
-
it++;
-
}
-
-
// Checking to see if we received the message
-
// and seeing how long it is
-
if(it>0) {
-
receivedMessage = true;
-
messageLength = it-1;
-
//analogWrite(greenR2, 255);
-
}
-
-
if(receivedMessage == true && messageLength == 3) {
-
-
validCmd = true;
-
ii = 0;
-
-
// Check each letter to see if it’s right
-
while(validCmd && ii<messageLength) {
-
if(msg[ii] != fsrCmd[ii]) {
-
validCmd = false;
-
}
-
ii++;
-
}
-
-
// If it is right, do the command
-
if(validCmd) {
-
readFSR(false, true);
-
}
-
-
}
-
}
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!
-
byte nextByte() {
-
-
while(1) {
-
if(Serial.available() > 0) {
-
byte b = Serial.read();
-
return b;
-
}
-
}
-
-
}
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:
-
def danceCmd(arduino, args):
-
print "Dance Command"
-
arduino.send(‘%’)
-
arduino.send(args[0]) #bajngl
-
arduino.send(‘%’)
-
#r = arduino.read((7*19) + 3)
-
#print r
-
arduino.flush()
-
arduino.flushInput()
-
return arduino.read(4)
Arduino:
-
// Pre programmed moves command
-
} else if(newByte == ‘%’) {
-
-
byte byteIn = 0;
-
-
// Getting the command details
-
while (byteIn != ‘%’) {
-
byteIn = nextByte();
-
msg[it] = byteIn;
-
it++;
-
}
-
-
// Checking to see if we received the message
-
// and seeing how long it is
-
if(it>0) {
-
receivedMessage = true;
-
messageLength = it-1;
-
}
-
-
if(receivedMessage == true && messageLength == 6) {
-
-
validCmd = true;
-
ii = 0;
-
-
// Check each letter to see if it’s right
-
while(validCmd && ii<messageLength) {
-
if(msg[ii] != bothArmJngl[ii]) {
-
validCmd = false;
-
}
-
ii++;
-
}
-
-
// If it is right, do the command
-
if(validCmd) {
-
Serial << "okay";
-
bothArmJingle(1);
-
Serial.flush();
-
Serial2.flush();
-
}
-
-
}
-
-
}
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!
FNR – Robot Mesh Network: Intro & Node 1
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:
Robot Mesh Network – Introduction & Node 1 from RobotGrrl on Vimeo.
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!
Processing + Arduino + Twitter + OAuth
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)
-
twitter.setOAuthConsumer("***", "***"); // consumer key, consumer secret
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!
Welcome!
Robot Party
Thursday @ 8:00PM ET
Robot Party page!
You can participate in the Q&A of the Robot Party through the chat widget on the Robot Party page!
Social
Robotic Fund
Housekeeping
- 3D (10)
- Android ADK (4)
- apps4arduino (12)
- DUE (1)
- Electrical (8)
- EMSL (11)
- FIRST (3)
- Fun (52)
- MAKE: Projects (3)
- Maker Faire (18)
- News (189)
- Animation News (2)
- Other News (45)
- Robot News (104)
- Tech News (56)
- Projects (290)
- Android (3)
- Animation (7)
- Art (61)
- Deep Thought (2)
- iPhone (12)
- Lab of Misfit Robots (1)
- Mac (2)
- Newton (1)
- Other (52)
- Programming (90)
- Robot (174)
- MANOI (64)
- School (25)
- R.I.P. Banff (6)
- Raspberry Pi (1)
- Recycling (2)
- RoboBrrd (thx Adafruit!) (74)
- Robot Party (15)
- Tutorial (3)
- Uncategorized (4)
- WyoLum Progress (25)
- Active Robots (UK)
- Nucleus Learning
- Jeff Hopkin's Blog
- Foulab
- Robots Podcast
- AI & Robotics
- Media Lab
- Acroname Robotics
- Trossen Robotics Blog
- Robots Dreams
- MovieStorm
- LMR
- HRI 09
- Eric's Robotics
- Fat Man and Circuit Girl
- Robot Watch
- Automaton
- Get Robo
- Learn about Robotics
- Popular Science
Categories
Tags
Archives
Links
Map
