Android

[shent1080]

I was wrong, with orientation only ticked it works, will check it out with a game but it takes the readings from the side of the tablet,is there and way to get it to take readings from the back of the tablet?

I have a transformer tf101 and want to useit with lenses as both display and tracking for a wireless hmd

[mahler]

... it takes the readings from the side of the tablet,is there and way to get it to take readings from the back of the tablet?

What do you mean exactly?

[shent1080]

So if i point the tablet edge at my monitor and move up down left and right, the mouse cursor responds exactly as it should, mirroring my actions, but if i put the tablet so the screen is facing me and i do the same, the response does not mirror my movements at all.

[logicalChimp]

I don't think you can change the orientation of the sensors on the tablet.

However, you should be able to cross-map them in FreePIE.

E.g. mouse.x = Android.roll instead of mouse.x = Android.yaw

chances are pitch will still be correct - guess it depends on the specific orientation changes tho

[shent1080]

That makes sense, i'll have a play around with the script

Thanks logicalchimp

[shent1080]

I've changed the the script settings regarding yaw, pitch, and roll, got the cursor to move around in sort of the same direction as my tablet while the screen is facing me but the axis are off, either diagnally as illustrated in the screenshot, or forming sweeping curves through the screen.

Do i need to change anything else within the script?
messing around with sensitivity won't change anything will it?
does my pc need to be directly plugged into the router or is wireless fine?

Any help would be appreciated.

[CyberVillain]

How are you holding your tablet?
If you are not holding it flat i´m guessing that some advanced filtering is needed to compensate for the yaw not being aligned with the magnetic north. try holding it flat and use yaw as mouse x

I added a version that works with both formats being sent

[shent1080]

Thanks for the updated APK, when my tablet is charged i'll have a play with it.

Regarding the mouseX to yaw did you mean changing any values with mouse x to match my Yaw setting at the top of the script ie Pitch, so...

mouse.deltaX = -deltaYaw*multiply
to
mouse.deltaX = -deltaPitch*multiply

or just changing the code at the top of the script so Yaw=Yaw and not Pitch etc?

[CyberVillain]

Yes, but more important how are you holding the tablet? Try holding it flat with the screen facing the roof. Yaw should then be mapped to x. If you want to hold the tablet in another direction then you need to come up with a way of calculating a new yaw.

[shent1080]

Sorry didn't answer the tablet orientation q.

I have the screen facing me, just waiting for my tablet to charge and i'll have ago on it, i think it was actually more accurate when the screen was facing the roof.

BTW checked out that imu that i posted, 2 out of the 3 sensors are the same as the razerimu and the 3rd sensor appears on one of the other freeimu boards so should be accepted.

I think this is going to be the way to go for me if i can't get the control scheme working when the tablet is facing me.

I'll ask over at the fov2go forum regarding the tablet scheme and will post you a script if can find/create one.

Thanks Cyber Villain

[CyberVillain]

The problem is that the magnometer won't work with the tablet faced like that, try the Google fusion, its not using the magnometer

[shent1080]

Google fusion, is that just replacing android.yaw with android.googleYaw in any script?

[CyberVillain]

Yupp

[shent1080]

Thanks

[mahler]

I didn't test this myself, but I saw an interesting post concerning the open source Madgwick AHRS algorithm written in C (Blog post: Nov 2, 2012)
http://www.diydrones.com/forum/topics/m ... quare-root

Currently the Android plugin is using the X-IO open source Mahoney AHRS algorithm written in C# because at the time (Sep 2012) it performed better than Madgwick in C# for some reason (which I forgot)

A while back, I also made a point about using the Fast Inverse Square Root algorithm, which is nice trick that can be used in C

Perhaps this improvement makes it worth while looking at the Madgwick algorithm again.
And make the decision to use a compiled version of the code written in C

Just putting this here as a reminder.

[CyberVillain]

I didn't test this myself, but I saw an interesting post concerning the open source Madgwick AHRS algorithm written in C (Blog post: Nov 2, 2012)
http://www.diydrones.com/forum/topics/m ... quare-root

Currently the Android plugin is using the X-IO open source Mahoney AHRS algorithm written in C# because at the time (Sep 2012) it performed better than Madgwick in C# for some reason (which I forgot)

A while back, I also made a point about using the Fast Inverse Square Root algorithm, which is nice trick that can be used in C

