Posts Tagged ‘XBee’

RoboBrrd Cosmic Soap

Posted by Erin, the RobotGrrl on Sunday, August 28th, 2011

Creating art with robots usually ends up with a result that is unexpected from the beginning! I created this fluid dynamics + physics sketch in Processing that was fun, and sort of looked like the soap from space. I connected it with RoboBrrd, and it was super unreal the result that it created.


IMG_2870

Watch the video on YouTube :D



All sorts of people have different ideas about what it is, it seems to change from person to person, which is really interesting :) With RoboBrrd, since the light is being shone into its “eyes” (because the LDRs are located close to the eyes), lots of people have said it like a RoboBrrd hallucination. I’m not so sure about this, but playing with it is lots of fun, and shooting some long-exposure photos creates interesting results :)


IMG_2924

My inspiration for creating this was lack of inspiration. I couldn’t focus on more important things to do, but at the same time I didn’t feel like doing nothing.

You can look at the code on GitHub. It’s commented and annotated, so it should be a good starting point if you want to create something like this.

Oh yeah, and to maybe answer a question you might be wondering- I’m not “on” anything. The only thing I’m “on” is my computer 18 hours a day, coding and creating.

If you use this sketch or make something similar, leave a comment with your project! It would be cool to see how this translates into other robot art :D

Posted in: Art, Programming, Projects, RoboBrrd (thx Adafruit!).

Dogcow + iPad

Posted by Erin, the RobotGrrl on Tuesday, June 14th, 2011

IMG_1734 - Version 2

Dogcow now works with the iPad without the use for a middleman in between! It goes straight from the App to the XBee for Dogcow to receive.

Here is a video explanation:

Or view the video on YouTube.

The process begins with an App using the ExternalAccessory framework:

IMG_1749 - Version 4

Then goes through the SkyWire cable:

IMG_1747 - Version 2

RS232 is converted to TTL:

IMG_1752 - Version 2

Which is then sent through the XBee:

IMG_1757 - Version 2

The XBee is powered by 3.3V, using an Arduino as a simple power supply haha:

IMG_1758 - Version 2

And Dogcow receives with the XBee:

IMG_1741 - Version 2

Making this whole process really cool!

IMG_1764 - Version 2

Here are some resources that may be helpful:

Also, as per Technote #31:

Dogcows, by their nature, are not all dog, nor are they all cow, but they are a special genetic hybrid. They are rarely seen in the wild. Since dogcows are two dimensional, they will stand facing a viewer “on edge” to avoid being seen.

IMG_1736 - Version 2

:P

Posted in: Projects, Robot.

Robot Mesh Network: RoboBrrd and MANOI AGAIN!

Posted by Erin, the RobotGrrl on Saturday, May 14th, 2011

After getting the initial communication between RoboBrrd and MANOI working, I went and fixed some things and added new commands. There are still some aspects that are iffy about the communication, mainly due to timing and the part that there are at least 8 places where if something doesn’t work at the right time frame, then the whole process won’t work. With communicating information without many handshakes and checksums, it is known to not work all of the time.

I made a new video about RoboBrrd and MANOI with the commands. I like the angle used for the robots in this video, it portrays the social cue that they are talking to eachother, which they are, but in their own robotic-mesh way. :3

View it on YouTube.

RoboBrrd now has passive behaviours, which turned out to be really cute and fun. I love how passive behaviours always add so much more depth to the robot. Only problem is the sequential and timing aspect of them, sometimes they override the sensors. Also, the gurgling of the speaker can probably be fixed with a capacitor and resistor. I moved the speaker to the main board from the communication board because it wouldn’t work all of the time. It was really fishy. :/

Last week I worked really hard on RoboBrrd to try and finish something (anything!- just trying to make it work!) for the MAKE: Bots With Character contest. One night I stayed up really late trying to debug the TLC5940 PWM shift out circuit. The next day I ended up scrapping it and just using the Arduino MEGA’s PWM outputs (there are a lot of them!).

Luckily, the contest was pushed back, so I have more time to write the written tutorial. The written tutorial is getting pretty long, it is quite surprising!

