Project Flying Robot: The Flying Dorkboard

As we proceeded along with our flying_robot project, one thing became abundantly clear: weight matters. The Arduino Diecimilla that we had been using up to this point, although a fine package for beginners, was just not going to make it when it came time to weigh in. Yes, there is the Arduino Nano, but it is not a cheap device. Also, it has a few options that were not important to us, like the integrated USB, since we planned on only using XBee based communication with the blimp.

I had been doing some research, and have learned a lot more about this whole Arduino ecosystem. There is incredible work being done by people like ladyada, and many others too numerous to list here. There are many variations on the Arduino, like the Boarduino, Sanguino, and so many others.

However, one option in particular caught my attention, called the Dorkboard. This thing is small, I mean tiny. Especially considering that it does not use the surface mount version of the ATMega microcontroller. And it has almost nothing on the board itself. You need to provide both power, and an interface to communicate with it, in our case, using the XBee modems.

This highly stripped down, minimalist approach was exactly what we had been looking for! Cheap, simple, light, and having everything that one needs from any Arduino/Freeduino platform. I ordered a few of the kits, and they were shipped from Wulfden just a few days later.

Once they came in, my brother was eager to get right into one. I dropped off the package, and he had soldered up one, plus the power supply, in less then an hour. We had the USB-BUB interface, so we just plugged it in. Once we had all the cable pinout correct, and we had downloaded the "hello, LED" code from RAD, we were watching it flash under our command.

The brain of our flying robot was ready! Now we needed a way to communicate with it, and update its code, all wirelessly. The next step, would be building an XBee breakout board, and doing some XBee hardware/firmware hacking...

RailsConf 2009 Program Is Looking Juicy

I just noticed that there are already a whole bunch of the approved presentations for RailsConf 2009 on up the web site here.

It is looking really good already, go check it out. If you are into Ruby on Rails, you really should be going... I am!

Project Flying Robot: A Compass, Two Motors, And A Servo

Last weekend was a fantastic hardware/software jam session with my brother Damen, working on our autonomous Ruby Arduino Development (RAD) powered blimp. Lots of little pieces had been coming in the mail, my brother had been soldering, and I had been programming away. Both of us were eager to start putting it all together.

The first item of business was getting our bearings. We had acquired from Sparkfun a very cool HMC6352 digital compass module. Based on the Honeywell chip, this tiny but powerful breakout board is a very easy device to use with Arduino, thanks to supporting the i2c protocol, also known as "two-wire interface" or TWI. No one had created a RAD plugin yet for this device, so I had whipped one together a couple days earlier using some Arduino code I found online, combining with the techniques used in some of the examples in RAD. Now, finally I would get a chance to see if it would work.

We plugged in the unit to our handy breadboarding setup, downloaded the code to the Arduino via USB cable, and viola! Amazingly, it worked perfectly the first time... we were able to obtain the heading, and turning around the unit resulted in the compass data updating correctly. Naturally, we started to get a little excited.

Of course, things would get a little bit trickier with our next item for integration: the Pololu Micro Dual Serial Controller. The pricey but useful Pololu chip allows for extremely simple serial command of 2 DC motors. Why would we want to do this, when we already have the Arduino itself? The ease of commanding a separate device that handles monitoring and setting the motor speeds, allows us to focus on the important parts of our application: integrating it all together. Plus, there is only so much processing power available in the ATMega microcontroller, so offloading that part of the work to the separate Pololu microcontroller frees up our Arduino to process more sensor inputs, and also do other interesting things we have planned.

Since the Pololu is a serial device, we used the Arduino's AFSoftSerial library to communicate with it. The soft serial library allows you to use any 2 of the Arduino's digital pins as a serial interface. Support is already in RAD for this library. With some more Google searching, and some assistance from the Pololu forums, I had written another RAD plugin. A few moments for Damen to wire things up, and we were ready for our test. We had only wired up one motor, and we had used the Arduino's own power to power both the Pololu's logic chip, as well as the motor. That would turn out to not be a very good idea.

The Pololu works by sending it simple serial commands. You tell it which of the two motors, which direction, and what speed to set it to. We fired things up set our motor to "forward speed 10" and it started to move. Glorious! So, overwhelmed with enthusiasm, we decided to try "20". Much to our surprise, setting the speed to 20 caused the motor to stop entirely. Say what? We looked at each other blankly.

