VRPN won't update

[Wytze]

After a period (a few months) of not using the WorldViz PPT system ( 4 camera's) i wanted to use it again. But to my supprise my renderingsoftware wasn't working anymore. After some bug chasing i found that when i push the TALK button, the position of the trackers doesn't update anymore. On the WorldViz console the x,y,z positions do not change. The result is that on my VRPN i once get a change in postion (the initial position) and all next positions are equal to the previous position, so my change_position_callback isn't notified. As soon as i press the talk button again (stopping the vrpn connection), all trackers update correct again. On the ethernet i see the communication packages in normal rate , so there communication between server and client.

So basically starting the VRPN connection stops the update of the trackerpositions. Any ideas why this happens or what the cause of this problem is.

Thanks,


Wytze

[farshizzo]

I've actually witnessed this behavior before, but it randomly fixed itself before I could track down the cause of it. While PPT is talking is the marker trail being updated with the new position values, or are those frozen as well?

[Wytze]

Nothing is updated, If you take another window (notepad or whatever) and move this window over the GUI the camera windows will go blank (blue) and are not updated, which indicates me that there is no update from the camera. But the window self is redrawn, which indicates that the program is still running but there is no update from the camera's.
Also the communication with the PPT is still working there are ethernetpackages at 60 Hz on the line and if you stop the TALK the vrpn client immediatly responds with a "cannnot contact server error", pressing TALK again solves this again.

So in my opnion the program keeps running its mainloop but the camera's are not updated.

[Wytze]

I'm sorry my statement "Nothing is updated" is not true. The trace window is correct updated, i can see the correct traces of the LED's. This means that the camera's are working and the position is correct updated in the trace window. Makes it even stranger.

[farshizzo]

PPT 2.0 would intentionally not render the camera images and certain other UI elements while talking. That behavior is normal. However, it should still draw the marker trails in the center grid. If that is being updated then I believe you are seeing the same problem I did. As I said I was unable to find the cause of the problem and haven't experienced it again. Have you tried restarting the PPT computer?

[Wytze]

I have restarted the computer a few times, switched off the camera's etc. no change in behaviour.

It is new for me that the position values in the GUI don't update while TALK pressed (is this really true, i never noticed it)

I also tested something else: While TALK pressed, i started the TestPPNLights demo, which is in Vizard, and this demo runs fine. The balls are tracking the LED's correct (while VRPN running and not updating).

[Wytze]

After a few days of searching, the problem remains and it doesn't "randomly fixed itself". So i'm getting desperate right now.

Farshizzo you should try this system, the problem remains.

Is there a new version of the PPT software i can try or ................

[Wytze]

The problem is solved.

Serial VRPN -> works fine. sending over a serial line no problems. (the program from the download area)

This means there is something wrong in the Ethernet version. So i traced all the packets on the ethernet and there i found something strange:
TCP connection is between 192.168.0.200 and 192.168.0.203 (which are the correct ethernetaddresses for the server and the client)

but the UDP update packets are send from 192.168.0.200 (the server) to 169.162.1.100 (???????)

This is an unkown ethernet address to me and therefore no updates are received by the client. The reason for this strange address is that the client machine has a few (3) ethernetcards and two are getting their ethernetaddress from a DHCP-server. But these two are not connected at the moment, this means their ethernetaddress is bogus. VRPN somehow uses one of the bogus ethernetaddresses to send the UDP info.

When i disable these two connections, there is one one valid ethernetaddress/card and the software runs fine.
This means that the VRPN-software picks the wrong ethernetcard for the UDP-connection, but the correct for the TCP-IP. Very strange. I don't know enough of the internals of VRPN to explain this behaviour, but i'm sure this is the reason.


But at least it works and the problem is identified.