Was Able to Get BAM working with iRobot Create

I just ran a couple of quick checks at home with both my work laptop (Windows XP) and the Ubuntu Laptop. I used RealTerm on the Windows laptop and was met with some success using "128 132 136 4" as the series of commands: start, go to full, execute figure 8 pattern. All I had to do was plug in the BAM, connect the Bluetooth via 0000, and send out the byte stream (not ASCII characters). Using the Ubuntu Laptop was pretty much the same, plugged in the Class III bluetooth dongle, connect the Bluetooth via 0000, and send out a hex series using the moserial Terminal emulator with "80848804". The Class III bluetooth dongle gives a max range of 300 feet. Now that I know that I can communicate with the BAM on the iRobot Create, I can now get down to writing some interface code. I will probably base much of the interface code off of the libiRobot package by USC's ILab. I would rather start from a package that I know works than write my own right now. I have a lot of other levels of software to go through before I can claim success. It might seem like I am far behind but I am trying to concentrate on the software architecture with the inference network as opposed to putting code at the bottom layer. I am almost at the point of testing the inference network classes.

Changes to Arm and Updates

I modified the robotic arm to only have 5 DOF capability due to arm loading issues.  I also purchased a Chumby Hacker Board to control a second robot. I need the second board to start working on the networking capability with the bots for the competition.  Right now I need to get on the stick and get some designs done.  I have been working on the software architecture which includes a statechart mechanism and a blackboard system.  The two of these will go hand in hand to get the overall architecture going. Right now I am also getting some updates and configurations for the development system on the Ubuntu Laptop up and running. I will begin working on compiling a kernel for the CHB and for the Chumby One that I have. I have also ordered a BAM and bluetooth USB connector for connecting to the iRobot Create without a physical connection.

No Robotics Club Meeting This Week Due to Thanksgiving Holiday

I have received word that because WT Woodson is having a half day on Wednesday, and the fact that the next day is Thanksgiving, the Robotics Club meeting is canceled for this week.  That is actually a good thing because I need the time to work on the camera issues and finish up the Chumby ROS software load.  I am hoping to get this settled by the weekend.  I still have a self-deadline of December 9 to get my top level design together for the KIPR Open and I need all the time that I can get to make this date.

Washout under florescent lights!

Once I had BotGuy, an example orange ping-pong ball, and the maroon cube that will be used in the KIPR Open, I proceeded to try some quick tests with several webcams.



What I noticed was that under medium florescent lights, the maroon cube goes almost dark because it absorbs light, BotGuy has an intense reflection from his chest, and the ping-pong ball exhibits a lot of specular reflection rendering it almost white to the camera. This will be much more pronounced in the glaring lights during the KIPR Open. I also cannot rule out that the location where the Game will be held will not have a lot of natural lighting as well, compounding the problem. This is going to raise some interesting issues in the image processing. I most certainly will have to switch from RGB processing to HSV in order to account for the light levels. This will involve a little more processing than I wanted to do, but it will be worth it in the end. HSV stands for hue, saturation, and value. I should be able to pull out colors in the scene without having to deal with the light intensity levels.

Update: this situation is even more pronounced on the Clique Cam00131 Webcam (part of the CBC package). The above picture was taken using a Microsoft Lifecam Cinema HD. I was going to use the Clique webcam but when I saw the washout I knew that I needed to concentrate on the image processing.

Trying an Honest Analysis of the KIPR Open Game Description

When the KIPR Open game description (Game Description) came out on Thursday of this week I was elated.  However, now that I have it in my hands the real test of engineering begins.  First things first, do an analysis of the game and define the problem to be solved and possible scenarios that might happen and possible ways of solving the problem.  This is not a trivial pursuit, nor is it an over complicated one.  I have many individuals who are interested in participating in this with me and I don't want to disappoint them.  I do need to have a firm idea in my head of the challenge and what it really means.  I am a software architect most of the time and I want to be sure that I nail the architecture with the robots down on this one.  There needs to be some planning intel on the part of the robots in the game and that needs to be done smartly.  Also need to set up a plan on the Robotics Club website along with an interaction area (closed to public of course).

I will be going over this analysis with the Woodson Seniors on Wednesday.  Hopefully we can have a meaningful conversation about it and make a determination of whom will be working on it with me.

Boost is Compiled ... On to ROS

I would like to thank Ken (apparently from Chumby Industries) for stepping in and giving me a solution to the Boost compile problem. I was able to compile it with some variation on his instructions. Apparently I have to have Boost Signals compiled. Now I am going through the compile for ROS itself. I am using a variation on the gumros shell script (which I will post later). The current problem centers around the gTest program which tests some of the ROS framework. I will post the errors later. Right now I need to get some sleep.

Some System Updates ... HTTP Server on Chumby

This weekend has been pretty hectic and I have not really had much of a chance to do much on the robotics project. I updated the software suite on the Chumby and actually got a copy of the lighttpd web server running based on instructions at Chumby as a web server. Gotta hand it to the Chumby folks, their instructions are pretty easy to follow. The web server will come in handy to set up parameters prior to the competition. Also need to lock down the wi-fi capability so that only my guys will be able to control the bots.

In light of the KIPR Open ruleset, I have been trying to come up with a top level architecture to suit the design of the robots. Yep, I have decided that I need more than one to do the job. One of the overall criteria is that the robots must react to events that they have no control over, hence this is going to force me into some AI programming. Wish me luck, I have an architecture in mind but I am not sure that I can explain it to the Woodson Seniors so that they can get a grasp of how it fits into the problem. Anyway, I have to watch what I say on this website from here on out since I do have competition waiting in the wings.

Woo Hoo ... KIPR Open Rules Posted

Well, alright!  The first iteration of the KIPR Open Ruleset have been posted at http://kipr.org/kipr_open.  I just did download them and need some time to read and sort the challenge out in my mind.  More later.

Still Cannot Get Boost to Link on ARM Platform

Well, truth be known, I was unable to get Boost to link after performing a cross compile for the Chumby. It appears that the holdup of getting to compiling the ROS material using my GNU Toolchain is Bzip2. The output of the linking indicates that it cannot find the library for Bzip2. I have tried everything that I know of to prevent the linking from adding Bzip2 to the mix but have failed miserably. I will now have to wait until the weekend to complete the compile process. Wish me luck!

Made Some Modifications to the Robot Arm

I received a package early on Friday with some new parts for the Robotic Arm. One of the things that I was after was to increase the torque on the shoulder and elbow servos. You can see in this picture that the new shoulder servo is rather big.





