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: Getting RAD With The ATMega328

I have been wanting to upgrade the hardware used in our Dorkboards for flying_robot, from the ATMega168, to the newer better faster ATMega328. More memory, and a faster UART for serial communications with the XBee modems in the same pinout = easy win. Thanks to a quick shipping turnaround from @adafruit I got them in before the weekend, so I could play a little bit today.

The first step was to upgrade my hard-working Arduino Diecimila to a 328. I now have it working great with Ruby Arduino Development (RAD), but since RAD was really setup for Arduino 12, I had to make a couple changes. Here is what I did:

1. D/l and install Arduino 15 (brave, I know, since that is the latest release, and many people run one version down from the latest)
2. Change my hardware.yml entry

mcu: atmega328p

3. Change my software.yml entry

arduino_root: /Applications/arduino-0015

4. Lastly, since the ATMega328 bootloader runs at a faster rate, I had to tweak the RAD code itself to support it. The file "/vendors/rad/generators/makefile/makefile.erb" is the template used to create the makefile that compiles and uploads the code to the Arduino. Line 77 in that file controls the baud rate, which needs to be set like this for the '328:

UPLOAD_RATE = 57600

Once I had done this, I was easily and quickly able to recompile/re-upload the latest flying_robot code to my test board. Yeah! Hopefully tomorrow I can upgrade Rogue 1 and try a flight at the new, higher communication speed.

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: By Your Command

Our flying_robot project for Unmanned Aerial Vehicles has been underway for a few weeks now. Much soldering, and playing around with cool Arduino tricks has been taking place. You can read more here, here, here, and here if you need to catch up.

One aspect that I have mentioned several times, but not gotten into much detail about, is our protocol for communicating with the UAV from the ground station. It is amazing to me, but there is still no dominant digital protocol for controlling UAV's. Many people are this using analog radio controllers, with some kind of sideband channel for autopilot commands.

There are a few characteristics that seem essential to me for a proper ground control system design:

• A nice way to send control stick commands from a "virtual r/c" that can be used with any UAV


• Consistent way to send autopilot commands


• A way to be able to read the instruments remotely, and display them as part of your "control surface"

Another observation I have, is that there is every current Arduino UAV project has an entirely different code base. There also does not seem to be any practical way for these projects to share much, even though they are all targeting the same microcontroller.

Certain characteristics seem essential for developing on-board UAV system programming, but are lacking in any of the projects I was able to find:

• A nice, modular way to put together the pieces you need in software that match the hardware configuration for that particular vehicle


• A high-level domain specific language (DSL) to specify the UAV's behavior, and not just programming in C++ or assembly language


• A consistent programming interface that corresponds to the protocol used by various ground controllers

With all of these design criteria in mind, I have been implementing the flying_robot command parser and interface. Here is an example of the minimum code required to create a UAV using the current implementation:



As you can tell, there is not all that much to it. The base for a UAV in 34 lines of code.

The most current code for the actual "Rogue 1" LTA vehicle is being committed to http://github.com/deadprogrammer/flying_robot_rogue_one/tree/master if you want to follow along with our progress.

Next post, we test the main thrusters and vectoring controllers, and nearly start a fire...

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

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!