I was able to get ROS to Run!

Ok, after some fear that I would be having difficulty getting ROS up and running on my Ubuntu Laptop, I am pleased to report that everything works just fine. I was able to go through a number of the tutorials, including the TurtleSim routines. The OS is interesting in the way that it communicates between nodes. My next endeavor will be to get the webcam working via ROS on the Ubuntu Laptop. I will be following the routines mentioned in the "I Love Robots" website for video. More Later.

Still Waiting ... Now Into Setting Up Environments

I am still waiting for the KIPR Open Ruleset to be placed online.  Gee, it sounds like I am chomping at the bit on this one.  It would be disastrous if I discovered that I wasn't smart enough to solve the riddle that is KIPR Open.  Luckily, I have a whole bunch of people that I can tap into for advice on this one.  I also have quite a few that have volunteered to help me put the robot(s) together.  I still don't know what strategy to use or the number of robots that I will need for the competition.  That will also probably change as the rules are changed during these next few months.  I will be concentrating on the programming environments for the Ubuntu Laptop, the Chumby, and the Command Module.  I have already loaded ROS onto the Ubuntu Laptop.  I was surprised at how large it is when you add the complete ubuntu environment to it.  I need to make sure that it will fit on the Chumby in the near future.  I have started to look at the ROS site to see how they managed to get ROS on the Beagle Board and on other embedded Linux boards.  That would be closer to what I have to deal with.  The neat thing is that if I can get the Chumby setup, at least in a minimal configuration, I will be able to try out some algorithms on the Laptop and use the ROS elements to communicate with the Chumby to execute the overall program.  That way, I will have experience in setting up ROS on a smaller base and have some programming background when I actually do get around to figuring out what to do with the KIPR Open ruleset.  I'm keeping my fingers crossed.

Tales of Getting ROS to run on my Ubuntu Laptop

Ok, admittedly much of what I say in this tome actually doesn't have anything at all to do with installing and running ROS, but has everything to do with the Ubuntu Laptop that I own.  My Ubuntu Laptop is an old Gateway 450ROG which I bought second hand from my company after they decided to get rid of them at auction.  I decided to use a different hard disk to put a new copy of Ubuntu and ROS onto.  The steps were as follows:

(1) I originally wanted to use a PATA 250GB drive that I picked up from Micro Center.  Much to my dismay, I have been almost completely unable to install Ubuntu using this drive.  So much for downwards compatibility! I also tried using an 80GB drive that I had lying around that was not being used.  So I went back to the 250GB drive and this time it worked!  The install of Ubuntu 10.04 worked correctly.
(2) Next, I went through the Ubuntu instructions for the install of ROS which involves first adding a sources list to apt-get and getting a key from the ROS site into apt-key.  Once I had that I tried to do an apt-get update which worked.  When I attempted to install ros-cturtle-base I was confronted with a three hour delay brought on by my initial install of Ubuntu onto the drive.  Since I am currently at work, I will have to wait until I get home to accomplish that feat.  However, it looks like I will be more successful now that the Ubuntu install is working correctly.
(3) At home, which has a faster connection than at work, I was able to get the entire Ubuntu Laptop up to speed and install the ros-cturtle-base with no problems.  I have not had a chance to check out the installation yet, but I will probably try out the image processing routines first.  The reason for this is that I do not have to have a robot or various servos connected to check the execution.  I was able to get my Microsoft LifeCam Cinema to work with standard Ubuntu routines so I am hopeful of success over the weekend.

Still no word on KIPR Open ruleset

Well, it is the 20th of September and I still have not seen anything posted involving the 2011 KIPR Open rules.  I was kind of hoping that I would get to see the rules before I have to go into a CISSP class starting in October that will stretch until December.  I figure that they may be having trouble coming up with a "new and better way" to confuse the old-timers.  There has been a significant push on the part of the designers to get AI into the mix, come hook or crook.  The last KIPR Open really did require a lot of thought and even though I didn't participate, I was pretty impressed with the challenge.  However, since I am new to this whole thing, I would like to be able to plan out a strategy for winning and determine what I need to build in order to achieve the strategy.  I have a number of people waiting in the wings who want to participate with me on this.  I might not get to help out the BotBall team as much as I would like because they seem to be headed to the "directly after school" type meeting.  That would be difficult for me to attend because of my work schedule.  Hurry up KIPR Open, I want to be able to address the challenge!

Trying to put together parts

Ok, tried to put together some of the Lynxmotion parts that I ordered today. I forgot how difficult it is to put together tiny parts when you are as old as I am. I have large hands and that works against you as well. My grandson and I used the Pololu servo controller with the canned program for controlling via a slider with two of the servos. That worked very well. This was when the servos were not connected in any of the metal parts. We put together part of a robotic arm and again tested the movement of the servos. We discovered that I had ordered the wrong parts. I actually needed the long "C" brackets instead of the short ones. Part of this misunderstanding came about because I did not realize how small the parts were from Lynxmotion. Well, nothing that I can do about that right now. I will order more parts so that I can complete the robotic arm.