You simply cannot power both the Arduino, and the motors, from the same power, unless you do some additional circuitry to provide both the higher voltage that the motors want, along with the 5V that the Arduino desires. Once we had thought about it for a few moments, it seemed obvious. We switched the motor supply to a separate battery, and the motor performed at 20. "Let's try full power", I said, and with a nod from my brother, I boosted the power to maximum. "Hey!" we both exclaimed at once a second later, as Damen grabbed for the now flying motor, which was trying it's best to lift the breadboard up by its power leads, and I frantically typed the commands that would shut down the motor. I wish we had THAT on video!

We then decided to keep going, and integrate our servo. The servo is used to change the vector of the thrust motors, a design that is also used by the Blimpduino. Unlike the main thrusters, we are just using the Arduino itself to control the servo motor, using one of the digital pins. It is really easy to use the servo library to move a servo to a particular position. In this case, no new plugin for RAD was required, cause others have already figured it all our for us. Which is nice.

We made the same mistake of connecting our servo to the same battery as the Arduino itself, due to the fact that the servo wanted the same voltage. By this point in the day, the poor thing just didn't have the force left in it. This caused the very odd side effect of resetting the Arduino itself when the servo would be ordered to move. We only realized that was what it was, once we tried getting power from the USB port. We had been testing using our wireless XBee modems. Once the power problem was solved, the servo did exactly what we told it.

It was a tremendous session, and we were now very satisfied that this project was, ahem, going to fly.

Prepare For The RailsConf 2009 Jam Session

I will be running the music BOF at RailsConf 2009 in Las Vegas. What does that mean? We're gonna get down. All styles will be represented, so if you have an instrument or a voice, bring it.

We have a Google group started here.

So Long, And Thanks For All The SSH

I read Jamis Buck's posting late last night, about how he was retiring from involvement with Capistrano, Net:SSH and a few other closely related projects. First of all, the community owes him a lot for doing so much work on these crucial parts of the Ruby on Rails ecosystem.

Seems like he has fallen victim to his own project's popularity. So many people using your code, and they start to expect things, and then demand them. I have seen friends in the Ruby community who are committers on a very popular tool, pretty much accosted at a conference, by fervent users of their project, who proceed to drag them off to the side to show them some obscure edge case. And like any good public servant, they go off to see whatever it is, regardless of whatever they were planning on doing the moment before.

Jamis was for sure getting burned out. I know that from personal experience, when programming pal Ari Lerner and I worked some patches for Net:SSH that solved a longstanding problem for public key authentication. Our first discovery on cloning the repo was that the original commit did not actually pass all of the unit tests. Then once we had corrected both that, and the original issue, and we contacted Jamis, he was pretty ambivalent. I am not knocking him here. Eventually, he accepted the patches. I think it was more that he had just had it with being a slave to his own creation.

Now we are on own, people. However, there does need to be some organization to the community. Github allows anyone to fork a project, sure. But having 25 different versions of the same project wandering around is too confusing for most people. New users would not know which version to install, the beauty of the standardization would be lost.

Jamis, you need to pick a successor to inherit the main responsibility for these projects, if for no other reason than this. Anyhow, we thank you again for all your efforts, and we look forward to seeing what you get into next.

Frankie Gets Some Fixes

It has been very overdue to get Frankie updated to work with the latest versions of Sinatra and Facebooker.

But where I have been lagging, mjfreshyfresh has stepped up, and submitted a patch that gives compatibility with Sinatra 0.9.x and Facebooker 1.0.2. Thanks, my main man!

The Frankie gem has been updated to version 0.3, and it is available at your convenience. Note that you really do appear to need the 1.0.2 version of Facebooker for this release. Make sure you install facebooker using -v=1.0.2 to get only that version.

Let's all go huge on Facebook!

Project Flying Robot: Getting All XBee With It

We have been making some amazing progress on our flying_robot project. This post is actually from almost a week ago, but I have not had time to catch up blogging with what we have been getting accomplished.

As I had mentioned in my first posting, one of the reasons that we did not simply copy the Blimpduino, is that we do not want to use a standard R/C controller for manual control. No, that would be too easy. Actually, it is because we have other kinds of ground control in mind... but I will get into that in future posts, once we have a working vehicle.

One focus of our project is to create a fully digital protocol to communicate wirelessly with UAV's. Something like MIDI is to music, the flying_robot command set is to flying. In other words, flying_robot is intended to provide a device-independent way to communicate with various kinds of unmanned aerial vehicles. So we started looking at digital wireless solutions. WiFi is common, but does not have the range, plus it uses too much power. Bluetooth just lacks range, period. Sounds like a job for XBee to me.

If you have not heard of it, XBee is a wireless data standard that has several priorities: it must have good range, use very low power, and be very cheap. The internet of things will likely be connected via XBee, since it it ideal for low-cost devices that wish to communicate with each other.

