Possible to measure displacement at one point with µDIC?

[e-dub]

I am a bit new to DIC and have a question if it is possible to measure the displacement at a single point on a structure. The video below show the compliant mechanism that I would like to test. I want to measure the horizontal displacement at the end of the middle section. Is this possible with µDIC (of course with a better videoJ)?

[PolymerGuy]

Yes, this is possible. However, you need to apply some kind of speckle pattern to the surface of the component. In our lab, we use an airbrush to apply the speckle. This pattern is used by the correlation routine to "track points" between frames. A speckle made by "dotting" with a pen might very well be sufficient...

If the in-plane movement is of interest, make sure to have the camera positioned perpendicular to the plane.

[e-dub]

Thanks for the tips! I found your example virtual_experiment_u.py from which I could figure out most issues. I have a further question though: Displacement is given in pixels. What is the best practice getting this into millimeters?

[PolymerGuy]

Well, I am usually just interested in the strain fields, so I have not done a lot of displacement measurements like you are trying to do now, but I would measure a known distance (the length of the specimen for instance) and the same length in pixels on the image. What kind of accuracy are you aiming for?

[e-dub]

Thanks for your quick answer. Yes, strains are definitely easier in this regard as they are without units (and probably generally more useful). In my case, I am expecting displacements are in the order of approx 5 mm. Therefore, precision of about a tenth would be good, hundredth would be great.

[PolymerGuy]

Then, it all depends on the resolution of the camera and the speckle pattern. 1/10 of a pixel could be a usable guess on the precision, but varies depending on a lot of factors

[e-dub]

Thanks for the tips! So far so good!

I have a couple questions:

1. I extracted 50 images from the video of the test, but only 6 "references" are being used. Am I doing something wrong here?

   muDIC.solver.reference:INFO:Splitting in 1 blocks:
   muDIC.solver.reference:INFO:Pixel coordinates found in 4 iterations
   muDIC.solver.correlate:INFO:Processing frame nr: 0
   muDIC.solver.correlate:INFO:Frame converged in 0 iterations
   muDIC.solver.correlate:INFO:Processing frame nr: 1
   muDIC.solver.correlate:INFO:Frame converged in 13 iterations
   muDIC.solver.correlate:INFO:Processing frame nr: 2
   muDIC.solver.correlate:INFO:Frame converged in 13 iterations
   muDIC.solver.correlate:INFO:Processing frame nr: 3
   muDIC.solver.correlate:INFO:Frame converged in 11 iterations
   muDIC.solver.correlate:INFO:Processing frame nr: 4
   muDIC.solver.correlate:INFO:Frame converged in 11 iterations
   muDIC.solver.correlate:INFO:Processing frame nr: 5
   muDIC.solver.correlate:INFO:Frame converged in 15 iterations
   muDIC.solver.correlate:INFO:Processing frame nr: 6
   muDIC.solver.correlate:INFO:Updating reference at 6
   muDIC.solver.reference:INFO:Splitting in 1 blocks:
   muDIC.solver.reference:INFO:Pixel coordinates found in 4 iterations

2. Question about the array that is returned by post.viz.Fields.disp(). Can I confirm that the meaning of the five dimensional array for displacement is as follows: 1, disp in x or y, x position, y position, number of images

[PolymerGuy]

The first frame is used as a reference image and this image is updated whenever the software is told to or wants to in order to speed up the convergence of the solver. So by looking on the log above, it seems like a reference update was triggered by "slow" convergence at frame 6. Could you share an example image?

The ordering is correct, but the position is in element coordinates not in image coordinates. The displacements are in image coordinates.

[e-dub]

Here is the 6th frame:

Area of interest:

[PolymerGuy]

Nice! The surface of the specimen does not look like a typical speckle but contains a lot of texture, so the correlation between frames might be possible. I would move the camera closer or use a higher magnification lens, but it's hopefully not necessary.... In order to make life easier for the correlation routine, you can use a single large linear element. You do this by passing deg_e=1 and deg_n=1 to the mesher and create a mesh with 2x2 nodes.

Does the analysis give the results you want?

[e-dub]

We are still working on getting a good speckle, that was a first try.

With respect to the video: I can get a bit closer, but I want to keep the camera at this distance to make sure I can measure the displacement on the left (top jaw of the tensile machine) to correlate the results with the measured force-displacement at the jaw.

With your advice it advances to 13 frames of 50 frames and stops. Unfortunately the numerical results are not even correct with respect to sign. It shows that both x- and y-displacements being negative, which the actual displacement is to the left and upward.

muDIC.mesh.meshUtilities:INFO:Element contains 73.9 X 136.5 pixels and is divided in 2 X 2 
muDIC.solver.reference:INFO:Splitting in 1 blocks:
muDIC.solver.reference:INFO:Pixel coordinates found in 5 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 0
muDIC.solver.correlate:INFO:Frame converged in 0 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 1
muDIC.solver.correlate:INFO:Frame converged in 12 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 2
muDIC.solver.correlate:INFO:Frame converged in 12 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 3
muDIC.solver.correlate:INFO:Frame converged in 10 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 4
muDIC.solver.correlate:INFO:Frame converged in 10 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 5
muDIC.solver.correlate:INFO:Frame converged in 11 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 6
muDIC.solver.correlate:INFO:Frame converged in 19 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 7
muDIC.solver.correlate:INFO:Frame converged in 9 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 8
muDIC.solver.correlate:INFO:Frame converged in 9 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 9
muDIC.solver.correlate:INFO:Frame converged in 6 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 10
muDIC.solver.correlate:INFO:Frame converged in 12 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 11
muDIC.solver.correlate:INFO:Frame converged in 10 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 12
muDIC.solver.correlate:INFO:Frame converged in 10 iterations
muDIC.solver.correlate:INFO:Processing frame nr: 13
muDIC.solver.correlate:INFO:Updating reference at 13
muDIC.solver.reference:INFO:Splitting in 1 blocks:
muDIC.solver.reference:INFO:Pixel coordinates found in 8 iterations

[PolymerGuy]

Hm... It is very strange if things stop without raising an exception. If you want, you can send me a sample set and I can give it a try. I cannot promise to do this immediately, but I will have a look at it.

If data is returned, try to plot it and see where the element is at. It is probably flying around somewhere :)