Go to the first, previous, next, last section, table of contents, index.

Troubleshooting

If your system seems not to be working like you want it to, you might find a solution to your problem in this appendix.

Status Lights and Beeper

You can find out a lot about what's going on with your board by looking at the nine LED's and listening to the beeper. For a diagram showing the names and locations of the various status indicators, see section Cognachrome Vision System Board Diagram.

The beeper should beep during power-up or reset. If it doesn't, you might have a power problem, a blown fuse, a problem with your ROMs, or a serious hardware problem with your vision system.

The three red LED's indicate the status of the three power sources (digital +5v, analog +12v, and analog +5v). All three should be lit. (Do not run the board for extended periods of time without all three power inputs supplied as it will damage the board). If you see an LED which isn't lit, it probably indicates your power supply isn't connected properly (or maybe isn't turned on). If the digital +5v LED (leftmost in the bank of 6 LED's) doesn't light but its power supply seems to be working, you may have blown a fuse. See section Digital Power Connector. For more information on tracking down analog power wiring problems, see section Analog Power Connector.

The green LED closest to the video connections tells whether horizontal and vertical sync signals are being detected from the incoming video. If this light isn't on, it's probably because your camera is off or disconnected.

The group of three green LED's are connected to the video recognition channels--you can tell by looking at them if each of the three channels is detecting anything.

The group of two yellow LED's are connected to internal lines on the board. As part of a normal boot sequence, you should see them flicker for around 5 seconds.

Processor Board Jumper Configuration

Hopefully you received a properly configured processor board with the jumpers all in the right places. However, if the processor board does not work quite right, it may not be configured properly. Check the jumper configuration against the following diagram:

Serial Port Troubleshooting

Before you can sucessfully interact with the vision system, you'll need to know the name of the serial port you intend to use. This is a multi-step process. First you must determine what the names of the serial ports are on your system. Once you have determined this, you must determine what name corresponds to the port you physically hook your cable to. It may also be necessary to change the permissions on the serial port before you can use it. This may require you to contact a system administrator if you do not have root access to your machine.

Serial Port Names

The device names for serial ports vary from system to system. Here are some typical serial port names, but realize that names sometimes vary even between different machines of the same architecture, so the following are suggestions for names to try, rather than the final answers.

The serial ports should show up in the file system, so you can do an ls in the `/dev' directory and see if you see any of the names listed above appear.

Serial Port Acess Privileges

Once you have determined a likely candidate for the name of the serial port, check that you have both read and write permission to that port.

quasar% ls -l /dev/ttyS*
crw-rw-rw-   1 root     tty        4,  64 Jul  5  1995 /dev/ttyS0
crw-rw-rw-   1 root     tty        4,  65 Feb  7  1995 /dev/ttyS1

The set of letters and dashes at the left side shows the access privileges for each port. If there are dashes instead of rw in any of the three positions above, you may not have enough access to use the serial port.

If you have root access, you can do the following to set the privileges properly. If you do not have root access, contact a system administrator:

quasar:/usr/local/arc% chmod a+rw portname

Now if you repeat the ls -l command, it should look like the example above.

Determining which Serial Port to Use

On some machines, the serial ports are labeled in an intuitive manner. For example, a Sparc station generally has two serial ports named `/dev/ttya' and `/dev/ttyb', and on the side of the computer are two serial ports--one labeled with an A, and the other labeled with a B.

On Linux machines, sometimes the ports are labeled as COM1, COM2, etc. If this is the case, then generally /dev/ttyS0 or /dev/cua0 corresponds to COM1, /dev/ttyS1 or /dev/cua1 corresponds to COM2, etc.

If which port to use seems unclear, it should still be possible to figure out experimentally which one to use by using loopback cable. The basic idea is that you connect the transmit and receive lines together on the serial port you plan to use. Then you send data out to a likely port name, and listen to see if you can hear yourself. If you do hear yourself with the loopback in place, but do not hear yourself when the loopback is removed, then it is likely that you have the right port.

Installing a Serial Loopback

Follow the instructions corresponding to the type of connector you are using. The loopback can be installed either directly at the back of the host computer, or at the end of a serial cable. Generally, you should start by installing the loopback as close to the computer as you can. Once that works, you can move the loopback further out towards the end of the cable. If it still works at the end of the cable which will plug into the vision board or robot, then you know that your cable is alright (with the possible exception that it may still need a null modem--this procedure does not test that).

DB-25 or DB-9
These are common connectors on Sparc, DEC, and IBM PC compatible computers. Both are shaped like a trapazoid with one more pin on the top row than the bottom row.

To loop back these connectors, connect pins 2 and 3 together. Usually there are small numbers printed next to each pin. If this is not the case, look at the connector with the larger side up. Pin 1 starts at the top left for male, and top right for female connectors. Pin 2 is beside pin 1 on the same row. Numbering restarts on the bottom row starting from 13 for DB-25 or 6 for DB-9 below pin 1.

If the connector is female, use a piece of solid core wire. Be careful about the gauge of the wire--too thick may damage the connector, and too thin may not make a reliable contact. If the connector is male, you can use a jumper lead or have a friend hold a wire in place.

8-pin Mini DIN
These connectors are round, about 1/4" in diameter, and have 8 tiny pins. They are common for serial ports on Macintosh and NeXT computers, as well as recent Sparc models. Do not try to deal with these connectors directly. Instead buy a DB-25 adapter cable and follow the DB-25 directions. These cables generally cost around five dollars and are sold as Macintosh modem cables. DO NOT buy a Macintosh printer cable--transmit and receive (pins 2 and 3) are swapped on these cables. If you only have a printer cable, you need to buy a null modem. These are available from just about any computer store.
3-pin Molex Connector
These are the connectors used for the serial ports on the Vesta 68332 board (see section Cognachrome Vision System Board Diagram). If you are using a stand alone vision system, you should have received a cable with one of these connectors at one end. Connect the outer two pins together for loopback.
RJ-11 (Phone Cable) Connector
If you are using RJ-11 with adapters for serial and it is not convenient to use an adapter for loopback using the above instructions, you can loopback the RJ-11 connector directly. Have a friend hold a fine wire against the outside two of the 4 metal contacts. (If you are using a similar cable which has 6 or 8 metal contacts, use the outer two of the center 4 contacts.)

Finding the Right Serial Port

After installing the loopback on the physical port you plan to use, you are ready to send data to various port names until one echoes what you send. Any serial interaction program which allows you to specify the port name will work for this task.

Using ARC
Start ARC in the following manner:
arc -port portname -gdb_inhibit
The -gdb_inhibit flag is to prevent it from querying the status of the board.

If you do not use the -gdb_inhibit flag, it will automatically send a packet to itself every second or so. If you try this on the port which has the loopback installed, it will complain about the format of the response.

got bad gdb packet: >$H2,0:wsb<
got bad gdb packet: >$H2,0:wsb<
...

This is a way to have ARC automatically talk to itself, but it is probably more satisfying to type yourself.

When ARC starts up, it enters prompt mode. In this mode, ARC waits until you time a whole line followed by RETURN, then decides what to do with what you have typed. In order to send and receive characters directly to and from the serial port, type `^x' (control-x). This will put ARC in terminal mode, which allows you to type directly to the serial port.

When you are done, type `^x' again to go back to the arc> prompt. Then type quit.

Using Kermit
Kermit is a standard serial communications program installed by default on most UNIX systems. By performing this test using kermit, you can verify that any serial problems you may have are not ARC's fault.

Invoke kermit in the following manner:

kermit -l portname -b 38400 -c

Note: Do not be concerned if you see everything fine except that the cursor does not move to a new line when you press RETURN. This is normal behavior for kermit.

When you are done, type the escape character (typically `^\') followed by c to quit.

If you did not see anything echoed, try a different value of portname and try again.

If you did see what you typed echoed, you may want to remove the loopback and verify that the port no longer echoes. This is to make sure that you are not just talking to another device which happens to echo.

Write down the value of portname you used, and use the -port portname flag when running ARC in the future using that port. Even better yet, write the name on a sticker and put it right next to the port on the computer so no one will have to do this again.

Setting the Default Serial Port for ARC

If you are the sole user of ARC at your site, or if you know that everyone will want to use the same port, you can set this to be the default serial port for when no -port flag is used.

This procedure requires that you have write access in the binary directory (ie. `sparcbin', `linuxbin', etc), and that you use a machine of the appropriate architecture. For example, it is not possible to change the default serial port for the Sparc version while running on a Linux machine--you would have to be on a Sparc. If you do not have write permission in the directory, you may need to contact someone who does before continuing.

Go into the binary directory containg the ARC binary and type arc -config. Backspace over the old value for the default serial name, and type the name you just determined was appropriate.

quasar% which arc
/usr/local/arc/linuxbin/arc
quasar% cd /usr/local/arc/linuxbin
quasar% arc -config

ARC version 1.4.1  (18-May-1996)
Copyright 1995, 1996 Newton Research Labs
   by Randy Sargent, Anne Wright, and Carl Witty
   For information or help, please see http://www.newtonlabs.com/arc
   Email: arc@newtonlabs.com

Backing up arc to arc.bak
Done
Configuring `arc'.
For each option, you can press `return' to leave item same,
or you can edit the item (by either backspacing the old item and typing in
the new, or using emacs-style control keys).

Default serial device name (in the form /dev/?):  /dev/ttyS1
Person, Company ARC is licensed to:  xxxxxxxxxx [RET to leave the same]
License key:  xxxx-xxxxx-xxxxx-x [RET to leave the same]

Serial Port Usage Conflicts

A common problem encountered with using serial ports is that it does not work for more than one program to read a serial port at the same time. Unfortunately, it is not always clear what programs are using a given port. This section provides strategies for dealing with this problem.

Symptoms of Serial Port Usage Conflicts

There are two categories of symptoms which are caused by another program using the same serial port that you are trying to use:

Locking Conflicts
Some systems perform locking on the serial ports. This means that the first program which tries to open a given port succeeds, but any other programs are denied access. When a serial port is locked and you try to run ARC, you will get a message like this: Could not open port portname for input. ARC will then print usage information and exit.

Locking is in general a good thing, and it is not as confusing as contention without locking, but it causes some problems:

Non-locking Conflicts
When a system does not perform locking on serial ports properly, it will allow more than one program to connect to the serial port at the same time. Generally this will work reasonably on output: all output sent by any of the programs will be sent (it is, of course, probably confusing to the device at the other end if they talk at the same time). However, on input it will give the serial data received to whoever asks first.

A good test for this condition is to reset the board and look at the boot message. If it seems to be missing chunks of letters, then there is probably another program getting those letters. See section Startup Behavior, for information on what the boot message should look like.

If you see these symptoms, you have the following options:

If you know which program conflicts and can exit
If you control the conflicting program, then the solution is easy--quit it. This is the most common case.
If you know which program conflicts and cannot exit
Sometimes you started the conflicting program, but cannot quit normally, either because it was started from a different machine or beacuse it crashed. In this case, you should use the ps command (see below) to determine the process ID, pid, of the program, then kill it using kill pid. Use ps again to make sure it is dead. If it is not dead, you can kill it more insistently by using kill -9 pid.

If someone else started the program, you probably do not have permission to kill the process. In this case, you should contact the person who started the program, or a system administrator, and ask them to quit or kill the program.

If you do not know which program conflicts
Sometimes you cannot figure out what program is already using the port. In this case, use the methods listed later in the section. Once you have determined what program it is, follow the instructions above.
If you cannot determine which program conflicts
This is the worst case. This may be solved by contacting someone else who has more experience with the particular machine involved, such as a system administrator, who can find what is conflicting. Sometimes, however, there is simply no program which is conflicting and the locking is in a bad state. In this case, the machine may need to be rebooted. Do not try this with a UNIX machine unless you know what you are doing--contact someone who does.

Determining what Programs are using a Serial Port

If you are experiencing the symptoms of serial port usage conflicts (see section Symptoms of Serial Port Usage Conflicts), the first thing to try is to look at the process table for other programs which are likely to be using the serial port.

Determining Serial Port Usage with ps

The most general method for finding what programs may be using a serial port is to use the ps command. It lists what processes are running, as well as various statistics about it. This method has the advantage that it is available on all UNIX machines, and it does not require you to have root access, but it has the disadvantage that it is not very specific and therefore is hard to use accurately.

Note that the flags to ps vary somewhat from machine to machine (in particular, System V and BSD derived systems differ in this respect), so you may want to do man ps to determine what flags to use if the example below fails. In the following example (which will work for Linux and SunOS), the flags tell it to list the processes for all users (`a'), list which user owns the process (`u'), list all processes (`x'), and use multiple lines if necessary to list all the arguments (`w').

quasar% ps auxw
rsargent 17024  1.7  8.2  6276  5172  pf S 07:11 1:47 emacs 
rsargent 17451  0.0  0.5  2072   328  pa S 07:33 0:00 arc -port /dev/cua1
rsargent 17866  0.0  0.6   864   400  pf R 08:52 0:00 ps auw 
...

Typically this list will continue for a couple of pages, so it may be difficult to look through all of it. Therefore it is a good idea to pipe the result of the ps command into grep, which will filter the output according to a pattern and only print the lines which match.

quasar% ps auxw | grep arc
rsargent 17451  0.0  0.5  2072   328  pa S 07:33 0:00 arc -port /dev/cua1 
rsargent 17889  0.0  0.4   968   260  pf S 08:56 0:00 grep arc 

In this case, the argument to grep made it look for all processes containing the sequence of charaters arc. It found that user rsargent was running arc on port /dev/cua1. (The grep process usually appears too--don't let that worry you.)

Determining Serial Port Usage with fuser

The fuser command is a more specific and accurate method of determining serial port usage. Unfortunately, it is not available on all systems, and it requires root access for accurate results. If you have the fuser command on your system and have enough privilege to use it, it is the best way to go.

To use fuser, first become root, and then call fuser with the port you are interested in as an argument. It will tell you what process or processes are using that port. Then you can use ps to find out more about the relevant processes.

quasar# fuser /dev/cua0
/dev/cua0:        13702 13705
quasar# ps auxw 13702 13705
USER     PID %CPU %MEM  SIZE RSS TTY STAT START TIME COMMAND
anarch 13702  0.0  0.5  2072 328  p9 S    14:55 0:00 arc -port /dev/cua0
anarch 13705  0.0  0.2  340  168  q6 S    14:55 0:00 simple_telnet 

In this example, fuser determined that processes 13702 and 13705 were connected to `/dev/cua0', the serial port I want to use. By running ps, I determined that user anarch is running arc on that port already (simple_telnet is a helper program started by arc).

Disabling getty if it is Running on a Serial Port

getty is a program which runs on a serial port to allow users to log in remotely over the serial port. This interferes with using the serial port for anything else. getty is usually set up to run automatically on startup. Therefore it requires special methods to find and disable it. It is somewhat common for a getty to be running even years after it was set up, long after everyone who knew about it has forgotten or left.

If you do not have root access on your system, or if your system does not conform to the directions below, you should contact your system administrator for help.

Under System V derivatives (Linux, HP-UX, etc.)
Look in `/etc/inittab' for lines like this:
s2:45:respawn:/sbin/agetty 9600 ttyS0 vt100

In this example, a getty may be running on `/dev/ttyS0'.

To disable the getty, do the following:

Under Ultrix, SunOS, and some other BSD unixes
Look in `/etc/ttys' for lines like this:
tty00   "/etc/getty std.9600" vt100     on nomodem

In this example, a getty may be running on `/dev/tty00'.

To disable the getty, do the following:

Serial Port Pinouts

DB-25
These are common connectors on Sparc, DEC, and IBM PC compatible computers. They are shaped like a trapazoid with 13 pins on the top row and 12 on the bottom row. Usually there are small numbers printed next to each pin. If this is not the case, look at the connector with the larger side up. Pin 1 starts at the top left for male, and top right for female connectors. Pin 2 is beside pin 1 on the same row. Numbering restarts on the bottom row starting from 13 below pin 1.

Computers that use DB-25 connectors will wire their ground on pin 7, and their transmit and receive lines on 2 and 3. Which is on 2, and which is on 3, depends on the computer.

IBM PC's, DECstation 5000's, and Macintoshes with modem cables will wire the computer's transmit to 2, and the computer's receive to 3. (You should, of course, connect the computer's transmit to the board's receive, and vice versa). In general, when your cable doesn't work, there's a good chance you've just swapped pins 2 and 3. Either try rewiring the cable, or insert a null modem in the cable (this swaps 2 and 3, as well as some of the handshaking lines, which the vision system doesn't care about).

DB-9
These are common connectors on IBM PC compatible computers. They are shaped like a trapazoid with 5 pins on the top row and 4 on the bottom row. Usually there are small numbers printed next to each pin. If this is not the case, look at the connector with the larger side up. Pin 1 starts at the top left for male, and the top right for female connectors. Pin 2 is beside pin 1 on the same row. Numbering restarts on the bottom row starting from 6 below pin 1.

The IBM DB-9 standard is to put ground on pin 5, computer transmit on pin 3, and computer receive on pin 2.

8-pin Mini DIN
These connectors are round, about 1/4" in diameter, and have 8 tiny pins. They are common for serial ports on Macintosh and NeXT computers, as well as recent Sparc models. Do not try to deal with these connectors directly. Instead buy a DB-25 adapter cable and follow the DB-25 directions. These cables generally cost around five dollars and are sold as Macintosh modem cables. DO NOT buy a Macintosh printer cable--transmit and receive (pins 2 and 3) are swapped on these cables. If you only have a printer cable, you need to buy a null modem. These are available from just about any computer store.
3-pin Molex Connector
These are the connectors used for the serial ports on the processor board. See section Cognachrome Vision System Board Diagram for pinouts.

If you have a voltmeter, you can distinguish between the transmit and receive lines in the following manner:

If you want to check if this transmit pin corresponds to a specific port, you can check the voltage when you send characters out that port. It should pulse briefly from the negative idle voltage to a positive voltage (between +5V and +10V) when data is transmitted. If you have an oscilloscope, you can see this happen. However, it happens too quickly for a voltmeter in DC mode to detect.

If you only have a voltmeter, you can detect serial data transmission somewhat by measuring AC Volts. Continuously transmit data over the serial port, either by holding down a key (and setting your auto-repeat rate fast enough), or by pasting a large buffer of text into the serial interaction program. You should see the AC voltage reading change from around 0V when data is not being transmitted, to something higher when data is being transmitted (in my test, I read up to about .4V when data was being transmitted).

Pioneer-Specific Serial Troubleshooting

If you are using a vision system installed in a Pioneer robot and you are having trouble getting serial interaction to the robot to work even though the loopback tests above work, follow these instructions. If you still cannot get the interaction to work after trying this procedure a couple of times, you may want to seek help. See section Reaching Newton Research Labs.

Problems and Possible Solutions

This section goes into problems you might run into that you can't figure out simply by looking at the LED's.

Symptom: The board acts as if it receives spurious commands during operation.

Your board stops tracking or executes unrequested commands at unexpected times.

If the jumpers on the processor board are misconfigured, the input to serial port B may be floating. Make sure that the Serial B jumper is installed (see section Processor Board Jumper Configuration).

If you are using a system with an IR receiver, you might be receiving noise through the IR receiver which the board interprets as commands. IR receivers will normally see a small amount of low-frequency noise during normal operation, but this small noise is extremely unlikely to ever be recognized as a valid Sony IR command. Still: You might try disconnecting your IR sensor.

In direct sunlight, Sharp IR sensors become extremely noisy, and may cause spurious commands on the order of one every few hours. Furthermore, it may be too noisy to interpret your IR remote control. Therefore: Disconnect your IR sensor when operating in direct sunlight.

Poor Color Recognition

Symptom: The debugging monitor shows that the color recognition is bad, but I can't seem to make it better by retraining.

Often this problem is due to a poor input video signal. There are lots of things that can cause a bad signal: some are camera-related, some are wiring related, and some are related to environmental conditions such as lighting. See section Video Input, for some highly recommended reading to help you recognize and fix this family of problems.

Another possible problem is that your target is hard to distinguish from the background. If your target is too small, or has a surface that is "glossy" rather than "matte", you may have problems. Try to use targets with high color saturation--fluorescent or "neon" colors work well. See section Choosing Tracking Targets, for recommendations.

Check whether signal filtering is on. When filtering is on, a minimum horizontal size must be reached in order for the system to recognize an object. If you need to track small objects, reduce filtering. If you see a lot of noise in the background, increase filtering. See section Training and Configuring Channels Detail.

Double-check that your power supplies, especially those supplying analog voltages, are well-filtered. See section Power Connections.

 


Go to the first, previous, next, last section, table of contents, index.