The Twitter 1-2-3 Rule

I just had a small realization: there is a perfect ratio for Twitter use. Wait, before you laugh and hit the back button, hear me out on the following idea.

There is an emergent trend in optimal Twitter use:

If you have X followers,
You should have 2X people that YOU follow
And have made 3X updates

Get it? Twitter 1-2-3. Nice simple rule...

Here is what is means if these ratios are out of whack:

• Less then 2X people that you follow = who do you think you are, Shaq?


• More than 2X people that you follow = perhaps you should do something besides Twitter?


• Less then 3X updates = why are so many people following you?


• More than 3x updates = you really like to listen to yourself, don't you?

Let's Celebrate The Female Side Of Tech

It is Ada Lovelace Day today, and to support the women in technology, bloggers all over the world are celebrating the female side of tech. What do I mean? You may not know it from the throngs of hairy guys at tech events, but not only are there women in tech, they have done a lot to make YOUR life easier. Let's review a couple current ladies of technology that have been rocking my world.

First of all, no mention of modern geek tech can even begin without another Ladyada, aka Limor Fried. As the proprietor of Adafruit, she has done a lot to make physical computing with Arduino and other cool hardware a lot more accessible for novices, as well as helping out pros when they are stuck. As as engineer and MIT alumni, she is a great leader in the electronics community. We could not have made the progress we have on the flying_robot project, without her great hardware and helpful blogging.

Another female developer I know is Andrea O.K. Wright. Andrea is a very serious Rubyist, and did a really great talk on Ruby in gaming that I attended a while back. She was even kind enough to remember to send me a couple links to some of the tech she had mentioned in the presentation.

We smelly guys have to be be a bit more welcoming to the women of tech. Why? Not even for any of the standard reasons related to social progressivism. Simply enough, we all need all the help we can get, and not encouraging women to explore their interests in technology, is like losing 50% of the potential advancement we could be collectively making.

'Nuff Said!

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!

Come Fly With Us At Los Angeles RubyConf 2009

Yes, the rumors are true, our talk for LARubyConf was accepted. If you want to see the first ever public live demonstration of flying_robot, the real thing, actually flying around and such, come check it out live and direct at the first Los Angeles Ruby Conference on April 4.

I do yet not know exactly what our demo will include, but from what we have been doing so far in the lab, you won't want to miss this one. Unless what you get to witness is massive fail. Either way, it will be spectacular.

Not to mention, there are some really excellent presentations happening. Actually useful stuff you might put into daily practice. We're talking shining beacons of the Ruby community like Jim Weirich, Jeremy Evans, Aaron Patterson, Daniel Philpott, Dan Yoder, my boys Ari Lerner & Michael Fairchild, and many, many more. So if you have not registered yet, get with it!

Click here RIGHT NOW and register for LARubyConf. Do it!

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

Playing With Hoops, or Every Step You Take

I do not often pay full attention to Giles Bowkett. That is the flip side of being the provocateur that he is, some people will occasionally tune out. However, when anyone plays the Steve Krug card, I am compelled to take a look.

Yesterday, Giles posted a dead-on point about user registration, called "I Don't Care About Your Hoops". When you compare the success of simplicity, as in the Google and Apple examples, to what we all tend to fall into, I hope you are as embarrassed as I was. Time for some self-examination.

I was ready to hack down the user signup process to size. Here are my new rules:

• 4 or more registration steps = FAIL


• 3 registration steps = A long shot, but you might make it


• 2 registration steps = At the top of the key, worth taking a shot, but no sure thing


• 1 registration step = A free throw, you should easily sink it


• 0 registration steps = Slamdunk ala Michael Jordan. Ain't no stopping us now.