Leaving Arbor Networks was a tough decision. There are so many good people and interesting problems at Arbor. When I was approached by folks, I said, “I’m not done working on stuff at Arbor.”

The work, people, culture and environment really are that fun at Arbor. As a result, the last weeks and days of my working at Arbor have been super busy as we came together as a team and decided to get some stuff done. We set some goals and achieved them before I left.

On Monday, I start at Canonical working on Juju. I am super excited to work with a team of people who are behind making the best cloud orchestration tool, and contribute to making it even better.

I’ll be learning more about Go in my new roll. Expect me to write a bit about learning go. I learned a ton about Python at Arbor Networks. I didn’t write about it because I feel like everything I learned is very well documented. Go is a much younger language. Hopefully I can contribute to its documentation and share my learning experience in a meaningful way.

Originally written by Steven M. Bellovin <smb@research.att.com> while at the University of North Carolina at Chapel Hill. Later tweaked by a couple of people on Usenet. Completely overhauled by Rich $alz <rsalz@bbn.com> and Jim Berets <jberets@bbn.com> in August, 1990;

I was asked by Packt Publishing if I would read and review this book. I’ve owned a BeagleBoneBlack for a little while now. My use case was not robotics. This book might shed some new light on my old Black, so I agreed to review it.

The book starts off very accessible. Chapter 1 covers just about everything I did with my BBB when I first received it, hooking it up like a PC, replacing the default distro, making sure I could SSH to it were all in there. The author, Richard Grimmett, goes a step further and installs XFCE gui and vncserver and walks through connecting from a Windows PC using vncclient. All in all, chapter 1 is a great super basic tour.

Chapter 2 dives into programming on the thing and introduces Python. It does it in a really weird (to me) way. It has the reader running emacs in a putty window remote connected to the device. This must just feel weird to me because I do a lot of remote programming and its never with emacs (I’m a vim guy) and its rarely remote. For a new user, it seems to me like it would have been simpler and more friendly to say “use an editor of your choice” and “here is notepad2 or sublime” along with “here is how you copy files to and from the device.” I think this is mostly my background causing me to see things differently. The emacs in putty walk-through is very adequate.

Its not a programming book, so this is really a nit pick, but technically some of the descriptions of python aren’t really true. For example, if __name__==”__main__”: does not “tell the program to begin its execution at this point.” Again I’m nit picking, but I do feel like a different phrase that isn’t so very false to someone who knows python could have been found. Still, its not a programming book. The beginning of the chapter does list many resources for learning python.

Ugh, and then the book moves on to C++ and has quotes like this, “C++ is the original language of Linux” I’ve used Linux for almost as long as I’ve programmed C, and I am very (perhaps overly?) sensitive to the difference between C and C++.

OMG what do you mean Speech Input and Output? Really? Chapter 3 tackles it. Really. For real. Speech Input and Output on that tiny little board. I can make my own Siri! This is a really cool topic; espeek is something I’ve only played with a little bit prior to reading this. It looks fun.

Speech recognition is done with software I’ve never used before called PocketSphinx. It isn’t packaged and so one has to compile it. Pretty sweet BBB being able to compile stuff like that. (I’m thinking of iOS and Android where I’ve not seen a compiler run on device.) The demo walks through limiting the grammar of speech input so that you don’t have to train the recognizer.

I’m a programmer, so I’m going to nitpick programmer things. I really wish authors wouldn’t do this, “I like to make a copy of the current file into continuous.c.old, so I can always get back to the starting program if it is required.” I really do wish authors would just say “go read about version control systems.”

Whew, speech is fun. Next step is video. Hook up a webcam and let’s do some image recognition. The book walks through OpenCV and it is as this point that we are forced to do a bunch of Linux sysadmin stuff to make our SD have enough free space to have a dev environment. This really could have gone anywhere in the book. I kind of like that it put it off until it was necessary.

The python image tracking example using OpenCV looks pretty cool. It is a complete example without going too deep or going off in the weeds.

Making the Unit Mobile introduced me to mobile platforms. The Magician Chassis that the book shows first, I found online for under $20! I knew that this stuff was accessible, but this is downright cheap. I feel almost guilty NOT getting one and trying it out.

