Since we have just started working on this, not all the details have been worked out.  My friend will be writing the computer software and the ZigBee transmitter; I will be building and programming the clock itself.

The choice of using ZigBee is to evetually allow multiple stock clocks to recieve data from the computer without needing to dramatically increase the complexity of the network.  Plus, its a good excuse to use the ZigBee controllors that we already have.

I just purchased one of the PIC development kits that I have used before at a previous job, so once that comes in next week, I will be able to get started programming the microcontroller.  I will eventually design a PCB and have one built for the final device.  Updates will be posted once work actually starts.

The core of the robots is a OOPic controller, the OOPic-R board with the B.2.2+ controller worked well for this project. Its certainly not the fastest or most powerful board or processor, but provided the basic functionality I needed. This board has 4 ADC ports and 16 digital I/O ports and provides a regulated 5V supply to sensors or any other peripherals. The compiler for the chip uses its own custom syntax for many things, but also allows BASIC and C syntax for the code. The custom commands make setting up some sensors quite easy. On these robots, each wheel has its own servo, and the servo commands that are part of this compiler made it relatively easy to control them.

The obstacle avoidance used in each robot is a quite simple. Each robot has two Sharp GP2D12 infrared rangefinders mounted on the lower platform on the front of each robot. They are angled out from the center of the robot by about 30 degrees so that an object that would clip the side of the robot will be detected. When an object is detected within the range specified by the code (in this case, about 40cm) the robot will turn away from the object until there is no longer an obstruction. The proximity sensors themselves are analog and will output a voltage that is very nearly linear to the real distance of the object detected. The sensors are connected to the first two ADC ports on the OOPic board. In the code, the voltage read by the ADC is compared to a predetermined value that I found through testing the sensors. These sensors were very easy to use and seemed to be quite reliable in the testing that I did on my robots. They did not fail to detect an object even under bright fluorescent lighting, but I’m sure one could find a situation where they may not be ideal. The only time I could cause the sensors to fail was to put something about 5cm in front of the sensor in which case they would fail to see it, but due to the rather slow movement of the robot, it is very unlikely that something could get that close before the robot could react.

Perhaps the most important part of the robot was the infrared detection of the other robot. The circuit to do so is rather simple and consists of just a comparator connected to the photo transistor, a voltage divider, and an output LED to provide visual confirmation that it is working.

Infrared Detector Schematic

The IR LED is shown on the schematic for reference. To demonstrate the capabilities of the robots, I took two short videos of them in the lab. The LM339 comparator chip used is a quad package. I used three of the comparators to allow Oedipus to sense from the left, right, and behind. I could not get the fourth to work and I was not able to determine why. Tiresias had 4 of the IR LEDs in it with the 470 ohm current limiting resistors on each LED. I could have run all four of the LEDs in series and used a single resistor, but I did not think of that until after I started building the board.

The only issues I had in getting the robots to work properly, besides my own inability to build a perfboard right the first time, is that the phototransistors could detect the IR LEDs from behind and on the side as well as in front of them where I wanted. This meant that when the IR LED was susposed to trigger the right detector, the left would also trigger due to IR light going into the bottom of the left phototransistor. To solve this, I put a small piece of electrical tape to cover the side and bottom of the phototransistors which solved the issue. The robots work to my expectations, but there is certainly more that could be done with them. First of all, only one robot is able to detect the other. One robot wanders around the room without any knowledge that there is another robot involved. I would like to put detectors on both robots, and have one actively chase the other. In its current state, on robot runs away from the other, but no attempt is made to make chase. Since this project has already been completed for a grade, I doubt I will continue working on it. Below is a zip file with the code used for the OOPic controller and an EAGLE schematic of the controller board.

robotics_project.zip These files are released under GPL version 3 as specified in the COPYING file contained within.

Here are some images of the robots.

Tiresias with 4 IR LEDs

Oedipus with Infrared Detectors

Oedipus Front View

Oedipus Rear View

“If they charge for it, they are going to make millions and millions of dollars,” said Mike Boyd, an aviation consultant. “Most of us cannot be away from the Internet or our laptops for very long. We get separation anxiety when we are not on the Internet for a few hours.”

I do not know how they plan to make millions of dollars when the cost for service on Delta flights will be $9.95 on flights of 3 hours or less.  Sure, some people will use it, but I have a feeling the majority of travelers will simply wait the few hours until they are on the ground when they can use any number of free wireless access points.  If the airlines are planning on using this as a way to offset their other rising costs, I think that they will be greatly disappointed.  Either the cost of the internet access has to be very cheap, or it must be free if there will be any kind of significant utilization.  If the wifi was free, then the airline could use that as something to attract additional passangers.  Even if the ticket prices were slightly, say a few dollars more, I think people would be more willing to travel on that airline, because the cost of the service is hidden in the cost of the plane ticket and removes the pay barrier that would instantly turn off some people.  I can see myself paying $5 more for a ticket on an airline that had free wifi, but I doubt I would pay $5 to get internet access once I was on the airplane.  I would think that the airline would at least offer it free to first-class passangers and those that are members of the airlines club.

