Meant to be Seen

It works I tried with all 4 and it can read it on the other end. The memory mapped accessor is marshalling them for us

Any news on the new version that was going to include the Generic Plugin?

Thanks, Matt.

Hi Matt.. Yeah, sorry, the new Wiimote plugin is taking more time than I thought. I hope we can release soon. It shouldnt be long now. But until then you can download the source from Github if you want.

New version out, see first page

FreePIE has just been Rifted, so if you are a Happy owner of a Rift dev kit, download new version... NOW!

CyberVillain wrote:FreePIE has just been Rifted, so if you are a Happy owner of a Rift dev kit, download new version... NOW!

Awesome! Great Work This is going to be great for use with OculusOverlay for all those unsupported games. I found OpenTrack a little difficult to get working. Is there any way through freePIE to adjust the prediction rate on the Rift Tracker (as the UDK and Unity integrations allow)?

Prediction rate?

If its in the SDK i guess its an easy task to add, to be honest all I did was to take the minimum example in the SDK and compile that with a C wrapper so that C# could load it.

You can check out the source code here

https://github.com/AndersMalmgren/FreeP ... reepie.cpp

CyberVillain wrote:Prediction rate?

If its in the SDK i guess its an easy task to add, to be honest all I did was to take the minimum example in the SDK and compile that with a C wrapper so that C# could load it.

You can check out the source code here

https://github.com/AndersMalmgren/FreeP ... reepie.cpp

I'm not sure whether its a programmable setting on the chip and hence automatically gives revised results or another API call after raw results are achieved (like a smoothing filter). Ill have a look at the API when I next get a chance and see how this can be configured.

Thanks a bunch for including Rift a well! FreePIE is a really amazing tool.
I was just thinking.. wait a minute, now that we have Rift support can I plug my YEI tracker into into Rift tracker and my DIY Rift will act like a real one? Please tell me something along the lines is possible: That means I could play all the games and all those demos in rift mode!!

Or am I just daydreaming?

Sorry no, it is not possible because the rift SDK is not a compiled dll. Which means there is no entry point for us to fake rift output. Only way would be to fake the HID device, and send raw values to the real SDK. But that would be really hard because the SDK is written around the raw data from the rift and would probably behave strange if it recevies values from another hardware

Awwww.... Well, at least it was a nice thought.

Hey,
I tried this to map the Oculus Tracker to the mouse: (based on the trackIR example)
The compiler does not complain about anything, but it just does not work.
Any ideas?

[EDIT] It works if I use Pitch and Yaw directly instead of the filtered values. But now the Cursor moves as long as the rift is not in center position. (not only when actually moving)

OculusVR SDK uses radians so multiply of 17 gives to small deltas for the mouse emulation to register

try
However there is problems with how sending mouse inputs, it uses integers, and the current implementation does not convert this very well so small movements are removed entirly, will try to fix this for next release

Looks like this is the same issue with the YEI small movements as I reported. If possible we should roll out my change to only these 2 trackers (if you ar not happy with rolling out the changes to all of them).

Its the same problem with Android too for small movements. But Im not happy with the way your fix makes it drift. I will make some tests with my Oculus and see if I can improve the code to work both with Oculus and Android

CyberVillain wrote:Its the same problem with Android too for small movements. But Im not happy with the way the code makes it drift. I will make some tests with my Oculus and see if I can improve the code to work both with Oculus and Android

I think this is an issue with the sensor, rather than the code. I have found a similar issue with the rift tracker that when completely still there is some drift. However it is quite difficult to differentiate between this and real movement. I have a look at some of these movements through the YEI and see if there is some tell tale sign of when this is happening.

I have a branch for this better to work there then in master.
https://github.com/AndersMalmgren/FreeP ... lMovements

I've also added a epsilon property to try to fix the drift, but it does not. I cant really get a grip on your code

That together with

Created a dedicated thread for this so that we can continue discussion there

New version out with important mouse and filter updates

New version out with alot of goodies like Wiimote M+ support, 1000hz refreshrates etc. Check it out!

CyberVillain wrote:New version out with alot of goodies like Wiimote M+ support, 1000hz refreshrates etc. Check it out!

Hi Cyber - does this include the rewritten YEI sensor stuff by RoadKillGrill?

yupp!

The new SDK 2.5 features look promising: https://developer.oculusvr.com/?action=hist

Added GetAcceleration, GetAngularVelocity and GetMagnetometer methods to OVRDevice used for reading raw sensor values.

Yeah, saw that in the mail this morning, will compile that tonight. Thanks!

@mahler Here is a new version compiled against 0.2.5 of OVR

https://github.com/AndersMalmgren/FreeP ... reePIE.dll

New release out!

Is it possible for FreePIE to use Bluetooth instead of UDP for Android ? There are a number of projects built around mobile HMDs and any bandwith gain is critical. Instead of congestioning the traffic with two way communications, you could use the PC-Android TCP/UDP route for video streaming and the reverse (Android-PC) bluetooth route for headtracking.
It would be great to at least have the option to connect this way

I can see what I can do, but I cant promise it will be any time soon sadly

CyberVillain wrote:Sorry no, it is not possible because the rift SDK is not a compiled dll. Which means there is no entry point for us to fake rift output. Only way would be to fake the HID device, and send raw values to the real SDK. But that would be really hard because the SDK is written around the raw data from the rift and would probably behave strange if it recevies values from another hardware

Perhaps you can use the HIDUSBFX2 sample from the WDK Samples Pack ("Demonstrates mapping of a non-HID USB device to a HID device.") as a starting point:
http://msdn.microsoft.com/en-us/library ... s.85).aspx

It may be possible to use this method to treat a Rift Tracker clone IMU (or other tracker data sources such as FreePIE, VRPN, etc.) as a "non-HID USB device", and present that as a Rift Tracker DK device.

Or you could use an embedded processor to emit a Rift Tracker DK USB data stream. A software-only approach would be better, of course.

Has anybody tried DLL injection into HID.DLL?

geekmaster wrote:

CyberVillain wrote:Sorry no, it is not possible because the rift SDK is not a compiled dll. Which means there is no entry point for us to fake rift output. Only way would be to fake the HID device, and send raw values to the real SDK. But that would be really hard because the SDK is written around the raw data from the rift and would probably behave strange if it recevies values from another hardware

Perhaps you can use the HIDUSBFX2 sample from the WDK Samples Pack ("Demonstrates mapping of a non-HID USB device to a HID device.") as a starting point:
http://msdn.microsoft.com/en-us/library ... s.85).aspx

It may be possible to use this method to treat a Rift Tracker clone IMU (or other tracker data sources such as FreePIE, VRPN, etc.) as a "non-HID USB device", and present that as a Rift Tracker DK device.

Or you could use an embedded processor to emit a Rift Tracker DK USB data stream. A software-only approach would be better, of course.

Wiiwok Deva already has discrete external headtracking sensors but we would preffer to be able to use the integrated ones, albeit without taking a toll on the connection. Apart from the latency reduction (however small), this would be reflected in a price decrease for the user as well.

Am I doing something wrong?

I installed FreePIE 1.4.433 using the installer on Windows 7 64bit.

I have an Arduino Yun + a FreeIMU supported sensor. I've verified that the Yun is sending yaw, pitch, and roll values to serial.

In FreePIE, when I've set the FreeIMU settings to point to the correct COM port (the same port I connected to using a terminal program to verify values were indeed being sent). When I run the following code, nothing happens (I'm expecting the mouse to move):
I tried simplifying things and ran this code - again, nothing happens:
I would expect that to move the mouse. But nothing happens.

So what am I missing?

update only triggers when a new data tream is recived from the IMU thats why
wont work, strange that it does not work. Whats the format of the FreeIMU output? It should be
Also what baud are you using?

CyberVillain wrote:update only triggers when a new data tream is recived from the IMU thats why

Code: Select all

def update():
   mouse.deltaX = 1

won't work

I guess that explains that.

CyberVillain wrote: strange that it does not work. Whats the format of the FreeIMU output? It should be

Code: Select all

  Serial.print(ypr[0]);
  Serial.print(",");
  Serial.print(ypr[1]);
  Serial.print(",");
  Serial.print(ypr[2]);
  Serial.println(""); 

