Friday, February 23, 2007

To the caribbean!


You won't see any updates for a week because Jane and I are heading out on a caribbean cruise! When you live in New Hampshire it is critical to go someplace warm every other winter or so. I will take pictures and post them here when we get back.

Thursday, February 22, 2007

[technical stuff] my atmega32 PCB design


Been a very busy day! I plan on using some AVR ATMega32 microcontrollers as a cheap and easy way to add some A/D converters which can do their own averaging / filtering of analog signals. Last night as I was experimenting with the smaller ATMega8 I quickly came to the realization that things would go MUCH more smoothly if I had some PCBs fabed for these (so I don't have wires running everywhere). Since we are leaving Saturday for our cruise I need to get this sent out for manufacturing TODAY!

Now I am far from a hardware expert. I have only designed 1 board before and that was several years ago (and was a much simpler board). Luckily there is some good software for this. Eagle CAD from CadSoft runs on Linux and has a free version which has all the capabilities I need. It took me about 1/2 the day just to learn the software, 1/2 the day to design the board, and 1/2 the day to figure out how to generate the files needed by the manufacturer (yes, that is 3/2, like I said it was a busy day!).

Tomorrow I plan on putting together a digikey order so the last of my components should be here when I get back. The boards have a 10 day lead time (which is why it was critical to get that in now). That will give me a week when we get back for working on the mechanical parts of the bot. So for I _think_ I have things planned out so that I won't waste any time waiting on parts!

Monday, February 19, 2007

[technical stuff] The hard drive saga

I ran into a few snags over this weekend. My goal on Saturday was to get the sonar hooked up so I could experiment with it. I put together a distribution board that I can use to connect multiple i2c devices onto the bus and added a couple resisters to pull the data lines high. Then I went to my workbench computer (an old G3 mac running ubuntu linux) and it crashed! After attempting to reboot I found that it was complaining about bad sectors on the hard drive. Oh well, it is an old computer and all of my critical data is on my newer desktop system. Since it appeared to be just the drive I figured it would be worthwhile to just get a new drive for it. After booting from CD I was able to do an fsck (after several tries) and mount the disk read-only. I backed the data up over the network and called it a day (had a party to go to that night).

I picked up a new 320GB drive and installed it sunday. I made several unsuccessful attempts to install ubuntu to it, fiddled with connections, tried various methods of partitioning the drive, none of which worked. I was starting to suspect the new drive was bad but then did some research. Turns out the IDE controller on the old G3 mac has a maximum of somewhere around 130GB!!!! I was frustrated but at least I understood the problem. I had been wanting to add another drive to my newer system to allow me to do backups. The drive worked just fine there.

So, after nearly 2 days of fiddling (and yes a little slacking off I admit, it was the weekend!) my workbench system was still down. Since the drive seemed happy after the fsck and the data was then backed up I went ahead and put it back in. It seems to be working ok at the moment but I plan on buying a new (under 130GB of course) drive and replacing it soon.

Today (monday) I finally got back to experimenting with the sonar. I was using the linux kernel's i2c "bit bang" code along with my own driver for the digital I/O board from technologic systems for this. I was not able to get the sonar device to send the ack's when it is addressed on the bus. I decided to back up and write some user-space code to implement at least a minimal subset of i2c. With a lot of technical specs, example code, and most importantly my logic analyzer I was able to get it working. The code is a bit of an ugly hack for now but I can use what I learned from this to make the kernel driver work. I imagine it is something simple.

Tomorrow I plan on experimenting with my AVR microcontrollers and and make sure I can communicate with them over the i2c bus as well.

Saturday, February 17, 2007

My sabbatical has begun!

You may have noticed that I have not done many updates lately. That should change now that I am officially on sabbatical for the next 8 weeks! It sort of feels like summer vacation when I was a kid (except for the weather). It sounds like a lot of time but I will be busy getting rockhopper going. But don't worry, it won't be all hard work. Jane and I are taking a week long cruise leaving a week from today.

Ok, now more technical stuff...

I received a few more parts in the mail the other day. Most importantly my sonar units. I found some really nice units made by Devantech. I chose the SRF08 sonar because it should be easy to interface using an i2c bus and also because it has the ability to listen for multiple pings. I have not had the chance to do any work with sonar since college but what we found from experimenting back then was the first ping received is often not not always what you want. The plan is to take the data from 3 sonar units and feed that into a neural network. I will write up more on this later on. The plan for today is to just try to interface the sonar to my ARM board to make sure I can get readings.

I also ordered a digital compass, also from devantech. My first robot for the Trinity robot contest also used a compass. I found that while in a building such as the gymnasium at Trinity it will at first appear to give random readings. You can move in a straight line and have massive compass deflection. While this may appear random it _is_ consistent in a single location. I hope to be able to use this to help recognize locations inside the maze. The compass also interfaces using i2c.

Sunday, February 4, 2007

[technical stuff] rockhopper gets a brain!


This is _not_ battlebots. While I enjoy robotic mayhem of two robots fighting to the death as much as anyone I find the challenge of autonomous robotics much more interesting. For the robot to be autonomous it of course needs some sort of CPU. My first Trinity competition robot from 2001 used 2 PIC microcontrollers for low level functions connected to a Palm for higher level processing. That worked fairly well however since it was all implemented on solderless breadboards it was less than reliable. It did however show me just how much you could do with a $5 PIC. My second entry from 2005 (Fawkes as shown in my first blog post) used a Motorola 68HC11 based "Handyboard" robot controller.

The most difficult part of these earlier robots was debugging the code. Since these run embedded code with no operating system there is little that can be done for debugging beyond printing short messages on an LCD or flashing an LED. I found myself spending most of my time making minor changes to the code, recompiling, downloading to the robot with a serial cable and trying again. So much time was spent on this that it did not leave time to write any complex AI code.

I needed something that could run a real OS. In my line of work there is only ONE choice here! There are several companies that make single board computers (SBC) using the ARM cpu that run Linux quite well. I made the choice to go with the TS7260 from Technologic Systems.

Basic specs:
  • 200 MHz ARM cpu
  • on board ethernet
  • on board USB
  • PC104 bus to allow for expansion options
  • 64MB RAM
  • 32MB Flash memory
Running Linux means development and debugging should go much more smoothly. Code can be compiled using a cross compiler on my desktop Linux system and copied over to the ARM for testing. For the early development work I am running the ARM booted with the root filesystem over NFS but I will move over the the flash filesystem when the initial kernel and driver work is complete. Having onboard USB will allow me to use wirless networking so I can log in and debug code _while_ the robot is moving about. I also plan on using a USB memory stick for additional filesystem space since the 32MB flash will be tight.

The one downside of the Technologic Systems boards is they only support a 2.4 Linux kernel. With the help of others on the discussion group and a lot of digging I was able to cobble together a set of patches for the 2.6.20 kernel.