XBee modems come in several different flavors, depending on the needed range and desired type of network topology. The simplest version supports the 802.15.4 protocol, which is probably best for most point to point type applications, like a ground control to a base station. This is what they sometimes refer to as the "Series 1" modems.

The ZigBee modems, also sometimes called Series 2, add a protocol for mesh networking that looks to be very interesting. It could be used for a swarm of robots that communicate with each other, not just with a base station. This appealed to my inner geek, and so I ordered two of these modems, with the intention of experimenting with mesh networking in the near future.

On that note, there is an amazing deal right now for experimenters directly from Digi. You can get a development kit for the super-powerful next-generation XBee 868, that includes a pair of the modems, for only $99. I could not resist, and just ordered a pair of these to play around with, as well as the XBee-Pro 2.5's I already had acquired from SparkFun.

One thing I discovered quickly, was that the XBee modems I had purchased are really small. The next, was that I had to do some additional programming on them, before they would talk to each other. I found a useful Ruby script for configuring XBee modems from madrona, but it turned out to be a little more complicated, due to my choice of ZigBee over the simpler 802.15.4 protocol.

Fortunately, others have already been blazing this wireless trail, so I found these recent instructions on the Liquidware blog. It turns out that when dealing with ZigBee, one of the modems needs to be designated the "coordinator" for all the others in that mesh network, to hand out the all-important MY addresses. The coordinator needs different firmware than the individual nodes, which requires a utility provided by Digi, which is Windows only. Without this firmware on one of the modems in your mesh, you can send as many AT command as you like, the modems will never talk to each other. I dusted off a VM, and installed the Digi utility. Once I had updated the firmware, and updated the configurations of each modem using madrona's script, I was ready to go.

With one XBee modem plugged into my Mac via the USB port thanks to the XBee Explorer adapter, and the other plugged into the Arduino via the XBee Shield from Sparkfun, serial communication "just worked". Now I was ready to start coding on the Arduino itself... but that is another story.

Should We Call It Mails, or Rurb? Yahuda Katz Clears Things Up At The LA Ruby Meetup

We just had a fun time at the latest LA Ruby Meetup, once again at UCLA. This time, we had presentations by James Foster from Gemstone, and Yehuda Katz from Engine Yard.

James Foster was showing MagLev, which is a Ruby VM based on top of the Gemstone Smalltalk VM. Not much to see here, just some Ruby code benchmarks running at about 4-5X faster than Ruby 1.8.6. That is, of course, not a very fair comparison, but no question that this is another Ruby VM to watch. His talk ended with the ever popular demo showing how Seaside does continuations, plus running the Smalltalk class browser right in the web browser and editing some code. Yes, this does kick serious butt, but it would be nice to see something new from the SmallTalk universe. I've seen all this from them two years ago, thanks to Avi Bryant.

The second presentation was where things got a lot more interesting. Yehuda Katz is well known to hard-core developers, thanks to his work on jQuery and Merb. He has also been very vocal about his differences of philosophy with the Rails way of doing things. Given the fairly recent announcement of the Merb project merging with the Ruby on Rails project, we all wanted to know, like, what's up?

As explanation, Yehuda gave a really complete history of Ruby on Rails. He showed slides of DHH's first Mac, he had dates and times of the first SVN commits for Rails. He explained the back story of what was going on in DHH's life while he was creating the first version of Rails. This was all ostensibly to justify that Ruby on Rails and Merb started with the same sort of motivations.

OK, great. That was fun. But what about the real dirt? He did not say anything directly, but my take on it was: when you really look at it, Merb was already turning into Rails++ so why not just merge all that effort into Rails itself? Putting too much emphasis into a separate framework also did not help sell services to the million Rails users out there, which is what Engine Yard's investors need them to be doing.

Yehuda was obviously comfortable with it, even thou he quipped about how many times he said "No!" when first presented with the concept of the great merge. But Merb seems to have the implementation, and Rails the sugar, plus the momentum, so your peanut butter is now in my chocolate. And the big winner? Has to be Rack, or the "Unix of web servers" as Yehuda called it.

Personally, I think it sounds great. Adding some API rigor to Rails will make it a lot more stable of platform for long-term development. And let us not forget that ezmobius has been contributing performance improvements back into Rails for a long time, so nothing shocking there. Just more good stuff for the Ruby web development community.

Project Flying Robot: The Adventure Begins

I love robots. OK, there, I've gone and gotten that out into the open. Like many programmers, I have long dreamed of dominating the world with my robot legions. Or failing that, at least getting my RoboSapien to walk around in a little circle by itself.

