Eureka, Again...

I was walking around Eureka today, taking some photos with my new camera, and as usual I got to thinking--this time about digital cameras. I've noticed them explode in popularity in just the last six years or so, concurrent with their meteoric rise in capability, to the extent that there is now hardly anything film can do that digital can't do better. The digital method is, although I admit some prejudice here, a much more logical (if not quite as straightforward) method of recording visual input, and it crossed my mind that if digital cameras came first, the analog method, when it surfaced, would seem quite unconventional and marvelously clever. Rather than interpreting the input and distilling it into data, the analog input is instead transferred directly to another physical format, one which is static and long-lasting. It is, when it comes down to it, another method of storage, but it is a method particularly suited to its domain.

This line of thought brought me to the wholly unoriginal insight that digital processing is designed to be domain-general. It still exists in the physical world, of course, but the physical has been distilled out of it to the greatest extent possible. The majority of processing is done by clever arrangements of a single physical object--the transistor--with domain-specific hardware needed only for the interfaces to the outside world (the buttons, the displays, the light sensors, etc.). "Processing" has been purified and commoditized, and in doing so has taken the concept of "economy of scale" to a level never before seen in human history. Like most commodities, there is a healthy amount of competition in processor development, and the product has been further refined and expanded upon... but it's still the same basic product.

Processing, as a concept, need not be limited to how we think of it today. Film cameras, after all, still process and store information in their own way, and although it is a highly domain-specific method, it is also highly efficient. By thinking of processing as a theoretical task, rather than a uniform commodity, I realized that the super-fast single-stream CPU that dominates computing today is not the only option--and that its monopoly may leave other potential approaches withering in the shadows. Multi-core processors are a step in a new direction, but they are still merely an adaptation of the existing paradigm, weighted down by the heavy burden of their pedigree. The tortured adaptation of popular programming languages in an attempt to ease parallelism is evidence that a fresh start is needed.

I'm aware, or at least I suspect, that stripping "processing" of some of its uniformity will injure one of computing's greatest strengths. Nevertheless I think it might be just what is needed to wring more concrete benefits from Moore's law. Even exponential advancement in single-stream processing will only produce minimal benefits for problems best suited to a parallel approach, and meanwhile the problems best suited to linear, step-by-step processing already have more than enough speed. Moore's law is creating a surplus of a currency we can't spend, and the exchange rates are usurious.

I should note, for the record, that this post was not researched, and there's a chance that all of this blathering might be nothing more than me reinventing a square wheel. I know that parallelism is not a new concept, and frankly I'd be surprised if a dedicated parallel programming language hadn't been invented by now (albeit perhaps an ancient, user-unfriendly language like Lisp or Haskell). I'm also not aware of the state of processing hardware, but there certainly seems to be something of a monoculture going on--at least in the commercial sphere. But I'm no stranger to intuiting existing insights, and it's actually kind of fun. If anything might be new in all of this rambling, it's the realization that processing is treated as a commodity, and that this unspoken assumption may be the root of today's difficulties in transitioning towards parallelism. Also, this post was not initially all about parallel processing--that's just the example that sprung to mind. My aim is to conceive of processing, even digital processing, as a broader concept than just the classic CPU. That's an insight... isn't it?

The Joys of Linux

I'm taking a course on Python this semester. I'm really excited about it; there really is no other word for it. I'm sure that my excitement over something as simple as, say, simultaneous assignment, won't be easily conveyed to non-programmers or even anyone besides myself. Nevertheless, the new toys in Python, and particularly the new paradigms (I have never dabbled in functional programming before now, but the potentials offered by yield and generators are making me positively giddy), are very exciting.

