kwc.org Photos Spare Cycles MythBusters

May 31, 2012

ROSCon 2012: Lightning Talks

ROSCon 2012 was a blast! Thanks to everyone who attended. It was a bit mindblowing to me to see something I've worked on reach the '-Con' Achievement Unlock.

January 7, 2012

Man Hands: Galaxy Nexus vs. iPhone 4S

nexus_iphone4.jpg

Any review of the Galaxy Nexus will note that it's huge. I like it. I'm 6'2" and this phone is great: it's much easier to type on and I can see much more content.

In the photo above I'm holding the Galaxy Nexus and my wife is holding her iPhone 4S. My phone is smaller relative to my hand, which leads me to conclude either:

a. The iPhone is too small for me
b. The iPhone is too big for her

She says (b), as she can't fully use the phone one-handed. I can use my Galaxy Nexus just fine, so it seems (a) and (b) are both true. Regardless, anyone who argues that the 3.5" is ideal must have ideal hands.

I was going to write a Galaxy Nexus review, but got distracted by the previous post. I fear that two posts in one month is all I can manage right now

Why Android is Better Off

I think this John Gruber quote on Siri explains why I use Android:

"...the whole thing still isn't up to Apple's usual level of fit and finish, not by a long shot. But I'm still glad it's there. I think the iPhone 4S is better off with Siri in its current state than it would be if Apple had waited until Siri was further along to release it."

If I had to distinguish between Google/Android and Apple/iOS, it's that each company decides differently whether or not a new feature is "ready" to put in.

Apple typically denies a new feature/product is necessary, secretly works on it for a very long time until it's polished, and then claims their solution is better than everything else out there. Sometimes this is very true (original iPhone), other times its marketing.

Google will see a need for a feature and put it in as soon as it is useful, even if it's not fully baked yet. They will then iterate on that feature again and again to make it right.

Google's approach means that people can take advantage of features sooner. It can be more difficult to discover these features because they can start so small and they get better and better in small and frequent chunks. On the downside, Google makes more missteps (Wave, Buzz, Google TV), and the ground shifts more rapidly (Android 3, 4).

Apple's approach means that new features are usually more polished and the additional fanfare helps users discover that they exist. But you have to wait a lot longer for them to arrive (notifications, Siri, cloud sync) and there are still mistakes (Apple TV, iTunes Ping, Spaces/Launchpad/Widgets/Expose mess).

It goes almost without saying that Google's approach is the web company style, and Apple's is the desktop software style: incremental, frequent updates versus major releases.

This is all just a spectrum, and Siri is one example of Apple straying a little more towards Google's side: releasing something when it is useful, but not fully polished.

So, I find Android has many more useful features *, and that's why I'm better off. YMMV.

* cloud syncing, turn-by-turn navigation, notification, desktop widgets, voice transcription, Face Unlock, Google Voice, customizable keyboards, Android Intents (apps plugging into other apps), NFC, etc...

May 13, 2011

Cloud Robotics

Video from a talk I gave with some Googlers at Google I/O 2011.

October 5, 2010

Hacks with ROS: rosproxy

I've resurrected rosproxy, which is a hack I wrote several months ago to enable access to services and topics within a protected network. It's written in Python, so it's not super efficient, but it's useful when interfacing your robot with an external website or the like.

For example,

Internal network:

rosrun test_ros talker.py & 
rosparam set proxy/topics [chatter]
rosparam set proxy/xmlrpc_port 11313
rosrun rosproxy proxy.py

External network:

rosrun rosproxy register.py pub /chatter std_msgs/String http://externalname:11313
rostopic echo chatter
---
data: hello world 1286321252.19

Another related hack I did awhile back is ronin, which is a "masterless node". This is useful if you need to keep a node attached to a graph that is going up and down, e.g. if you want to pull data from a robot whenever it is up.

Both of these are "experimental" and will likely never be fully stabilized, but they are fun starting points and show some of the hackability of ROS.

September 10, 2010

Python script for Hudson API

Update: please use python-jenkins instead, which is the new-and-improved version below (and available via PyPI and in Ubuntu Oneiric).

We use Hudson to do our continuous integration -- anything from building and tests to creating documentation. It's been a fairly versatile tool for us and I highly recommend it.

I was a bit surprised to find that there were no Python scripts on the web for using Hudson's programmatic API. I ended up writing one and I'm posting it here for others to use to save themselves time. As good as Hudson is, the programmatic API is not well-documented, and there are also some annoyances like non-HTTP-compliant authentication that require minor workarounds.

We're now using this script heavily to make Hudson even more versatile: programatically creating jobs, chaining jobs, etc... We're now able to test at a much finer grain, which has led to better testing.

All the code I do for work is BSD, so enjoy:

https://code.ros.org/svn/ros/stacks/ros_release/trunk/hudson/src/hudson.py

July 6, 2010

Our robot fetches beer!

More info