Also what baud are you using?

That's the exact format I'm using. The baud rate is 112500 - the Yun is certainly capable of sending at that speed, but is that too fast? I'll try sending at lower speeds to see if that makes a difference.

I've tried dropping the baud rate down to 57600, though it hasn't made a difference.

Just to prove I'm not crazy (to myself, mostly), I've included some screenshots showing the output on COM4 as seen using Putty, as well as the settings for FreeIMU in FreePIE. I've also modified the script I was using before to try and output some diagnostics. Notice that I've removed any toggling - the mouse should be working right from the start. Is that a problem?

I've noticed something that might be of use: when you make a serial connection to the Yun its TX and RX leds will show activity. When I connect with Putty, the lights go bonkers the entire time, as expected. When I run the FreePIE script the lights blink for a split second then stop. It's as if the connection tries to happen, but then disconnects. What would cause FreePIE to close the serial connection?

Sorry missed that you had replied.
The only reason I can think of is that FreePIE and the device do not sync baud rate, but you said you have checked that.

For the sake of sanity, can you test with a simpler script that does not use the update event.
Like
I will have to load my IMU with the FreeIMU software to see if something has happened with newer versions of FreeIMU library. But since its just a textstring I cant see why it would not work.

I'll give that a try when I get chance. I'm also going to try using an Uno instead of the Yun. Failing that, I'll use a Teensy 3.1 and just emulate a joystick or a mouse.

I think I finally solved this.

I was totally out of ideas and decided to see if I could get FreePIE to recognize any value sent over serial. So I dropped this sketch onto an Arduino UNO: Then in FreePIE I set the FreeIMU settings to use the correct port and speed of 115200. Then I used this FreePIE script as suggested earlier:
Then I ran the script. I immediately got an error in FreePIE saying: "Input string was not in correct format."

Which is a bit crazy. On the one hand, it means FreePIE is getting something, but on the other hand, why was it thinking it was wrong? Just to make sure I wasn't crazy, I ran the script again. This time, no error. On the "Watch" tab in FreePIE I saw the freeImu.yaw value change from 0 to 1.0. I went back to my Arduino sketch, changed all the values from 1.0 to 2.0 and went back to FreePIE. On the first run, I got the incorrect string format error. When I ran it again, it worked, the 0 turned into 2.0.

So I then loaded up the full FreeIMU script on the Arduino (actually, just the MPU6050 parts, enough to get yaw, pitch, and roll values from the sensor using DMP).

As expected when I ran the FreePIE script it failed on the first run, but on the second, it finally worked. I was seeing real values in the Watch tab.

I haven't looked at the FreeIMU plugin code, but I suspect that it might need to either wait a bit for the serial connection to be ready, or it might want to ignore the first few chunks of serial data. As it works now, I think it immediately tries to parse the serial data and doesn't get what it expects and throws an error.

I considered the idea that it's not a FreeIMU plugin problem, but a problem on the Arduino side, but I've since loaded the simple sketch I showed above on two Arduino Yun, an Arduino Nano, an Arduino UNO, a Teensy 3.0 (an Arduino compatible Cortex-M4 board), and an Arduino Leonardo. Yeah, that's a lot of boards, but they're all just sitting here and super easy to simply test. In all cases, they had the same issue - first script run fails, then each works fine on the second try.

Now I just need to figure out how to calibrate the MPU6050 so the mouse isn't going insane. In any case, thanks for everyone's help!

Strange, it works every time with my Sparkfun. Do you have Visual Studio? Would be great if you could debug FreePIE and see what it recevies when it crashes
https://github.com/AndersMalmgren/FreeP ... gin.cs#L26

I'm actually checking that the message contains three values otherwise I'm waiting for next message

When you say Sparkfun, what exactly does that mean? Are you talking about an Arduino clone or some sensor that Sparkfun sells?

I don't have Visual Studio but could probably get a good idea of what those first lines of serial input look like by writing some tests that do pretty much what the FreeIMU plugin does.

I wonder if simply ignoring malformed text would fix the issue though ?