Perhaps this improvement makes it worth while looking at the Madgwick algorithm again.
And make the decision to use a compiled version of the code written in C

Just putting this here as a reminder.

Do you feel like you wanna do it? I'm a bit stuck with my other paying projects

[mahler]

Do you feel like you wanna do it? I'm a bit stuck with my other paying projects

I want to. Too many interests, too little time.
I'm sure I'll have some time in the next few weeks, so if it hasn't been done by then... I'll probably pick it up.

I also made a note for 2013 to get out more (and I don't mean with a backtop like brantlew )
Good luck with the projects!

[Unclebob]

Help

So snow days are good days for rift building.

To summarise I am trying to get Freepie to work with my Nexus 7 and stream to the Nexus 7 via Splashtop THD.

Unfortunately I can't get it to work.

With the NEXUS 7 held still in a vice the DeBUG on the Andriod app shows 0 changes across all the sensors.

However.

All the "watched" variables in the Freepie PC application are changing constantly. In fact they are all dropping at a regular rates.

Could this point to some variable in a loop being incorrectly assigned within Freepie? Surely with little or no change on sensor data being generated by the NEXUS there should be no variation in the values of the variables that then drive the mouse in Freepie.

Stuck unfortunately.

Did I say Help?

I love snow days

UB

[CyberVillain]

Help

So snow days are good days for rift building.

To summarise I am trying to get Freepie to work with my Nexus 7 and stream to the Nexus 7 via Splashtop THD.

Unfortunately I can't get it to work.

With the NEXUS 7 held still in a vice the DeBUG on the Andriod app shows 0 changes across all the sensors.

However.

All the "watched" variables in the Freepie PC application are changing constantly. In fact they are all dropping at a regular rates.

Could this point to some variable in a loop being incorrectly assigned within Freepie? Surely with little or no change on sensor data being generated by the NEXUS there should be no variation in the values of the variables that then drive the mouse in Freepie.

Stuck unfortunately.

Did I say Help?

I love snow days

UB

You have tried both android.yaw and android.googleYaw? They show the same amount of strange values? Instead of outputting to the mouse use diagnostics.watch(android.yaw) etc its probably easier to debug that way

[CyberRascal]

I just wanted to point out that even a small value (0.000000001) on the gyro or even mag/acc sensors will over time cause a large amount of drift. My initial tests using the same algorithm with a HTC One X causes drift from 0 -> 90 degrees yaw in about 120-180 seconds (the gyro sensor is biased towards the last direction it moved, in my case)

I'm not a good enough physics and numerics guy to correct the algorithm though... It might also be my phone that is giving a lot of noise!

[mahler]

Help. So snow days are good days for rift building.
To summarise I am trying to get Freepie to work with my Nexus 7 and stream to the Nexus 7 via Splashtop THD. Unfortunately I can't get it to work.
With the NEXUS 7 held still in a vice the DeBUG on the Andriod app shows 0 changes across all the sensors. However.
All the "watched" variables in the Freepie PC application are changing constantly. In fact they are all dropping at a regular rates.
Could this point to some variable in a loop being incorrectly assigned within Freepie?
Surely with little or no change on sensor data being generated by the NEXUS there should be no variation in the values of the variables that then drive the mouse in Freepie.
Stuck unfortunately. Did I say Help? I love snow days. UB

Hi UB,

After looking at these values again I saw what you meant. The fused values you see in FreePIE (mainly yaw, but others too) have quite a bit of drift.
My initial reaction was that something must have gone wrong in the last few versions. But then I noticed that I was looking at the radians instead of degrees. After they are converted to degrees it results in 'just' about 1 degree per ~3-4 sec. which is actually not that much after you translate that to pixels for a mouse pointer. Although this may depend on the quality of your device-sensors. So for now, I will have to say... this is how it has always worked. The mouse-pointer will stay relatively at the same position, but it will shake a bit up and down and drift some pixels per few seconds. As previously said, the google-fusion is somehow more stable and drifts a bit less, but has a higher latency.

The fact that the values on the phone are not changing much is because they are the raw sensordata. The Acc. & Gyro only describe relative movement/rotation over the axis between intervals and don't give you absolute data. And although the accuracy of the magnometer is very good, it has too much lag to perform well on it's own. So all this data will still have to be fused into orientation angles.

Note: Mahoney (raw-data) fusion will work as well as your Wi-Fi connection, because if packets get lost it has less samples per second on your PC to work with. For Google fusion it doesn't really matter because this is already done on the device and only the absolute orientation is send to FreePIE. If a packet is lost, the next update will correct. You will notice that the values of GoogleYaw/Roll/Pitch in FreePIE are exactly the same as the Debug-value in the Android-app. Which also drifts.

Another note: I'm testing on the Galaxy Nexus containing an Invensense MPU6050 which is the same as your Nexus 7

[Unclebob]

I just wanted to point out that even a small value (0.000000001) on the gyro or even mag/acc sensors will over time cause a large amount of drift. My initial tests using the same algorithm with a HTC One X causes drift from 0 -> 90 degrees yaw in about 120-180 seconds (the gyro sensor is biased towards the last direction it moved, in my case)

I'm not a good enough physics and numerics guy to correct the algorithm though... It might also be my phone that is giving a lot of noise!

Saw this.

Stop one axis by using a #.

if enabled:
mouse.deltaX = deltaroll*multiply-.2
#mouse.deltaY = -deltaPitch*multiply

Then experiment using a constant to fix the drift along that axis in the above case it was -2.

You can also define multiply1 to a different value and gain the same sensitivity across both axis if necessary.

It does not have to be too complex as the drift seems constant.

Hope this helps.

By the way I can always get one axis to work properly. Unfortunately for some reason the values for mouse.deltaX effect mouse.deltaY even though its rem'ed out.

Possible due to the fusion algorithm. But I would have assumed if no data is being sent to mouse.deltaY then no movement on that axis would be possible...

Good luck

UB

[Unclebob]

Help. So snow days are good days for rift building.
To summarise I am trying to get Freepie to work with my Nexus 7 and stream to the Nexus 7 via Splashtop THD. Unfortunately I can't get it to work.
With the NEXUS 7 held still in a vice the DeBUG on the Andriod app shows 0 changes across all the sensors. However.
All the "watched" variables in the Freepie PC application are changing constantly. In fact they are all dropping at a regular rates.
Could this point to some variable in a loop being incorrectly assigned within Freepie?
Surely with little or no change on sensor data being generated by the NEXUS there should be no variation in the values of the variables that then drive the mouse in Freepie.
Stuck unfortunately. Did I say Help? I love snow days. UB

Hi UB,

After looking at these values again I saw what you meant. The fused values you see in FreePIE (mainly yaw, but others too) have quite a bit of drift.
My initial reaction was that something must have gone wrong in the last few versions. But then I noticed that I was looking at the radians instead of degrees. After they are converted to degrees it results in 'just' about 1 degree per ~3-4 sec. which is actually not that much after you translate that to pixels for a mouse pointer. Although this may depend on the quality of your device-sensors. So for now, I will have to say... this is how it has always worked. The mouse-pointer will stay relatively at the same position, but it will shake a bit up and down and drift some pixels per few seconds. As previously said, the google-fusion is somehow more stable and drifts a bit less, but has a higher latency.

The fact that the values on the phone are not changing much is because they are the raw sensordata. The Acc. & Gyro only describe relative movement/rotation over the axis between intervals and don't give you absolute data. And although the accuracy of the magnometer is very good, it has too much lag to perform well on it's own. So all this data will still have to be fused into orientation angles.

Note: Mahoney (raw-data) fusion will work as well as your Wi-Fi connection, because if packets get lost it has less samples per second on your PC to work with. For Google fusion it doesn't really matter because this is already done on the device and only the absolute orientation is send to FreePIE. If a packet is lost, the next update will correct. You will notice that the values of GoogleYaw/Roll/Pitch in FreePIE are exactly the same as the Debug-value in the Android-app. Which also drifts.

Another note: I'm testing on the Galaxy Nexus containing an Invensense MPU6050 which is the same as your Nexus 7

Thank you for yesterday mahler. Very much appreciated.

I still don't understand how a constant drift (like a countdown) is introduced

diagnostics.watch(deltaPitch)

given that the values input into the algorithm are not increasing but staying constant even though they may be pitching around one number by .00001s of value in Debug on the phone.

Or

As above if I rem out the feed to the mouse #mouse.deltaY

mouse.deltaX = deltaroll*multiply-.2
#mouse.deltaY = -deltaPitch*multiply

Movement of the device still causes movement on the Y axis. Surly as there is no #mouse.deltaY input from the script it should remain unchanged at zero.

Hey ho - time for work

Good luck all and thank you again

UB

[Unclebob]

http://www.thousand-thoughts.com/2012/0 ... utorial/3/

So Gyro drift is unavoidable.

Although can be minimised...which is why fusion is less accurate.

UB

[CyberVillain]

I got inspired by Brantlews work on his Red Rovr system and want to try the same thing with the Android plugin.
Before I reinvent the wheel does the Android SDK provide a way of getting fused GPS / Gyro / Accelerometer data?
Using raw GPS will probably be to laggy and it will jump around too much to get a good delta speed, but together with the other sensors it might get good enough for in game movement tracking

[mahler]

I got inspired by Brantlews work on his Red Rovr system and want to try the same thing with the Android plugin.
Before I reinvent the wheel does the Android SDK provide a way of getting fused GPS / Gyro / Accelerometer data?
Using raw GPS will probably be to laggy and it will jump around too much to get a good delta speed, but together with the other sensors it might get good enough for in game movement tracking

I like the idea. If you start building, I'll be keeping a close eye on the code.
Unfortunately there isn't anything clearcut exactly like the Red Rovr system.

If there's anything in the latest API regarding sensors you can use, you should be able to find it in the API guides.

Starting point: Guide: Location and Sensors
You best chance would be this guide: Guide: Location Strategies

Other important guides are:

• Guide: Using the Location Manager
• Guide: Motion Sensors
• Guide: Position Sensors

[CyberVillain]

I was workig some on this tonight, looks like Loaction.distanceBetween is our best bet if we do not want to mess with long and lat ourself

http://developer.android.com/reference/ ... float[]%29

But I must say that I do not understand the output, bearing in the WGS84 ellipsoid format?

What I really want is delta X and delta Y in meters then I can use the orientation vector to calculate x and y speeds relative to the way the body is facing

I must have been doing something wrong, because now it returns the bearing in degrees

[mahler]

I didn't read your message correctly. From what I see in the documentation, the Android library always returns angles (and bearings) in degrees.

From what I read on Wikipedia the WSG84 is just a method to calculate distances on the earth based on a mathematical model. You will still get normal degrees as usual.

[CyberVillain]

I didn't read your message correctly. You want the bearings in ... RAD?

No i didn't get any sense out of the readings the first time around but now i get distance in meters and bearing in degrees.
Will see how accurate it is when I go to work tomorrow I live in the city so it probably wont be too accurate with all the houses.

I created a branch if you wanna check it out,

https://github.com/AndersMalmgren/FreePIE/tree/VRWalk

It's not sending any data to FreePIE yet, I only show the GPS data in the debug part of the app

[CyberVillain]

Tried it to work today, as suspected the data was way off, but thats probably just because of all the houses, though small Stockholm still has some

What I also noticed was that it was very slow updating not even a frequency of 1hz, maybe it has todo with the low data quality but maybe I'm doing somethign wrong.

I'm using

Code: Select all

	if(sendGPS)
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,
                       0, 0, this); 

