|
Post by Frisbone on Sept 20, 2013 14:41:10 GMT -5
I threw that formula into my spreadsheet on the 12.5Hz raw data on the Y axis and I saw a couple of things:
1) The higher the factor, the less sampling required to stabilize your readings
2) The amplitude of the first sample that you care about will be a suppressed version of the original - spread out thereafter for multiple samples (the number of which depend on the factor - less for a smaller factor).
3) The higher the factor the more is squashes the amplitude of the output data. So if you are really falling at a rate of +2g and you want the output to read 1g (negate gravity) you will only see this if you sum it up over multiple samples
So this brings up some interesting questions about the built-in HPF of this chip. Does it internally sample at hits highest rate (800Hz) at the start so it can normalize its readings first? I certainly don't see any stabilization in the data - it seems like almost immediately it has stabilized as soon as you begin running the program.
It also means that the raw acceleration you would like to have seen in a zero-g world, only exists when accumulating several samples. In real world terms it is decreasing response time.
Finally, changes in orientation will have an affect on acceleration results as the shifting affect of gravity won't be filtered out immediately. Rotating the gun will have a similar affect of moving it quickly for a short period. Will be less prominent the slower you rotate it (Pitch, Yaw, or Roll).
|
|
|
Post by Frisbone on Oct 25, 2013 6:21:25 GMT -5
To calculate the at-rest bias I would think that what you could do is hold the gun in a steady upright position for 10-20 seconds and basically sum the converted G numbers. The longer you hold it, the more accurate the bias number you get. Then - whenever you get a value from the AM - you always subtract out the bias before you use it.
|
|
|
Post by Frisbone on Jan 15, 2014 6:31:23 GMT -5
Over the past two nights I've been working on a controlled test setup and I've got it all physically setup now. I've used a ribbon cable here that I got quite some time ago that has come in very useful for all my PI wiring: www.adafruit.com/products/824I took 10 total wires and cut the female ends off of one set, and the mail off of the other 5. The 4 wires I had soldered into the AM were desoldered and then clamped into 4 different terminal blocks (3V/GND - SDA/SCL). On the other cut group I wired them directly into my AM. This gives me an easy to disconnect AM with wiring I can re-use when I put it back in my gun. It also gave me almost 2' of length stretched away from the gun for movement. I placed the gun next to my 3D printer and with double-sided table aligned the Y axis of the AM breakout board with the Y axis edge of my 3D printer. Got the basic controls of the printer back up and running and am able to have the Y axis move 100mm upon command. I switched to setting parameters in the software to automatically record on launch and terminate after 3 seconds, 300 samples at 100Hz. I did run one test to collect data - but it indicates I have a bug somewhere because it ran 30 seconds for 300 samples - and there was no non-zero sample data. Obviously I've got a bug somewhere - or pilot error. Gonna have to do some debugging. But the plan is to run this start/stop single axes test a bunch of times - say maybe 20 times. Then massage the raw data later - see how consistent the results are. If the sampling is a problem - the results should indicate that each run yields substantially different results for approximating movement. Really we are looking for the moments of start/stop and how much the acceleration measurements vary. For sampling to be an issue (where you miss data) expect it to vary a lot. Decreasing sampling should make it worse, increasing it should improve it. If it varies without being influenced by sampling rate - then maybe I have a malfunctioning board - or the errors with mid-range G changes are large, perhaps look at another board. Of course the last possibility is that in this test the data looks could - and that could lead me to identifying a software bug that is introducing error. Some things to check against the data: - Sum of all acceleration changes should be zero since it starts at rest, and ends at rest
- With known distance and known approximate time (observation) can calculate average velocity and then differentiate to get acceleration at the start point and stop point.
I do believe I might be at a disadvantage with my test setup though. These NEMA 17 motors have high acceleration (1.4E+06 1/16 steps/secĀ² - whatever that means, but people say it allows it to be virtually ignored in the slicing approach used when printing) and might represent a much more extreme example than what a human is capable of. But on the plus side, if I can get that to track - I'll have no problem with human movement.
|
|
|
Post by Frisbone on Jan 16, 2014 11:41:23 GMT -5
I completed my test setup last night and found the bugs causing my sampling issue (was related to my last changes creating a simulated ISR separating Am sampling frequency from PWM output frequency). The results are very confusing. The sampling rate was 100Hz. Of the three axes the first reported (X I think) reported the most variation - attached the pic. However all three showed non-trivial and similar changes in acceleration during the 790ms of movement over the 100mm distance. I thought I was lining the Y axis up with the axis of movement on my printer. I know the code flips Y and Z so I was prepared to see it on Z as well. Wasn't expecting X to have the most fluctuation - still possible I oriented it wrong and will have to look again. The other strange thing is that I was surprised to see so much fluctuation during transit. Constant motion wouldn't be as stable as a stationary situation, but I wasn't expecting that either. In an ideal world you would expect to see an initial positive or negative acceleration pulse (like a square wave) and then zero acceleration for most of the period, then another pulse in the opposite direction at the end of the period (representing deceleration). Although the transition doesn't seem to have matching patterns the beginning and end of the cycle do roughly correlate between the 9 samples i took. It spikes low, and then immediately spikes high in the beginning - then spikes high then low at the end. This seems odd to me - almost like its "bouncing" or "snapping back". Could this be a side-effect of how the accelerometer works? I've seen references to people talk about their design and describe them as springs on 3 axes. Attachments:
|
|
|
Post by lintball on Jan 16, 2014 13:15:29 GMT -5
That seems very odd that you are seeing accel on all axes. Is it mounted so that the other axes are exactly perpendicular to the rotating one? Is it possible the raw data isn't being read correctly? Do you have the filters enabled on the accel?
|
|
|
Post by Frisbone on Jan 16, 2014 13:41:48 GMT -5
The movement is linear along a single axis. I'm sure its not perfectly aligned - but certainly enough so that you should see a significant difference between the 3 axes. Tonight I'll post all of the graphs (each axis) and post the raw data.
I still need to go through the raw data in more detail and verify that it is sampled regularly. But the values look as "correct" as I've ever seen them.
And yes, the High Pass filter was enabled. Certainly I'll run it again with it disabled as well as run the test at varying sampling rates.
I was contemplating a couple of possible issues though:
- The abruptness of the initial movement and final movement might be enough to "shake" the entire printer assembly enough to cause significant accel on all 3 axes. Weighting it down might not be a bad idea to remove this possibility - as well as make my bed rigid (currently its on springs! doh)
- Need to investigate Am design a bit more to ensure that this "spring back" effect isn't normal.
|
|
|
Post by lintball on Jan 16, 2014 14:05:39 GMT -5
Running the motor slower would also help the shakes
|
|
|
Post by Frisbone on Jan 17, 2014 15:57:55 GMT -5
Ok, so a little less confusing now. Seems I just rotated it differently than I thought when I put it on my printer bed. The direction of movement is lined up with the X axis. So one less mystery.
My biggest concern right now though is that when I sum the acceleration data over the entire period you would theoretically get a zero value for objects that begin and end at rest during the period. I don't .
In my measurements I see a .001 to .002 when not moving and it fluctuates in either direction. I know it can't be perfect but you'd think that errors from sampling (missing data) would average out over time and that they wouldn't contribute to a sum problem. What is left I suppose would be an inherent bias that even the high pass filter isn't dealing with. What I don't know yet is how big this number gets over time.
The X axis can change anywhere from -.2 to +.2 during active movement. With 300 samples of data taken (79 of which are active movement) this will add up so my sum on the X axis of .3948 isn't incredibly alarming - obviously there is quite a bit of offsetting going on.
Ultimately if there is a HPF bias present at all times (whether constant or growing constantly over time) - we'll need to remove it before using the data to calculate velocity.
When summing the data up in sections I get (for one execution sample):
- Pre-Movement (26 samples): 0.0058 - 1/2 way through initial movement (37 samples): 0.227 - Finishing movement (37 samples): 0.1355 - Post-Movement (199 samples): 0.0266
The disturbing part is that I would have expected polar results on the two ends of movement - firstly, being signed opposites of each other. Secondly, would have expected them to be roughly the same magnitude. Don't see either.
So I guess my next step is to try to eliminate possible jolting effects.
Regarding you suggestion of slowing it down - I can't really do that without rebuilding the firmware on the printer board - something I haven't done for well over a year and I'd have to research how to do it. Think I'll do that as a last check.
|
|
|
Post by Frisbone on Jan 20, 2014 8:21:59 GMT -5
Have MLK off today. This weekend I did a few things to my test assembly:
1) Took it off the table and put it on the floor 2) Weighted the top down with two 10lb weights 3) Mounted the AM on the bottom plate of the moveable bed that isn't affected by spring action.
I re-ran the test twice, then I ran it again with the filter turned off. Can't really say it looks much different with the filter on - perhaps the tail end looks a little dampened - but there is still a lot of movement during transition and the beginning still "bounces" about as significantly without my changes.
With the HPF filter off it looks a little more of a low to high trend - but still with a lot of variety. I'll email you the file so you can look.
|
|
|
Post by Frisbone on Jan 20, 2014 8:30:10 GMT -5
So I ran into this paper the other day: www.cem.brighton.ac.uk/research/cig/papers/Displacement%20from%20Accelerometer.pdfInteresting in that their paper is almost exactly about the simple linear test I've been running and their stated goals are similar for similar purposes. I've also noticed from it at least one small error in my own conversion calculations - but I'm also left questioning their work a bit because I got lost in their math - need to look at it more. They seem to imply that they ran a similar test as I did but at 60 Hz. However, their data looks so smooth that it appears almost staged. I wonder if its actually real captured data - or if they were assuming the data would look like that and then focused on the math. So the bad is that I'm left wondering about efficacy. But the good is that it is exactly what we are doing and they have a formula for displacement calculation that isn't based on tracking velocity - its based on accumulating acceleration. But you would think that you'd want to see acceleration sum to zero for this to be useful. I'm really beginning to wonder if I'm doing something wrong in a very basic way. I'm now anxious to see you collect your first bit of data for comparison.
|
|
|
Post by iepblakey on Jan 21, 2014 9:29:45 GMT -5
Several years ago I performed the above. The data is genuine. The black box was wired up to a PC analog games controller, providing access to the output data. In an attempt to try and understand the output data I performed a series of simple experiments. These experiments consisted of resting the black box on my desk. Then, taking hold of the black box while resting on the desk, I made a series of small 'measured' movements, along a single axis, across my desk. These movements spanned approximately 50 cm's in one direction, exerting the effort not too dissimilar to that of moving a hand held mouse. Movement was sampled at 60Hz and, when plotted, produced a relatively smooth oscillating graph. The oscillation visualized, roughly, the acceleration and deceleration of the black box; from the start to the finish of the hand movement. From the acceleration data were able to calculate the approximate distance covered, using a method of double integration. If I remember correctly, from each data set were able to calculate a distance traveled within about 10% of the actual distance traveled during the movement. I should add that we gathered the data from the analog driver output and not directly from the accelerometer itself. As we increased the distance of movement the less accurate the calculations became. I would conclude that an accelerometer, on its own, is not a very accurate mems for measuring distance traveled, as one might expect. However, over short precise movements it is reasonably effective. I should also point out that the silicon substrate in which the sensing is derived is free to move in all directions and, when minimum force is applied will want to come to rest, or, if its calibrated force is exceeded will run out of 'head room'. As I was keen to generate accurate positional data I decided upon using wiimotes and an infra red light source. To this end, I placed two wiimotes on my desk and at 90 degrees to one another, with the infra-red ends pointing towards one another. The wiimotes communicated their output to my PC via a open source driver. Using a torch, I shinned the bulb in the region of the desk that the wiimotes covered and could accurately calculate the position of the light source in a 3D space. Regards, Andrew.
|
|
|
Post by Frisbone on Jan 21, 2014 15:09:18 GMT -5
Sorry to have implied that the data may not be genuine - it was more of a swipe at my own data collection efforts than yours. You said that you collected the analog output and not the readings from the accelerometer. Would you be able to tell use what equipment you used in your test? Perhaps the analog device and how it was being read - and why you chose not to read the actual output of the accelerometer. Perhaps I misunderstood your point. I'm assuming you used a device that generated both digital and analog output?
|
|
|
Post by Frisbone on Jan 24, 2014 7:40:54 GMT -5
I've seen several references now reinforcing this idea that high frequency changes in acceleration may result in oscillation: [url=http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&ved=0CFQQFjAE&url=http%3A%2F%2Fmechanical.poly.edu%2Ffaculty%2Fslee%2FME3511%2FExp6.pdf&ei=TE3iUvCfJ7DnsATFwYHYDA&usg=AFQjCNH2oW5uERyc0kmMcqLdNqcJSnOP9w&sig2=uANPhXwXhv9bRgMRRGv4Qg&bvm=bv.59930103,d.cWc ]Experiment - mechanical.poly.edu[/url] Kionix drop-force modelingThe first reference was related to uses with beam vibration so I dismissed the graphs that looked similar to mine - but it reinforced the idea that the mechanism inside our AM chip is piezoelectric capacitive. The second one has a graph that looks like what you would expect with a free-fall impact - except for post-impact. The post impact picture looks very similar to the tail end of my test. I'm starting to thing that there is a natural oscillation occurring during abrupt starts/stops that perhaps my high-frequency sampling is detecting. These piezoelectric capacitive transducers are essentially acting like a spring with dampening. If this is all true then the question becomes - how do we adjust for this since it is a symptom of the measurement technique - and not a measurement of true acceleration? Ideally we would like to be able to recognize the oscillation and convert it into a DC offset that can be used with velocity and position tracking.
|
|
|
Post by Frisbone on Jan 30, 2014 12:55:09 GMT -5
I finished my analysis of the MMA8452Q and the ADXL345 and have attached the differences for the features we actually use. Will work on creating a more general AM driver base class that allows a child class to override certain settings for initialization and access. Will make it so we access the accelerometer through the parent class and you can instantiate based on a parameters setting either device. The ADXL doesn't seem to have a high pass filter capability so I'll have to limit my comparisons to HPF off - or create a software-based HPF that both can use. THe ADXL does have a FIFO that the MMA8452Q doesn't have. This could be useful for a host processor that doesn't have a good interrupt response time and can't respond well hat high rates - but over time could keep up (like the PI using linux) - expect it to be fairly useless in an Arduino world. However, it seems like a perfect mechanism to implement a filter - surprised not to find one. Also was thinking that a running filter like that could allow you (if it had been designed this way) to sample the hardware at a higher frequency that you request for it - when you request the sample, it sums up the samples and returns the sum - so you don't actually miss any higher frequency sampled data. Would allow you to effectively sample at 800hz while responding at 100Hz (requiring you to queue 8 samples, but FIFO is 32 - so it could work up to 32X). Don't see any references to stuff like this so I'm not sure I understand what the deal is with the FIFO. Gonna try to get the ADXL code finished this weekend. Attachments:
|
|
|
Post by Frisbone on Feb 1, 2014 8:29:12 GMT -5
It seems my analysis was slightly off with the X/Y/Z differences between the MMA and ADXL. They do have conflicting info in the specs though.
MMA page 3, ADXL page 22 show XYZ with arrows with respect to PIN 1. The axes show that X and Y are swapped and in the negative direction from each other.
But then you look at pages 4 and 22 respectively where it shows physical orientation with respect to pin 1 and the resulting G answers and those examples show that the axes are not reverse, but instead if you rotated the ADXL 90 deg clockwise from the MMA position - you get the same answers. I suppose I should trust this more than the single axes picture - plus it only makes sense that they would copy off each other so programmers wouldn't have to rewrite such fundamental code.
If you get a chance to look at it - let me know your opinion.
|
|