The course is just now migrating to Python 3, so in a sense it's good that I didn't get started with the language until now. Unfortunately the default Python documentation (http://docs.python.org/) is for 2.6.4, so it's very easy to get tripped up by outdated information. In a yet more sinister turn, Ubuntu itself uses 2.6 by default! I didn't think this was much of a problem at first. A bit of Googling eventually schooled me in the proper use of update-alternatives, and soon I had set the default python command to call python3. But then the problems came.

The first sign I had that something was wrong was a big red "do not enter"-style notification at the top right, telling me that the update manager wasn't working. I won't go into the details, but I tried all I could to fix it, and somehow I fooled around with dpkg to the extent that GRUB now displayed my install as "Debian". I had all but given up, and I was on the verge of reinstalling, when I booted up today and realized that Dropbox wasn't running, either. Running dropbox in a terminal gave me some strange error, which seemed to hint that the contents of the file were text, not the binary executable itself. So, on a hunch, I opened up /usr/bin/dropbox in a text editor, and what do I see?

#!/usr/bin/python

The dropbox script was formatted for Python 2.x (it was Unicode strings causing this particular error), and my messing around with the default python command was what caused my problems. Evidently the update manager also relied on Python, because resetting the default command back to 2.6 allowed the update manager to run again, and at the moment it looks like everything's going to be okay.

UPDATE: Everything was not okay.

Clam's Search for Meaning

Sometimes I feel as if I lead a charmed life. I feel privileged, knowing that I can achieve anything I put my mind to, and I remind myself not to take that privilege for granted.

But sometimes I get the feeling that I've been spending my life diligently avoiding any desires that can't be fulfilled. I can always have anything I want, as long as I'm careful about not wanting what I can't have. Far from being uplifting, this is really very sad. What it means is that I can't fail, so not only do I stop before attempting risky-but-surmountable heights, but I also avoid the learning experiences of failure. It's kind of a fox and the grapes thing, although I don't think I'm bitter about it.

This is an exaggeration, of course. I have taken risks before, and I have not led a life entirely free of failure. The degree of it, though, is really quite humbling. I've been trying to write my resume, and I've got it pretty well sorted out now, but I am choking on the "personal statement" part. I know that my first job out of college doesn't determine my entire career, but I'm expected to have some idea of what I want to do in life... a passion. And right now, I'm feeling pretty dispassionate.

It seems to me that the reason for this lack of passion is fear. What I'm going to do in a job is very different from what I've been doing in school, so by necessity my passion will be something I've never done before--I need to be moving forward, essentially. What that means is that I need to want something that hasn't been shown (through experience) to be achievable... so I feel like I'm taking a leap of faith. Yes, I know I've been learning this stuff in school, and I've even been pretty successful doing actual work at my internships. But it's still just far enough out there to give me fear, and we all know what the Bene Gesserit say about fear.

So what are my options? Well, if I'm opposed to stagnation (which, for the record, I am), it seems like there's no option but to face the fear and overcome it. Kind of platitudinous, I admit, but it's much easier said than done. How to face it is the real question. I'll get back to you when I figure out an answer.

Back to Work

I have been working this whole time (well, except last week), even though I've kept pretty quiet about it on the blogging front. I think it's about time for an update.

The DynamixelNetwork code is just about finished. That is, it feels very well-rounded, it's densely-commented, and it'll do everything we need it to do. (In fact I think there's now more comments in it than actual code... but I did it for Doxygen, so that you don't even have to open the source code now to find out everything you need to know about it.) There are still one or two problems with it--a couple obscure functions of the servos aren't yet supported, and the latency is pretty high--which I'm hoping to get the chance to iron out before I leave, but I still think it's a nice bit of code, and better than anything else available for Linux for these servos. I hope the university will choose a license for it soon, so I can post a link. It's my first real contribution to the "open-source community", and hopefully not the last. I hope it gets a good response.

On the robot front, I'm making good progress writing the pan-tilt unit module to integrate into the software framework. That's kind of minimal, though--just a bit of code to accept and send messages, which talks to the servos with my library. I've also been tasked with designing the hardware for the robot body... somehow. Heh. When I first got here I started in on the pan-tilt unit, and I had never designed hardware before. What I'm doing isn't really too complicated, it's just a bit of CAD... but I had never done it before, and I didn't have any idea where to start. I did it, though, and it was pretty fun. It turns out that by doing that, I became the most experienced person on the team when it came to hardware. So I was the natural choice to design everything else.

I'm not complaining, though. I'm learning some valuable new skills, and I do like to tinker with gadgets every now and then. It's staves off the drudgery of programming 24/7, and I'm getting better at it, too. So on Tuesday I'm going to take the robot apart again, pull off a few things, walk to the workshop with an armful of aluminum, and slap it all together. Fun times.

I'm leaving Germany on the 12th of August. That means I've got three weeks left to finish up. If I finish the hardware next week, I should be able to get the software wrapped up before I leave. It's really strange to be leaving so soon. Three months isn't really much time at all. It's okay, though--it wasn't long enough to get overly attached to the place, but it was long enough to get a whole lot of stuff done, and get some memorable moments in there, too. I'm not really excited about jumping right back into school again, though...

Well hot damn!

You know that shell interface to C++ I was talking about? Turns out it already exists! It's a tool called SWIG, used for wrapping up one type of code to be used by another language. And it turns out to be exactly what I'm looking for--a (relatively) simple way to access class member functions directly, in an ad-hoc way.

I don't have the servos with me right now, so I can't test it out fully, but after sweating over a hot command line for the better part of an hour, I've got it to the point of compiling and throwing the expected exception when it can't find the serial port. I am super excited about this, and I'm definitely going to be learning more Python from here on out. And maybe I'll finally get back into Lisp, if I can find a single goddamn interpreter...

EDIT: It works like a charm. :D

Theis Schmesis

For about a year now I've been actively contemplating graduate school. I'm getting my Bachelor's degree (barring misfortune) in just two more semesters. After that, the rules go away. Oh, they've been fading for a while, and college has been a great way to gradually transition into the concept of actual responsibility. But up to now I've always had a pretty well-defined "roadmap" for success. Every year a new class, every week a new assignment, every summer a few grades and a long vacation. This pattern has structured my years for literally my entire life--I can't remember a time when I wasn't in school. And it's been something of a crutch, too, at least for me. I crave structure. I fear making decisions. And although I've had to make a few vague choices about my future when applying to college, choosing my major, and taking classes, in one year I'm about to fall out of the structured, comfortable, predictable, guaranteed, reliable system, and into... what? Whatever it is, the transition isn't going to be structured, and it isn't guaranteed to be smooth.

So for about a year I've been contemplating the steep cliff in front of me. And I can see two options: get a job (career?), or go to graduate school. (I can't help but notice here that I've implicitly defined failure as "not an option". I wonder if I'll be chuckling about this in 12 months...) And I'm really not very familiar with either of them. I'm afraid that at some level the primary reason I want to go to graduate school is just to stay within a structured system--if true, I would consider that a "wrong reason", perhaps even a character flaw. But I can't tell if it's true. What I can say is that the thing that frightens me most about graduate school is the concept of the Thesis. And despite the two rambling introductory paragraphs, that's actually what I started this post intending to talk about.

