|
|
Post by Frisbone on Oct 31, 2013 20:49:20 GMT -5
This post is for anyone daring enough to jump in and help solve some of the math related issues I'm currently wrestling with.
1. The sensitivity adjustments that are made for a certain game (settings ranging 1 through 15) alter an X-Y plot in such a way that when you look at PWM duty cycle (% ranging from -1.0 to +1.0) compared to resulting rotation rate of free-look movement - The plot looks like a hyperbola (y=1/x sort of thing). I need to determine a good formula that accurately represents this curve. Curve fitting program that I downloaded is telling me something different (1/(ax^2+bx+c)) - but when I plug their recommended coeficients back in, I don't get what I expect out. There is a posted thread with more details on this problem. What I need is someone to just take this over, give me the formula and perhaps explain what the heck I wrong
2. In order to reduce accelerometer drift (drift of the simulated point representing the gun) I want to alter the acceleration vector that is used as part of the double-integration so that it removes all components that don't fall on the plane that is perpendicular to the original position on the point of the virtual sphere. Imagine the point is tethered to the center of the sphere with a string - this represents a center point on the gun tethered to the center of a person which the gun rotates around. So when the gun center moves - it must essentially move along the surface of the sphere - so drift in other directions is not realistically possible, so I can at least eliminate that from the original acceleration vector so it isn't adding to the problem. So what I'm looking for here is someone that can present a series of mathematical steps to remove that acceleration component (I can of course provide more detail here - just providing a summary for now).
3. A statistical analysis of the sampling would be nice to have - perhaps an understanding of how fast we would need to sample to essentially reduce drift to a level that isn't very noticeable. Also perhaps an understanding of other related mathematically oddities.
|
|
|
|
Post by tbolling2 on Nov 5, 2013 20:50:10 GMT -5
Sorry, I got lost in parts of point 1. I'm not sure if the 'sensitivity' mentioned is like mouse sensitivity and relates the perceived acceleration of the device to the delta v of the aim point. Do you really mean -1.0 to +1.0 is a percentage? It represents -100% to +100%, right?
The general formula for shapes like y = 1/x ought to be something like:
y = k/(x-b) + c
b is the vertical asymptote. c is the horizontal asymptote. k is a scaling factor.
Is the goal to find a best fit curve to some data? That is very different from finding the one solution that goes through 3 given points.
Also, if the asymptotes are always the x and y axis, then you can set b and c to zero and adjust k until you minimize the sum of the squares of the distances from the points to the curve.
Changing subjects again, drift negation could be accomplished by assuming 'friction'. This way, there is always a retarding force (of -k*V for V as a vector) and micro forces (F) detected by the controller get cancelled automatically by static friction. Static friction for a motionless object can be modeled either by ignoring any force with magnitude below the threshold or by:
Net Force = F - F/abs(F) * min(abs(F), max_static) .
Regarding motion along the surface of a sphere, change of coordinate systems is your friend. Using spherical coordinates, you get to ignore forces in the r direction. Do you need to know where on the surface of the sphere the point is in order to calculate a field of view? So, does that point need to be translated back into rectangular?
However, if you want to stick to x,y,z; to remove the component of the force that is not on the surface of the sphere:
Dot that vector with a unit vector pointing toward the point take that times the vector pointing toward the point, then subtract the result from the original (based on a 30 year old recollection).
So, for a point on the sphere at r = {x, y, z}, the unit vector toward the point is
U = {x, y, z}/sqrt(x^2 + y^2 + z^). Of course, this all gets easier if you imagine doing this on a sphere of radius 1.
if the force vector is F = {X, Y, Z} then what you want is:
F - (F dot U) * U
One of the best classes I ever took in Physics was all about picking a convenient reference frame for your calculation. Does it mess everything else up if you just pretend that the aim point is at (1, 0, 0) at the moment you do the calculation? If you do that, the x component of the force is always perpendicular to the sphere and you can just ignore it.
If the rest of your 'universe' is in a fixed coordinate system for graphical engine purposes, you can still take the elements of your calculation and transform them momentarily into the convenient coordinates by a rotation transformation. Do the calculation, then reverse the rotation transformation.
Mathematically, I don't see that as any different from finding the component perpendicular to the sphere and negating it. But, I had to mention the trick of rotating your axis so that the point under consideration sits at (x, 0, 0) as it turned out to be so damned useful in many later problems.
|
|
|
|
Post by Frisbone on Nov 5, 2013 22:15:48 GMT -5
You are correct about -1.0 to +1.0 meaning percent. Think of it as percentage of voltage as it relates to a potentiometer where the center point is the middle of a range (like -1.0 = 0V, 0.0 = 2V, +1.0 = 4V - where 2V is the center). You'll see references in other points to duty cycle and this is related to a PWM signal that generates these voltages.
Yes - I am going for a curve fit - but I have much more than 3 points to go by - but the data points are not exactly high precision as they are recorded via observation - There is a post some here where I show the plotted points.
The Asymptotes are not the axes, they are offset - but in the end refer to the data. Good info, a bit over my head - but if you can get us to an equation - that would be great. Not convinced though it is y=k/(x-b) + c.
You've kind of lost me on the friction point. Are we talking about faking friction? The only forces that are detectable are due to the 3D acceleration components that we are sampling at a given rate (currently 100Hz). The "drift" I believe is occurring due to the problems inherent in sampling - that invariably we miss changes that accumulate over time - it can be improved with higher sampling, but never eliminated - and we have a practical limit on sampling rate that we are still trying to determine.
Regarding the coordinate system we do originate in a 3D system as all detectable forces (G-forces) are sampled in 3D space. So yes, we can convert to spherical but in the end all forces start out in the cartesian world.
As it currently stands I am using the 3D forces to freely move the point in the directions sensed using basic newtonian calculations. Then using the center of the coordinate system as a line reference, I compare the new line to the old line and determine Ascension & Declination angles. So from that point of view, spherical coordinates makes sense as I'm sure the process of determining ascension/declination would be natural.
Ideally what I'd like to do is essentially "tether" the moving point about the origin (keeping it on a surface of a sphere) and basically ignore any acceleration components that want to move it anywhere but along the surface. I think I understand your point about using friction to diminish drift over time - not sure how to practically implement this though - would need more explanations I'm sure.
I'll read the rest tomorrow - I'll post some additional details on the algorithm I'm using - the calculations are actually split in to steps and performed at different rates.
|
|
|
|
Post by Frisbone on Nov 6, 2013 6:43:02 GMT -5
Ok - so the practical approach towards sampling the hardware and outputting the results is to divide the process into two steps:
1. Sample accelerometer data at a high rate (say 100Hz) - and update the virtual position of the gun.
2. At a slower rate, say at 10Hz, sample the position change from the last noted change and determine the change in ascension/declination and convert this to a PWM output for moving the free-look of the controller.
Step 1 is fairly simple. We are essentially double integrating over time the acceleration and tracking resulting velocity to get position for each of the three axes (accel has Z as up, but I change that to Y to keep consistent with most 3D representations).
Step 2 is just some fairly simple matrix math to convert two unit vectors to an angle - we squash the unit vectors onto the two planes that we want for ascension/declination:
double cosTheta = mult(a, b) / (magnitude(a) * magnitude(b));
retVal = acos(cosTheta);
where a and be are the unit vectors for the old/new position projected onto the planes (XZ - ascension, XY - declination)
This is established software. Certainly any efficiency improvements that can be made will be so sampling rates could be increased (although one bottleneck right now is going to be the I2C hardware that won't be able to deliver the data any faster than 200Hz).
As far as being able to choose the radius - I'm not so sure that will be doable. I'm fairly confident at this time that we'll need to dynamically adjust the radius in order to get the movement sensitivity right (closer to the center you are, the more the same Delta D affects the resultant calculated angle - further out has the result of decreasing angle sensitivity). So at least in the beginning its going to be useful to manipulate these. I suppose an alternative is that once we know what we want we can manipulate the input accelerometer data with some fudge factor that results in the same thing - but allowing us to keep a radius of one. I suppose it depends on which math is more intensive - a decision for later.
Ok - so you ask does it matter if you assume the same reference frame for each calculation. And my answer I think is that it depends on which calculation. If its part of the first stage - determining position - then yes, it does matter because the second stage depends on 10 samples of stage one to accumulate to keep an accurate position. If its in the second stage, then I'd say no because in the end all we care about is a Delta angle change from the previous position - not tracking an absolute position.
You are close to having a good grasp on what were doing I can tell and I think once it sounds like all we need once we've settled all the questions - is some particular steps/calculations to replace in the two stages - where adjusting for drift would have to occur in stage one.
I hope I'm my descriptions are ok. I do tend to be overly verbose.
|
|
|
|
Post by Frisbone on Nov 8, 2013 6:52:35 GMT -5
Ok - for so anyone following this post - I uploaded a picture (pdf actually) that in a crude way describes visually what I'm trying to accomplish. The following things can be seen in the picture: 1. A sphere with radius vector OA 2. Two tangent planes - the right one also represents the 3D coordinate system in that it is home to the X/Y and its tangent (which is also an extension of the sphere's radius vector) is the Z axis. This merely shows relative orientation. The actual orientation of the center of the coordinate system is at point O. 3. Point A represents the virtual position of the accelerometer. 4. Line OA represents both a vector pointing to the accelerometer and a tether to the origin of the sphere. 5. There are two additional lines drawn crudely with paint  . One is pointing in the +X+Y+Z direction (label is Acceleration Force Vector), while the other is contained within the XY Plane (Labeled Projected to eliminate normal component acceleration). We will call this first vector F to represent the acceleration forces felt by the accelerometer in one sample period when at point A. 6. We'll call F' the second vector in the XY plane which is a projection. 7. The point B is the position the accelerometer ends up after being subjected to force F. Ok - so what I'm trying to demonstrate here is the theoretical virtual way we are choosing to describe how the center of the gun (where the accelerometer is located) is connected to a stationary center (the person, pivot point represented by the center of the sphere). Since a person isn't really moving - just rotating - the example seems sufficient (there obviously is some movement of the origin - but for now we are going to ignore it). So this issue of "drift" has been mentioned and for those of you not paying what this means is that the current approach is having us model only the current position of the AM and its velocity. When a new sample comes in it is integrated, accumulated with the current velocity, then integrated again - to get the new position. Drift is what I'm calling the tendency for lack of high precision sampling to result in loss of information causing the current velocity to be inaccurate as it relates to true velocity and this error accumulates over time causing the AM to drift into never never land. There are some things we can do to minimize if - my first suggestion was to use the fact that we are tethered to eliminate the force vector component that doesn't matter. The normal vector to the plane in question is this "doesn't matter" vector component of force F - and when you eliminate it, you get the vector that is projected on that normal plane to point A on the sphere. Current math isn't attempting to modify the force vector F - but I want to. So I'm looking for a series of simple steps to achieve this (the less intensive the math the better as this calculation will happen once per sample). So, this F' force results in the AM wanting to move in that direction - however, we know it to be tethered to point O. Current math is not taking this into account - its allowing the point to move in the direction of the tangent vector F' freely moving off the sphere. Now - we can either figure out a calculation that keeps it on the sphere from the beginning - or perhaps we can fudge it and re-project the new line OB and just get the sphere intersect point for the real point we want B (So there is a B' point on the XY plane that when projected onto the sphere, you get point B). Again - no math for this yet. Ok - so at last we come to the proposal in this post which says lets assume there is friction. Friction should eliminate drift since it is a constant apposing force that without acceleration will slow the velocity. This sounds good in principal - but I'm going to need some practical examples of how to implement it in the context of the problem parameters. (Not a big math guy here, so you need to keep it simple for me). So if F' is my force during this sample I'm assuming that I can say that there is a friction force in the opposite direction -F that is some fraction of the original force - working against it. This force it experiences is based primarily on its current velocity. Anyway, I need a step by step on how to do this. Perhaps I'll setup a practical scenario in a subsequent post and let the math geniuses tell me how to proceed. Attachments:
|
|
|
|
Post by Frisbone on Nov 8, 2013 7:02:51 GMT -5
Ok - for simplicity sake lets say that at point (0,0,-1.0) we have the AM and this represents point A.
Lets say that acceleration is sampled 4 times at regular 10ms intervals (100Hz)
So, measured in G's we have:
(-.12, .23, -.3) at time 0
(-.07, .01, -.22) at time 10ms
(-.02, .35, -.31) at time 20ms
(-.12, .23, -.29) at time 30ms
Ultimately I want to determine the points B1, B2, and B3 taking into account all that has been discussed where the B points are on the surface of the sphere with radius of 1.0.
Assume everything is in meters.
Since I assume the drag friction force is some factor of velocity, you can use your discretion of what that force should be (since its imaginary anyway).
|
|
|
|
Post by Frisbone on Nov 8, 2013 15:10:24 GMT -5
Ok - for any math dudes that plan to tackle this - I've outlined my general approach that you can critique and I have "*" stars next to the NEW steps. Please feel free to point out errors in the general approach, step sequence, or detailed implementation. What I'm looking for is someone to supply the actual math and an example based on the earlier data/info I provided.
=================================
Starting conditions:
Current Velocity - V
Current position (0.0, 0.0, -0.2)
Sample Frequency - 100Hz
EVENT - 100Hz sampling
- Retrieve accelerometer data, Ax,Ay,Az in G
- * Eliminate the sphere normal component of this vector (project onto the plane)
NOTE: Can I project it onto the plane's normal unit vector and then subtract his from the original AM vector? The vector projection would be: a1 = ((a DOT b) / (b DOT b)) * b. Where DOT is the vector dot product and * is just a scalar multiplcation against the vector.
- * Calculate drag force based off of the square of the velocity vector and some additional fudge factor
NOTE: Fudge factor will have to convert to acceleration by dividing by the imaginary mass of the AM - which is a constant. They key here is that we need to pick some constant to multiply by V squared that will result in a good balancing act for the applied acceleration forces felt - not sure yet how to determine the constant.
- * Subtract the acceleration forces
- Integrate over .01s (multiply)
- Accumulate velocity vector
- Integrate new velocity over .01s (multiply)
- Accumulate distance
- * Project line to new point through sphere, get intersection point with sphere - this is our new position
|
|
|
|
Post by Frisbone on Nov 9, 2013 8:56:51 GMT -5
Of the above steps I list I'm wondering if perhaps the drag/friction should be calculated AFTER the new velocity has been determined. I say this because what if the drag calculation results in a force that overshoots and overcompensates the slowing and then has it reverse course on any particular action? Perhaps it makes more sense to calculate the velocity due to actual forces, then apply the friction force such that if any particular axis reverses direction - it is instead zero'd to stop movement. Can easily see how calculation precision and lack of an accurate constant could lead to an overshoot. Grant - stop playing WoW. You have a math problem to solve.  Please ....  Anyone? Bueller, Bueller? |
|
lx
New Member
Posts: 1
|
Post by lx on Nov 13, 2013 8:16:58 GMT -5
Ok... I've been tied up the last few days getting a QA deploy around for a project I'm working on at work. I'll post back tonight with some of my thoughts on this...
|
|
|
|
Post by Frisbone on Nov 14, 2013 11:18:22 GMT -5
- Would it help if I begged? |
|
|
|
Post by Frisbone on Nov 17, 2013 19:57:10 GMT -5
Ok, starting to look like I might be on my own on this one - but I do appreciate your input Grant - hopefully I'll make some headway. My latest checked in code demonstrates my latest attempt to handle the following:
1. Eliminate that normal component of acceleration that would tend to take you away from the sphere's surface.
2. Add a drag force operating against the direction of current velocity.
3. After new position vector is calculated, alter the position so that it gets pulled back onto the sphere keeping it tethered.
The youtube video here shows how I am visualizing this with the current imaginary sphere (wire-frame) allows the AM position to track on its surface. I rotate the gun in circles both clockwise and counter clockwise and generally speaking it can be seen to track. However, , one time linear movement is not correctly tracked - it seems to bounce/snap back to its original location. Slow movements don't seem to be detected. I think coming back I need to continue to reduce the size of the tracking sphere so that movements result in more drastic angle changes.
|
|
|
|
Post by Frisbone on Nov 26, 2013 6:28:52 GMT -5
I've tried a bunch of slight adjustments here and there but haven't made any head-way. Hoping the t-giving break will give me some ideas. Going to be away from it until Saturday.
The behavior is so weird. Circles tracked fairly well - straight line movement barely detected - only when quick, and when it is detected it "snaps" back. I've wanted to avoid a control test due to the amount of time required to set it up but I'm running out of ideas. The control test being:
1. Remove AM and attach/orient it to a rigid & square block with long wires attached.
2. Create guides forcing movement along a single axis between two fixed-distance points
3. Level the surface (align gravity component along a single axis)
Test - attempt to move the block from one end to the other at a constant rate - try different rates of movement.
Code - Attempt to plot simple X/Y/Z points based on simple Newtonian calculations and tracking velocity.
Evaluate - Determine if this simple test can be made to work (track) at realistic movement speeds and at what sampling rates. If we have problem with this simple test then it might explain some things - but if we can show that it can roughly track position - perhaps it may reveal some issues.
BTW - all my code is checked in for anyone who wants to take a peek.
|
|
. One is pointing in the +X+Y+Z direction (label is Acceleration Force Vector), while the other is contained within the XY Plane (Labeled Projected to eliminate normal component acceleration). We will call this first vector F to represent the acceleration forces felt by the accelerometer in one sample period when at point A.
