sorry for asking

[ADWSystems]

Question about your math though. Why are you going
F=mA as well as F=1/2*mV2.
One is force, the other is kinetic energy, so really it should be E = 1/2*m*(v^2).

Now you decide to look at the math. That was the example on the physics class website. Guess those students didn't get that question right.

 

[dknguyen]

No, that example is wrong. Here's what you need to do.

You need momentum for this problem (which is related to kinetic energy in calculus, but we don't care about that). Did you take momentum in high school? Where p=mv and its conserved so if two perfectly elastic bodies hit each other, their momentum gets split up and they go off in opposite directions with the same total momentum?

You need that here. But there's two problems:

First is you have an acceleration measurement, but momentum equations requires velocity.

You can get velocity of the target by integrating acceleration over time. You run into signal processing issues here. Your Arduino may not be able to keep up. To actually do the integration, search up "numerical analysis" and "numerical integration". There are lots of methods but just stick with the trapezoidal method or rectangular method.

I would high-pass filter the acceleration readings since you don't care about slow accelerations here such as gravity or wind or anything slower than the sharp acceleration of an impact. You will also need to high pass filter too so your ADC samples don't alias. You don't want to low pass filter too much though or you will not be able to capture the sharp (high frequency) accelerations from the impact.

This is going to require you to sample fast enough to get a very good view of the detail that tiny acceleration spike. Zoom on it hard with your oscilloscope. Zoom in before acquisition so your scope actually grabs it with sufficient resolution. Your processor needs to sample it the same way. You need to sample fast enough that if you split area under the waveform up into rectangles with the dimensions (Sample Interval) x (Current Reading), that it fills up the area underneath that waveform accurately.

Since you're integrating (or doing any complex math) on a processor, beware the pitfalls of numerical analysis due to finite number representations. Fixed point or floating point. One such problem is adding a very large number to a very small number makes the small number might as well be zero...which is a big problem if you're integrating because the whole principle is that all the little bits add up to make a whole. There are other pitfalls. I can't go through them all, nor do I know of or understand them all.

Cease integrating when the the calculated velocity peaks and use that peak velocity value in your momentum calculations. Presumably, this will be the full speed of target after the momentum exchange. Hopefully not too many losses while it reaches this point (i.e. losses from the swinging beam). There's a lot of room to go wrong here.

Second is that you don't have perfectly elastic bodies which the basic form of the problem equations assume.
Elastic collisions perfect transfer and do not dissipate momentum/energy in the impact. But it is highly unlikely your ball and target will result in an elastic collision. This is handled using a "Coefficient of Restitution". Basically a fudge factor that is material dependent between 0 and 1 that is multipled into the momentum equations to take into account that there is momentum lost in the pact. I doubt you will be able to find a table that just lists the values you need.

The easiest way to figure this out (I think) is to drop the ball from a known height onto the target against and measure the rebound. If the collision were perfectly elastic, then the ball would rebound to the same height it was dropped from (the Coeffient of Restitution (CoR) = 1). If it is not a perfectly elastic collision then the ball will rebound at a lower height. The ratio of the rebound height over the dropped height should be the CoR.

Other Issues:

A potential problem is that I have no idea how a CoR works with an air filled ball. It's possible that the CoR changes depending on how the speed of impact due to the air inside the ball. You can figure this out by dropping at the ball from a bunch of different heights so the impact velocity varies and see if the rebound-drop ratio changes. If it does, things get tricky since you would either have to incorporate pneumatics into everything which ends up being simulation territory. Or more easily, but still complicated, do more drop tests and obtain a CoR vs Impact velocity curve. This curve has to then be incorporated into the conservation of momentum equations, either by replacing the CoR variable with the a curve fitting formula or treating it as a constant but solving it from both ends (both unknowns) at the same time using an iterative method where you progressively plug in different values from the curve into the equation until both unknowns converge.

A second issue is that your target swings, it introduces two issues:

(a) When it swings the center of gravity rises introducing potential energy into the equation. At that point you have to use the conservation of energy equations (which are themselves derived from the momentum equations) so that you can introduce an E=mgh potential energy term into things. It's messy here though because it's rotation swinging motion that raises the CoG so there's some calculus involved in this term and it gets messy. I'm not entirely sure I know how to do it myself...using an integral (I think) to replace the height variable in E=mgh where h is a function of the velocity.

(b) The swing means that the CoG is not moving linearly anymore. That means the target is basically rotating so instead of the linear p=mv momentun equation, you need to use now use the Moment of Inertia and angular velocity. Which means you have to calculate the angular acceleration from the linear acceleration reading of the accelerometer using its position relative to the fulcrum. Similarly, if you use the kinetic energy formula you need to replace mass and linear velocity with these values as well.

It would just be best if you construct things such that the target does not swing up appreciably so that the swing is small so the CoG basically moves linearly along the tangent line of the swing. I think the allowable range of this is about 17 degrees or 0.3 radians where the small angle approximation is valid. That should let you just assume all linear motion without this rotation business. The downside is it may get very tricky to measure and integrate the acceleration spike properly.

As you can see, there's a lot of unknowns that you have to assume out of things so you will need a speed gun to test things to see if your data and math actually works in the real world.

 

[ADWSystems]

You need momentum for this problem (which is related to kinetic energy in calculus, but we don't care about that). Did you take momentum in high school? Where p=mv and its conserved so if two perfectly inelastic bodies hit each other, their momentum gets split up and they go off in opposite directions with the same total momentum.

Yes plus 4 physics classes. All more than 20 years ago.

First is you have an acceleration measurement, not a momentum measurement. But momentum is based on speed. Second is that you don't have perfectly inelastic bodies.

So what is need to convert the acceleration reading to energy? For go the fact of the lack of inelastic bodies, additionally that assume kids can kick the ball hard enough to cause it to deform appreciably.

Everything you said is theory with exception for the fact that you have not provided the corresponding theoretical equations. (except for p=mv) How about the equations that pertain to the rest of the items you mention.

Zoom on it hard with your oscilloscope.

What oscilloscope? I don't have an oscilloscope. (wish I did)

P.S. The ISR method on an Arduino produces a ADC sample rate of 9615 per second.

 

[dknguyen]

Yes plus 4 physics classes. All more than 20 years ago.


So what is need to convert the acceleration reading to energy? For go the fact of the lack of inelastic bodies, additionally that assume kids can kick the ball hard enough to cause it to deform appreciably.

Everything you said is theory with exception for the fact that you have not provided the corresponding theoretical equations. (except for p=mv) How about the equations that pertain to the rest of the items you mention.


What oscilloscope? I don't have an oscilloscope. (wish I did)

P.S. The ISR method on an Arduino produces a ADC sample rate of 9615 per second.

Consolidated responses of energy questions into Post #42. In short, you can use momentum or energy since they are derived from each other, but if enough potential energy is present due to the target CoG rising during the swing, you might not be able to use conservation of momentum if. However conservation of momentum is simpler if you can use it.

I don't know if 10kHz sampling rate is enough. You said the spike on the waveform was very narrow which means you weren't zoomed in enough. Until you get a clear view of it, you won't know if 10kHz is enough. My money is that it's not since impacts happen in milliseconds and only a few dozen samples in that time period is not enough resolution to properly integrate. You don't integrate real sensor readings unless there's no alternative. That's huge especially if you have a slow processor which the Arduino is. Very slow. That sampling also has to be bang on in timing for integration. Variability in timing here due to the sample will destroy the integration result. That's the sampling only, the ISR can run whenever as long as it starts and finishes before the next sample.

One alternative to an accelerometer is to use a rotary sensor to measure the swing of the target itself and measure the time between two angular positions to get the angular velocity which can be simplified to a linear velocity as long as the swing is small (basically linear movement, or the small angle approximation). That's much more reliable than the accelerometer but has its own caveat: the sign has to swing enough to be picked up...not too much though or you have to use the rotation momentum or kinetic energy equations (and with it comes the potential energy term as well).

How did you view the waveform if you did not have an oscilloscope? If you got the MCU to sample at 10kHz and spit out the data for you to plot and all you saw was a thin spike for the impact's impulse, then the MCU is woefully insufficient to integrate that acceleration to get velocity. It needs to be able to sample fast enough to get a very clear view of that impulse spike.

 

[ADWSystems]

That's the sampling, the ISR can run whenever as long as it starts and finishes before the next sample.

Huh? No. Not even close to how an ADC ISR works. The ISR runs when the interrupt fires indicating the conversion is complete. The ISR ASM code runs to read the values and start the next conversion. Basically 3 MOV statements (because I'm not changing channels). Which is how you get the 9615 samples per second. Anything else goes slower. Trying to read two channels drops the sample rate to 2404 using this method (read A, change to A1 and read to clear, then read A1 again for data). Sucks don't it?

Since you're integrating (or doing any complex math) on a processor, beware the pitfalls of numerical analysis due to finite number representations. Fixed point or floating point. One such problem is adding a very large number to a very small number makes the small number might as well be zero...which is a big problem if you're integrating because the whole principle is that all the little bits add up to make a whole.

I know about this and so doesn't a very unfortunate waste water treatment plant (their totalizer stopped because of this)

More verbiage, no math. What is the math? What equations are you trying to implement?

 

[dknguyen]

Huh? No. Not even close to how an ADC ISR works. The ISR runs when the interrupt fires indicating the conversion is complete. The ISR ASM code runs to read the values and start the next conversion. Basically 3 MOV statements (because I'm not changing channels).

I know about this and so doesn't a very unfortunate waste water treatment plant (their totalizer stopped because of this)

More verbiage, no math. What is the math? What equations are you trying to implement?

The equations are simple which is why I mentioned the topics instead of the equations themselves. If mentioning the topic was not enough to spark that image in your head then re-read the topic before using them.

It's just P = mv, where m = mass and v = velocity. Or \[P = I* \omega \] where \[ \omega =angular_velocity\]

You can sum (or subtract) the linear and rotational momentum terms if required since the units should be the same (i.e. you can sum the linear momentum term of the ball with the swinging velocity of the target).

Same goes for kinetic energy E = 1/2 *m*(v^2), just replace m and v with their rotation counterparts.

One momentum term for the ball, and one term for the target. Momentum before impact has to equal momentum after impact.

P_ball_before + P_target_before = (P_ball_after + P+target_after) * CoR

Now that I type it out, I see that I forgot the problem of the momentum of the ball afterwards. You obviously can't track the ball after impact so you'll have to do your best to make the ball stop and drop after impact so velocity after impact is a known value (near zero). If you play around with the equation above, you might notice that there are two actually two unknowns: Both the velocity of the ball before impact and after impact. It works out that what this equation spits out is the velocity CHANGE of the ball. If you want to pull the actual impact speed from this you need to make the system so that the ball loses most of its speed after impact, though I am fairly certain this comes at the cost of it being tricky to properly measure the target's impact acceleration and calculate the target's velocity from this.

There's has to be a way to modify these equations to not need to make this assumption, but I don't know what it is which probably means it's tricky.

Look up the numerical integration yourself. The images of what is happening should make it self-evident what's going on during numerical integration.

 

[ADWSystems]

The equations are simple which is why I mentioned the topics instead of the equations themselves. If mentioning the topic was not enough to spark that image in your head then re-read the topic before using them.

It's just P = mv. One term for the ball, and one term for the target. Momentum before impact has to equal momentum after impact.

P_ball_before + P_target_before = (P_ball_after + P+target_after) * fudge_factor

Now that I type it out, I see that I forgot the problem of the momentum of the ball afterwards. You obviously can't track the ball after impact so you'll have to do your best to make the ball stop and drop after impact. If you do it well enough, you might be able to ignore the fudge factor. Look up the integration yourself. The pictures should make it self-evident what's going on.

I already said the ball drops nearly vertically after impact.

Those equations cannot be implemented. I don't have momentum sensors. I don't know what a "momentum sensor" is, and I don't know and the point is to measure the velocity or the impact force.

 

[dknguyen]

I already said the ball drops nearly vertically after impact.

Those equations cannot be implemented. I don't have momentum sensors. I don't know what a "momentum sensor" is, and I don't know and the point is to measure the velocity or the impact force.

You didnt understand anything I said then. The equations arent the magic sauce here. When did i talk about momentum sensors? Do you know why I was talking about integrating acceleration to get velocity? Read post 42 again carefully. I will edit it and make it more obvious but it assumes you understand conservation of momentum and elastic collisions.I already outlined the equations and process required. There's enough gotchas that you can't just the equations blindly and may have to modify them to the specifics of your system. There's not just one way to put the equations together. You might be able to get away with some simpliications and assumptions but not others. What you can get away with depends on your fundamental problem but also specifics about how you construct your system. I cant also explain conservation of momentum and integration to you to. What you need to know about them is simple to grasp if you google it.

I have given you the for of the momentum equation and the various types of terms that can be used in them depending on you go about things. I've also the equivalent equation using kinetic energy (very similar to the conservation of momentum equations just with energy terms for everything) but have not gone into it in further detail since there's not much point because the only reason you need it in this case to deal with potential energy which, like I already mentioned, I don't know math offhand to break down the potential energy term.

With regards to interrupts, they don't always actually run "immediately" It depends on if the processor is doing something that can be interrupted or not. If the processor is doing a task that can't be interrupted then the programmer may choose to disallow interrupts from executing and delay their execution until the uninterruptable task is complete.

 

[dknguyen]

Made some corrections and consolidations to my posts above. Posts #42, 44, and 46 have all been edited.

 

[Pommie]

Seems to me the indoor working system would have been perfect for testing (debugging) the current one. Indoors, of course.

Mike.

 

[ADWSystems]

With regards to interrupts, they don't always actually run "immediately" It depends on if the processor is doing something that can be interrupted or not. If the processor is doing a task that can't be interrupted then the programmer may choose to disallow interrupts from executing and delay their execution until the uninterruptable task is complete.

You assume. The opposite is also true. They do execute immediately if the program is design to allow them to execute immediately, and has no interrupt-blocking code. That would be very stupid to have a program that is trying to detect a peak have any code that would slow the sample rate of the ADC.

How did you view the waveform if you did not have an oscilloscope? If you got the MCU to sample at 10kHz and spit out the data for you to plot and all you saw was a thin spike for the impact's impulse, then the MCU is woefully insufficient to integrate that acceleration to get velocity. It needs to be able to sample fast enough to get a very clear view of that impulse spike.

That's what I said. Only took you three tries.

You didnt understand anything I said then.

Ditto.

When did i talk about momentum sensors?

What equations are you trying to implement?

Same goes for kinetic energy E = 1/2 *m*(v^2), just replace m and v with their rotation counterparts.
P_ball_before + P_target_before = (P_ball_after + P+target_after) * CoR

Those equations require to measure either the velocity or the momentum. I don't have a way to directly measure velocity, and I don't know a momentum sensor. Therefore, the momentum must be derived from another formula for which I have a sensor available, and those equations are the final answer to the question.

So lots of typing to clarify lots of things to yourself (because you have only reworded what you previous had or stated the obvious basics) and nothing to me, and no solution yet.

 

[ADWSystems]

For the ball:
E=1/2mv2
For the target:
I = m*h2/3
Which makes P=4/3*omega
and T=4/3*alpha = 4/3 a.
I can measure a.

 

[Pommie]

Did you just ask with help with the physics so you could argue with people trying to help?

Mike.

 

[ADWSystems]

Did you just ask with help with the physics so you could argue with people trying to help?

Not at all. I asked for help with the physics for a specific scenario. The OP was for help with the physics of a specific setup. Of the 26 responses, 11 are OT (re-)design suggestions. There are some nuggets scattered in the other 15 (more) pertinent responses, but they also include a lot of attempts to see how long of a response can be written (that's supposed to be equivalent to "talking to hear yourself talk") as well as a smattering of implied insults.

 

[dknguyen]

Those equations require to measure either the velocity or the momentum. I don't have a way to directly measure velocity, and I don't know a momentum sensor. Therefore, the momentum must be derived from another formula for which I have a sensor available, and those equations are the final answer to the question.

omg. INTEGRATION. Look it up. Integrate the acceleration to get the velocity. If your response to this is still "what's the formula" then this math is beyond you.

Stop treating the formula as the holy grail. Numerical integration is not even a formula as much as it is an algorithm and there's a bunch of versions that have to be selected and fine-tuned to your application which is why I fast-tracked you straight to rectangular or trapezoidal method which you may ultimately find are not sufficient and need to be replaced with another method.

If you didn't understand what I said then you need to READ about the topics I am talking about. The stuff I am talking about is conceptually SIMPLE which is why I am talking about it that way. Throwing in more equations makes it more convoluted than understanding the concept and laying out the process. The equations make it look way more complicated than it really is because the written one-shot formula is not the way its used in practice nor will the equation make sense unless you already understand the things I am saying.

You want the formula? Here's the formula and it tells you diddly squat. It's just saying "integrate acceleration to get velocity" which I have said before:

I can tell you did not even bother googling numerical integration or the trapezoidal rule just because you saw no formula from your quote above. Well, here's the formula. It will mean little as you read about numerical integration and it will mean little (nor will you need it) after you finish reading, yet that's what you need for this problem. This is endemic of your focus on the pure equations rather than how to actually use the math (note I said the math, NOT equations) and implement them. There's a lot more to this than equations.

Just google numerical integration. Just do it. Ignore the equations you see. Just look at the curves and the rectangles, triangles, and trapezoidal areas beneath the curves. If you understand that (it's not difficult), the equations write themselves which look much more difficult (and aren't used in practice like that anyway).

If you have specific questions about numerical integration, I'll be happy to answer them, but you need to understand what it actually is first. The thing about using integration is that you're in for a world of hurt if you start approaching it from an equations standpoint before grasping the concept. Approach it from the conceptual standpoint first then worry about equations after. Mathematicians didn't come up with it straight from equations so its folly to try and do the same.

 

[ADWSystems]

OMG, yourself. I have so many pieces from you my notes look like a connect the dots puzzle with no numbers. You have yet to draw a complete straight line between the start and the finish. You have yet to make one complete consecutive response. You started well in the response with the momentum formula and then....stopped and changed directions.

Integrate the values from the accelerometer and do what with what? Why not use an equation that does not require integration? I can almost guarantee the answer is in my freshman physics text book and the explanation will be a lot simpler than the 12 wandering posts read here. Unfortunately life got in the way of digging it out last night.

 

[ADWSystems]

You want the formula? Here's the formula and it tells you diddly squat:
View attachment 117973

Yet another disconnected piece. We are talking about momentum and you through out a velocity equation.

You are right and wrong. It says a lot. It also says that you need to go find the formulas related to the dynamics of the target. WHich 57 posts later is still the OP.

 

[Ian Rogers]

The thread has been undeleted by member request... But will stay closed.