If your system seems not to be working like you want it to, you might find a solution to your problem in this appendix.
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.
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:
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.
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.
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.
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.
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).
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.
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.
arc -port portname -gdb_inhibitThe
-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
.
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.
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]
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.
There are two categories of symptoms which are caused by another program using the same serial port that you are trying to use:
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:
ls -l
portname (see section Serial Port Acess Privileges).
If you are using Linux, it may work to use a cua
port instead of a
ttyS
port, as the locking mechanisms are somewhat different between
the two. If you were using /dev/ttySN
(where N
is
a number from 0 up) and then experienced locking problems, you can try
/dev/cuaN
. This is generally an alias for the same port with
different locking mechanisms.
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:
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 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.
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.)
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
).
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.
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:
init
re-read `/etc/inittab' and disable getty
,
become root and type kill -1 1
.
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:
init
re-read `/etc/ttys' disable getty
, become
root and type kill -1 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).
The IBM DB-9 standard is to put ground on pin 5, computer transmit on pin 3, and computer receive on pin 2.
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).
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. .
-saphira
flag: arc -saphira -port
portname.
Control-c to inhibit reset run...10...9...8...7...6...5...4...3...2...1... Initializing library vislib-26_0 Cognachrome Vision System Software version 26.0 Channel 0: Restored 1164 bytes Channel 1: Restored 1035 bytes Channel 2: Restored 6 bytes Restored a total of 2205 bytes Restored protocol string: "$%04xF:%04xR:%04xC#" from EEPROM Running program pioneer-26_0 as process 99 vestaboot.986>
Running program pioneer-26_0 ...
, then you need to download the
Pioneer software (see section Downloading Programs to the Vision System).
Checking for reset run programs vestaboot.986>
Restart ARC at 38400 baud--do not use a -baud
,
-saphira
, or -pioneer
flag:
arc -port portname
Now download the Pioneer software to the board (see section Downloading Programs to the Vision System), and go back to the start of these instructions.
This section goes into problems you might run into that you can't figure out simply by looking at the LED's.
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.
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.