This particular view shows the larger servo and the fact that I moved the shoulder servo to the elbow. That effectively increases the torque in both joints and should give me a better chance to have the Robotic Arm work correctly. I also added some mechanical dampeners to both of the joints to effectively help the servos maintain their positions. I have to be careful however because tightening the dampeners too much will burn out the servos. The mechanical dampeners were based on two pieces of lexan, screwed together on either side of the "C" clamps. Now on to finishing the assembly and final checkout.

Thinking of Some Mods to the Chumby after porting ROS

It has occurred to me that I should have a way of keeping the functionality of the Chumby intact, i.e. being able to run the Flash Apps, as well as changing the Chumby to be able to operate in several modes for robotics work.  The key is probably in the debugchumby file on a spare USB drive.  I think that I need the following cases:

(1) Set up files to put the Chumby in a "normal" mode, with connections to the work wireless via a capture port
(2) Set up files to put the Chumby in a "normal" mode, but having a wireless access port / USB ethernet capability (for home use)
(3) Set up files to put the Chumby in a "robotics" mode, having a wireless access port, no ethernet, not running Flash Apps, with a web server, with ROS routines launched and connection to external Ubuntu Laptop running ROS routines and/or downloading of software loads
(4) Set up files to put the Chumby in a "robotics" mode, not running Flash Apps, launching internal ROS routines (totally autonomous)
(5) Set up files to put the Chumby in a "robotics" mode, having a wireless access port, no ethernet, not running Flash Apps, launching internal ROS routines (totally autonomous) [mode for communicating with other robots running ROS]

The deal is to have each of these setups available on separate USB drives with the proviso that they put the Chumby into a known state before setting up the mode.  I will attempt to do this with some scripts in the debugchumby script on the drive.

Robotics Club and More Updates on the Chumby

Had a good time with the WT Woodson Robotics Club this afternoon. It never ceases to amaze me how focused everyone can become when they have something they really like to do. This evening's activities are to setup a toolchain on the Ubuntu Laptop and attempt to cross compile the ROS system for the Chumby.

(1) Downloaded and setup the toolchain on the Ubuntu Laptop re: Chumby GNU Toolchain. Following the directions and everything appears to be set up correctly, including the symbolic links to the compilers, etc.

(2) Went back and wiped out what I had attempted to do over the weekend with the gumros.sh file (converting to have it do the chumbyros build). The reason for this is that I have a new compiler setup for the arm processor in the Chumby and I want to make sure that it is right. This is for a cross compiler system for the Chumby. I was able to compile and link apr-1.4.2, apr-util-1.3.10, apache-log4cxx-0.10.0, and then had a compile failure on boost. I will have to meter the output of the compile to see what went wrong.

It's late and I will get back to this on the weekend.

Ordered a Stronger Servo for the Robotic Arm

Ok, I broke down and ordered a stronger Servo to use with the Robotic Arm.  The current set of servos are not strong enough to pick up the weight of the new wrist rotator, much less pick up a weight.  I am just trying to get to the point of picking up around 2 oz without breaking the bank.  The parts are ordered on a 3 day turn-around, however, the place that I am ordering it from, Lynxmotion, does not do a very good job of putting your order status online, nor do they share the tracking information until after the goods are delivered. Very bad policy.

I am also contemplating buying an additional Chumby One for use with a separate robot in the future, possibly a wheeled vehicle, and to make it available to the Robotics Club for their experimentation purposes.  Still need to consider the wedge robot for defense. Gotta save a little more coin however.

Backed up and Updated Chumby microSD

The wife is out to get her hair done and I am here trying to get the Chumby drives backed up. I was referencing the excellent article by Bob Smith, "Control a Robot using a Chumby." So here are the things that I was doing:

(1) Power off, popped the back off of the Chumby One, removed the bottom, and removed the microSD from it's slot. Put the microSD into the reader on the Ubuntu Laptop and executed the following:

cd ~/Documents
mkdir OldChumbySDs
cd OldChumbySDs
sudo fdisk -l /dev/sde
sudo dd if=/dev/sde of=Chumby_Disk_101030_0.img

The fdisk identifies the partitions from the Chumby microSD and the dd command will make an image of the entire disk in the OldChumbySDs directory. The /dev/sde may vary from one computer to another. The fdisk command returned the following:

Disk /dev/sde: 3965 MB, 3965190144 bytes
5 heads, 4 sectors/track, 387225 cylinders
Units = cylinders of 20 * 512 = 10240 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 1 14670 146697+ 53 OnTrack DM6 Aux3
/dev/sde2 1563 14063 125000+ 83 Linux
/dev/sde3 14063 26563 125000+ 83 Linux
/dev/sde4 26563 99073 725092 5 Extended
/dev/sde5 26564 39063 124998+ 83 Linux
/dev/sde6 39064 99073 600089+ 83 Linux

I am not really sure about the Id 53 here but I will take their word for it. Since I am interested in making the partitions a little bigger, I chose to also execute the following:

sudo dd if=/dev/sde1 of=Chumby_Disk_101030_1.img
sudo dd if=/dev/sde2 of=Chumby_Disk_101030_2.img
sudo dd if=/dev/sde3 of=Chumby_Disk_101030_3.img
sudo dd if=/dev/sde5 of=Chumby_Disk_101030_5.img
sudo dd if=/dev/sde6 of=Chumby_Disk_101030_6.img

Now I have a copy of each of the partitions on the microSD. I also find it interesting that the last update I did of the microSD, when I copied over from the original microSD in the Chumby did not take up the whole 4GB of the card. So I did something wrong the last time around.
(2) Now that I have a backup in place, I put a 4GB microSD into the drive and proceeded to update and make new partitions by using fdisk in the command line mode. This was necessary to get partition 1 to be type 0x53. Then I executed the following commands to copy the partition information:

sudo dd if=Chumby_Disk_101030_1.img of=/dev/sde1
sudo dd if=Chumby_Disk_101030_2.img of=/dev/sde2
sudo dd if=Chumby_Disk_101030_3.img of=/dev/sde3
sudo dd if=Chumby_Disk_101030_5.img of=/dev/sde5
sudo dd if=Chumby_Disk_101030_6.img of=/dev/sde6
sudo e2fsck -f /dev/sde2
sudo resize2fs /dev/sde2
sudo e2fsck -f /dev/sde3
sudo resize2fs /dev/sde3
sudo e2fsck -f /dev/sde5
sudo resize2fs /dev/sde5
sudo e2fsck -f /dev/sde6
sudo resize2fs /dev/sde6

