Shot Arc and Backspin

I do not understand what the Speed column means on the attached CSV, exported from PocketLab.  This data is from a foam ball with PocketLab inside, tossed-rebounded-and-tossed (no bouncing on the ground) repeatedly at a wall.  The tosses are in an arc, starting from about 5'4" height and bouncing off a spot on the wall that is higher than the initial height.  Why is the speed always greater than 0?  Why is the speed generally increasing?  

Attachments

Thanks for your question. 

The Projectile Speed graph can be a little tricky. The PocketLab calculates speed using just the accelerometer and the application is meant for projectile motion experiments. If you place the PocketLab sensor inside a ball and throw it up in the air and then catch it, you can approximately measure the projectile speed. However, you'll want to zero the graph right before you throw as small amounts of noise in the accelerometer can cause drift. 

In the case of your experiment, my guess is that every time the ball bounces off the wall and is then caught the acceleration from those impacts are causing the data to drift and then the graph is not being zeroed, so it is only continuing to drift throughout the experiment. The speed graph would be more accurate if it was zeroed right before the throw, then thrown and caught. I think it's the bounce off the wall that is throwing off the speed data. 

For a more detailed description of the Projectile Speed graph and its limitations, here is a link to a previous forum post: 
http://support.thepocketlab.co...echnically-difficult

Let me know if you have any other questions. 

Thanks, 

Robby

This example lesson, Projectile Motion of an Object, introduces some of the concepts that are related to Shot Arc calculation:

http://support.thepocketlab.co...-motion-of-an-object

Enabling the accelerometer and barometer, using the speed graph (zero'ed) and the altitude graphs, I can see on the graphs where my throw begins, where my ball hits the basket, and returns to me.  I can chart the maximum height.  I think I can accurately calculate the release angle.  Just not sure how to accurately calculate the angle when the ball hits the basket .... any suggestions for that from this set of data?

 

 

 

Great! Glad that lesson was able to help in some way. 

In terms of measuring the angle when the ball hits the basket, there isn't really a way to do that with the sensors. My suggestion would be to take video of the shot (if you're using iOS or Android you can use the video function in the app) and then measure the angle by analyzing the video. 

Exporting data as a .csv should work from the two-graph mode in the same way it works in the one-graph mode. It would just export two files. Let me know if that doesn't work for you. 



Thanks again! 

Robby

Hi Robby,

I have several follow-up questions/notes:

(1) In single-graph mode, I Share Data by exporting to Dropbox (Save to Dropbox appears in the bottom row of options).  In two-graph mode, that option is not presented.  I have found that I can share two-graph mode CSVs with AirDrop, however, so I'm using AirDrop-to-Mac-to-Dropbox to get the file where I need it.

(2) Is there documentation about the role of the Acceleration Scalar (g)?  I would like to understand how to use it with the Acceleration x(g), y(g), and z(g) columns of data, and I would like to understand if I should use it as a multiplier with its sign or using its absolute value.

(3) The Speed column in the csv file, which we have determined is impacted by drift problems unless I zero the data collection between tosses, is labeled (m/2); should that be in meters per second?

 

Thanks!

Great! Thanks for the questions. 

1) Let me look into that and get back to you. It could be an odd setting in iOS. Another good app to share CSV files on iOS is the Notes app. You can save the CSV and add a title or a note like "Trial 1" right when you save it. 

2) Good question! We currently don't have anything posted, but that's good feedback. For now, here is a quick explanation: 
The acceleration scalar graph is the resultant of all three axes -1g to offset gravity (this allows the acceleration to read 0g when the PocketLab is stationary, otherwise it would read 1g when stationary because gravity is pulling down on the accelerometer). To calculate the resultant we use the equation a= √(〖a^2〗_(x )+ 〖a^2〗_(y )+ 〖a^2〗_z ).

In terms of whether you should use its sign or absolute value when multiplying, I guess it would depend on what your doing, but I would think you should use the sign. The only time the Acceleration Scalar graph is really going to be negative is when the PocketLab is in free fall, so the negative sign would help you determine that. When the PocketLab is not in free fall, like if you were shaking it back and forth, because it's the resultant of all three axes the acceleration scalar graph should just read positive. 

3) Yes, that column is labeled incorrectly. It should read m/s. We are fixing that in an upcoming app update. 

4) The accelerometer is calibrated, but there are slight offsets due to noise in the accelerometer. That may be why you see 0.01 g in the Acceleration Scalar graph when the PocketLab is stationary. We do not have a "zero" button like in some of the other graphs. I can look into that further and get back to you though. 



Let me know if you have any other questions. 


Thanks, 
Robby

Add Reply

×
×
×
×