Relief

I finally got all my mouse buttons working in Linux. And no, I'm not going to bitch about how unhelpful Linux was this time... I'll leave that task to the simple fact that I've had this laptop for almost a full year now. Granted it mostly worked correctly, and the only thing I was missing specifically was that the back/forward buttons didn't work in Nautilus. But it's nice to have it working fully again, and even nicer that I found a comfortable solution.

It didn't take me long to abandon the "supported method", which is to install imwheel and edit the settings by scratching arcane figures into stone tablets. Fortunately I was quick to find an alternative called btnx, which has a (gasp!) graphical user interface. Although it's not exactly shiny, and it was probably just a lucky break that it supported my mouse, it was simple to use, fully-featured, and worked the very first second time. (It didn't say it had to run as superuser, and didn't warn me, either... it just failed when I tried to save the settings.) But the interface was nothing less than I expected--a straightforward "click the button you want to edit" process. One limitation I think it might have compared to imwheel (I haven't really searched for it, though) is the ability to have different settings for each program. Fortunately that's not one of the things I want to do right now, but hopefully it'll be supported in the future.

I wouldn't exactly call this a glowing recommendation ("Ubuntu: Its inadequacies aren't entirely unsurmountable!"), but it's the closest anything in Linux has come to "just working" in quite a while.

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.

What I'm Doing Here

I'm here in Koblenz working with the Arbeitsgruppe Aktives Sehen (AGAS)--the active vision team. In a word, I'm working with robots. Right now I'm involved with the Robbie 13 project, which is the 13th iteration (in as many semesters) of a robot that is by now quite adept at fulfilling its duties--namely, to autonomously navigate a simulated "disaster area", map the area, and find "victims" (heat sources). Robbie has been very successful at past competitions, participating in the RoboCup Rescue League. I won't go too far into detail, but there's a lot more information at the website if you're interested. Now, though, Robbie is being groomed to take part in a different competition, the SICK Robot Day. Unfortunately the description is all in German, but I'll summarize the basic competition. The robot will be placed in a large oblong arena with obstacles scattered about, and 9 signposts clearly labeled 1-9. The robot's task is to navigate to each of the signposts in order (naturally, it has to read the numbers itself), while avoiding the obstacles as well as a second robot doing the same task in the opposite order. A collision with the other robot will mean disqualification, but the final judge of success is speed. It sounds pretty challenging, but a lot of Robbie's existing capabilities are well-suited to this task. In fact, except for the lack of image recognition (to read the numbers) and weatherproofing (this competition will take place outside, rain or shine) he's almost got everything he needs right now. But of course there is always room for improvement, and we've got until September to make him ready.

Unfortunately I'll only be here until mid-August, so I won't get to see the little guy compete. Currently my task is to build a pan-tilt unit to integrate the new laser range finder. Robbie already has one of these, and it's an indispensable part of his operation--it scans a wide radius in 2 dimensions to sense walls, and it's hooked up to a little servo which allows it to scan up and down to get a 3-D snapshot, mostly for identifying inaccessible areas ("rough terrain"). It's just a little tiny one, though, and now we've got a big heavy-duty new one--the SICK S300. It's actually quite portable compared to most LRFs, but it still weighs more than a kilogram, so just sticking it on top of a servo won't quite work. That's what I'm here for. Although I've never done any CAD before, I jumped in feet-first and over the past week I made a pretty good, basic schematic for an aluminum bracket to hold the LRF. Once the servos get here, I can take a few final measurements, get the design finalize, and then find out if the thing works at all, but for now I'm working on the software to control the servos. It's been a long time since I've done any object-oriented programming, so once again I'm really learning on the job. Overall, though, I think I can get this all finished in just another week or so. I hope so, anyway--this is interesting work, but I'd like to get this finished and start on another project before I go. I'm particularly hoping to have a crack at the higher-level designing... actually contributing to the intelligence of the robot. Anyway, I'll keep you posted!

Hello Internet

I will be blogging for you today. Let me introduce myself--my name is Thomas Foss, and I'm a California college student currently interning at the University of Koblenz in Germany. I figured this was as good a time as ever to start a blog, because it seems like I might actually have something to talk about for a few months. So, glad to make your acquaintance... now let's get started.