Getting Ready For Takeoff At FutureRuby

I just realized it has been an entire month since my last post. Sorry! In case you were wondering, the always overambitious plans for Project Flying Robot have taken up more time than expected. And parts. Especially parts.

Lucky for us, the benefit of a hard deadline approaches: FutureRuby is coming up next week. My brother Damen Evans and I are going to be showing off our latest works in Unmanned Aerial Vehicles (UAV) based on Ruby Arduino Development (RAD). I don't want to let on too much, so as to eliminate the surprise element, but this should be our biggest spectacle yet.

So if you're going to be in Canada next week, we look forward to seeing you. If not, I'm sure there will be plenty of video to watch in either amazement or amusement, depending on how well we can pull this off...

Project Flying Robot: Supporting The Blimpduino

As Maker Faire approached, my brother Damen and I were very busy working on something cool: support for the now-shipping Blimpduino kit!

Thanks to the tireless efforts of Chris Anderson and Jordi Muñoz, the long awaited Blimpduino kit is now shipping at Makershed. As readers of this blog know, we have drawn a lot of inspiration from the Blimpduino. Now, we actually have 2 of them, and you can get your own. For less than $100, plus a few other items, and flying_robot software of course, you have everything you need for a complete experimenters kit for Unmanned Aerial Vehicles at home.

There are a few mods you need to make to your Blimpduino, if you want to be cool like us, and control/reprogram it using a linked pair of XBee modems. We will post complete directions soon on how to mod your blimpduino into a flying_robot using Ruby Arduino Development.

In the meantime, you can look at the almost completed flying_robot for Blimpduino code here.

Project Flying Robot: I Believe I Can Fly

At long last, after many obstacles to be surmounted, yesterday we achieved liftoff. The blimp prototype "Rogue 1" of our flying_robot project to create a platform for Ruby Arduino Development powered Unmanned Aerial Vehicles has achieved an important milestone.

After our third complete rewiring of the main circuit board, two burned out Pololu micro serial motor controllers, some time reviewing the schematics of the Blimpduino project, and too many revisions to the basic software to list here, we had finally gotten everything ready for what would hopefully be a successful flight test.

There were some major limitations to this test, which was mostly intended to verify proper functioning and integration of the hardware. Happening inside my brother's small apartment, we would not be able to really do much flying. Also, we were going to measure our maximum payload capacity, but not really planning on balancing the blimp to achieve a proper neutral buoyancy.

The final assembly took place, we did a quick flight check, and you can see for yourself the results in this poorly shot and edited, but somehow still amusing video.

Now, this thing is really starting to take off!

Project Flying Robot: Better To Burn Out Than Fade Away?

We had made incredible strides forward in our construction of "Rogue 1" our autonomous blimp that we are building as the first implementation of flying_robot, our Arduino-framework for Unmanned Aerial Vehicles based on top of Ruby Arduino Development (RAD). We are also heavily influenced by the cool Blimpduino project. We were finally ready for a live test... or so we thought. We inflated our envelope, and my brother attached the gondola that he has been carefully constructing.

We had already done some testing of the software/hardware, so we were heady with our previous successes. "Let 'er rip," said Damen. Next thing you know, the blimp was careening about, as the motors pulsed wildly out of control, then stopped abruptly. "That is not a good sign from an electric motor controller, " said my brother glumly.

We peeled the gondola off the envelope, and disassembled the components that had been connected so carefully, and yet not carefully enough. Multimeter in hand, Damen carefully traced each connection looking for power as I entered the commands into the serial interface.

Finally, after a few moments we looked at each other. There was one more test... we rewired everything properly, but using the spare Pololu Micro Dual Serial Controller and a breadboard. I entered the commands and the motors powered up. Now there was only one conclusion: we had fried our costly little Pololu.

Ouch! After spending a while on post-mortem analysis of our dead little bird, Damen muttered something about power. "Huh?" I looked up from debugging the Arduino code for the differential thrust calculations.

"Power. We need less power."

"Less power? I thought the specs said that controller was rated for more than our LiPo battery and more?"

"Specs lie."

I had to acknowledge the simple truth of that statement, especially given the obviously dead chip. With a lot more knowledge about our bimps power requirements, learned the hard way, Damen began planning the third iteration of our main board wiring, with a new extra power regulator. And an external kill switch.

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.

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.

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!