What the previous e2fsck and resize2fs commands do is first check the file system on the partition (e2fsck)and then maximize it to the size of the partition (resize2fs). Seems to work correctly.
(3) put the new microSD card back into the Chumby and fired it up. It proceeded to work just like a Chumby, so first part of mission accomplished - I got the partitions to be larger on a new microSD. The sshd, access port, and ethernet connections work correctly.

Got Access Port and Ethernet working from Chumby

This evening I added a USB to Ethernet adapter and reset the control panel to interface through it. I was surprised that the ethernet connection showed up because I thought that I might have trouble with the type of cable. I used a cheap ($34.99), generic USB to Ethernet adapter [Intellinet 503686 Hi-speed USB 2.0 to Fast Ethernet Adapter] and it seemed to work just fine. I also re-added the /psp/start_ap file and rebooted and the access port came up just fine. So now I have another access port to play around with. In this case, I wanted the access port because I need it to play point of contact for my robot.

I have the Ethernet adapter plugged into the non-powered USB hub along with the lifecam camera. Now I need to search for a driver to allow the camera to work with the Chumby in preparation for porting the ROS.

The Ethernet address chosen by my home system is 192.168.0.135 and the wi-fi access port address is 10.0.50.1, which is probably a default. I noted from a check of what daemons were running that a dhcp server is also running. When I connected to the AP via my laptop it gave me an ip address of 10.0.50.199, again probably a default. Everything works much as an AP would, I was able to get to the internet through firefox and other programs. I was also able to go into the SSH server at 10.0.50.1, so I am pretty much assured that it works correctly. The dhcp server appears to be udhcpc. On my laptop the resolv.conf has a nameserver address of 10.0.50.1 and the Chumby shows my home nameserver and Domain name. I gotta hand it to the Chumby guys, they did a nice job with this.

Getting some video from my lifecam might be a bit of a trip though. I did determine that a USB drive would post and come up mounted correctly. I put a USB drive into the hub and it came up as /dev/sda1 and mounted as /mnt/usb-0000-0484. I then recompiled the lighttpd web server to the usb drive. I followed the commands at Chumby_as_a_web_server. Since I had gone through the process once before, I knew that it would come out correct. I now have a web server that I will test on another night.

Mod to Chumby for SSH Server and Access Port

This evening I tried to modify the Chumby a little by adding a capability to run the ssh server and make it into a access point normally. The Chumby has a few easter eggs to allow it to do some cool things. To launch the ssh server on a normal basis you simply make a file called start_sshd in the /psp directory:

touch /psp/start_sshd

this will cause the Chumby to launch its sshd server each time that it boots up. In order to setup the access point you make an additional file called start_ap in the /psp directory:

touch /psp/start_ap
reboot

To stop each one of these, you remove the files and reboot. The access point did not come up so I removed the launch file for it. I need to revisit and make the output go into a ethernet port.

I didn't realize how big that ROS was

I am in the process of updating my Ubuntu Laptop at work.  Part of that process is to update the files on my system that need updating.  There were a number of the Robot Operating System (ROS) files that needed updating as well.  I was wondering why it was taking so long for the update to complete when I looked at the listing and noticed that most of the ROS files were large.  For instance:

(1) ros-cturtle-point-cloud-perception is 56.5 MB
(2) ros-ctrutle-visualization is 44.5 MB
(3) ros-cturtle-navigation is 9.5 MB
(4) ros-cturtle-laser-pipeline is 6.7 MB (probably will never be used)
(5) ros-cturtle-visualization-tutorials is 308K (not a problem)
(6) ros-cturtle-simulator-gazebo is 146 MB (will never be loaded onto the Chumby)

Given some of these sizes that are reported, I can see why people have been having problems putting the ROS package onto an embedded system.  I am however going to take the tack of shoehorning the code onto the Chumby as best I can and try and figure out what parts will be missing after I get the initial set online.  If the packages are too big, I will end up having to abandon ROS and go to something smaller.  At the moment, since I know that ROS has been put on the Beagle Board and the Gum Stick I have faith that I will be able to add it to the Chumby mix.  I really need to test this out over the weekend.

Added wrist rotate to robotic arm proto 2

Over the weekend, I had a chance to modify the Robotic Arm Prototype and add a wrist rotation servo and accompanying gears.  I also shortened the forearm part of the robotic arm to take some of the stress off of the elbow servo.  In addition, I changed out the shoulder servo to a higher torque model to help with the stability of the robot.  Unfortunately, due to many things that I had to get done over the weekend, I did not have time to check out the functioning of the arm with the Laptop and SSC-32.  I really need to check out the moment arm equations to see if the servo torque values are correct for this Prototype version 2.  Maybe I will have time to do that tonight after work.

Another day of not working on the robot

Today was the second class in my pursuit of a CISSP certification. It was all I could do to get my work done and then get home in enough time to change clothes, eat, and sit down in front of the computer for the class. I did think a lot about what I should be doing, but I did not accomplish much. Most days are going to be that way, I am afraid. I think that some of my original plans to explore the robotic arm and a pan/tilt camera control were essentially good ideas, I just need more time to get them accomplished. Hopefully this weekend will be different and I will be able to push harder. The plans for this weekend include more testing of connections between the Laptop and the servos that need controlling, finish the 2nd prototype of the robotic arm, change out the 4GB microSD chip in the Chumby and start attempting to get ROS installed. I need to concentrate on getting the Chumby to control some of the servos and at least some of the sensors. I am hoping there will be enough horsepower in the Chumby to accomplish these things. If not, I will be spending even more money to figure out a solution. All this without completely knowing what the KIPR Open ruleset entails.

The KIPR Open announcement appears to be getting closer

Well boys and girls, there were two changes to the KIPR Open announcement pages this morning.  The page at http://www.botball.org/kipr_open changed to say that it was imminent and it then points to the page at http://kipr.org/kipr_open to announce the game.  Can't wait to see what they have come up with.

Some test done over the weekend

