Anyone use the accelerometer to calculate jump height?

if you want to get the height you need to sum the duration of only the moving up phase, which means you have to know exactly when it is.

You can know that by noticing when the vertical velocity is changing sign, which means you have to know the velocity at each moment.

you can get it by integrating the vertical acceleration. This type of integration is susceptible to drift error. The time frame might be short so the error could be small enough.. depends on the accelerometer noise..

I don't know of an app that does that (also on smartphones), there might be.. but i think it would be better using the barometer, or maybe even combining the two and using a Kalman filter..

I was very clear (and correct) about how this would work from a physics perspective. An accelerometer will detect zero acceleration under free fall. And free fall starts exactly at the moment the person stops accelerating (because they have left the ground) and starts decelerating because they hit the ground. Read this if you don't beleive me https://physics.stackexchange.com/questions/402611/why-an-accelerometer-shows-zero-force-while-in-free-fall

So all aI need, as I've already said, is the time for which 0g of accelleration was detected. From this time we can get height:

height = 0.5 x 9.81 m/s^2 x (time / 2 )^2

What I asked was:

Is there a problem with this idea? And I asked that because I don't see it implemented anywhere in the Garmin universe.

I also asked about getting accelerometer data in different app types (e.g. data field).

Yes there is a problem with your method, the acceleration will show 0g at the moment the athlete will leave the ground, that's the moment he stops accelerating up and therefore you will sum both his way up and down.

The equation I have shown includes "time / 2". I use half the time. Time up = time down because acceleration is constant.

So this is accounted for.

Yes it can work that way as long as he lands on his feet and on the ground (not a mattress or something..)

The other thing to consider is how often the sensor is sampled by the firmware and made visible in Sensor.Info  Maybe look at how things are done in the PitchCouner sample in the SDK.

I think the key is "Assuming the jumper keeps arms still relative to body". Put a video camera on a table and record yourself jumping with different "styles". Try to do it casually as any other user would (don't try to keep your arms still). Then also do the same jump styles and try to keep the arm still. I GUESS you will see in the video how much that assumption is correct (i bet it's not)

Now if you insist then you can go a step further and do the same video while recording the raw accelerometer data on the watch (make sure you synchronized the time on the camera and the watch) and try to analyse the data + video and see if there's enough "data" to write an algorithm to find out when the "body" left the ground and then contacted it again.

Next thing you can do is to concentrate also on the legs: my guess is that they're not 100% streight at the moment they leave the ground and when they touch it again. So you'll also need to calculate/guess (or ignore :) the difference between takeoff and touchdown.

What would be ideal is to put the watch as close to the center of the body mass... That would eliminate both the arm and leg movement problem. Maybe if you put the watch in the pocket of your pants it will help in this regard.

I think the key is "Assuming the jumper keeps arms still relative to body". Put a video camera on a table and record yourself jumping with different "styles". Try to do it casually as any other user would (don't try to keep your arms still). Then also do the same jump styles and try to keep the arm still. I GUESS you will see in the video how much that assumption is correct (i bet it's not)

Now if you insist then you can go a step further and do the same video while recording the raw accelerometer data on the watch (make sure you synchronized the time on the camera and the watch) and try to analyse the data + video and see if there's enough "data" to write an algorithm to find out when the "body" left the ground and then contacted it again.

Next thing you can do is to concentrate also on the legs: my guess is that they're not 100% streight at the moment they leave the ground and when they touch it again. So you'll also need to calculate/guess (or ignore :) the difference between takeoff and touchdown.

What would be ideal is to put the watch as close to the center of the body mass... That would eliminate both the arm and leg movement problem. Maybe if you put the watch in the pocket of your pants it will help in this regard.

flocsy🤠 said:

Assuming the jumper keeps arms still relative to body

Right. I have tried some jumps where I keep my hands on my head, or folded at my chest to keep my wrist stationary. And I'd have to put this in instructions. The thing I'd want to measure is *progress*. So, how much better is a person getting at this type of jump, and maybe tracking some jerk (rate of acceleration) details to see if the jumper is getting better at certain phases of the jump but not others. But I'd have to avoid making the claim: "You can jump this high".

I had not considered the legs not having the same extension upon liftoff and landing. So that's a great point. I'll have to see how that effects things. I suppose one could attach the watch to their ankle (or pocket as you suggest) to be more precise. I'll have to play around a bit and see if it's a problem on the wrist. 

Thanks for the considerations Gavriel.

Regarding claiming "you can jump this high": maybe you should have a way to "calibrate" it. It sounds easy (ask the user to jump a number of times AND type in the actual height) but it's close to impossible to do it. I mean I would not be able to determine how high I jumped. I'm not even sure if someone next to me could help with it...

But assuming you can find some way to measure it, then giving that information to the app as a calibration would make it possible to give better calculations later.

BTW having this calibration might even be useful for other aspects of the algorithm.