The primary issue I had after the expansion was the proper partitioning of the free space. When the RAID expansion was complete, I now had 1TB of used space using a JFS that was the original partition, and 1TB of unused, unpartitioned free space. Attempts to use Gparted to expand the partition failed due to a known bug that prevents partitions over 1TB. I tried to use Parted, the CLT tool that Gparted is based on, to expand the filesystem but was unable to do so. This seemingly left me with two options, either use multiple smaller partitions, or to reformat and restore the data from the backups. I decided that smaller partitions would be a lot of extra work in terms of keeping tabs on the free space on each partition (and may require more frequent partition modifications) which is something that should not be necessary. Restoring from backups was not welcome due to the time involved. Deciding that those options were not acceptable, I was determined to find the solution I wanted, having a 2TB partition without going through a backup restore process. If anything, it would be worth doing simply on the principle of the matter: that having large partitions on a modern filesystem that supports volumes up to 32000TB should not be a problem. Several Google marathons and man page studies allowed me to successfully perform the operation that I wanted.

My main problem was a lack of understanding of the way that fdisk actually works. With fdisk, you can delete and recreate a partition without actually destroying the filesystem that lives on the partition. I am not sure exactly what the limitations are, but it seems that as long as you do not change the starting point of the partition, the filesystem will remain there. In my case, the drive in question (/dev/sda) had a 1TB partition starting at the beginning of the disk (/dev/sda1) with 1TB of unpartitioned free space residing after the JFS partition (created by the RAID expansion). I deleted the JFS partition (/dev/sda1), and recreated the partition, but this time using the full 2TB of space. In the tests that I did, the free space MUST come after the partition. I wrote the partition table, and them mounted the drive. All the data was still there, but the JFS partition was only showing up as 1TB with the command dh -h. This was rather concerning until I realized the state that the drive was in. fdisk only edits the partition table, not the actual filesystem. When it writes out the partition table, it is just redefining where the partition begins and ends and does not touch the filesystem. Thus, although I had expanded the partition, I did not expand the filesystem. Doing some more searching, I found this article that gave me the last piece of information I needed. The command mount -o remount,resize /mount/point tells the JFS filesystem to expand to fill the entire space of the partition. The command is unique to JFS and will not work on other filesystems because the options passed are used by the JFS kernel driver. When you issue the mount command, note that the partition must be mounted.

Perhaps most frustrating is the lack of data on the JFS filesystem. It does not seem to be very popular in the Linux community, most of whom use ext2/ext3. Those that do use an alternative filesystem tend to use ReiserFS with a small number using XFS. In the limited, unscientific testing I have done, JFS performed very well performance wise and used far lower CPU than ext3 or ReiserFS. JFS has worked out well for me so far and, despite my initial difficulty in expanding the filesystem, is the filesystem I will use in the future.

In terms of weight, the MacBook Air is advertised as 1.36kg, a respectable lightweight notebook. The Thinkpad X61 is listed as 1.41kg with the X61s being 1.24kg. These weights are usually the lightest the laptop can be without any additional options. The weights are rather close, so lets see the stock features and compare.

Both the Air and the X61s come standard with a 1.6GHz Intel Core 2 Duo processor and an 80GB hard drive. The Air comes with 2GB 667MHz RAM, Bluetooth, and 802.11 a/b/g/draft n wireless, which are options that must be added to the X61s. The Air has a 13.3 inch screen while the X61s has a 12.1 inch. The thickness of the Air is 19.3mm (0.76″) and the Thinkpad is 20.32mm in the front and 27.94mm in the back. Neither come with an optical drive. Overall, the performance specs of both laptops can be made very close. Configured with identical hardware, the Air costs $1799.00 and the Thinkpad X61s with the options is $1354.00, a significant difference in my mind.

To me, the main differences are in the physical (the Air is thinner with a larger screen) and in the connectors that are available. The conneectors are something that is very important to me and is one of the main reasons that I think i would be unable to use this laptop. The Air has a very limited set of ports, namely 1 USB port, a mini DVI (useless to me) and audio. The X61s has 3 USB ports, VGA, ethernet, 1 PC card slot, and SD slot. There have been countless times where I needed multiple USB ports and in my opinion an ethernet port is not an option.  The expandability of the Air is quite limited and is something that would be very difficult for me to deal with.

What it boils down to is the MacBook Air is Apples entry into the ultralight notebook arena that falls short of the other players already on the field.  I’m sure that there are people who find the Air to be what they want, but it is not exactly a deal when there are more powerful laptops with less weight that cost significantly less.

There seems to be a fascination with sexual crimes and crimes against children in the government recently, and the repercussions of this trend are rather worrisome. As these kinds of severe punishments become more commonplace, they will be used more and more in other, less severe crimes. I see this as a bad sign, as a sign of a government that does not understand technology or the internet, and a sign of a government more obsessed with information on its citizens. Although these laws do not affect me, it is a slippery slope that can soon start impacting citizens who have not committed a crime. There is already a problem with warrantless surveillance, and I fear that these laws are a continuation on a road that I do not think any government should go down.