I was rather busy this weekend and although I had my grandson with me I did not get into any robotics with him.  It wasn't until Columbus Day that I had a chance to work on the robot.  I did manage to test out some of the parts.  I removed the long arm on the robotic arm, leaving the base and elbow portions.  With that I had a total of three servos to try out the SSC-32 servo control from the Ubuntu Laptop.  I used the battery setup that I had made for the Pololu and connected it to the SSC-32 for power through two pins that I scavenged from an old modem printed circuit card.  By putting a serial terminal on the laptop and setting it up for 115K I was able to send serial commands to the SSC-32 to control each of the three servos.  That is when I realized that there was a bit more to changing the pulse width than I had thought.  The SSC-32 is capable of adding offsets to get the alignment of the servos correct.  Originally I had set the robotic arm up to have essentially 90 degree angles to deal with.  However, the weight of the long part of the arm caused the servos to dip by themselves.  Yesterday I had a package arrive from Lynxmotion which contained a set of gears to turn the claw plus or minus 90 degrees and some shorter aluminum tubes so that the moment arm would not be so great on the robotic arm.  I perhaps will have to invest in some stronger servos and different clamps in order to get the robotic arm to be more robust.  For right now, I just want to be able to play around with the concept.  I also was able to purchase another servo over the weekend to use with the webcam in order to form a pan/tilt unit.  I will work on the pan/tilt unit tonight.  My goal is to get some image processing up and running using the pan/tilt unit to move the webcam towards a specific colored object.  This is one of the experiments that I want to accomplish in preparation for the KIPR Open since I know that color will be a deciding factor.

WT Woodson Robotics Club not meeting today

I will not have a chance to get to the Robotics Club today, the PSATs are being given at the school and they take precedence.  I was partially prepared to talk more to some of the seniors about the KIPR Open competition, but now this break will give me some more time.

Met with the WT Woodson Robotics Club Today

I had my first meeting with the WT Woodson Robotics Club today. I was not able to get to the kick off or to last week's demo due to work commitments. I mostly went around looking at the electronics lab and robotics lab setups. The gang were busy building robots as an exercise. The teacher let me know that the club would be participating in a robotic exercise starting in November, so the amount of activity in the club has increased dramatically. I overheard that there are about three times the number of students signed up than there were last year. That is a great achievement and reflects greatly on the students that were in the club last year getting the word out. I got to meet a few of them and was able to talk about some of my ideas for the KIPR Open. I let the teacher know that I had the okay to come and help on Wednesdays. Most of the other days I am tied up doing one thing or another at work and I now have classes on Tuesdays and Thursdays until the end of the year.

I have a feeling that I will not be shy of students that want to help with the robots for the KIPR Open this year. So, I am committed to getting everyone involved as soon as I know what the challenge is. That should be arriving next week and will give me a chance to study tactics before I meet with the group. I am hoping that I will be able to contribute as much as I can to help with everyones interest in robotics. It looks like it is going to be an interesting year.

A Gracious Post from Steve on the KIPR Open

Many thanks to Steve for letting me know that the KIPR Open ruleset should be available in mid-October. That is great news! Now I have to rally the troops at home to be ready to figure this thing out. Ok, I'm stoked. Of course, when I see how difficult it really is I might change my mind but right now I am looking forward to it.

Almost Completed the 1st Prototype Arm

I was able to get the first prototype of the Robotic Arm almost put together. This is a five DOF arm and I believe that the arm is a little too heavy to work correctly, even with the offset springs. I will try this out again this week and in the mean time, I will order other parts to make the forearm shorter to keep the servos from drooping. I just want to try it out for size and usage. Thereafter, I will be converting the arm to something more useful as soon as I see the new ruleset.

Test Architecture is Starting to Take Shape

I am currently interested in getting the test architecture setup to the initial robot design.  Right now I have settled on an interface over wi-fi between the Ubuntu Laptop and the Chumby.  The Chumby will be the interface to the iRobot Create, the robotic arm/servos, the light sensors, the single line detectors, the IR Optical Range Finder, and the webcam.  I need to make sure that the Chumby will both connect and communicate with the Ubuntu Laptop.  The first step is therefore to ensure that all of the interfaces via the USB work correctly.  I will do that with testing on the Ubuntu Laptop via Ubuntu and then via ROS.  The next step is to get ROS working on the Chumby and ensure that the Ubuntu Laptop and the Chumby communicate via ROS.  I will then move the ROS routines for interfacing to the sensors to the Chumby and attempt a checkout there.  That will be followed by interfacing to the sensors through a user interface on the Ubuntu Laptop then through ROS through wi-fi to the Chumby through ROS to the sensors.

This setup will allow me to make major adjustments to the programming on the Ubuntu Laptop and then check it out with the ROS connection.  As the programming portions become more mature I will port them to the Chumby, eventually having all of the routines on the Chumby.  This will also prove to me that I can interface between different robots via ROS.

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.

Ordering Some Parts for Robot

I think that I will take the time and order some parts for the Create. I am looking to order enough servos and metal to build a pan/tilt unit to mount a webcam on. I will also have to order some servo controllers as well. I will try to keep the cost down but who knows.

Update: Ordered $74 worth of brackets and servos from Lynxmotion. I realize that I can get a pan/tilt for less, but I wanted to order the parts from the same place that I will be ordering parts for the Robot Arm from so they will be interchangeable. I of course need a webcam and a servo controller to use with this setup. I could of course use some of the lines from the iRobot Create, but I don't want to have to do too much electronic design, although I could - might be fun too.

Update: The parts should be in on Aug 30. I ordered L and C brackets (2 ea), multi-purpose servo brackets (2 ea), and 2 HS-485HB standard servos. I ordered a servo controller from a different source (Pololu 18 channel) along with an IR distance detector. Those parts came to $49. The shipment should come in later in the week.

Update: Parts from Lynxmotion showed up on Aug 31, I guess that I didn't give it enough time. I was all set to complain because their website said that they had not shipped yet when the parts arrived. The remaining parts are slated to come in on Sep 3. I also ordered another set of brackets and servos from Lynxmotion. These will probably show up on Sep 6 since I ordered them late. Give Lynxmotion a try, they do get things out the door after all!

Tests for this Weekend

In the spirit of doing a kick start to get my butt on the move, my grandson will be spending the weekend with us and I am going to take the opportunity to work with him on the iRobot Create. I now have a battery and battery charger for the Chumby so I should be able to do the following:

(1) Test the iRobot Create Command Module development environment by compiling a few of the Create test programs and downloading them to the Command Module and executing. This should enable us to be able to try out some different test sequences that we can dream up on the fly, program, and download.
(2) Test the Chumby development environment by writing a test program to be executed via the USB-Serial cable from the Chumby to the iRobot Create. This should enable us to be able to command the Create via the Chumby through the serial cable. I would like to try out some of the test sequences that we did through the Command Module this way.

The first test should be straight forward except for communicating with the Command Module via a USB cable on the Ubuntu Laptop. I already have the test environment made, I just have not tested it out yet. Maybe I might try out the connection tonight after dinner just to make sure that it is working correctly and to see what problems show up (guaranteed to happen). The second test will make sure that I know how to find my way around the Chumby development environment and how to command the USB-Serial line correctly. That last part will probably be the kicker to getting a decent test sometime during the weekend. And oh yea, I have some work-work that I have to get done as well.

