@FingerFlinger: Two ways that non-coders can help. Testing and documentation (user manual). Programmers are notoriously incompetent at both of those tasks (myself included), so it would be great to have others help out with that.

Woah! Just spotted this thread.

We could look at making an official section on the site for this - maybe a sub-forum? Do you think it would be popular?

Regards,
Neil

Well so far it has only generated casual interest. Right now there is almost no reason to choose FreePIE over GlovePIE except for the Vuzix support. Hopefully over time it will become more compelling, and there will be a reason for a support thread. But I don't think it's there yet.

But anything that can bring it out in the spotlight is welcome

Just released new alpha binaries.

Finally got moved into my new apartment, and tried out the new alpha. Seems stable, and stuff works.

@brantlew the iphone_script_works great for me; it tracks pretty smoothly and without excessive lag. Did you ever find out why you were only getting 10Hz update speed?

Oh that's great! I'm glad it's finally working. No I did not investigate the stuttering. It could be some apps on the phone or maybe something about my network. I'm happy to hear that you are not experiencing it.

BTW. There are several iPhone belt clip cases that you can simply clip onto a set of headphones for a simple head-tracking solution.

Yeah, right now I am stuffing it underneath the top-of-head strap on my HMZ, but it works well enough!

I was testing it in Oblivion for about 15 minutes and I noticed that FreePIE quit tracking suddenly. I exited and FreePIE had shut down, so a possible crash. When I have some time, I'm going to see if I can replicate the problem.

Nice its working for you, strange with the crash, can you please check the windows event viewer for errors?

1) The example uses FreeTrack which outputs in Radians, remove Math.deg if you use the AHRS plugin it outputs in Degrees, that can change the output sensativity. If its still too sensitive change multiply = 20 to something smaller

2) Ok, i tried that without success, let me know how it goes!

3) There is no raw com plugin yet for FreePIE, could wip something up. The AHRS plugin switches to binary mode by it self by sending the this command (The AHRS plugin uses binary input not text)

Thanks for clearing up a couple of those issues mate. Totally explains why I'm getting binary code to begin with hehe.. Will have a go later tonight and post my progress here. And oh, totally missed this thread to begin with

Im working on Intellisense for FreePIE which would make it a little esasier to work with

Nice to hear you're working on Intellisense, would definitely help speed things up for the likes of me

Anyway, I've got some great news actually! I calibrated the IMU like stated in that tutorial from the guy in Berlin, and tada: no more drifting! It used to lock back into a certain point before, but after calibrating the magnetometer and gyro it's doing pretty damn well. Maybe just a tiny hint of noise when used in Left4Dead2, but seriously, I was not expecting this..

Been trying to edit a video in Premiere to show you guys, but my phone apparently recorded in 22FPS and Fraps did 30, so syncing those 2 has become a pain in the ass for this late a night. Will try again tomorrow when there's more light so my phone will do 30FPS with no problem.

Next challenge is to calibrate the accelerometer though. I noticed that when I aimed at a certain point in the game with the mouse, then turned on the IMU to control it, moved it around a bit and centered the IMU again to it's original spot, it wasn't pointing at that starting point anymore. This must have something to do with calibrating the accelerometer, does it not? Anyway, going to bed, will make a new video tomorrow and upload, lol..

Cheers

I got bad news for you BadKarma. There is very little you can do to solve drift with accelerometers. They are inherently unstable devices and you should expect some drift if you use them. The only way to really fix them is with sensor fusion which basically means dynamically recalibrating them with other sensors. Often magnetometers and compasses are used to recalibrate but those are also a bit unstable because of electromagnetic field noise - so it really is a big problem. Sometimes you can "hack" it by programming a calibrate button that re-centers everything when you press it.

Even with optical tracking you get some drift in games that does not support absolute yaw and pitch (Mouse emulation)

You're right, I know it's a big problem and it cannot be 'fixed'. It's not my goal to create a perfect tracker with this, as I know it's most likely impossible without extra calibration sensors or some genius algorithm I'll never be able to conjure up .

