|
|
Post by Frisbone on Sept 5, 2013 19:17:23 GMT -5
I ran a series of tests moving the gun around in a variety of ways so the algorithms could be consistently repeated for debugging purposes and so we could anticipate expected results. The title of each file indicates the type of motion. The start/stop times in the log files (microseconds) can be used to identify elapsed time. The raw Delta %G is presented and can be filtered out- then we write some read from file code to unit test it. Attachments:
|
|
|
|
Post by Frisbone on Sept 6, 2013 7:23:33 GMT -5
I analyzed the data from sample file that had as its movement a 360 horizontal rotation that was regular but quick (Although strangely the test says 3 seconds, would have thought it was faster than that).
The data was very odd. Where you would expect only two axes to show noticeable shifts, all three did. Where you would expect one axis to have an overwhelming influence - there was no clear winner. Where you would expect to see a trend in one direction - it all axes shifted directions.
Oddly when I counted the number of times an axis indicated movement in the positive direction - they all had similar numbers X-12 out of 27 samples, Y-14 out of 27 samples, Z-11 out of 27. That makes no sense to me.
So I'm trying to work out expectations and the physics of this example in my head. We have an object spinning in a circle from a center point. The velocity is relatively constant - which means there is no acceleration change for most of the test.
As a spinning object I know that it will experience a force proportional to the velocity along its longitudinal axis (of the gun) and directed away - (which is a concept of artificial gravity), so it means that the object is feeling the force, but since its not moving relative to that axis - then it probably isn't accelerating along it. And of course not much of anything significant should be happening along the Y axis (Z to the accelerometer).
Interestingly I thing I just convinced myself that I probably should have seen any useful data in this test except for the beginning of the rotation and the end. I'm also realizing why I originally wanted the sample frequency to be really high - and slapping myself virtually for even running this test without having changed how data is being recorded and adjusting the frequency to something faster than 10Hz (polling at 100ms).
Furthermore I'm starting to realize that I likely have a serious bug in my design. When you read the AM I believe you are looking at an instantaneous snapshot of acceleration in all 3 axes. So if the points of acceleration (in my example) are at the beginning of the rotation, and at the end of the rotation (deceleration) then the sample rate needs to be fast enough to catch the detail of that change (which I already covered). BUT - I don't think my 3D to 2D mapping algorithm design is based off of velocity, and not acceleration - and I would have to accumulate velocity from the acceleration changes in order to get an accurate picture of it.
So basically I:
1. Take a sample
2. Get a delta from the last sample
3. Convert that to a 2D equiv
4. Tell the joystick to move in that direction during that sample
So - if in the sample there is no acceleration, the joystick is told to do nothing. But this is not reality - the joystick needs to stay in that relative position until its told otherwise. The changes in joystick position should be looked at (I think) as changes in acceleration (my delta alpha). I need to re-think these elements of the design before I take more samples and increase the sample rate.
I do realize that if I basically tell the joystick to go in a particular direction without re-directing it - it will get "stuck". Putting it in a steady centered state is pretty easy when you aren't seeing any movement in the delta alpha - but if are moving it then all these instructions are being accumulated and you are simply hoping they balance out to be "centered" - accumulation error could be a big problem. May have to be very concerned about sampling rate (even more than I thought) and precision of calculations.
|
|
|
|
Post by lintball on Sept 8, 2013 21:26:04 GMT -5
I tried to download the file and it just displayed gibberish, instead of letting me save the zip.
Is it possible that the data is just not correct. Maybe something happened when the gun was closed up.
I see your point on the translating the physical movement to the joystick. The joystick is used to set the rotation velocity of POV. So if the joystick is held at 50% right it will hold that velocity. It sounds like that is the same way the gun is set to work now too. Move it till it accelerates to the desired velocity(which is then translated to joystick position). Then to stop move it in the opposite direction until it is more or less where it started. By tracking velocity and position, probably could define an area that is a dead zone and that velocity/position resets to zero. Other option might a button that while pressed resets velocity/joystick to zero.
But is that the way we want it to work, or do we want to only move the POV while the gun is in motion? Which is harder since the player is naturally going to want to move back to a comfortable position with the gun point straight at the TV. Though a button to hold while you don't want to movement to be translated to joystick movement could solve that. Not sure how awkward that would be.
|
|
|
|
Post by Frisbone on Sept 9, 2013 6:52:58 GMT -5
When I gave it more thought the data began to make more sense.
The reality is that I don't think that your average engineer can visually interpret acceleration data in the context of matching it up with example data.
In my test cases I was always trying to move things in a constant motion. But if I was successful in my test then there would only be data at the beginning, and then data at the end (sudden accel turning to zero accel turning to sudden decel). Since I can't do to perfectly then it would show little up and down deviations along the way. All told if I start motion and then stop it as part of my complete test then the acceleration should average out over the period to be zero.
Ill upload the data to another location. Did you try a "save target as?"
Since all acceleration should balance, translating to velocity should be a pretty natural thing so long as the precision.and sampling is high enough.
|
|
|
|
Post by lintball on Sept 9, 2013 8:01:09 GMT -5
It worked this time on a PC, might of just been safari doing something funny with it.
|
|
|
|
Post by Frisbone on Sept 9, 2013 14:33:57 GMT -5
The button idea I only was reserving to adjust occasionally due to calibration issues.
I'm going to work on some changes where I am specifically tracking velocity in 3D and adjusting it as acceleration changes are detected. From there we get position after each sample. Should be as simple as integrating acceleration.
|
|