Where ther zeros are minTime and minDistanc between updates, zero should give as fast as possible?

[CyberVillain]

Mahler can you try the latest version in the branch? I have some problems, i think its thread related because the program only crashes when i have both Orientation and raw ticked. Since its java i do not get a good stacktrace or anything to go on :/

[mahler]

Mahler can you try the latest version in the branch? I have some problems, i think its thread related because the program only crashes when i have both Orientation and raw ticked. Since its java i do not get a good stacktrace or anything to go on :/

One of the ideas I've had for the Android app was separating the sending of orientation and raw data. Since I never use both and I suspect nobody else does either. Instead of a checkbox, just have a switch. This would also make it easier for users who get confused and you can get rid of GoogleYaw etc. in the FreePIE Android-plugin. Perhaps this would help with the current issue also.

As much as I would like, unfortunately I don't have much time to spend on this myself.

[CyberVillain]

Found the problem

[CyberVillain]

First test version of VR Walking

Install the apk included in rar copy over the plugin dll to the plugin folder in FreePIE

You need to send both Orientation and GPS data from the Android app, DeltaX and DeltaY reflects the movement between two GPS samples relative to the Yaw. Current version requires the phone yaw to be synced with the body yaw, so if body faces north phone should face north too, you can test this with the debug feature Zero = North.

