Free-Fall Lab Help - Getting weird results

[Unity+]

So, I am doing a free-fall lab for my physics class. We got the values and I have the results here(we used a infrared photo-gate). Basically, we have a brass cylinder and a wood cylinder. Each are dropped in the middle of 5 infrared photo-gates before hitting the ground, which calculate the velocities and the time at which they passed through.

 

 

We had 4 trials done(the recommended amount). We needed to calculate the acceleration to determine whether it was approximately equal to 9.81 m/s^2. However, when calculating the acceleration, we got weird results.

 

First, we decided to subtract the velocities between gates and subtract the times between and then divide the velocity change by the time difference and here is one result we got that makes no sense: 31.13 m/s^2.

 

We then decided to calculate it as if we are going from 0 velocity to N velocity, the results we got. We got better results, but they had an increasing acceleration. Here is the first set of results: 10.18 m/s^2, 13.96 m/s^2, 15.63 m/s^2, 19.8 m/s^2.

 

I will try using averaging, but I wanted to make sure I calculated the results correctly. Is there a mistake that was made?

[fiveworlds]

10.18 would be ok if your timer was starting before the cylinder had stated dropping. But your values are weird are you sure there wasn't a malfunction with the gates and/or timer??

 

I know when I was doing the freefall experiments we simply dropped an object through a distance onto a timer which turned off when it was hit. We got fairly close to 9.8m/s.

 

Edited September 12, 2015 by fiveworlds

[imatfaal]

Your timing splits are consistent across all four runs - with deltas of 96, 66, 55 milliseconds. But your speed, not sure I believe it I a speed, varies massively. This would be enough for me to say your data is screwed

 

The speed delta between first and second reading is consistent and only has a variance of about 1pct (3 runs are even closer, and two are almost identical. But if the units are to be believed it gives an acceleration of 31.3ish m/s ie first decimal place is uncertain. The second delta is not consistent to the units place , and the third varies in the magnitude of tens. Acceleration is in this instance change of velocity over time and these figures must be consistent for you to give an answer.

 

And of course the one consistent answer is rubbish. But as I mentioned above "if the units are to be believed" - you are with in a couple of percent of the correct answer in feet per second per second

 

Maybe post a data dump and we can work out what is going wrong - it looks as if you have posted only selected data; and I wonder if your selection is what is at fault

[Unity+]

Here is another set of data that we had for a wood cylinder:

 

[Mordred]

Have you considered the possibility of scan times interference? The results shown could be due to execution delays and input scan time resolution with your program.

 

I haven't used datastudio itself, but I often run into problems of this nature in various software. In particular PLCs. In particular programs I write for motion control systems, in many cases this can be reduced by setting the appropriate priorities and interrupts on your measuring inputs.

 

As datastudio is Windows based I would also stop any other tasks the PC may be performing to an absolute minimal. Also defrag and scandisk your PC to get some PC optimization.

Another idea is run tighter subroutines when your performing the test to minimum instructions and record the result into a pointer driven datatable as opposed to variable driven. Variables use more memory than pointers.

 

Essentially you want as few instructions used as possible during the test itself. If you look at the instruction clock cycles per instruction you should be able to tweak your software. Use subroutines instead of any jump commands. Jump commands typically require a greater number of clock cycles.

 

Remember compilers execute instructions in the specified program order. So reduce the number of instructions per loop required to examine and scan the input of your senser

(Lol in many ways I miss the good ole DOS days. For running fast execution times you can't beat the lack of interference from other programs running on the background and the lack of GUI. Running basic hardware for precision timing was far far easier.)

 

 

One thing to remember program execution scan times can vary on a PC. Largely due to other programs running at the same time. Your CPU can only execute x instructions at a given time.

 

One idea might be write a seperate program that does nothing more than scan the input and record the result to a datatable. Then use your main program to later examine and display the data. Shorter programs execute per program cycle far faster than longer programs

 

Another method is to have a separate subroutine that just runs the input of the sensor, your timer and recording. Control said subroutine with keyboard commands.

 

Example press ctrl t

Execute test subroutine

Execute drop gate

Run timer

Read input

record

if ctrl E goto main (exit subroutine command) else repeat subroutine

 

 

Keep this subroutine as short as possible.

Edited September 13, 2015 by Mordred

[Unity+]

Sorry for the late response.

 

It turns out there was an improper unit measurement with the diameter of the cylinder, therefore the calculations in the software were done in ft/s^2 rather than m/s^2, aka human error.

[imatfaal]

...

And of course the one consistent answer is rubbish. But as I mentioned above "if the units are to be believed" - you are with in a couple of percent of the correct answer in feet per second per second

...

 

 

Sorry for the late response.

 

It turns out there was an improper unit measurement with the diameter of the cylinder, therefore the calculations in the software were done in ft/s^2 rather than m/s^2, aka human error.

 

I am so chuffed I spotted that one!

[Sensei]

Unity, watch this video to see how it should be calculated:

 

IMHO for this kind of stuff, pretty good results are obtained with high speed camera. The more FPS the better.

Put vertical scale behind failing object. Then you can see every frame by frame in 2D animation editing software.

And from scale read distance it traveled.

Frames are with pretty much constant delays each other, so current_frame_count [unitless] * 1.0 / frames_per_second = time

Edited September 16, 2015 by Sensei