Different Servo Controller Ordered

Ok, I have put decision to action and have ordered the Lynxmotion SSC-32 servo controller.  On a side note, one of the articles that I have been looking at on Kinematics calculations mentions the SSC-32 in the writeup.  After reviewing the capabilities of this controller, I have discovered that the controller is capable of more than just controlling a single servo at a time, in fact, it can control several servos at once and has the ability to reprogram an EPROM to allow for customized changes.  Not sure what to do with the Pololu servo controller at this point.  I will probably keep it around for other experiments or maybe something that doesn't require a different processor.

Ok Altering the Servo Controller To Save Time

I have decided to change my mind and go with the Lynxmotion servo controller instead of the one from Pololu. I don't feel like taking the time to re-invent the wheel just because I need to have the system work on a couple of different processors. The Lynxmotion SSC-32 is a bit larger than the Pololu Maestro but I think the open functionality will make it more worthwhile. The Pololu is not wrong in and of itself, there was a design decision made and it does not fit with what I am doing. I want a drop in and play device. I will make my own set of classes to deal with the servo control but I don't want to have to re-do an interface package just to work with my robots.

Found an Intriguing Issue with Servo Controller

I didn't take the time to really review all of the capabilities of the Pololu 18-channel Maestro Servo Controller.  That was an unfortunate mistake.  I could have saved myself some headache with that one.  The problem is that the Maestro SDK assumes an i386 processor architecture, not one based on an AVR or a ARM.  In fact their example code is C# based, not C based and makes use of some DLLs (either Windows or Mono .NET emulation).  You can use C and a serial link to control the Maestro, but it works with the default settings - there is no way outside of USB to reset how the servo controller works with it's specific capabilities.  I need the servo controller to be able to play with multiple different processor groups for test and development.  That is the reason that I originally went for the USB/serial nature of the Maestro.  But the other discovery was buried in the user manual (which admittedly I should have read).  I have the iRobot Create Command Module (AVR) and the Chumby (ARM) which I wanted to interface with, but now I am going to have to rethink my strategy.  There will be times that I will want to use an Ubuntu based laptop for control, but not all the time.

What I did find on the forum were some very helpful employees from Pololu who were able to steer individuals in the direction of what to do with their C code to control the Maestro.  I may attempt this route, I might develop a USB package under general Linux to meet their command structure, or I might regroup and go back to a different servo controller such as the one from Lynxmotion (SSC-32) which seems to do most of what I want to do with a simplified serial interface.  I don't have a lot of time to be fiddling with the interface to the system that I am trying to build and I still want to hold on to the USB interface nature if I can.  Having a USB to serial interface cable in the mix is not a problem for me, it just adds a little more weight that will have to be compensated for.

I also failed to order a cable for the IR Distance sensor so I will have to wait for that with the next order that I make.  Lessons learned.

Interfaces As They Currently Stand

Settling in on the use of a USB interface was actually a good idea. I may have trouble later on because of latency, but in terms of testing and experimentation, this is turning out to be a very good decision. It turns out that I can do a "table test" with some of the gear hooked up to my Ubuntu laptop via the USB cable into the USB Hub to get the overall structure of the software running correctly. I can then port the software over to the Chumby and test it further from an autonomous view. Since pretty much everything is USB connected, I can perform this type of integration testing in independent chunks with all of the equipment. It even allows me to add parts later on as they are needed and I become more familiar with their characteristics. The only thing that is annoying me right at the moment is the amount of power that will be consumed by the Pololu servo controller. I may end up having to add an extra battery somewhere in the mix, perhaps connected to the USB Hub or directly to the servo controller. I also have one more USB Hub port available to me for an extra USB drive or another camera (stereo?). I will visit this again later.

As an interim measure, I will probably make a simple routine that passes information via Wi-Fi from my Ubuntu laptop to the Chumby and directly to the USB port on the Chumby. The main idea here is to add the capability to have an tether-less interface to the Ubuntu laptop for integration testing. This will increase the overall testing and experimentation capabilities of the setup.

Might Have to Get Busy After All

Well, with parts showing up as rapidly as they have, I am going to have to up the amount of time that I spend on Robotics at home.  I really need to get the iRobot Create tested through a couple of different programming mechanisms.  I was not able to work with my grandson last weekend due to several personal events happening.  I probably won't get to work on it this coming weekend due to the Hurricane and Labor Day.  I can only dream can't I?  On a lighter note, I have a couple more individuals interested in working with me on the Robot from the family.  I will probably need all the help I can get.