Todo, I would love some help!

1) Explore the possibilities of fusing GPS and Acceleremoter data. Integrated Acc (Velocity) and Kalman Filter could work, but I think the error in the Acc can be too great.

2) If #1 isnt possible maybe code some fuzzy logic around the Acc-data to improve fast changes in movement like strafing, coming into a halt etc

3) Yaw calibration feature. Current version requires the phone and body yaw to be in sync. This could create problems if a user puts the phone in a Rucksack and the yaw of the phone ends up out of sync with the user. A calibrate method can be called from the script, the users takes x meters and we use that data to get the Bearing (Of the GPS) then we can store the delta between Orientation Yaw (Phone) and bearing yaw (Body)

4) Explore the possibilities of redirected movement. The user puts in a Long and lat coordinate from script (center of circle) and a distance in which its safe to walk (Radian of circle). This data is then used to micro change the Yaw of the games viewport to make the user walk in circles around the center of the circle.

[CyberVillain]

Hey everyone,

I was trying to get the motion track mouse stuff to work with my Android phone, but doesn't seem to work.
I opened the port 5555 in my firewall and I do get an response of some sort. I start the Freepie script, I got the Diagnostics.watch in place so I can see what it does, and all that gives me is android.googlePitch 0 once I start the UDP stream from the app. changing to android.Pitch yields the same results. The thing is, in the debug mode on the android app, only the magnetometer gives off a value, the accelerometer and gyro just give off 0 0 0. Is this an bug in my phone? in the app? my phone is the Huawei Ascend G300, and all the sensors work with all other apps.

