Post by Frisbone on Sept 30, 2013 5:36:26 GMT -5
I don't know if you noticed this post:
I think I need to commit to a slight redesign and I'm seeking comment. It will require one additional input - perhaps you can tell me if we have it after your latest change.
I am now convinced that I need to separate out the process of converting AM input to a virtual position and the process of converting changes in position to an angular directional velocity. The main reason is that the CPU and I2C bandwidth usage for handling the conversion to angular velocity is huge in comparison - and does not contribute to accuracy of following movement of the gun, yet it is obviously a limiting factor in the achieving the highest possible sampling rate.
Knowing that there is a breakdown point where very small changes in angles will result in voltage calculations that will essentially not move the joystick - having the frequency of the two functions be 1 for 1 is not only not ideal, it may simply not work at all. I know that there is a "grace" range around the 1/2 max voltage range (.8V) - which represents "centered" where a little above or below that voltage will keep it centered without movement. Once I create a voltage to turn rate mapping - will have a much better profile of this.
Here is my design change idea. I want to make the AM reading interrupt driven (single interrupt, requiring one addition input pin) and for each interrupt it would simply calculate the new virtual 3D position (not too math heavy - a few multiplies). Then crank the sample rate up as high as 400Hz. Next I'll change the polling in the main program to represent the polling of the current position (stored by the ISR) and would then calculate angular velocity to achieve that new position within that sample period. The frequency/period of the polling would be much slower, perhaps 20Hz or slower depending on test results. This is the process that is more intensive anyway.
Lacking an extra input what I could do is pick frequencies that are multiples of each other. So if the sampling frequency for the AM is 400Hz, then every 20 samples i could kick off the angular conversion and PWM output logic. I don't like this option because it will cause a position reading hiccup every 20 samples - remember, this is not a threaded application so our options are limited.
Let me know your thoughts.
But I went ahead and started this. Currently working on an adapter class that provides a conversion from units of radians per time slice to -1.0:+1.0 (separate methods for ascension/declination.
Inputs at startup will be formula's that are tied to each individual game we can control that describe the mapping between rate of change and voltage (or percent in our case). When the mode is changed (or we startup) we regenerate a look-up table from the function. We'll need some mechanism for modifying sensitivity for games that have that - but a method for changing that will exist as well that alter the function - also repopulating the table (in our case, the formula is y = 1/(Ax+B)
I am now convinced that I need to separate out the process of converting AM input to a virtual position and the process of converting changes in position to an angular directional velocity. The main reason is that the CPU and I2C bandwidth usage for handling the conversion to angular velocity is huge in comparison - and does not contribute to accuracy of following movement of the gun, yet it is obviously a limiting factor in the achieving the highest possible sampling rate.
Knowing that there is a breakdown point where very small changes in angles will result in voltage calculations that will essentially not move the joystick - having the frequency of the two functions be 1 for 1 is not only not ideal, it may simply not work at all. I know that there is a "grace" range around the 1/2 max voltage range (.8V) - which represents "centered" where a little above or below that voltage will keep it centered without movement. Once I create a voltage to turn rate mapping - will have a much better profile of this.
Here is my design change idea. I want to make the AM reading interrupt driven (single interrupt, requiring one addition input pin) and for each interrupt it would simply calculate the new virtual 3D position (not too math heavy - a few multiplies). Then crank the sample rate up as high as 400Hz. Next I'll change the polling in the main program to represent the polling of the current position (stored by the ISR) and would then calculate angular velocity to achieve that new position within that sample period. The frequency/period of the polling would be much slower, perhaps 20Hz or slower depending on test results. This is the process that is more intensive anyway.
Lacking an extra input what I could do is pick frequencies that are multiples of each other. So if the sampling frequency for the AM is 400Hz, then every 20 samples i could kick off the angular conversion and PWM output logic. I don't like this option because it will cause a position reading hiccup every 20 samples - remember, this is not a threaded application so our options are limited.
Let me know your thoughts.
But I went ahead and started this. Currently working on an adapter class that provides a conversion from units of radians per time slice to -1.0:+1.0 (separate methods for ascension/declination.
Inputs at startup will be formula's that are tied to each individual game we can control that describe the mapping between rate of change and voltage (or percent in our case). When the mode is changed (or we startup) we regenerate a look-up table from the function. We'll need some mechanism for modifying sensitivity for games that have that - but a method for changing that will exist as well that alter the function - also repopulating the table (in our case, the formula is y = 1/(Ax+B)