Recently, my brother Damen Evans and I decided that we needed to realize our ambitions, and began work on a flying robot. Yes, that is what I said. Flying robot. After many years of respective obsessions about Lighter Than Air (LTA) vehicles and autonomous control, we are combining our forces and actually building something.

The "Rogue 1", as we are calling the airship, is heavily influenced (pun only, hopefully) by the very cool Blimpduino project. It will be controlled by an Arduino based system, like the Blimpduino. However, our focus is a bit different, which is why we are building our own hardware design, although also based on the open source Arduino hardware platform.

One major concept that we are working on, is creating a digital protocol for controlling the airship from a ground station. Where the Blimpduino uses a standard radio control setup, we are creating a fully digital protocol for Unmanned Aerial Vehicles (UAV) similar to what MIDI does for music. For example, an LTA vehicle would have a different way to perform a command like "rudder left 10 degrees" than an airplane or helicopter would. Especially since neither an LTA nor a helicopter even have rudders!

We have decided to use the Ruby Arduino Development (RAD) project for creating the software needed for flying_robot. It is still a bit rough in some ways, but it allows us to take advantage of a slick Ruby DSL-like approach for implementing the flying_robot command set for a specific UAV, as well as for integrating a bunch of the hardware we will be needing, like motors and sensors.

As the many small parts come in, both Damen and I will be blogging about the fun, so watch the skies... they're already here!

JSON-P Makes Progress Cross Domains With Apache, Passenger, and jQuery

As yet another part of the be-all, end-all media upload processing solution, my client wanted to provide a nice progress bar for tracking the status of file uploads. Let me note, that providing user feedback as to the state of an extended upload turns out to be a very important UI feature.

Luckily, the problem of a nice way to track file upload progress had already been solved several times. My own platform of choice at the moment is Apache running with Passenger, and cool dude Peter Sarnacki aka drogomir had kindly provided a handy version of the same JSON based file upload progress tracking that had been done so well on nginx, except this time for Apache in the form of apache-upload-progress-module. He even had created a jquery-upload-progress plugin too, which is exactly what I needed.

Only one small problem... those pesky cross-domain javascript calls. As in, browsers do not as a rule, allow them. Then again, browsers do turn out to know how to be promiscuous. Which is to say, execute arbitrary JavaScript code handed to them by strange servers. Say wha? Yes, that is correct.

Enter JSON-P, which is the JavaScript Object Notation you know and love, with an extra layer of "Padding". What does the P in JSON do? Sorry, I could not resist that. Anyhow, the padding consists of a special temporary javascript function created just to handle the data callback from a server that is not in the same domain as the calling server.

Here is an example from our need for upload progress tracking. A normal JSON request to the upload component, like this:

   http://www.yourdomain.com/progress?X-Progress-ID=1234

Would return JSON data like this:

   new Object({ 'state' : 'uploading', 'received' : 35587, 'size' : 716595, 'speed' : 35587 })

But if we are using JSON-P, the request would include the name of the 'magic' callback function, so that the data returned from the cross-domain request is available to the original calling page, even though it is in a different domain, or even just subdomain.

For example, this request:

   http://uploads.yourdomain.com/progress?callback=jsonp123&X-Progress-ID=1234

Would return the JSON-P function:

   jsonp123(new Object({ 'state' : 'uploading', 'received' : 35587, 'size' : 716595, 'speed' : 35587 }));

The calling page executes the 'jsonp123' function after the data is returned from the cross-domain request, and then the returned data is available to scripts on the original page. This is how Twitter and other Javascript API's are able to function with these cross-domain requests.

So I whipped up patches for each the apache-progress-module, and the jquery progress plugin, and now that drogomir has accepted them, we can all enjoy the benefits of cross-domain uploads, along with JSON-P powered shiny progress indicators. Well, as long as it is a jquery based progress indicator you seek. I will try to get around to looking at the Prototype progress plugin, but since I am mostly working with jquery now, perhaps someone else will jump into the fray.

Have fun, and make some progress.

Introducing Net Grommit

I have just begun a new blog called Net Grommit.

It is a place that I can go off and explore my experiences with technology and being a 21st century parent. I will get into anything from video games, kids programming, tech toys, education, and whatever else appeals to me. As a father of two boys, and an obsessive technologist, I have plenty of personal experience to talk about, and I really look forward to the participation of some other people, as well.

So, if you are a parent, or just find this as interesting as I do, please come over and join me at Net Grommit.

And now, back to our irregularly scheduled programming topics.