thanks in advance,

rocco.

Hmm strange, as far as I know we use the only way possible to retrieve the raw data from the sensors. Instead send orientation does that show up in the debug window?

[rocco156]

thanks for the reply,

I made a mistake in my post, actually. The magnetometer does not give off a value in debug, same for accelerometer and gyro. Only Orientation is giving off jittering values, with the occasional NaN.

Turning off "Send raw data" whilst leaving "Send orientation" on freezes the values next to Orientation. If I keep both check boxes ticked the Orientation value actually changes, but any other combination freezes the values. In the app no other values are given other than the Orientation value, this leaves me to believe the app is unable to grab any data from the sensors, but if there is no other way of getting that data then I wouldn't know what could cause this problem.

Today I tried a different app called "Wireless IMU" and that app does show accelerometer and magnetometer values, but the gyroscope values are at 0 0 0. This app does seem to work as the diagnostics in Freepie gave off a value and my mouse started moving, although slowly but this might be just a tweaking issue.

[CyberVillain]

Do not have theme checked at the same time, that has strange behavior in current version. Will be fixed for next version.
Looks like your phone has problem with its sensors, since it does not work in the Wireless IMU app or our app. You cant use the Wireless app btw, they use differnet data formats so FreePIE does not understand what it gets.

[rocco156]

what do you mean by "theme checked"?

Too bad my phone may have problems with it's sensors. The FOV2GO app also does not recognize/use the sensors, it just goes straight forward and then bumps into a wall.

Maybe I'll look into making/modifying an app specifically for my Huawei g300, but first I'll test other Huawei g300, my dad and brother both have them too.
I was really hoping to get this to work as I have a 7 inch tablet too which I could use as screen but it runs android 1.5 and has no sensors, not even a camera.

Otherwise I'll just spend some money on making a real proper HMD, I have a 3D printer at hand so complex parts aren't a problem.

[CyberVillain]

what do you mean by "theme checked"?

Too bad my phone may have problems with it's sensors. The FOV2GO app also does not recognize/use the sensors, it just goes straight forward and then bumps into a wall.

Maybe I'll look into making/modifying an app specifically for my Huawei g300, but first I'll test other Huawei g300, my dad and brother both have them too.
I was really hoping to get this to work as I have a 7 inch tablet too which I could use as screen but it runs android 1.5 and has no sensors, not even a camera.

Otherwise I'll just spend some money on making a real proper HMD, I have a 3D printer at hand so complex parts aren't a problem.

Typo, make sure not to have both checked at the same time, a bug in current version that can cause strange behavior when they are both checked.

Maybe it does not have all the sensors? Older phones just had the Accelerometer

[rocco156]

My phone does have all the required sensors, I've tried many sensor apps and almost all sensor apps recognize all the sensors.
sensor readout says it has: 3-axis accelerometer, 3-axis magnetic field sensor, orientation sensor, proximity sensor, light sensor, rotation vector sensor 2.