'mytrackd' design and things should be done

Design

Design of 'mytrackd' is quite simple. There are few classes to deal with CAVELib sensors, buttons and valuators in correspondent shared memory areas. Also 'mytrackd' has wrappers for "vrpn_*_Remote" classes that distribute incoming VRPN messages between that CAVE stuff and provide some additional service. Rest of 'mytrackd' is intended to parse command line parameters and configuration files.

Currently, VRPN generic server 'vrpn_server' is used as server part to collect data from hardware. This application creates and configures device specific VRPN classes depending on it's configuration file "vprn.cfg". After that it starts infinite loop polling each VRPN class created.

Things should be done


* To add daemon features to 'mytrackd'. Currently unimplemented since not necessary but anyway can be useful.
* To re-write 'mytrackd' and write anew VRPN server for more advanced design in part of data collecting.
* To try to synchronize data updating in CAVELib shared memory by 'mytrackd' with CAVE frame rendering. Currently, 'mytrackd' puts such data just each time new report is available. Unfortunately, CAVELib doesn't provide semaphore lock to solve this problem in usual way.
* To implement some sensors data filtering. Since tracker usually reports position and orientation for each sensor more often then CAVELib renders frames, it seems to be a good idea to use excess reports to smooth motion and even to predict next report.


[up] [mail me]