Robotic Arms are Expensive!

Well, if truth be known, I have finally come to the conclusion that robotic arms are expensive. By the time that you get around to ordering clamps, hardware, tubing, servos, claws, etc. you have dropped quite a bundle of money. I am still trying to decide how to proceed. Maybe I am itching to get into this too much. I really should wait on the information about the KIPR Open challenge which should come out in the early fall. I am really looking forward to that. I should probably settle on some preliminary things to add to the iRobot Create and get the robot working first. Let's see: Chumby, iRobot Create, camera, pan/tilt unit. Ok, maybe I should order up first a camera and a pan/tilt unit and get used to using those items. That might get me by for a little while. Chumby Lithium batteries should be in today. Battery charger by next week.

Discussion on Robotic Arms

I had a discussion on robotic arms with on of my engineer friends this morning. just as I suspected, I will have to take into consideration the dynamic movement of the arm with respect to the stability of the platform. I was hoping to get away with only having to consider the static case. I am concerned with the stability of the robot when moving and having the arm(s) move at the same time. This becomes very important as the number of independent movements increases - I was thinking of two independent arms on the future. So even before I begin, I need to concern myself with other problems along the way.

I'm Going To Start With Test Programs on Windows

Just to be sure that the iRobot Create is working correctly, prior to moving over to a Ubuntu based development, I am going to test a couple of the programs for the Command Module from Windows. I will be taking those very same programs and executing them from Ubuntu in the near future.

Testing Configurations and Gaining Experience with Create Functionality

I have been toying with the idea of using Bluetooth tether to run tests on the iRobot Create.  The idea is to be able to write code on a laptop and simply connect to the Create through a Bluetooth tether.  In that way, the Create could be running around and doing its thing without having a bulky serial link to the chassis.  However, this means an extra $90 to the overall cost of what I have already spent.  In essence I would have to buy a Bluetooth USB adapter for the laptop and a BAM wireless accessory for the Create.  How this works is that the BAM plugs into the 25 pin Din socket on the Create and acts like a serial connection through the Bluetooth USB adapter into the laptop.  The software on the laptop just uses this connection as though there were a serial cable connected between the Create and the laptop.  I may use this in the future, but for right now I think that I will concentrate on using the USB to serial cable that I bought originally to perform the functions.  Once I get the software running on the laptop correctly, then I can offload the same software to the Chumby and place the Chumby on the Create for a run with no tether.  In some ways this will be a better test because of the latency with Bluetooth connections.  If it turns out to be a pain in the butt, then I will buy the BAM.

emss or ROS - which will it be?

There is a class library at SourceForge called emss which was a Senior project geared towards writing a C++ library for use with the iRobot Create. I need to explore this library to see if it has any utility in the robot that I will be making. ROS has so many creative things, as well as a vibrant community of individuals who are contributing to it continually. The only difficulty is that ROS seems to be geared towards big processors and more horsepower than the little ARM processor in my Chumby. I would like to see ROS being used in a good way, perhaps being able to scale up the processing by adding one or more Chumbys to the mix. That is something to think about.

Some Thoughts on Robotic Arms

The more I think about this, the more I think it would be advantageous to have one or more robotic arms not he robot. When I got to thinking about the arm it occurred to me that perhaps I might want to consider placing the camera on the arm itself. In this way the arm could act independently of what the rest of the robot is doing. I guess in a way this is what the "Hydra" was all about in ancient mythology.The Hydra was a beast that had many heads, each was independent of the other and was supported by the body. In that way it was difficult to conquer by Hercules. In the same way, if the programming is done in an independent fashion, the robotic arms could maneuver independently of each other and therefore become much more difficult to conquer. The problems with doing such a scheme are enormous. It would require a lot more processing power than I probably have available int he power and weight budget that I have available to me. This of course does not mention the cost involved in development time and in parts (servos are not cheap). I would like to determine if this would be a good idea before I commit to buying parts to make a camera mount with multiple degrees of freedom. I note that what is possible with this setup is to have a set of routines programmed which could then be reused by the program as another instantiation. That simplifies the programming somewhat and would give me an edge if we were to decide to have even more arms. Need to think about this one a bit more.

Setup Eclipse Development IDE

My next step in the development setup process was to add Eclipse to the Ubuntu laptop. This is fairly straight forward since I could do this through the ubuntu software manager. However, to get Eclipse to work as a C/C++ IDE is another matter. It turns out that CDT is the package for Eclipse that turns it into a C/C++ IDE. To get to that you need to instal it via Eclipse from the Eclipse website. This is fairly straight forward given that there is an "Install New Software ..." menu item which can be selected. If you go to the Eclipse website and copy the PS2 ink under CDT, you can paste it into the install dialog in Eclipse and the system will take over from there. Hmmm... methinks that I will need a few other tools down the road and this will be a good place to accomplish that. My only problem now is setting up the C/C++ IDE to develop programs for three different situations. Should be interesting.

Successfully Setup Chumby Development

I am feeling pretty good right now.  I just got through setting up the GNU_toolchain and compiled the Chumby kernel on my Ubuntu laptop.  Now I just need to try the kernel out with some modifications.  I think at this point I need to write down how to perform the modifications and build the software to load to the Chumby so that I won't forget sometime later in the year as I start focusing on the KIPR Open.  I still have not tried compiling something so that the Chumby controls the iRobot Create.  That will come later.  Right now I need to concentrate on what steps need to be done to get the environment setup the way that I want them.  I am thinking that I need to find a decent IDE to perform all of the test software builds.  I also need to set up a configuration management system so that I can backtrack as necessary.  So many things to do before I really start programming.  I now have a development environment on the Chumby (for the Chumby), a development environment for the Chumby (on the Ubuntu laptop), and now I need a development environment for the iRobot Create Controller (on the Ubuntu laptop).  So far I have not been able to find anyone who has specifically set one up.  More digging is needed apparently.

iRobot Create is In!

The iRobot Create showed up at work today. I will not have time to get into it until this weekend. Such is the life of an engineer. I am concentrating on the development system for the Chumby right now. I also am going to be setting up for the iRobot Create processor, which I bought with the Create. This photo shows the iRobot Create with the various parts that I will be using for experimentation.

Got the Native Toolchain Running

I was able to get the native toolchain working on the Chumby with the instructions mentioned before from Bob Smith. This is a really well written set of instructions, fairly detailed. To repeat, the instructions are at http://www.linuxtoys.org/chumbot/chumby_as_robot.pdf. I highly recommend them. I was able to get a compile of a hello world program to work correctly. I think that my next thing would be to get the cross toolchain running on my Linux laptop. Once I get that running I should be able to try my hand at getting ROS compiled. I might try some other things first just to get my hands wet with the overall development environment and moving things around. Time will tell.

Got the Chumby to Work on a 4GB micro-SD

Wow, I was able to get the Chumby to work on a 4GB micro-SD chip. I took the 1GB micro-SD out of the Chumby and with the instructions from http://www.linuxtoys.org/chumbot/chumby_as_robot.pdf, I was able to get the 4GB micro-SD to work with the Chumby. The pdf file was notes from a lecture at the Home Brew Robotics Club that was given by Bob Smith. This is a pretty amazing set of notes. You can find pointers to the notes at http://www.demandperipherals.com. There is a second set of notes which describes the interface elements fro a robot which is based on Demand Peripherals BaseBoard4 set. In looking at the way in which the BaseBoard4 works, I am seriously considering using one of their boards to control other elements of these robots that I am thinking of building.

Essentially what I did was take the 1GB micro-SD out of the Chumby, by removing the 4 screws from the back, pulling the back away from the case, pulling the bottom panel off and away from the Chumby, and opening up the micro-SD cage cover. I then performed a "dd if=/dev/sde of=Chumby_Disk.img" to get an image of the micro-SD onto my Ubuntu laptop. I then setup the 4GB micro-SD with the same set of partitions: 3 150MB partitions and one extended partition (with a 128MB partition and a 3+GB partition with the remaining space). The only difference was that last partition space of over 3GB. I then performed a "dd if=Chumby_Disk.img of=/dev/sde" to get the image onto the 4GB micro-SD. When you boot up the Chumby, you must wait for the Chumby to finish doing its check of the micro-SD which in this case is much bigger. I can now breath a little more knowing that I can get back to the original micro-SD in a different size. I then put the original 1GB micro-SD in a safe place.

So how come you cannot buy a 1GB micro-SD any more? I wasn't able to find one anywhere. The smallest size that I was able to find was 2GB. I am of course happy with the fact that I have a 4GB micro-SD in the Chumby to play around with. More on this later.

General Robotics Interface

To illustrate what we are thinking, the following diagram shows how the tablet computer, the laptop, and the Chumby communicate to perform the functions. Notice that we are leaving the interface to the Chumby as either USB to the robotics hardware, or wireless 802.11 b/g to everything else. In this manner we have the opportunity to develop the software for the Chumby to be able to communicate not only with the controller/laptop but also with any other Chumbys on robots in the network. We are thinking of making the Chumby into a wireless access port for all of the connecting devices.

Some Thoughts on Where We are Headed ...

The iRobot Create should get here sometime today when UPS makes it's delivery to our company.  I am pretty much excited about the prospects with what I can do.  Looking back at older videos and pictures of previous Beyond BotBall and KIPR Open matches, the Create is a pretty good choice for a platform.  Even though I have ordered the iRobot Create with its own processor, I still feel that the things the Chumby brings to the table will make it a more formidable platform for next year's KIPR Open match.  I have been looking around at various open source software sites and it would seem that ROS has a fairly large following.  I am not sure that I can stuff the primary ROS into the Chumby however.  ROS has some pretty cool elements that can be used, including some AI and planning algorithms that work within the system.  ROS uses a multi-threaded operating kernel and I have been led to believe that it has been compiled before on an ARM processor, the type that runs the Chumby.  There is a growing library in ROS for interfacing with the iRobot Create.  I still need to get the development system for the Chumby up and running on my Ubuntu Laptop.  Seeing that I have chosen to use the Chumby for the processor, I will still need to have interface points to any servos or additional sensors that I may decide on using.  I am pretty sure that I will be trying to get a camera or two working to provide sensory input to the system.  In addition, I would like to try my hand at building an arm or two.  I would like to keep the USB interface as the tie in point between elements of the system.  Again, I am not sure about the Chumby and what I will be able to do with it.  If I cannot get some of these elements in place, I may be forced to use a netbook as the processor.  On the other hand, what transpires with the KIPR Open rules may keep the robot simple.  I am probably thinking overkill here.  Looking way out there, I may have time for my initial goal of building a spiderbot but that will have to wait for a while.

Hope to Run Some Initial Experiments This Weekend

Hopefully the boss will let me run some initial experiments using the iRobot Create this weekend. I might however end up cleaning out the tool room, which needs it pretty bad. However, doing the iRobot thing will be much more interesting to me. I have ordered some light sensors to go with the command module and I hope to try a couple of things with that. I will probably order the bluetooth interface so that I can command the iRobot Create through the command module without having a physical connection to the unit. That would be kind of neat. However, first things first - I need to understand what the robot is capable of doing in preparation for the KIPR Open next year. I should see signs of the gaming board in September hopefully. I currently have a note in the forum to find out if this is true. I would like to have a bit more time than what is given to the BotBall crew of 8 weeks prior to the area trials. My experience with embedded systems is pretty good, with robots, not so much. This is my chance to pick up on that and document my progress. I am going to treat this like any other engineering project with deadlines and requirements that must be adhered to.

Some Initial Chumby Experiments

I tried a couple of experiments with the Chumby today. Boy was that frustrating. I was able to get the micro-SD out of the Chumby and dd the contents of the chip onto my Ubuntu Laptop with no problem at all. The real problem is that the Chumby comes with a 1 GB micro-SD and that is a size that you pretty much cannot find anywhere. Most everything is either 2GB or 4GB in size, and obviously this means that the structure of the SD is different as well. I was able to set up a 4GB micro-SD with the requisite number of partitions (3 150MB partitions, 1 extended partition with a 128MB partition and a rest-of-the chip partition under it). However, I was not able to get the dd'ed image to copy correctly. That means that I will probably have to get each partition into a separate image and then dd them back to the new micro-SD. I am trying to do this to prove to myself that I can create a micro-SD with a copy of the original system on it. When I first copied the image back over a 4GB micro-SD it pretty much clobbered the makeup of the chip. It took a bit of time to get that one undone. I now have the correct partitions but when I do a df command, the partition information comes up incorrect for the size of the micro-SD. Back to the drawing board tomorrow. In a better note, I did find that the iRobot Create had shipped.

iRobot Create has been ordered

Well, I decided that I needed to get back into the groove and go ahead and order some more parts for the robot.  I ended up getting an iRobot Create to be controlled from the Chumby.  The cost counting shipping was $350, but I ended up with the create, a microprocessor controller, two infrared walls, a docking station (that the create can find on its own), a rechargeable battery/charger, 4th wheel, USB cable, some light sensors and an interface board.  I'm looking forward to the package arriving later in the week.  The create has a lot going for it and it merges quite nicely with ROS and other packages that are out there.  Now need to hurry up and get a programming environment setup on the Chumby.

