VRPN 06.04

Troubleshooting VRPN

This page contains a list of problems that users have encountered with VRPN and the solutions to these problems.

I can't get my Flock to work

The VRPN drivers only work with flocks that are in the "Flock of Birds" configuration, where the extended-range transmitter unit is not also a receiver unit. They do not work with flocks that are in "Standalone" mode with the transmitter and receiver plugged into the same unit.

The VRPN drivers only work with flocks that have the transmitter set at the first unit. If the transmitter is not set to be the first unit, the open code will complain and the tracker will not be opened properly.

All released versions of VRPN through 06.03 have been tested with a parallel flock running connected to a Linux server (that's how we run at UNC). Version 6.00 and 6.03 has been tested with a Flock in the daisy-chained configuration running on a Windows 2000 machine (it worked with 1, 2, and 3 sensors connected).

Make sure that the baud rate on the serial port is set to match the one being used by the Flock (the dip switches determine this, as per the manual). If they don't match, the tracker continually resets and never gets any characters from the Flock (although the lights sometimes flash).

Make sure that the baud rate is fast enough. We find that a rate of 38400 is not fast enough to keep up with three daisy-chained sensors (the tracker runs for a very short while, then times out and resets, and repeats). 115200 is fast enough for three sensors (and why would you run slower?).

Make sure that you have only the transmit, receive, and ground lines on the serial cable connected to the Flock: Sebastien Maraux reported the following behavior when using his flock in daisy-chained mode: "I have to nitialize the flock with cbird.exe (flock utility) and use 'change value' (parameter 15 in main menu), and 'autoconfig FBB' (choice 16 in submenu), then set number of devices to 3 in order to make vrpn server work after each ERC boot. Rebooting flock and trying to use vrpn server directly leads to never ending 'POLL-RESET-SETTING PARAMETERS-WAITING FOR RESPONSE'. To be more precise, I can make VRPN work if I use cbird to initialize flock, then quit with alt F4 (not closing properly) and then launch VRPN server. I also noticed that I always need to call submenu 15 of cbird twice to get it working (first call always returns : rx line errors have occured, could not read bird status). I don't know if this two things are related ? (as vrpn makes several attempts automatically)." David Nahon and Kyle Smith reported the following fix: "Have you tried to use a cable with only Tx, Rx and GND wires? I haven't read your mail very carefully, but it looks like this is the problem. Indeed, cbird and winbird work fine with a more wired cable, but vrpn doesn't. Just for clarification, Tx, Rx, and GND are pins 2,3, and 5. You can remove others from the male end of the cable easily with needle-nose pliers."

I don't hear from the buttons on my IS-900 Wand/Stylus

It seems likely that the "remote" button object is defined with the name of the tracking device, rather than with the name of the button device. The button device name is defined on the stylus line in the config file, and might not be the same as the tracker. In the case described by the example configuration below, if the name of the machine running the server is "myis900server" you would connect to the tracker as "Isense900@myis900server" and to the buttons on the stylus as "Stylus0@myis900server":

vrpn_Tracker_Fastrak Isense900 COM1 115200 /
Wand Wand0 0 -1.0 0.0 0.0 1.0 -1.0 0.0 0.0 1.0 /
Stylus Stylus0 2

If you connect the button to "Isense900@myis900server", it will not complain, because there is a device with that name at the other end, but it will never receive button reports from it either.

I can't get my SGI to talk to my serial tracker (Flock, Fastrak, ...)

A couple of sites have had trouble talking with their tracking devices from SGI machines (Onyx, O2). We really don't run these servers on our SGI machines, since we use Linux (usually) or NT (rarely) to drive the trackers and other serial devices. This prompted us to verify that the serial-port code works on an SGI. As of a beta version 4.11, it does work for talking to a 3Space tracker from an O2. Since the driver code is not OS-specific (except at the serial port layer), this leads one to suspect that the other drivers should work as well. However, there are a host of problems that one can encounter when trying to get RS-232 working between a device and a host computer. So, here are the things we try for SGIs:

Ensure that the serial cable pinout is correct for the SGI ports. Older Onyx computers have a different pinout than the standard used by PCs. If you can't get anything back from the tracker, try adding a NULL-modem cable.
We use /dev/ttyd[1234] for the devices.
Make sure that the machine isn't going to launch a getty() on the port by editing /etc/inittab and commenting out the lines for the serial port you are using (or maybe changing the line to say "off"). When the getty() runs, you can get all sorts of strange behavior, as you and another process fight for the characters from the port.
Set the permissions on the port. Note that on some machines, /dev/ttyd1 is a link to another location; you need to follow the link and chmod the actual device. You want read/write access for all users, probably.
If the server still won't run, verify the physical connection by doing 'cat < /dev/ttyd1' in a window to capture the output. Then, set the baudrate by (for example) 'stty 19200 < /dev/ttyd1' to the correct rate in another window. In that window, do 'cat > /dev/ttyd1' so that you can send commands to the device. For the 3Space and Fastrak, 'S' for status should get you a response. Power-cycle the tracker, then try this command after waiting 30 seconds or so. Keep retrying the above things (or others) until you can get a command to send you data back from the tracker; if you can't get this to happen, no software can talk to it.
If you can get information from your tracker using the 'cat' commands, and there is no getty() running, and the vrpn.cfg file is pointing at the correct port with the correct baud and it still doesn't work, then there might be trouble: Send the output from 'ls -l /dev/ttyd*' and of 'hinv' and of 'uname -a' to vrpn_support@3rdtech.com, along with a description of the tracker you are doing and what other machines/OSes the tracker is known to run on.

My code calls tracker->mainloop(), which stays busy and never returns.

You should not normally place your rendering loop (or any other heavy computation) inside the tracker callback. If you do, there will likely be another tracker message by the time you have finished the computation. This will cause the program to enter an infinite loop and never return from the mainloop() call to the tracker. This is because there is a new report from the tracker after each call to the handler for the last message; the tracker never finishes handling all the messages.

When I try to connect to a server with a certain client, the whole server locks up and never responds to any other clients until this client disconnects.

If a client program does not call mainloop() on any connections it makes (either directly or through created Remote objects), then the TCP buffers between that client and the server will eventually become completely full and the code will block. Since VRPN is not threaded, this blocks the whole server until the offending client disconnects. An example of a problem client is shown here:

#include <vrpn_Tracker.h>

void main(void)
{
    char  tkr[] = "Tracker0@localhost";

    vrpn_Tracker_Remote *t = new vrpn_Tracker_Remote(tkr);
    printf("Blocking tracker %s\n", tkr);

    while(true); // endless spinning without mainloop() blocks the server
}

The tracker reports always lag way behind (about one frame time).

Trackers use unreliable (UDP as of 2/24/98) transmission for their updates. They report these updates at some frequency, perhaps 60-100 times per second. If the application does not call mainloop() on its vrpn_Tracker_Remote object frequently enough, the incoming buffer fills up and some of these messages are not delivered. Unfortunately, UDP discards the later packets and keeps the oldest ones. This has the effect of introducing latency equal to the application's main loop time when that time is much slower than the tracker report time. To get around this, the application should make sure that it gets a new report each time through its main loop. It can do this by purging all of the old reports (through a call to mainloop()) and then reading until a new report comes in. A code fragment showing how this might be done is given on the tracker page:

I unregistered a handler that did not exist, and then the code blew up when I registered another.

This may have been fixed in recent releases.

I can't get my code to compile under HPUX 11 (allocateEndpoint not defined).

Try using g++ rather than CC to compile the code.

When I stop the Phantom server under Irix, my machine crashes!

Email from the author: A while back I reported that stopping the VRPN server with the Ghost3.1/Irix port crashes the machine from time to time. I think I have further pinned down the problem. It seems only to occur when one runs the server from within an X-Session where xphant is also running. Then it is quite reproducable. But when I rlogin into the machine and run it from terminal, I have had no crashes so far by stopping the server.