The motor controller tutorial looks very straightforward. I already have ideas for code changes. Immediately after the simple time based tutorial it goes into speech controlled movement, which is pretty sweet.

After the wheeled robot tutorial is a walking robot example. The author makes a compelling argument for this type of robot, and the Pulse Width Modulation servo motors are cool, but I have to admit, this type of robot just doesn’t excite me. The book also punts on the PWM, using a controller which interprets serial USB commands into the PWM for the servos. For beginners, this is certainly the right choice.

Incidentally, the –help output from UscCmd includes Version, Culture, PublicKeyToken values like a Mono program might. I wonder if it is written in C# and running via Mono. I’m going to assume it is. That is pretty sweet. Indeed the linked download page mentions C#. http://www.pololu.com/docs/0J40/3.b

The sonar sensors section is a straightforward and great introduction to the use of them. I never knew how those things worked or what kind of value they returned. Now I do. Mounting the sensor to a survo makes for a nice subsystem on the bot.

Next, a fully remote control system is built. I don’t know if I like the choice of using an LCD monitor. It seems like overkill, but depending on the particular robotic application it would be a good choice. For the applications I have in mind, I think I’ll skip it. A wireless usb keyboard and mouse makes for an obvious choice. At this point, I just keep thinking about bluetooth and using an extra Wiimote, mostly because I think it would be a more fun control.

Oh, a GPS receiver! This could be necessary for when I lose my robot in a parking lot or the woods. As with the LCD Monitor and KB chapter, I kind of feel like I know how to do this since I’ve looked into it before. It is great coverage and good intro to the topic.

Much of my day job is what would traditionally be called Systems Programming so Chapter 10 is kind of a duh to me. I’d have started there, but that is just how I think about coding these days. Its great to have this in a chapter to tie some things together. In other words, read this chapter!

Using the BBB in sea, air and submarine applications is an interesting idea. I don’t think it is for me yet, but the book gives introduction to some ideas on the topic. The introduction to feedback control is very welcome.

Overall this is a great book. It really gave me a lot of ideas. It also showed me how easy it is to get started, something which I’d been a little hesitant to do. I’m actually a little excited to dive in now. I’ll be doing a bunch of this stuff with my 6yo over the next few years.

I ran across a zlib stream, which is like a gzip file, but without the gzip header. I wanted to decompress it and piping through gunzip doesn’t work because of the missing header. Python to the rescue!

I recently read a post by someone lamenting the thanklessness a programmer gets. I once worked in IT where services are really considered a utility. No one calls the utility company unless there is a problem. Have you ever called your electric, phone, or gas company to thank them for the great service? I didn’t think so. This was my response:

Sounds like a bad environment. For a long time now, I’ve worked on teams where we are our own worse critic and where I’ve received more thank you emails than criticizing emails. That said, I don’t consider error reports to be criticizing emails. They are just that, a report of something which went wrong. Things always go wrong, not just in programming. In business and in life, something will always go wrong. How you respond to the wrong doing can largely influence your happiness as a human being.

Sometimes mind shift has to happen to really make this effective. Things like http://www.c2.com/cgi/wiki?EgolessProgramming can help you remember that you are not your code. Error reports mean that someone care about what you created and wants to help you make it better. That is awesome. I’d love much but maybe not too much of that kind of feedback.

yum install scala on Fedora will grab all the dependencies, including a JVM, but its a pretty old scala.

Luckily it is pretty easy to install scala-2.9.1 by snagging it from rawhide, but just the RPMS only get you so far. Fedora seems to be changing their JAVA_HOME in 17. A little hack, and you are off and running.

testdrive uses the -net user feature of kvm by default, which is really cool because it becomes a lan client and magically gets internet via proxy. If you want to test server software, you probably want your testdrive VM directly on the same LAN as your host OS.

In my case I already had a bridge setup so it was as simple as changing the -net option on my kvm command line.

The only drawback is that kvm has to be run as root. There is a way around that by specifying a network interface start script which would be suidroot, but for a personal system or testing development system, I find that overkill. I let her run as root.