The second bio-inspiration video and the design video will be next on the line. Also going to make a character overview of RoboBrrd for the contest.

I am crazy for this contest because I live, eat, breathe social robotics, and having character in your robot is an important part of that and so many people forget about it! I want to show the whole world what it would be like if robots were their own sentient species! I want to be able to get people to make their own interactive robots so that they can experiment too! It is all so super exciting with so many exclamation points!!!!!!!!

Posted in: MANOI, Projects, RoboBrrd (thx Adafruit!), Robot.

RoboBrrd is on the Mesh Network!

Posted by Erin, the RobotGrrl on Monday, May 9th, 2011

This is just a quick few sentences update to say that RoboBrrd is successfully on my robot mesh network! WOOHOO!

Had some horrible interrupt bugs that were resolved by switching out the main controller board (Arduino Diecimila 328) with an Arduino MEGA.

The communication board is spread out all over RoboBrrd’s back flap, I’m going to solder up the proto screw shield that was designated for RoboBrrd #2 and use it with this RoboBrrd #1 anyway. Since I have accidentally destroyed many servos with RoboBrrd #1, the possibility of a second RoboBrrd might not be realized.

Hopefully I will be able to show you this in action with a short video (unrelated to the tutorial series) tomorrow! :D The idea is to show RoboBrrd reacting to the PIR sensor, sending a command to the mesh network, and MANOI will be reacting to the command.

I posted some of the code and resources on Github. You can look at it, but please know that I’m going to improve it and make it a lot easier for everyone to use a little later on. :)

Next few days are going to be crazy, since I need to get RoboBrrd going to enter it into the MAKE robot competition. So much documentation of the design, circuits, and code has to be done!

BTW, I was selected for the WWDC Student Scholarship! Really excited :)

More details later!

Posted in: RoboBrrd (thx Adafruit!).

FNR – Robot Mesh Network: MANOI & IRC

Posted by Erin, the RobotGrrl on Friday, October 1st, 2010

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:

IMG_9970

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:

IMG_9971

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:

  1. 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:

  1. def readFSR(arduino):
  2.         print "MANOI Read FSR"
  3.         arduino.send(‘*’)
  4.         arduino.send(‘FSR’)
  5.         arduino.send(‘*’)
  6.         return arduino.read(4)

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

  1. if(newByte == ‘*’) {
  2.                
  3.                 byte byteIn = 0;
  4.                
  5.                 // Getting the command details
  6.                 while (byteIn != ‘*’) {
  7.                         byteIn = nextByte();
  8.                         msg[it] = byteIn;
  9.                         it++;
  10.                 }
  11.                
  12.                 // Checking to see if we received the message
  13.                 // and seeing how long it is
  14.                 if(it>0) {
  15.                         receivedMessage = true;
  16.                         messageLength = it-1;
  17.                         //analogWrite(greenR2, 255);
  18.                 }
  19.                                
  20.                 if(receivedMessage == true && messageLength == 3) {
  21.                        
  22.                         validCmd = true;
  23.                         ii = 0;
  24.                        
  25.                         // Check each letter to see if it’s right
  26.                         while(validCmd && ii<messageLength) {
  27.                                 if(msg[ii] != fsrCmd[ii]) {
  28.                                         validCmd = false;
  29.                                 }
  30.                                 ii++;
  31.                         }
  32.                        
  33.                         // If it is right, do the command
  34.                         if(validCmd) {
  35.                                 readFSR(false, true);
  36.                         }
  37.                        
  38.                 }
  39. }

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!

  1. byte nextByte() {
  2.        
  3.     while(1) {
  4.                 if(Serial.available() > 0) {
  5.                         byte b =  Serial.read();
  6.                         return b;
  7.                 }              
  8.     }
  9.  
  10. }

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:

  1. def danceCmd(arduino, args):
  2.         print "Dance Command"
  3.         arduino.send(‘%’)
  4.         arduino.send(args[0]) #bajngl
  5.         arduino.send(‘%’)
  6.         #r = arduino.read((7*19) + 3)
  7.         #print r
  8.         arduino.flush()
  9.         arduino.flushInput()
  10.         return arduino.read(4)

