The messages are sent from a UART, and received by a NewSoftSerial implementation. I had a hard time trying to get anything being sent from a NewSoftSerial to be received by NewSoftSerial. Once I finally realized this, it started to come together.

Here is a video explaining the success that I finally had, it was so amazing!

I will be blogging more about this later, with extended details of the problems that I ran into, and how I overcame them. Right now I am trying to make my Macbook triple boot. If you haven’t done it before, it’s a long trial and error process! I also started mentoring some FIRST teams in Montreal! The build season is quickly approaching! Woot!

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!

I recently ‘inherited’ an iRobot Create. It’s a Roomba, but without a vacuum, and made specifically for hobby robotics.

Getting it to work with an Arduino was excruciatingly hard at first. It does come with a controller on board, but the instructions for that were more sparse than just using plain serial commands. Or, maybe I misread them and they are the same things…

In any case, I used the DIN connector to connect to the Arduino so that it can send and receive commands, as well as be powered by the iRobot!

Sending commands to the iRobot is interesting… you start off with a number from -500 to 500 in mm/s, then…
1. Take the absolute value
2. Convert this to a hexadecimal number
3. Split the hex into two
4. Add a sign bit infront of the first part
5. Convert the two parts into bytes

This works very well for 500 mm/s and -500 mm/s.

However, when trying it with -100mm/s and 100mm/s, the -100mm/s goes faster than the 100mm/s!

I believe this is the code where we got the -100mm/s to be almost the same, even though it made no mathematical sense…

The only thing we can think of is that the gearing of the wheels is different for driving backwards.

We’re going to keep playing with it, next time we’ll be seeing if we can get some sensor data from the bump and IR sensors!

Building up the RBBB wasn’t too hard. At first, I printed off the wrong ‘instructions’ – which mind boggled me a bit until I noticed that they were indeed wrong. Once I had the right instructions printed… it was more simple. I was worried about the polarity of the bigger capacitors. After I had it all finished… I went and looked up the FTDI-USB cable specs. This cable is pretty interesting if you think about it, 1 wire turns into 6 more colourful wires -Gnd, CTS (clear to send), +5V, TX, RX, RTS (request to send). I downloaded the Blink program without any problems… until I wanted to test it. The LED wasn’t blinking! After about 5 minutes of intense thought, I realized that there was no LED on pin 13. That was a stupid mistake!

Another stupid mistake, but this one is funnier, was when I was trying to test the other RBBB.
… I forgot to put the chip into the IC socket. =D That really made me ‘lol’ for 10 minutes.

Then, I was trying to fit it into the breadboard… lets just say it took a longer than normal time.

When the Pololu SSCs showed up, I was pretty excited! Then when I saw them… they are REALLY tiny! It was a big challenge to solder these without them flying out of my hand. I don’t have a 3rd hand tool to hold it steady, so I would sometimes have to hold the ‘pinchy-things’ with my elbow and hold the solder and soldering iron with my hands. The headers were extremely difficult too…

Getting the Pololu to work with the Arduino is pretty aggrivating. I think I’m almost there, I just have to switch the input to the logic level side as I was using the RS-232 one. I thought that the Arduino used RS-232 on its TX line, but it doesn’t. It uses a non-inverted logic level (er well, that’s at least what I read). Tomorrow I plan on looking up the difference between the two

Here are some pictures… I finally threw the desoldering pump out the window (joking) and bought solder wick. Also finally bought NON-LEAD SOLDER! =D

Other than playing with these, I’ve been flow-charting A LOT of AI programs, and learning more first-order predicate logic. I really like logic and the probabilities and Bayes and everything!!!!! Also having fun thinking about random and bell curves… More back-dated Stanford blog posts to come (so many photos hahah)!