I must say though that the AHRS firmware uses a nice sensor fusion algorithm to begin with (check out this small paragraph with more referrals to scientific papers, if you haven't already). The AHRS firmware already uses the magnetometer and gyro to compensate for drifting, and after calibrating these especially I've come up with some pretty good results (video is uploading as we speak!). And yes, I'll most likely implement a recalibration button, it seems to be my only option since I do not have all the time in the world to wrap this project up..

Anyways, still 30 min. to upload completion, so you be the judge then just be kind.. hehe.

Alright, here's the video finally. Let me know what you guys think (and be brutally honest, since that's way more helpful )

Looks great! I am glad you don't have the drift problems that CyberVillain had. It proves that this device is a viable head-tracker. Maybe he had a bad part or an electromagnetically noisy environment?

One other thought. It is possible that the drift you notice is due to mouse emulation. I am not 100% sure of the causes but I think the frame-rate/mouse sampling rate and the rate of mouse input commands can get out of sync and cause the type of problems you are seeing. Since the mouse movements are cumulative (as opposed to absolute), if the game misses some of them it will drift. Also if the game uses some type of mouse-acceleration algorithm where quick movements cause greater angular motion then you will have this problem as well.

Have you verified that the raw data angles are getting misaligned or is it just the "north" direction in the game?

Most likely.. Although judging from his last videos he had some yaw problems as well? Not sure if that had anything to do with his additional coding as he tried to get rid of his drifting though..


Thought about the mouse acceleration as well. Going to check how this works in UDK, since I probably know how to disable any mouse acceleration used in the game. Not so familiar with Source engine (which Left4Dead2 uses).


Not sure how I would go about verifying this? Perhaps turning on the debugging function in FreePIE to see the raw angles and check the response ingame would do the trick.. And what do you mean with the north direction?

Yes, you would have to use the FreePie debugging functions. Something like "diagnostics:debug(sensor:getYaw());" Unfortunately the FreePIE output console is not optimized to print quickly so it is difficult to debug with. You should try to limit your debug output to every 10th or 20th cycle to avoid overloading the GUI. I always compile a console-only version of FreePIE to avoid these printing issues.

"north" just meant any fixed direction in the game.

It looks way better than mine! I think its very hard to remove drift completely with mouse emulation. Will you hook it up to a rifle of some sort?

I will add a Watch feature "soon". So you will do diagnostics:watch(sensor:getYaw()) and then it will be presented in a grid with name sensor:getYaw() and the current value

Not too shabby. Some drift, sure, but the signal looks nice and clean at least.

By the way, in the clip when you aim for the bird you hit the roof of what the Source engine let you aim upward, but you continue to move the device up for e while even when the camera does not longer move. This will make the Y-axis out fo sync because when you start to move down again the camera will move directly

You know, I actually laughed a bit when I read this! It's so obvious yet I hadn't thought about that.. Thanks for pointing that out to me CV. Been working on a lot of paperwork today but will experiment further tomorrow with the Bluetooth module and see if I can work around the mouse restrictions in UDK. I'll run the diagnostics and compare them to the in-game results like brantlew suggested. Might even be Sunday when I do this though, but I'll keep in touch!

- Cheers

Added watch functionality, but will upload binary first when Intellisense is done
You can however download the source and build the binary yourself if you have VS

Oh nice! Could definitely use that output Yeah, I have VS installed. Will download the binary and see if I can compile it. Should I be aware of any special settings that need to be on or off for compiling? Just asking since the last time I compiled anything was over half a year, haha..

cool. nice feature

@BadKarma I think that brantlew had some problem with the Express version of VS, but I'm not sure, he can answer that better. If you have any of the paid versions it should work out of the box

@Brantlew, thanks man, been thinking of doing the feature for a long time, but haven't found the motivation until now

Quick update on the problems I was having. It turns out you were totally right CyberVillain! I managed to disable the vertical rotation limit in UDK by simply deleting the lines of code that were causing the limit in the first place. Not sure if any of you guys ever scripted in UDK, but I'll post it none the less

Original code in UTPlayercontroller:


Stripped code:


