|
It is currently Sat May 18, 2013 7:25 pm |
|
All times are UTC - 6 hours |
|
Page 1 of 3 |
[ 93 posts ] | Go to page 1, 2, 3 Next |
| Print view | Previous topic | Next topic |
[Video] Diy HeadTracking - Sparkfun Razor, Python, Gmod,
| Author | Message |
|---|---|
|
One Eyed Hopeful
Joined: Sat May 21, 2011 4:12 pm Posts: 24 Location: Minnesota 
|
Required Skills: Light Soldering, Programming with virtual com ports and sockets, Critical Thinking Required Hardware IMU: http://www.sparkfun.com/products/10736 Programming and Data Cable: http://www.sparkfun.com/products/9717 6 pin header for the cable: http://www.sparkfun.com/products/10527 (no soldering) otherwise: http://www.sparkfun.com/products/116 [EDIT by cybereality: get this instead http://www.sparkfun.com/products/9873 as per this comment viewtopic.php?p=68912#p68912 ] Required Software Python 2.7.2: http://www.python.org/getit/releases/2.7.2/ PySerial: http://pyserial.sourceforge.net/ Code: http://www.varesano.net/projects/hardware/FreeIMU#v0.4 (scroll down to FreeIMU library) Block Diagram overview: Sparkfun Razer --[UART]--> Python --[UDP Loopback]--> GMOD lua script This will get you as far as sending UDP packets to yourself. I don't know how many ppl are interested in GMOD or lua scripting so I'll leave that part out for now. 1. download and install the freeimu library 2. save and download the .pde code below to your arduino 3. check that you are receiveing UART data using the serial monitor button in the arduino IDE. 4. With pyserial and python installed, close the arduino IDE and run the python program below. 5. Use your own program to catch the packets. Alternatively, I'm sure libraries exist for other languages that allow you to interface with sockets and COM ports. I am using python because I like it and the code is really short. Last thing: In the video, the head tracking is not done through mouse or joystick input. I am directly commanding the neck joint inside of the game. I hope that more competent coders than myself will look into GMOD's lua scripting. Joint manipulation down to the finger is possible and there is example code. I am not skilled with lua scripts and there is little in documentation. rename it to whatever.pde Code: #include <ADXL345.h> #include <HMC58X3.h> #include <ITG3200.h> //#define DEBUG #include "DebugUtils.h" #include "FreeIMU.h" #include "CommunicationUtils.h" #include <Wire.h> #define ToRad(x) (x*0.01745329252) // *pi/180 #define ToDeg(x) (x*57.2957795131) // *180/pi int raw_values[9]; //char str[512]; float ypr[3]; // yaw pitch roll float val[9]; // Set the FreeIMU object FreeIMU my3IMU = FreeIMU(); void setup() { Serial.begin(9600); Wire.begin(); delay(5); my3IMU.init(); // the parameter enable or disable fast mode delay(5); } void loop() { my3IMU.getYawPitchRoll(ypr); //roll pitch yaw format Serial.print(ypr[2]); Serial.print(","); Serial.print(ypr[1]); Serial.print(","); Serial.print(ypr[0]); Serial.println(); delay(5); } rename to whatever.py Code: # UDP client example import socket import serial import time ser = serial.Serial(port='COM14',baudrate=9600, timeout=1) client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) port=5003 counter=0 print '---IMU Serial IPC Link---' time.sleep(3) try: while 1: counter = counter + 1 data = ser.readline() client_socket.sendto(data, ("localhost",port)) time.sleep(0.020) if (counter >= 30): print data counter = 0 except KeyboardInterrupt: client_socket.close() ser.close() print 'Disconnected...' client_socket.close() ser.close() Last edited by mars3554 on Mon Nov 07, 2011 6:35 pm, edited 1 time in total. |
| Sat Nov 05, 2011 8:22 pm |
|
|
|
|
3D Angel Eyes (Moderator)  Joined: Sat Apr 12, 2008 8:18 pm Posts: 10022
|
Wow! This is really awesome man!
I know a lot of people are going to be interested in a solution like this, for use with the HMZ-T1. _________________  |
| Sat Nov 05, 2011 9:24 pm |
|
|
|
|
One Eyed Hopeful
Joined: Sat May 21, 2011 4:12 pm Posts: 24 Location: Minnesota
|
cybereality wrote: Wow! This is really awesome man! I know a lot of people are going to be interested in a solution like this, for use with the HMZ-T1. Haha thanks, That's exactly what I'll be doing once I get mine. I'm working on a wireless board so I can stand up and turn around without wrapping myself in cables. I'm hoping to get the price down from what sparkfun (over)charges. |
| Sat Nov 05, 2011 9:37 pm |
|
|
|
|
Sharp Eyed Eagle!
Joined: Sat Apr 12, 2008 9:45 pm Posts: 373
|
Cool! How do you program that the game will recognize 0 degree pitch = horizontal level?
|
| Sat Nov 05, 2011 10:03 pm |
|
|
|
|
One Eyed Hopeful
Joined: Sat May 21, 2011 4:12 pm Posts: 24 Location: Minnesota
|
pierreye wrote: Cool! How do you program that the game will recognize 0 degree pitch = horizontal level? In the old days, programming mods for the hl/hl2 engine required you to recompile everything and then test. Since lua has been implemented into garry's mod, mostly everything is "hooked". I'm not going to pretend to know what that means but the end effect is that you can run text style scripts in the game in real time and then alt+tab out, edit some code, then rerun the script in game. Things like where the eye socket and arms and legs are pointed can be changed this way. It looks something like this (lua script) Code: lockedViewAng.r = -ControlNodes[2] lockedViewAng.p = -ControlNodes[1]-45 lockedViewAng.y = -ControlNodes[3] tl;dr the roll, pitch, and yaw, is "set". Instead of emulating a mouse, there's a variable that holds the direction of where the player is looking. That variable is over written every frame by my function. |
| Sat Nov 05, 2011 10:32 pm |
|
|
|
|
Petrif-Eyed  Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
Nice.
The sparkfun definitely seems like the best choice for 360 degree head tracking - regardless of price. |
| Sun Nov 06, 2011 2:58 pm |
|
|
|
|
Sharp Eyed Eagle!
Joined: Sat Apr 12, 2008 9:45 pm Posts: 373
|
@mars3554 - Thanks for the explanation. Looks like only way to get 1:1 mapping is to hook into their code or API. Unless there is a DirectX command that we can tap to get absolute position in the game we can only emulate relative position.
|
| Sun Nov 06, 2011 9:28 pm |
|
|
|
|
3D Angel Eyes (Moderator) Joined: Sat Apr 12, 2008 8:18 pm Posts: 10022
|
@pierreye: If the tracker is good enough, you can achieve close to 1:1 with relative movement. This is how I did it with my mouse emulator. The video should be up shortly, but I was able to play for around 10 minutes with little to no drift in pitch. Of course, absolute will always be better, but that is not to say that relative can't work.
_________________ |
| Sun Nov 06, 2011 9:34 pm |
|
|
|
|
One Eyed Hopeful
Joined: Sat May 21, 2011 4:12 pm Posts: 24 Location: Minnesota
|
pierreye wrote: @mars3554 - Thanks for the explanation. Looks like only way to get 1:1 mapping is to hook into their code or API. Unless there is a DirectX command that we can tap to get absolute position in the game we can only emulate relative position. I think you are correct. I had the advantage of having access to those resources but 99% of the games out there do not give you that privilege. That said, I do think it's possible to do it without permission by using the same method that aimbot developers use. I have personally never taken one apart but I don't see any other way to move the aiming vector to a different position accurate enough to get headshots consistently. cybereality wrote: @pierreye: If the tracker is good enough, you can achieve close to 1:1 with relative movement. This is how I did it with my mouse emulator. The video should be up shortly, but I was able to play for around 10 minutes with little to no drift in pitch. Of course, absolute will always be better, but that is not to say that relative can't work. That is interesting. I'm wondering if there is any errors accumulated from the game engine and OS side. The Mouse or device might send data but the OS might skip it. The OS might get the data from the mouse but the game engine will skip it. If the error rate is very low, then a user might not even be able to notice the offset error in a 2 hour session of gaming. |
| Sun Nov 06, 2011 10:30 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
This sounds very interesting I'm a very experienced C# programmer but not very good at algebra. How much work would it be to convert the input from the COM to xyz rotation and xyz translation values? If I have that data I could easily write a DirectX joystick emulator (I've done this part before).
I guess you will need a reset hotkey so that you can tell the API where zero is, but shouldnt be that hard. |
| Mon Nov 07, 2011 9:09 am |
|
|
|
|
One Eyed Hopeful
Joined: Sat May 21, 2011 4:12 pm Posts: 24 Location: Minnesota
|
CyberVillain wrote: This sounds very interesting I'm a very experienced C# programmer but not very good at algebra. How much work would it be to convert the input from the COM to xyz rotation and xyz translation values? If I have that data I could easily write a DirectX joystick emulator (I've done this part before). I guess you will need a reset hotkey so that you can tell the API where zero is, but shouldnt be that hard. you wont get any translational values, the imu is purely rotational. it doesnt know where your head is but knows what direction its looking. the values are comma seperated in roll,pitch,yawn format. the units are in degrees. |
| Mon Nov 07, 2011 1:21 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
mars3554 wrote: CyberVillain wrote: This sounds very interesting I'm a very experienced C# programmer but not very good at algebra. How much work would it be to convert the input from the COM to xyz rotation and xyz translation values? If I have that data I could easily write a DirectX joystick emulator (I've done this part before). I guess you will need a reset hotkey so that you can tell the API where zero is, but shouldnt be that hard. you wont get any translational values, the imu is purely rotational. it doesnt know where your head is but knows what direction its looking. the values are comma seperated in roll,pitch,yawn format. the units are in degrees. was a bit tired when i read that  offcourse it can only do rotation... cool, sounds easy enough.. So its ready to go with the USB virtual comport and the device itself, just plugit it in and connect to the com port using your language of choice?edit: its this part that makes me ask, "check that you are receiveing UART data using the serial monitor button in the arduino IDE." IF it was purely com it wouldnt need a third party software to receive the data? |
| Mon Nov 07, 2011 6:07 pm |
|
|
|
|
One Eyed Hopeful
Joined: Sat May 21, 2011 4:12 pm Posts: 24 Location: Minnesota
|
CyberVillain wrote: mars3554 wrote: CyberVillain wrote: This sounds very interesting I'm a very experienced C# programmer but not very good at algebra. How much work would it be to convert the input from the COM to xyz rotation and xyz translation values? If I have that data I could easily write a DirectX joystick emulator (I've done this part before). I guess you will need a reset hotkey so that you can tell the API where zero is, but shouldnt be that hard. you wont get any translational values, the imu is purely rotational. it doesnt know where your head is but knows what direction its looking. the values are comma seperated in roll,pitch,yawn format. the units are in degrees. was a bit tired when i read that offcourse it can only do rotation... cool, sounds easy enough.. So its ready to go with the USB virtual comport and the device itself, just plugit it in and connect to the com port using your language of choice?edit: its this part that makes me ask, "check that you are receiveing UART data using the serial monitor button in the arduino IDE." IF it was purely com it wouldnt need a third party software to receive the data? The cable I linked has an FTDI chip inside of it. It will convert the 6 female UART serial pins to a VCP port. With the VCP (virtual com port) drivers from http://www.ftdichip.com/Drivers/VCP.htm a virtual com port will be created when the device is plugged in. Inside the arduino IDE, there is a terminal where you can view data on different available com ports and at different baud rates. I also forgot to mention, you will need a 6 pin header for the usb cable razor board interface. They are 0.1" spacing. If you don't want to solder pins, I think these will work http://www.sparkfun.com/products/10527 otherwise: http://www.sparkfun.com/products/116 I know I link a lot of sparkfun stuff but feel free to use any vender you wish, eg digikey, mouser, newark, etc. And yes, any language should work. I know java likes rxtx, python uses pyserial, and c++ does its own thing. |
| Mon Nov 07, 2011 6:33 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
OK so one SEN-10736 and one DEV-09717 ordered, lets hope I can make something out of this...
|
| Thu Dec 29, 2011 1:11 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
Mars, have you seen this on the page for the cable?
Quote: Originally, the cable was designed to have 3.3V VCC, however something was lost in translation between SparkFun and our supplier and we got stuck with a whole bunch of FTDI cables that have a slight mix up in wiring. These have 5V VCC, and 3.3V I/O. The 5V Vcc output shouldn't be a problem unless this cable is being used to power a sensitive circuit such as a sensor. What is your take on this? |
| Thu Jan 05, 2012 2:02 am |
|
|
|
|
Petrif-Eyed Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
CyberVillain, I'm going to move the discussion onto this thread to increase visibility.
Previous thread: http://www.mtbs3d.com/phpBB/viewtopic.php?f=26&t=14167&start=0 CyberVillain wrote: Strange company, if it was my company I would have recalled the cables... I will ask mars3554 in his thread about this... If you look at mars youtube clip you can see that the 2 pin header at the front is not connected Yeah but at least those guys are "straight-shooters". They disclose everything about their components (warts and all) so you know exactly what to expect. The more I think about it, I'm pretty sure the 3.3V pin on the Sparkfun is an (optional) unregulated power supply pin to run the sensors and CPU. But you can also power the device through the regulated power connector (3 AA batteries would be sufficient). It's just unfortunate that the cable power can't be used because it does simplify the setup. However if you're thinking about going BlueTooth, you're going to need a battey pack anyways. |
| Thu Jan 05, 2012 9:14 am |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
If you look at Mars youtube clip you it looks like a straight connection from the USB to the IMU, but we need his answer to be certain.. Mars where are youuu
I want to hook mine up tonight |
| Thu Jan 05, 2012 10:07 am |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
I have a thread going on the sparkfun forum, nothing concrete yet though. I reallly hope mars reads this soon and can shed some light over it.. he doesnt mentioned anything about powering the chip in this thread so i guess i just let the pin on the cable do it, but i want confirmation before i hook up a expensive chip like this
http://forum.sparkfun.com/viewtopic.php ... 33#p137833 |
| Thu Jan 05, 2012 11:05 am |
|
|
|
|
Petrif-Eyed Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
I think you can safely just connect TX, RX, and GND pins and then supply power to the regulated power connector via a 3 AA battery pack from Radio Shack . A temporary solution until you integrate the BlueTooth
|
| Thu Jan 05, 2012 12:22 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
who, me? Im not going for a wireless solution (Your thinking about the guy who is doing a VR gun).. So I would rather use the cable only if possible, but I do not like risking the IMU just to test.. I hope Mars will see this anytime soon. OH well, going to the movies with my girl now so do time for playing anyway.. Hope i have an answer tomorrow so i can start playing
|
| Thu Jan 05, 2012 12:57 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
Got an answer from Sparkfun
Quote: The I/O on that cable is 3.3V, but the VCC pin is 5V. The microcontroller on the board can handle 5V just fine, but I don't think the sensors can. If you connect this directly to the FTDI port on the board you will most likely fry one or more of the sensors. If you plug the power into the connectors behind the JST connector (or the JST connector itself) you should be fine since this signal is regulated. Let me know if you have any other questions. Why would i care if the internal voltage is 3.3 volt when they output 5 Anyway, I guess I can remove the 5V pin from the header and route that 5v to the JST pin which as a volt regulatoredit: But what i want is that SParkfun or my Swedish distributor supply me with a correct cable |
| Fri Jan 06, 2012 6:16 am |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
when i connect the usb cable to the computer i get no reaction at all, and i get no voltage off the vcc pin, probably a faulty cable :/
|
| Sat Jan 07, 2012 10:39 am |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
Can a moderator change the first post in this thread and remove the link to the USB cable and add a link to this product
http://www.sparkfun.com/products/9873 The USB cable will fry the sensors on the board... |
| Mon Jan 09, 2012 7:57 am |
|
|
|
|
Petrif-Eyed Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
CyberVillain wrote: Can a moderator change the first post in this thread and remove the link to the USB cable and add a link to this product http://www.sparkfun.com/products/9873 The USB cable will fry the sensors on the board... Oh crap did you fry your Sparkfun? Does that cable not downconvert from serial to TTL voltages? |
| Mon Jan 09, 2012 8:58 am |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
brantlew wrote: CyberVillain wrote: Can a moderator change the first post in this thread and remove the link to the USB cable and add a link to this product http://www.sparkfun.com/products/9873 The USB cable will fry the sensors on the board... Oh crap did you fry your Sparkfun? Does that cable not downconvert from serial to TTL voltages? No, no.. I just dont wont anyone else yo fry theirs, if they only read the first post and go try it they will I'm waiting on a replacement cable because mine was broken.. I hope to get it tomorrow |
| Mon Jan 09, 2012 3:29 pm |
|
|
|
|
3D Angel Eyes (Moderator) Joined: Sat Apr 12, 2008 8:18 pm Posts: 10022
|
Ok, no prob. Made the edit.
_________________ |
| Mon Jan 09, 2012 9:15 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
thanks CR
|
| Tue Jan 10, 2012 1:58 am |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
it is all hooked up now, but I got problems
I have downloaded this copy of the FreeIMU library http://www.varesano.net/files/libraries_20111205_2110.zip And i've included all the libs that the compiler complains about. Now my sketch file looks like this Code: #include <ITG3200.h> #include <MS561101BA.h> #include <HMC58X3.h> #include <bma180.h> #include <Wire.h> #include <CommunicationUtils.h> #include <FreeIMU.h> Get this compiler error Quote: C:\Program Files (x86)\arduino-1.0\libraries\MS561101BA\MS561101BA.cpp: In member function 'long unsigned int MS561101BA::getConversion(uint8_t)': C:\Program Files (x86)\arduino-1.0\libraries\MS561101BA\MS561101BA.cpp:144: error: call of overloaded 'write(int)' is ambiguous C:\Program Files (x86)\arduino-1.0\libraries\Wire/Wire.h:55: note: candidates are: virtual size_t TwoWire::write(uint8_t) C:\Program Files (x86)\arduino-1.0\hardware\arduino\cores\arduino/Print.h:49: note: size_t Print::write(const char*) Looks like there are two write methods and it does not know which one to use.... Whats wrong? Thanks.. If you wanna try you can download the Arduino IDE, install the freeimu library and compile (You do not need the board to do this) |
| Wed Jan 11, 2012 12:18 pm |
|
|
|
|
Petrif-Eyed Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
Didn't download code, but I suspect a #define variable would probably clear it up, but you might have to dig around to find it. You might look at the definition of uint8_t for starters.
Another more direct method would be to just modify to source code to directly cast that variable or the object that's calling it. Code: // cast the parameter to clear the ambiguity object->write((uint8_t)var); // or cast the object to force the correct method call ((TwoWire*)object)->write(var); If that's the only ambiguous occurrence then you're golden - but don't be surprised if there are dozens in which case you might have to search for #define(s) Hope that helps. |
| Wed Jan 11, 2012 1:00 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
Fixed it! I am now receving data
Will write a quick C# test consoleprogram.. give me an hour and I have a youtube video up |
| Wed Jan 11, 2012 1:10 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
|
| Wed Jan 11, 2012 3:18 pm |
|
|
|
|
Petrif-Eyed Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
Looks great! Can't wait to get my hands on one of these. Maybe you are seeing tracker noise and just need to put a smoothing filter on it. Is it bridged through GlovePie or another interface?
Also when you get a chance can you look to see if the spatial translation (X, Y, Z) tracking works at all or does it look like garbage? |
| Wed Jan 11, 2012 3:32 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
Its a problem with my Freetrack emulation, if i send a static float on all 3 axis i still get jumpy behaviur.. Strange thing is when I include the freetrackclient.dll in a testproject it looks good, and Arma2 uses the same dll to read freetrack data so I do not know where they read the wrong data from :/
Hmm, theres only 3DOF? I cant get translation values of this one can I? |
| Wed Jan 11, 2012 4:10 pm |
|
|
|
|
Petrif-Eyed Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
It should have the sensors on-board to estimate translation. Maybe FreeIMU only supports orientation. Bummer.
|
| Wed Jan 11, 2012 4:22 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
I do not think freeemu supports it oit of the box.. maybe you can take the data from the 9 sensors and do the math yourself?
|
| Wed Jan 11, 2012 4:41 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
There is some huge drift, I do not know if its my copy or if all suffer from it :/
|
| Wed Jan 11, 2012 5:24 pm |
|
|
|
|
3D Angel Eyes (Moderator) Joined: Sat Apr 12, 2008 8:18 pm Posts: 10022
|
Not bad for a first test.
You can try putting a sort-of low-pass filter on the readings. I did that for the Vuzix tracker I made. Basically set a maximum delta value with something reasonable and then ignore anything over this amount. It should be the fastest you could expect a user to move during one frame (could be around 10-20 degrees). I found this to pretty much eliminate those kinds of random jitters. _________________ |
| Wed Jan 11, 2012 10:33 pm |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
YEah, I have a low pass filter... Its something else, maybe its the float precision or something, Arma2 maybe want a lower precision or something. If i use the real freetrack server everything works, but if I use my freetrack server emulator it does not work.. If I send hard coded values with low number of decimals it works, like 0.1, if i send 0.00001 or something like that I get the stutter.. So its not related to the sensordata, its something in my way of simulating Freetrack...
|
| Thu Jan 12, 2012 1:56 am |
|
|
|
|
Terrif-eying the Ladies!
Joined: Mon Jun 22, 2009 8:36 am Posts: 933 Location: Stockholm, Sweden
|
I've also written a little freetrackclient test program that uses the standard freetrackclient.dll (same as Arma2) and that works. So its a combination of some code in Arma2 and C# floats thats strange.. I think
 |
| Thu Jan 12, 2012 2:25 am |
|
|
|
|
Petrif-Eyed Joined: Sat Sep 17, 2011 9:23 pm Posts: 2035 Location: Irvine, CA
|
Any possibility its a byte ordering issue? I've stumbled across weird crap like this a lot working in Java where the byte ordering is enforced as little-endian as opposed to x86 native. Had same problem with OSC and GlovePie.
|
| Thu Jan 12, 2012 9:16 am |
|
|
|
|
|
Page 1 of 3 |
[ 93 posts ] | Go to page 1, 2, 3 Next |
|
All times are UTC - 6 hours |
Who is online |
Users browsing this forum: No registered users and 0 guests |
| You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum |