VRPN vs. Gadgeteer

[Maia R.]

Hi,

I am new to VR Juggler and VRPN. As far as I understand, there are two
approaches to get data from devices: from supported devices via
Gadgeteer or from VRPN (in this second case, VRPN should be configured
in VR Juggler). Gadgeteer and VRPN permit to create new drivers
(Gadgeteer - Device Driver Authoring Guide) and VRPN (Creating a new
Device class). I'd like to know the difference of the two approaches,
and the pros/cons, if any.
Thank you,
Maia

[Ryan Pavlik]

Maia,

There's two angles here - are you developing an application, or a driver for a new kind of input device?

There are many, many device drivers already available, and more all the time.  VR Juggler applications can transparently use any of the devices that have gadgeteer plugins. Because there is a gadgeteer plugin that is a VRPN client, that also means that any device that has a VRPN server (for instance, a Wii Remote) is also accessible transparently through VR Juggler. You can (and I do) use a mix of "native" gadgeteer device types and devices accessed through VRPN in a single system configuration without problem - there is no problem with this, and it works great. (If it ever doesn't, I or someone else usually ends up fixing it so it does - this is a pretty common usage.)

If you're developing an application, and using VR Juggler, then all you think about are the generic device types exposed by Gadgeteer - the configuration (jconf) files take care of assigning a given driver to a generic name.

If you're developing a new device driver (for instance, I recently got a Razer Hydra tracker/controller and wrote a driver for it to use it in real VR apps, not just a few computer games with keybindings), then you have a number of choices of how to write your driver. In my personal opinion, I would say write a VRPN driver. For one, this means you can use your driver not only with VR Juggler, but with a large number of other frameworks (open source and proprietary) for VR. It's essentially the "open" universal VR input protocol. (This is especially good if you're doing research, since it means more potential users.)  Furthermore, you also get network transparency for free - you can have your device connected to any computer accessible over a network.  (For instance, we have a dedicated Linux box that basically just runs VRPN servers, primarily for two wii remotes - the other nodes in our cave access it seamlessly from VR Juggler. https://github.com/vance-group/metal-devices-server )  Writing a native Gadgeteer driver requires that your device be connected to the head node (if you're in a cluster environment) and means that your code is at least not directly usable with anything but VR Juggler applications. In my experience, there hasn't been any functionality I've wanted to use in a device driver that would be possible with a native Gadgeteer plugin but not possible with VRPN and the VRPN gadgeteer plugin. (I think some of the more advanced event stuff being developed in master might be the exception, but I haven't needed that.)  And, in my humble opinion, the VRPN codebase is simpler when developing drivers. It's a lot smaller since it only does one thing, and you can test just your driver with the "vrpn_print_devices" tool. If your device is USB HID, which very many are nowadays, it's even easier - VRPN has a very good USB HID base class so you basically just write one method (to decode reports) and you have a driver that works on Windows, Mac, and Linux.  As an example, here's the driver I wrote for the Hydra, which is a tracker, a button device, and an analog device: https://github.com/rpavlik/vrpn/blob/master/vrpn_Tracker_RazerHydra.C Keep in mind that I had no documentation for the hardware or protocol when I started, and the device initially starts up in "gamepad" mode and needs to be coaxed into sending full tracker reports which accounts for most of the complexity. Here's perhaps a simpler one: https://github.com/rpavlik/vrpn/blob/master/vrpn_DreamCheeky.C

So, hopefully that's helpful. If you still have questions, more context about what you are trying to do would be useful in offering more targeted assistance.

Ryan Pavlik

(Full disclosure: I've had patches accepted to VR Juggler and VRPN, but many more to VRPN - as I mentioned, I've written drivers for it, etc.)

[Maia R.]

Hi Ryan,

First of all , I am very sorry that I didn't reply sooner to your
fantastic response.
I really missed this one.

Second, thank you a lot for this very good explanation. I am going to
develop an application with a new device (a new eye tracker and
possibly a new EEG). Therefore, I need to look at how to develop a
driver for these devices.
Could you suggest me some advices on how to start with VRPN ?
Thank you very much,

Maia

> other nodes in our cave access it seamlessly from VR Juggler.https://github.com/vance-group/metal-devices-server)  Writing a native

[Ryan Pavlik]

Simple - start by grabbing the code using Git, configure and build it (use cmake).  If the devices you use make use of the USB HID protocol, it's even easier.  You'll probably want to look at http://www.cs.unc.edu/Research/vrpn/Devices.html 

You'll probably be creating vrpn_Analog devices to report analog value channels.

Ryan

[Maia R.]

Ok, thank you Ryan.
Maia

On 7 mai, 12:54, Ryan Pavlik <ryan.pav...@gmail.com> wrote:
> Simple - start by grabbing the code using Git, configure and build it (use
> cmake).  If the devices you use make use of the USB HID protocol, it's even

> easier.  You'll probably want to look athttp://www.cs.unc.edu/Research/vrpn/Devices.html

> >https://github.com/rpavlik/vrpn/blob/master/vrpn_Tracker_RazerHydra.C...