Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 106 Roadmap
- 358 Game & application design
- 315 Plugins
- 70 User experience
- 74 Marketplace
- 290 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 660 Bugs and issues
- 195 Introduce yourself
- 236 Announcements
- 105 Forum talk
- 403 Relax cafe
In this Discussion
Relative device rotation
Hello,
This is what I'm experimenting with for a gameplay of one of my apps, where the character moves based on device rotation (the same as Labyrinth game). Problem is, that I don't want to force a player to hold the device parallel to the floor while playing (that's just sucks).
So my idea was to get current rotation of device and only use the relative movement. So take the position in which user starts the app and start from that (cause that would be just awesome).
Unfortunately as using accelerometer, acceleration that you get is basically due to gravity (its not that you have to move your device all the time, you simply lean it a bit and let the ball roll, let the gravity do its job) and if I want to use relative position, I can't count on gravity anymore (at least I can't find the way).
Next idea was to try gyroscope. I've implemented relative movement with gyroscope and it worked great. But over the time it begin to behave weird. I've tried to simply put my phone on the table and saw that gyroscope accumulates too much error (at least on my 4gen Ipod), that even low pass filter can't help it. (I've also tried high pass, just for testing and even it accumulated huge error over the time).
So if anyone can point me into right direction to implement relative accelerometer movement or proper filter to gyroscope. Please, I'm all ears
This is what I'm experimenting with for a gameplay of one of my apps, where the character moves based on device rotation (the same as Labyrinth game). Problem is, that I don't want to force a player to hold the device parallel to the floor while playing (that's just sucks).
So my idea was to get current rotation of device and only use the relative movement. So take the position in which user starts the app and start from that (cause that would be just awesome).
Unfortunately as using accelerometer, acceleration that you get is basically due to gravity (its not that you have to move your device all the time, you simply lean it a bit and let the ball roll, let the gravity do its job) and if I want to use relative position, I can't count on gravity anymore (at least I can't find the way).
Next idea was to try gyroscope. I've implemented relative movement with gyroscope and it worked great. But over the time it begin to behave weird. I've tried to simply put my phone on the table and saw that gyroscope accumulates too much error (at least on my 4gen Ipod), that even low pass filter can't help it. (I've also tried high pass, just for testing and even it accumulated huge error over the time).
So if anyone can point me into right direction to implement relative accelerometer movement or proper filter to gyroscope. Please, I'm all ears
Likes: r033rt
+1 -1 (+1 / -0 )Share on Facebook
Comments
But the system equation seems too complex for now, probably need to get some sleep.
But still if anyone knows any elegant solution, or any idea, please share
http://forum.thegamecreators.com/?m=forum_view&t=194503&b=41
- Accelerometer has no accumulated error but has the gravity component problem
I've heart about a technique (called sensor fusion) that uses accelerometer to calibrate the gyro's rotation values. But unfortunately I don't know any technical details. Maybe searching for "sensor fusion"+accelerometer+gyroscope gives some results.
http://www.slideshare.net/paller/better-motion-control-using-accelerometergyroscope-sensor-fusion
It actually could help a lot. Still thinking that it can be solved using accelerometer, as it's simply a mathematical problem. But the sensor fusion gives me even more ideas of interesting AR apps