Dora 

Getty 

Trees 

Uploading to Gmail

I recently signed up for a Gmail account. Normally, I get my mail through my ISP and download it to Outlook, and I want to keep doing this. At the same time, I'd like to have Gmail as a backup and a permanent store that I can access anywhere. There are some tools on the web for uploading your email to Gmail, notably GMLW. However, none of them work with Outlook, and though there are utilities which will extract from Outlook into a format GMLW can use (e.g. outport, readPST), I have not found them to work very well.

So I am writing some Perl scripts to do this. It's not too hard to read the Outlook mailbox, but there are some suprisingly difficult things, such as finding the email address of the sender, the reply-to address, and determining whether the message is plain text, RTF or HTML. In the case of RTF orHTML, there is also a problem of decoding it from the compressed form that Outlook uses. I've found solutions to most of these problems, through a combination of playing around, porting scripts from other languages (e.g. the RTF decompressor and the HTML-from-RTF extractor), and just picking up tricks here and there (e.g. how to get the SMTP transport headers).

The scripts are not yet ready to use, but I am working on them. Leave a comment if you might be interested.

Line Follower using Navigation

For the final version of the Line Follower control program, I used the Navigator API. The code is here. I like this approach: the code is much simpler and cleaner than the other versions, although it does rely on the calibration parameters being accurate.

One minor problem is this: when the robot needs to turn in order to find the line, it uses the navigator's rotate method. If the turn causes it to pass completely over the line from one side to the other, it will fail to notice that it has done so. I looked at the source code for rotate, and what it does is to calculate how long it needs to run the motors for in order to turn through the specified angle, and then sleeps (using Thread.sleep) until this time has elapsed. So I considered setting up a separate thread which watched the light sensor, and interrupting the sleep if this happens. If the sleep call in rotate is interrupted, it just stops the motors.

In the end, I decided this was too much hassle. However, it turns out there is another problem as well. The TimingNavigator class maintains an instance variable (called angle) containing the current angle. The rotate method updates this to the target value, i.e. the current value plus the rotation, before starting to run the motors. So if the thread is interrupted, angle will contain the wrong value.

A possible improvement to the class would be to update angle to the actual angle, based on when the thread was interrupted. Another change which might make life nicer would be to have a rotateUntil() method, which rotates through an angle or until some other condition is met. I would prefer this, as it gives you tighter control over how to interrupt the turn, and avoid the overhead of having a separate thread and catching the exception.

Line Follower robot, version 2; The Calibrator

I recoded the line follower to use behaviors. It doesn't really seem to be an improvement in terms of clarity, though there may be better ways of coding it. Take a look here.

For the next step, I want to try out the Navigator API, in its TimingNavigator version. I will return to this in a later posting. The TimingNavigator takes parameters specifying the time to travel a standard linear distance, and to make a rotation. To help determine these, I wrote a class called the Calibrator. I was also finding myself spending some time setting the motor powers to get the robot to run straight, and finding the sensor thresholds for the light and dark levels. The class includes methods to help determine all of these. See the comments in the code for details. There is also a main method, which allows you to execute each of the tests in turn.

Line Follower robot, version 1

I built the LineFollower, using chapter 3 of the O'Reilly book referred to in the previous entry. Here's the first version of the line follower control program. The robot follows a dark line on a white background (e.g. the Lego testpad). If the leaves the line, it turns a bit to the right looking for it, and if this fails turns further to the left, then yet further to the right and so on. The decision about whether it is on the line uses some thresholds on the light sensor value, which may need to be changed for different conditions. It works better following a line which is curving to the right because of the search strategy, and sometimes it will get confused and turn right round. I have a short movie of it, but I'm short of web space, so if you want to see it, leave me a comment with your email address.

[Later note: another reason why the robot works better following a right curving line is that the motors appear unbalanced. With the sensor disabled, it tends to curve slightly right. Changing the power setting on the motors helps to fix this, e.g. 8 for motor A and 5 for motor C.]

The style of the program is rather cruddy. It's a very procedural approach. For the next step, I aim to rewrite it using some of the more advanced APIs in LeJos.