You see, the Thesis scares me. But it just occurred to me that I don't know why. I hardly even know what it is! I suspect that all this "thinking about my future" that I've been doing has been nothing more than rehashing the precious little I know about what my future could be, rather than going out and actually researching what it would be like. My concept of a Thesis was only vaguely defined as being something along the lines of a 100+ page paper. I doubt anyone really enjoys writing papers, and in many cases it's been nothing more than drudgery. What's more, the drudgery has been directly linked to the length of the paper. Strangely enough, it only just occurred to me to look behind the mere stimulus-response of this learned aversion to paper writing, and figure out what was causing it. It's not all that surprising when looked at carefully: When taking six classes a semester, there's only so much time/effort/interest one can put into each class. And the greater the amount of work that an individual professor assigns, the more strained that already-small amount of time/effort/interet becomes. The result is often a whole lot of disingenuous boilerplate, which can quickly sour the entire paper-writing process.

But is a thesis different? I never asked myself that question before, but I think the answer is yes. I love to learn, and I'm gradually coming to the conclusion that having only one thing to learn at once, instead of seven, might make a huge difference in my motivation level. So far, in the last few weeks, I've been working on this code almost nonstop--partially because I don't have anything else to do with my free time, but also because I really am interested in improving it. I think this is a good sign, because hopefully this will be similar to what I could be employed to do... but something tells me that I might be better served by staying in a university setting, where I'd have more freedom to choose a topic to learn about, and spend my time producing knowledge, rather than being heavily focused on producing a product. Maybe the thesis is just an extension of this concept--I could learn and learn to my heart's content, and the "proof" of that learning, in the form of expounding on the topic at length in a paper (and in a verbal defense), would come naturally.

This gives me hope. But I have to make sure I'm not forgetting any key details... like teaching classes. Is that an inherent part of graduate school? I'll have to do some more research...

