Create/ASUS Troubleshooting Guide
for Tekkotsu Users

1. Verify that the white serial cable is plugged into the robot, and the other end is securely attached to the silver serial-to-USB converter cable. The other end of the converter cable should be plugged into the notebook's USB port.

2. Turn on the Create. The power button should flash red-and-green for a few seconds and then turn steady green.

3. Start Tekkotsu on the notebook by clicking on Accessories, launching a Terminal window, and typing:

   cd ~/project
   ./tekkotsu-CREATE
   

   The notebook should play a roaring sound when Tekkotsu starts up. Then launch a second terminal window and type:

   >/usr/local/Tekkotsu/tools/mon/ControllerGUI localhost

4. Click on the RawCam button in the ControllerGUI and verify that you get a camera image.

5. Click on the "Un-Stop" button in the bottom right corner of the ControllerGUI.
6. Click on the "W" button in the Teleop row in the ControllerGUI and use the Walk Remote Control to move the robot around a bit.

7. In the ControllerGUI menu, go to Root Control > Status Reports > Event Logger and select buttonEGID. Then press one of the Create's switches or bump sensors, but do not lift the robot off the table or it will enter "safe mode". You should see button press events reported on the Tekkotu console (terminal window).

You can update your software using cvs. You need to update both the master copy in /usr/local/Tekkotsu and any user project directories, such as the one in /home/user/project. Here is the procedure to follow:

cd /usr/local/Tekkotsu
sudo cvs update -dP
cd project
make

cd ~/project
cvs update -dP
make

"C" indicates a conflict was found when updating the file. Conflict lines are set off in the file by "<<<<<<<" and ">>>>>>>>" markers, with a "=======" line in between the two sets of lines that could not be reconciled. The easiest solution is to just delete the file and redo the cvs update. It is also possible to resolve the conflict manually by comparing the code in the two sections and deleting anything that doesn't belong, including the conflict marker lines. If you don't do this, the file will not compile. But for conflicts in the Tekkotsu source code, it's safer to just delete the file and repeat the update.

Tekkotsu provides access to the camera controls for the ASUS notebook or any V4L2-compatible webcam. In the Tekkotsu console window, type set Drivers.Camera to see a list of camera controls. Tpye set QueryOptions=true to see a list of allowable values for each option. Then type, for example, set Drivers.Camera.Contrast=10 to set the camera contrast to 10.

To check for zombies, type:

ps -A | grep tek

killall -9 tekkotsu-CREATE

1. Verify that the robot is powered on and the battery is charged. You can do this by turning the robot off and then on again. It should give a short beep and the LED should flash red-and-green for a couple of seconds and then go solid green, or turn off if Tekkotsu is running. If it glows yellow or red, the battery is low.

2. Verify that Tekkotsu's Emergency Stop mode is off. The indicator in the lower left corner of the ControllerGUI should be green, not red, and the button in the lower right hand corner should say "Stop", not "Un-Stop".

3. Make sure the cables connecting the notebook to the Create are firmly plugged in at both ends.

4. Make sure that the Create is not in safe mode when you power it up. It should be resting on a flat, stable surface, such as the floor or a tabletop, not sitting in your lap.

1. In the ControllerGUI menu, go to Root Control > Status Reports > Event Logger and select buttonEGID. Then press one of the Create's switches or bump sensors, but do not lift the robot off the table or it will enter "safe mode". You should see button press events reported on the Tekkotu console (terminal window). If not, see the following steps.

2. Verify that Tekkotsu's Emergency Stop mode is off. The indicator in the lower left corner of the ControllerGUI should be green, not red, and the button in the lower right hand corner should say "Stop", not "Un-Stop".

3. Make sure the cables connecting the notebook to the Create are firmly plugged in at both ends.

4. Make sure that the Create is not in safe mode when you power it up. It should be resting on a flat, stable surface, such as the floor or a tabletop, not sitting in your lap.

If the cable is firmly plugged in at both ends, but you're still getting device errors, it's possible that the cable is defective. To check this, unplug the cable from the ASUS, wait a few seconds, plug the cable back in, and type "dmesg" to the shell to display recent system messages. A normal cable will generate output something like the following. (The exact messages might differ, depending on the brand of cable you're using.)

$ dmesg
usb 2-1: new full speed USB device using uhci_hcd and address 18
usb 2-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usbserial
usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usb-serial.c: USB Serial Driver core
usb-serial.c: USB Serial support registered for pl2303
pl2303 2-1:1.0: pl2303 converter detected
usb 2-1: pl2303 converter now attached to ttyUSB0
usbcore: registered new interface driver pl2303
pl2303.c: Prolific PL2303 USB to serial adaptor driver

$ dmesg
usb 2-1: new full speed USB device using uhci_hcd and address 19
usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new full speed USB device using uhci_hcd and address 20
usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new full speed USB device using uhci_hcd and address 21
usb 2-1: device not accepting address 21, error -71
usb 2-1: new full speed USB device using uhci_hcd and address 22
usb 2-1: device not accepting address 22, error -71

Fortunately, USB-to-serial cables are inexpensive, so if yours is giving device errors, just buy another one, and perhaps try a different brand.

Turn on the SegCam viewer in the ControllerGUI and check that the color segmenter is recognizing the marker colors properly. A common problem is specular reflection from shiny marker material, which causes the marker to appear white instead of its natural color.

This happens when you #include the wrong file in UserBehaviors.h. If you have a behavior defined as a state machine, you must give it a filename like MyFile.h.fsm, but inside UserBehaviors.h you must put:

#include Myfile.h