Arduino:

  1. // Pre programmed moves command
  2.         } else if(newByte == ‘%’) {
  3.                
  4.                 byte byteIn = 0;
  5.                
  6.                 // Getting the command details
  7.                 while (byteIn != ‘%’) {
  8.                         byteIn = nextByte();
  9.                         msg[it] = byteIn;
  10.                         it++;
  11.                 }
  12.                
  13.                 // Checking to see if we received the message
  14.                 // and seeing how long it is
  15.                 if(it>0) {
  16.                         receivedMessage = true;
  17.                         messageLength = it-1;
  18.                 }
  19.                
  20.                 if(receivedMessage == true && messageLength == 6) {
  21.                        
  22.                         validCmd = true;
  23.                         ii = 0;
  24.                        
  25.                         // Check each letter to see if it’s right
  26.                         while(validCmd && ii<messageLength) {
  27.                                 if(msg[ii] != bothArmJngl[ii]) {
  28.                                         validCmd = false;
  29.                                 }
  30.                                 ii++;
  31.                         }
  32.                        
  33.                         // If it is right, do the command
  34.                         if(validCmd) {
  35.                                 Serial << "okay";
  36.                                 bothArmJingle(1);
  37.                                 Serial.flush();
  38.                                 Serial2.flush();
  39.                         }
  40.                                                
  41.                 }
  42.                
  43.         }

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. :P 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:

Click to download MANOI_awareness v01 pde

Here’s the link to the Python code:

Click to download Arduino IRC v01 py

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

IMG_9975


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

Posted in: MANOI, Programming, Projects, Robot.

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:

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.

IMG_9945 - Version 2

The transmitter node looks like this:

IMG_9911

Which is attached to the computer running a Processing sketch:

IMG_9912

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:

@RobotGrrlsBots RBGLYPH | RGB | RGB | RGB | *

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:

IMG_9946 - Version 2

IMG_9928

And this is it working!

IMG_9917

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:

IMG_9943 - Version 2

IMG_9913

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!


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

Posted in: Programming, Projects, Robot.

Friday (Sunday) Night Robotics – XBEES!

Posted by Erin, the RobotGrrl on Sunday, May 10th, 2009

This Friday (Sunday) I decided to put together the two XBee Kits that we got for Autonomous Robotics Club (ARC). Since its summer and the rest of the members are going to be busy, I get to be able to play with these all summer long!

Look at all the stuff!

FNR (XBees)

XBees are familiar to me- I used them for a project a few months ago. That was so long ago that the XBee Kits used to be GREEN and not BLUE! :P

Everything was going really nicely, all of the soldering was perfect. Until I tried to plug the XBee in… it wouldn’t plug in. (?!?!!?!?!?!) I took the plastic part of the header off, check out what I found:

FNR (XBees)

BLERG! I finally got the solder removed, but then when I was putting the plastic header back on, I noticed that there was a metal header missing! I found it on the desk, and I was trying to solder it back into place. This is how small the header is:

FNR (XBees)

Another one came loose… here, you can see this:

FNR (XBees)

I decided to just try putting the plastic back on and seeing if it worked anyway. Evidently, that was not possible to:

FNR (XBees)

Even further ridiculousness:

FNR (XBees)

BLERG! It’s amazing how devilish these headers can be. In any case, I’m going to go to the electronics store and pick up some headers and parts for RoboGlyphs tomorrow.

In any case, the 2nd XBee Kit was great! :D

FNR (XBees)

(I also have the quadratic formula on a stickie, on my laptop. LOL!)

What will I use these for? I’m thinking that I will want to make a communication between BubbleBoy and MANOI. However, BubbleBoy (who would be ‘hard of hearing’) will seldom understand what MANOI ‘says’. I’m not entirely sure if I want to do this with math, or just easy programming. :)

Upcoming blog posts:
- iPhone Info Button Tutorial
- MANOI’s Inner Workings (a series of posts)
- RoboGlyphs

Also, I totally believe that Adafruit is copying my FNR tradition. ;) Hahahaha

Posted in: Projects, Robot.