(Word to the wise: In case you couldn't tell, the verbosity of this post (both in length of individual words and number of words written) is a dead giveaway that I'm writing this post at or around midnight, frantically typing out a half-formed idea before I fall asleep and forget it entirely. I suspect that's the entire point of blogging, but I just thought I should warn you nonetheless. Hmm. Maybe I should just put that in my profile and save time.)

All you need is cash

Wouldn't it be awesome to have an interactive C++ shell? It's probably best to pay me no mind, because I'm pretty new to the concepts, and I'm speaking from enthusiasm rather than experience... but lately I've been doing a lot of testing of the DynamixelNetwork library using a rudimentary C++ program that's nothing but a few 'cin's, a switch statement, and some function calls. I have to recompile it every time I want to test something new, which makes it very difficult to test a variety of things at once. I'd love to just cut out the middleman, and type the function calls directly at the command line. In this project that wouldn't be much of a problem, although I can see how trying to build a general-purpose shell to handle every function of C++ could pose some difficulties. But it would be a neat utility, if only just for simple testing, wouldn't it?

I've been getting interested in learning Python lately, and today took the first step and found out that Python does indeed have an interactive environment available. And according to Wikipedia, it interfaces well with C++ code (among others). I'm not quite sure how to do it yet... but I think I might try to hack something together. Wait... isn't "hack" more commonly paired with "apart"...?

These servos are fun!

Driver code: Just about finished.

Today and yesterday were a bit of a grind. Although I was being productive, the type of work I was doing wasn't exactly mentally stimulating. But it had to be done. A lot of the functions of the servos--almost all of them, in fact--are controlled by setting registers. There are a few variations, but in the end the bulk of the class falls into four or five private methods, and the dozens of public methods are only there to provide a user-friendly interface to the servo registers. I tried to find a simpler way, but the data varied too much to make anything very consistent--for example, some of the values are stored in two registers (for values over 0xFF) with the high-byte and low-byte swapped, some are restricted to a smaller range of values, and some are just bit flags. So the class is now chock full of tons of one-line functions, but it should be pretty simple to use--abstract enough for anyone to have an easy time using it, detailed enough for someone familiar with the servos to do anything they want, and secure enough to prevent anyone from breaking anything without explicitly trying to (for the most part).

I wouldn't call this completely finished--there are still one or two functions which I haven't implemented yet, there are a few aesthetic decisions that I might change, and I've still got to write most of the comments. But right now, for the project I'm working on, the code will do everything we need it to do. I feel accomplished.

It compiled! It compiled!

Okay, it's not a gigantic achievement. But it is a significant milestone, and it took me a lot of work to get here (more than it ought to have taken, honestly...). I finally compiled my first C++ class. I mean, besides the little ten-line classes that I wrote in school when I was still learning what object-oriented programming was. This is the first real object-oriented code I've written, and although it's not finished, a firm groundwork has been laid.

What I've got now is a "DynamixelNetwork" class that controls a serial port with an arbitrary amount of Dynamixel servos on it (we're using RX-10's, but I believe the communication protocol for other Dynamixel models is very similar, if not fully compatible). The reason for having one "Network" class instead of individual objects for each servo is because they can be daisy-chained together, so the communications all have to share the same serial port. Plus, there's not a whole lot that an individual servo class would do. The main requirement is simply an interface to the communications protocol, and that can just as well be centralized and used for any arbitrary servo. I may uncover additional requirements as I finish up the class, but I'm doing my best to keep the code flexible.

What's been taking me so long is just figuring out how to write to and read from the serial port. It seems to me that it's one of those tasks that just seems to be harder than it needs to be. I'm using the termios.h interface, which is archaic, difficult, and fugly, to say the best, but at least it's a standard. Right now I've got a working "sendMessage" method, and the "getResponse" method is mostly working, but giving me some weird errors. I don't understand what's wrong just yet, but I've mostly isolated the problem, and once I get that solved I'll have just about all I need. After some little difficulty I rolled those into a working class, got the .h and .cpp files all nice and neat-looking, and poked it with a sharp stick until it compiled. Once that was working, adding additional functionality was almost as simple as just finding which registers to write to (in the servo), and sticking in a few more methods. I also took some time along the way to add some bounds checking, sprinkle in some custom exceptions, and put in a few routines to improve general performance (like one that instructs the servos to stop sending status packets back after each instruction, to save the time it takes to wait for each one).

It's not all a cakewalk from here, though. What I have to do now, and I hope to finish this before Thursday, is to finally get the getResponse method working, organize the inheritance of my exceptions into a more logical structure (right now they're all inherited from the base exception class), write a udev rule for the USB serial port adaptor, fully comment the code, and add in baud rate switching. This last one's the hardest, because if you make a mistake switching the baud rate, you could end up with a servo that refuses to listen to you. (Because of the way the baud rate is set within the servos, it might even be possible to switch it to a rate that the PC serial port isn't capable of using... I think that's my biggest fear right now.) I might also add in a few "scan for servos on network" methods, but that's on low priority for now, because we're going to be working with a known configuration for this project. Eventually I'd like to add it, though, so that this could become a good general-purpose C++ library for the Dynamixel servos. I searched pretty thoroughly before deciding to roll my own, but now that I'm putting all this work into it I'd like to make it a contribution to others who don't want to put in this much effort (and also don't want to use .NET).

Well, that was an unnecessary amount of detail. Hope you enjoyed it. It's good to get all my thoughts laid out in text, though.