This only works partially though, as my controls seem to invert as soon as I pass the top limit. This is only normal it seems (did some quick searching) as I would need to calculate my rotation using quaternions to get a correct rotation. BUT, for my project (a tracker on a HMD) it will work just fine, since no human can lift their head high enough and look behind themselves (except perhaps in Horror movies ). So for now, this will do. I set the multiplier in the FreePIE script to 5 by the way and the results are much better.

Anyway, no video as I didn't deem it necessary for now. Tomorrow I will work some more on the casing for the Razor, using a 3D printer. I'll post a couple of pics once it's all done

- Cheers

Nice that it works better. Since you can set the pitch and yaw from code isnt there wanyway to pass the values from FreePIE to UDK? Maybe with the memory mapped file in windows?

You own a 3D printer? I envy you!

Most definitely and this can be done by binding a DLL file to UDK. But since time is of the essence and DLL coding is not my strong point I am forced to do it this way. I will however continue to work on this project once it's officially done. Simply because it would be an awesome (and relatively cheap) way for others to use the Razor and FreePIE as a headtracker in UDK. Perhaps if you're willing and have the time to spare, it might be interesting for you to integrate this with UDK and it's DLL binding functions?


I wish! I just have real easy access to one. Our school invested in one Won't be able to post any pictures today though as the guy who runs the shop and printer didn't have time this morning. Will keep you posted on this though.

By the way, did you know FreePIE and the Razor IMU plugin just saved me from redoing my semester? I put so much effort in DLL coding research, but almost gave up until I came across the Mean to be Seen forum, and specifically a couple of your threads. So again, THANK YOU.

Sorry, dont have the time to learn their engine, but if you can import any kind of dll you could use the Freetrack client dll and send Freetrack commands from FreePIE.

Glad I could help, where can I send the consultant invoice?

Haha, well, you can count on a donation when all this is over, that's for sure!

Wiimote Button Support

I added basic button support for multiple wiimotes. The wiimotes must be connected via blue-tooth before running a script. Blue-tooth connection is tricky. First you must click both 1 and 2 buttons on wiimote until the LED's blink. Then go through the Windows blue-tooth connection wizards (no pass-code) and wait until you see a taskbar popup that says the device has been successfully connected. Then you must quickly run your script the first time to connect the wiimotes. If you don't complete all this before the Wiimotes stop blinking, they will timeout and you will have to start over again. Often I would frustratingly just connect the wiimotes using GlovePIE first because it gracefully handles wiimote registration. Once the devices are registered properly however, you can start, stop, and restart FreePIE scripts without problems.


FreePIE will handle up to 4 wiimotes and light up the LEDs to indicate the numbering order. Within the script, you must indicate the wiimote index number (even if you are just using 1 wiimote). The syntax is wiimote[n]:getValue() (ie: wiimote[0].getUp() ) Currently only buttons are supported and here are the available functions.

getUp()
getDown()
getRight()
getLeft()
getA()
getB()
getMinus()
getHome()
getPlus()
getOne()
getTwo()

Here is a sample script for dual-hand Wiimote control of a FPS game

Nice work! I removed the reference to Wiimote from GUI and made a script that copies it to the correct folder. Is it a bug with the Wiimote lib or whats the problem with realease?

I'm not sure. It works in my Console release and debug fine, but it doesn't work in my GUI release. Maybe it's just a compilation error. I will retry it again later.

I can try it out later tonight, what I did when i tried out indexed plugins were to declare an indexer for the global plugin, dont think I tried it in release though. I will try to find some time later tonight to try it out

I have been putting together a script for dual-hand wiimote control of SkyRim. This is the first time I've really done any integration and real-world testing of the project, and I have uncovered a number of lingering bugs and usability issues. I uploaded fixes to several modules. The previous script can now be written simpler like this...



I'll publish the full SkyRim script in a few days designed for untethered back-top usage - complete with Vuzix head-tracking and dual wiimote control.

It worked in release for me, I removed all Wiimote code since I dont have a wii mote. But the indexer part of your code works.

Make sure to "Clean solution" every time when you build the GUI since it does not have direct references to project, I've noticed that VS does not allways copy the dll to the plugin folder.