Placing the Site Updates on Hold

The updates to this site will be coming to a screeching halt for the near future.  I will not have enough time to express what is being done in terms of the robot until the September time frame.  I will be buying an iRobot Create for the programming efforts sometime in September.  Until then, there are many higher priority efforts which need to take place.  The thinking is to get more of the family involved and describe what will be done and to get some consensus on how to proceed.  Meanwhile, both the grandson and I are swamped.

Starting to look intently at the iRobot Create

I am starting to look at the iRobot Create for the basic platform to use for the robot.  I have also been looking at other sites dealing with robot operating systems and it would seem that the Create, along with a camera, and an arm would be a good first attempt at getting ready for whatever may happen in January for the KIPR Open.  We will not know what the problem space is until January or February of 2011.  That is about the same time that the BotBall challenge will be released for the students to work on.  Until then, I should probably get an iRobot Create and get familiar with programming it, via the Chumby.

We may have others to add to the team later

I had a chance to talk to the grandson yesterday and found out that his father would probably like to participate in the robot development.  He seemed to think that his uncle would like to get involved as well.  In my head I am thinking that there may be a problem with time and getting everyone together to resolve the problem.  I also had a chance to talk to my son and even he would be interested in the development of the robot.  It is starting to look like the next KIPR Open in 2011 may have a family group participating.  I'm not sure if everyone would be able to go out to Orange County, CA next year but at least putting this thing together might be a lot of fun.

Next Up ... Hacking Chumby

Now that I have set up the Chumby for use at work (because occasionally I will want to bring it in for its normal purpose), I can concentrate on breaking into the case to see the goodies. One thing about this, I will need to make sure that I have backups and can duplicate the environment that the Chumby was developed under. That means that I need to assure myself that I can remove the original micro-SD and replace it with one that does the same thing without simply copying the information from one to another. That way I can be assured that I know enough to be dangerous. The instructions are on the Chumby wiki site to do this. If I have time over the weekend to do this I will, otherwise, it will have to wait a while. I do have some work things that I need to get accomplished in the meantime.

I Was Finally Successful with Work Chumby Hookup

As I reported previously, the capture page at work was difficult to break into.  Up until this moment I had not been able to use our guest wireless access (requiring a user name and password) which is Cisco based.  It turns out that the problem was the value that I was returning for the buttonSelected parameter. Should you feel inclined, the best way to find out what a capture page requires is to capture the POST message before it gets back to the server.  For this I used "Tamper Data" on Firefox.  What I was able to do was to see the values for each of the parameters prior to its receipt by the wireless port.  I found out that in this particular instance the buttonSelected parameter was 4.  As soon as I corrected the value in the debugchumby file on my USB drive the Chumby hooked up.  Now I can use the Chumby as advertised at work.  I wanted to make sure that I had this working because I intend to be able to get back to a regular Chumby in between efforts at building robots (yep, probably more than one now).

Decided to Hold on Tablet

I thought that I had the perfect tablet for use in controlling the spiderbot in the Panvision, but I have decided to wait based upon my decision on the simulator. That may turn into an error but it is what it is. Right now things are on an even straightaway. I need to get a lost if things to do on this site and keep it updated.

Simulation Looking Much Better as Alternative

