= Week 1 = [wiki:Dailyupdates Back to Daily Updates] == 6/4/07 - Day 1 == All day we wrestled with the ERSP installation. The error we got over and over was a license error which appeared immediately after the installer asks for the product id (312). Apparently, the installer uses the ''less'' command to display the EULA. For future reference, ERSP will not install unless the ''less'' package is available. Many hours were spent on this problem. Once this was done, the packages ersp-license and ersp-config installed successfully. The main package, ''ersp'', faced a chain of unmet dependencies. Tracing them to their root led to the packages ''libraw1394-5'' and ''libdc1394-11'', libraries involved in firewire data transfer. Once these packages were downloaded from the debian site and installed via dpkg, the ersp package installed without further error. We’ve been working on Mobile 33, which after the day’s work has working copy of Debian Sarge with Gnome. The ''/opt/evolution_robotics'' directory is populated by the software package. The package ''ersp-sample-code'' installed easily. I created a folder in our home directory in which I untarred the sample code. I attempted to run the classic ''triangles.py'' example script, and received an !ImportError. The same error appears regardless of whether or not the thinkpad is connected to the chassis, leading me to believe the problem is a dead battery. I tried both batteries with identical results. I would like the charge the batteries and see if we can make this thing move tomorrow, but I’m unsure which of the many adapters lying around are correct. Ivan is characteristically unfindable. == 6/5/07 – Day 2 == We downgraded from python 2.4 to 2.3 on Mobile 33. The labtop can now power the chassis via python! Great success. We have begun setting up Debian on Mobile 37. After the minimal install, we upgraded the kernel to ''2.6.8-2-386''. We then attempted to install the package ''xserver-xorg''. We copied the file xorg.conf from the working version on Mobile 33 using ssh. We still have issues with fonts. The needed font package was ''xfonts-base''. Once this was done, the X server launched. We then installed the Gnome window manager. Python is a bit of an issue, as the scripts seem to expect python 2.3 whereas the software itself installs python 2.4. After much reconfiguring, some of which included switching window managers on Mobile 33 (now running KDE), the solution was found in the form of a symlink called ''libpython2.3.s.0.1'' pointing to the corresponding python 2.4 file in ''/usr/lib''. Some more packages were required in order to successfully compile the sample c++ code. Namely ''build-essential'' and ''libstdc++5''. Once compiled, the example 01-simple executed and turned the robot’s wheels. This is the first time I’ve successfully controlled the robot using c++ code. One observation that I’ve made is that the code will not compile passed to gcc on its own; the ''make'' command must be used. This makes it necessary for us to generate makefiles for our own programs – something I currently know nothing about. I spent a large part of the afternoon trying, unsuccessfully, to test the camera. ERSP comes with a binary package called ''test_camera'', which gives several hints at the problem. I don’t know the specific model name of the camera we are using, and google is not being very helpful either. One goal for tomorrow is to obtain printouts of the User’s Guide and Programming Tutorials. == 06/06/07 – Day 3 == For reasons unknown, Mobile 36 (gnome) crashed X when booting for the first time this morning. We found the problem to be a missing line, m''ousedev'' in the file ''/etc/modules''. A big accomplishment for today was to get printouts of both the User’s Guide and Tutorials. This will undoubtedly help us a great deal when we get started programming. Based on a pdf file from evolution found online, the robot’s text-to-speech capabilities are restricted to the Windows version of the software. This is lame, and we will look into it more in the future. Debian does have some text-to-speech packages in its repositories, so we can probably achieve that functionality of the robot even if the ERSP software doesn’t support it. Getting the camera to work took a while. We needed to load the module ''ov511'' (it was available) using ''modprobe''. Once this was done, the ERSP test application ''test_camera'' successfully snapped 5 images and stored them as jpegs. An attempt to enable sound on Mobile 33 (KDE) was wildly unsuccessful. I learned some useful commands I’d like to remember though: ''pcimodules'' – guesses which modules should be loaded based on ''lspci'' ''xargs [command]'' – performs [command] on every line of the data piped into it So, for example # pcimodules | xargs modprobe Attempts to load every module that ''pcimodules'' believes should be loaded. == 06/07/07 – Day 4 == Sound is working! The necessary module was ''snd-intel8x0''. Once installed (along with ''alsa-base'', ''alsa-utils'', ''alsa-tools'') sound is working great. The tools ''aplay'' and ''amarok'' are able to play wav files and audio CDs. We have installed some text-to-speech applications, one called ''festival'' and another called ''flite''. Both can generate audio speech from text information. Neither is yet linked with the ERSP software however, and ''triangles.py'' continues to give errors when it is trying to speak. Getting wireless to work was a small nightmare. The madwifi driver had a few dependencies unavailable in our repository, but we were able to find them online. Once the drivers were all installed we still struggled to get connected, but we think this might be do to interference in winlab. A new discovery: if instead of running the script ''run_client_gui'' we run the program ''navtool'' directly, the camera works. The mechanics of this are still under investigation. At the end of the day, the ''navtool'' and ''run_client_gui'' script are still a mystery. The program ''navtool'' outputs countless warnings that “The audio device has not been opened yet,” which follow a failed attempt to make a directory. The program appears to me to be searching for something in ''/home/builder'', a directory which does not exist at all as there is no user named builder. Also, whereas once attempting to open the vSlam applet resulted in an error in the debug output, it now causes an immediate crash of the application (step backwards?). An additional problem I have come across is that the tool ''composer.sh'', which is supposed to be a graphical tool for composing robot behaviors, outputs an error regarding ''libpthread.so.0''. This is the first tool so far we have attempted that uses java. We tested a second chassis today. All is in working order. I need an orbit account. == 06/08/07 - Day 5 == I got an orbit account. We spent all morning trying to get ''navtool'' to work. We had some success with Mobile 33, which began a preliminary exploration of the orbit room. Unfortunately there are still some kinks that need to be worked out before the robot can be controlled remotely via SSH. Mobile 33, controlled locally (as opposed to ssh) has a functioning ''navtools'' application. The camera and software joystick both work well. The IR sensors appear not to be doing anything however, or at least the robot is not responding when it crashes into walls. One of the steps in getting this software to work was creating an obscure symlink. The navtools application searches for the file USB.xml in all the wrong places, one of which includes a directory that appears to reflect the ERSP software developers' home directory. We are currently working on ghosting the image of Mobile 33 to Mobile 36. Weekly meetings for summer interns will be held on Wendesdays at 2pm. One feature I would like to add is battery monitoring for the labtops. As they are, we have no way of knowing how much battery is left. Twice so far I've had my computer abruptly switch off on me.