In hindsight, what I can do is build a simulation which incorporates a minimal set of hardware parts and shows the functioning of the bot in a virtual environment. This is the cheapest way to get a spiderbot running and I can then decide if I want to pursue it further. The math equations will need to be worked out anyway (that's part of the fun). I like standing up simulations and it will still give my grandson some programming experience.

It looks like next challenge on the board is to research existing sim systems, such as Tokkotsu which is based on Player and Ogre with a physics engine. Good stuff!

I May Have to Scale Back a Little

I just did a short computation on what the hardware is going to cost to build the SpiderBot.  And for cheap, it is going to be just under $1000.  That is $200 over budget, of which I have already spent $100.  Thus I need to figure out how to save $300 to get it done.  That is why I have been thinking about buying bits and pieces and constructing the rest myself.  The problem that I forsee, is the weight of the thing.  I need to keep the weight down in order to have something that can be run with the current set of servos that are available.  This is one reason that I have been looking at trying different avenues to getting the parts.  The basic spiderbot hardware, sans servos, servo controllers, and processor is around $260.  I could live with that purchase, buying a little bit at a time.  The servos that I want cost about $40 apiece, pretty cash hungry.  So anyway, I think that I should go back to the drawing board and rethink this a little.  On a positive note, I could simulate the parts and just use the Chumby as the go between for simulating what happens to the servos and display a simulation on the screen.  In that way, I could contain the costs of the project (just takes a lot of time to program the simulation) and still use programming on the Chumby as the way to do it.

Taping into the guest account at work ...

Well crap! I seem to not be able to tap into the guest account at work. Not sure of what the problem is, I get a connection via wireless but the "debugchumby" file is not working as advertised. Seems like it is not authenticating even though I have called up the correct portions of the form. I have narrowed the problem down to the IP site that is needed to authenticate (I may not have the right ip address), or the POST message is not using the correct form name. Just a little agrivating.

The Chumby is in ...

After spending about 30 minutes at the UPS transfer point, located some 16 miles from where I wanted the Chumby delivered, I now have it in my hands. The device itself is not particularly spectacular in appearance, but it is functional. Last night, I was on the Chumby site at http://www.chumby.com and was able to set up the Chumby to download some apps from the main site. The way that they have the Chumby set up is that it will always connect with the main site. The main site for chumby.com is located in San Diego, CA 92130. That does not mean that the main server for the chumby is located in the same place, but bets are, this is the location. I only say that because the device is made in China and could potentially have a backdoor to a server in China. See how trusting I really am? I am not afraid since I don't have anything at my house worth stealing and most of my network is closed off anyway. But back to the story. My hands are off to the Chumby people in terms of their ease of setup on the device. You have to have a computer nearby to finish the setup since it does interact with the Chumby site. There is an ID number that is exchanged with the Chumby site that authenticates your new Chumby so that you can make changes to the app structure. I still have a lot of exploration to make prior to hacking the box, but it is nice to see that they have put a lot of thought into what the device is capable of doing. My gameplan is to hack the Chumby and use it as a robotics controller. the Chumby itself weighs very little, which is a great advantage. It has a wifi capability which enhances its communication power with my laptop. I have not bee successful at hooking the Chumby into our guest wireless at work due to the capture page issue. I haven't figured out what completely is needed to do that yet. The debugchumby file that I created does not hook into our Cisco system. One thing, I do not have a real good sense of the IP address of the proxy and the fact that the form is not named from the proxy may have something to do with it. More later.

Simulator

It occurred to me that I would be able to program the robot without actually building the hardware by use of a simulator. I could simulate the actions of a robot down to what you put into the servos by using some software design methods to isolate the robot hardware and simulator using an "interface" and "adapter" design pattern.

Crap ... messed up the address

I am sitting here at the dining room table. I do not have a Chumby to dissect and play with because I forgot the suite number on the shipping address. I don't know what happens now, maybe they will send the Chumby back to Costco, I don't know. It doesn't appear that they could figure out my address information. Let that be a lesson to me for future purchases.

Waiting for the UPS Truck to Arrive

Well, I am at work and waiting for the UPS truck to arrive and bring the Chumby. When I open the package I will be getting photos together so we can see what this thing is. I have pretty much decided that one of the first things that I will do is take out the micro SD and make a copy of it, just so that I have a way of getting back to ground zero. I also have convinced myself to take another micro SD and setup a development environment under Ubuntu (on my laptop) and recompile the Chumby system onto it. Has anyone here used VMworks player? I might set up a virtual development system on my XP laptop to do the Chumby work. Anyway, I want to be able to reconstruct the Chumby system at any time.

Started Looking at Equations Again

Man, I am a glutton for punishment. I am starting to research equations for spiderbot leg articulation. Seems like I am dying to get back to geometry, trig, and algebraic equations. I don't really have to deal with calculus since the spiderbot will not be doing that much change that will require the calculations. I do need to define the overall requirements for what I want to do. In a nutshell, I want to take into account errors in construction and controlling (esp. things dealing with descrete commands), and also to define everything by a central point under the spiderbot. Alignment of parts will be an issue that needs to be dealt with in any of the equations. Hey, I haven't even gotten to the part about what the bot will look like have I?

Ordered a Chumby!

In an effort to get a jump on the game, I have decided to order a Chumby (http://www.chumby.com) for myself to start some experimentation. I ordered it online from CostCo for $104.99 counting tax. The specs for this device are interesting: chumby one specs * 3.5 inch LCD color touchscreen * Access to free content * Uses rechargeable lithium ion battery (not included) * USB 2.0 high-speed port * Stereo headphone output * 2W mono speaker * Volume knob * FM radio tuner * Accelerometer (motion sensor) * Wi-fi connectivity (802.11 b/g) * USB ethernet compatible * Over-the-air software updates * Dimmable backlight * 454 MHz ARM processor * 64 MB DDR SDRAM * Internal microSD card firmware * AC adapter included * 3.5" wide x 4" tall x 3.5" deep Apparently there is instruction on the inside of the case for the compatible Lithium-Ion battery that is compatible with the circuit. I should have some fun with this.

4 Legs or Eight?

I have always been intregued by the notion that a spiderbot should have the number of legs in real life. According to the wikipedia entry at http://en.wikipedia.org/wiki/Spider, spiders have eight legs. That is probably because of the environment that they move in requires a little more dexterity and having eight legs gives them the dexterity for the task. However, since more legs will cost more money, I am willing to compromise on the leg thing. I am going to go with six legs primarily because it provides a stable platform for walking and most spiderbots that I have seen on the internet have six. This also leads to an interesting way of movement. The cockroach has six legs and moves with a combination of three legs on the ground at any one moment, giving it a very stable platform. The cockroach movement is actually two on one side with a third leg on the opposite side on the ground while the remaining legs move. It also gives the cockroach the ability to move quickly and turn quickly, something that I would like to try out. However, I am still going to refer to Bob as a SpiderBot, not a RoachBot.

Budget?

Ok, I need to limit myself to a budget to buy parts for the spiderbot. Since I am going to piecemeal the robot together I will limit the cost to $800. This is a nice round figure and represents the amount of money that I have saved up for an iPad. Sorry Apple, it looks like I will not be getting one of your got-to-have toys for myself. My wife normally limits me to buying technology with cash because she knows that I will not part with cash unless I really want something bad and I have saved up for a long time. We do have a checking account and various savings accounts and credit cards but I refuse to use them for something like this. By reacting that way, I have been able to maintain a minimum of debt for a long time. Mortgage is paid off by the way so I do have a bit of other cash floating around. So $800 limit it is.

Next on the Horizon - Robot Choice!

I can't help but notice that there are innumerable options for building robots. As I look around the internet it occurs to me that there are parts and kits and ideas that pop up, giving me a headache just thinking about the options available. I think that what I will do is go for a robot type that I have always wanted to be able to build, a Spider Robot or SpiderBot for short. I think that this will be my goal. Not only will my grandson and I have to figure out how to make this robot walk, but we might even be able to give the robot some character. I think that I will name him Bob, just because that is typical of the walk of most SpiderBots. I am not sure that a spiderbot will be allowed to compete in the KIPR Open next year in Orange County, CA but I think that I have a reasonable choice made. I do reserve the right to change my mind as time and cost go along.

Blog Purpose

Having just come back from the 2010 Global Conference on Educational Robotics held at the Southern Illinois University at Edwardsville, I am really pumped to do my own robot. I accompanied 7 high school students as a chaperone and was very impressed with what was being done by these students in the area of robotics. I was also impressed when I realized that they were going through an engineering development process which involved aspects of EE, computer science, mechanical engineering, general design, and general problem solution. No matter what the students do in later life, they will have learned some valuable lessons on problem resolution. My grandson was one of the programmers on the team and will be going into his senior year in the fall. I have resolved to build a robot from spare parts to help coach him along in his programming. Also it should be a lot of fun, hence the name of this blog.

Is Chumby the Right Controller?

After having worked with the high schoolers in BotBall, I noticed that they were using a CBC to program the robots. CBC stands for Chumby BotBall Controller. This turns out to be a handy little device, with a linux operating system, that has an ARM processor, plenty of RAM (64MB), a flashable ROM, internal simplified C programming, and an interface to robotics control ports. I proceeded to look for this controller on the BotBall site but did not have much luck, and the price is around $300 which is a bit rich for my budget. On the other hand, I was able to locate the Chumby One at http://www.chumby.com which seems to be a more likely choice for what I want. In fact, this device is on sale at CostCo for $99.99. The device in and of itself is a highly usable internet appliance. But, it is also highly hackable, both in hardware and in software. I am interested in the processor because it has both Wi-Fi capabilities as well as a USB port. I am thinking that if I use the USB port for the robot interface that it would simplify the construction of the spiderbot. Hmm... more to follow.