Throwable Panoramic Ball Camera

Looks like a really cool camera but I don't think it's for sale yet
luxury_piesays...

^ I think it will take a photo everytime it stands still after being accelerated upwards. Using the fact that there will be no vertical forces applied to the "ballcamera" the moment it reaches maximum height after a throw.
*engineering

rychansays...

>> ^luxury_pie:

^ I think it will take a photo everytime it stands still after being accelerated upwards. Using the fact that there will be no vertical forces applied to the "ballcamera" the moment it reaches maximum height after a throw.
engineering


Actually, no. The acceleration on the ball is roughly constant through the entire trajectory. So it's somewhat tricky to estimate when you're at the top of the parabola.

luxury_piesays...

>> ^rychan:

>> ^luxury_pie:
^ I think it will take a photo everytime it stands still after being accelerated upwards. Using the fact that there will be no vertical forces applied to the "ballcamera" the moment it reaches maximum height after a throw.
engineering

Actually, no. The acceleration on the ball is roughly constant through the entire trajectory. So it's somewhat tricky to estimate when you're at the top of the parabola.

They seem to use an accelerometer to predict the time of max height as seen on
their website.
I wasn't referring to the acceleration rather to the forces, being applied while thrown, to a possible freely movable object inside of the camera, using the same principle as the seatbelt mechanism.
My train of thought leaves in a couple of minutes.

rychansays...

There's no freely movable parts inside the camera. The website makes it pretty clear:
"Our camera contains an accelerometer which we use to measure launch acceleration. Integration lets us predict rise time to the highest point, where we trigger the exposure."

So while your original post implies that it somehow detects the top of the trajectory as it happens, in fact the camera measures launch acceleration to predict the length of time until the top of the trajectory.

>> ^luxury_pie:

>> ^rychan:
>> ^luxury_pie:
^ I think it will take a photo everytime it stands still after being accelerated upwards. Using the fact that there will be no vertical forces applied to the "ballcamera" the moment it reaches maximum height after a throw.
engineering

Actually, no. The acceleration on the ball is roughly constant through the entire trajectory. So it's somewhat tricky to estimate when you're at the top of the parabola.

They seem to use an accelerometer to predict the time of max height as seen on
their website.
I wasn't referring to the acceleration rather to the forces, being applied while thrown, to a possible freely movable object inside of the camera, using the same principle as the seatbelt mechanism.
My train of thought leaves in a couple of minutes.

luxury_piesays...

This was my guess at first. But their way relies on math, so that's alright.
>> ^rychan:

There's no freely movable parts inside the camera. The website makes it pretty clear:
"Our camera contains an accelerometer which we use to measure launch acceleration. Integration lets us predict rise time to the highest point, where we trigger the exposure."
So while your original post implies that it somehow detects the top of the trajectory as it happens, in fact the camera measures launch acceleration to predict the length of time until the top of the trajectory.
>> ^luxury_pie:
>> ^rychan:
>> ^luxury_pie:
^ I think it will take a photo everytime it stands still after being accelerated upwards. Using the fact that there will be no vertical forces applied to the "ballcamera" the moment it reaches maximum height after a throw.
engineering

Actually, no. The acceleration on the ball is roughly constant through the entire trajectory. So it's somewhat tricky to estimate when you're at the top of the parabola.

They seem to use an accelerometer to predict the time of max height as seen on
their website.
I wasn't referring to the acceleration rather to the forces, being applied while thrown, to a possible freely movable object inside of the camera, using the same principle as the seatbelt mechanism.
My train of thought leaves in a couple of minutes.


MilkmanDansays...

>> ^Mojofreem:

If this was made by a German university group, why is it tagged Asia? Last I checked, Germany was still in Europe. Just sayin'.


First lines of the credits:

Throwable Panoramic Ball Camera
an Emerging Technologies demonstration at the
SIGGRAPH Asia 2011

(SIGGRAPH = Special Interest Group on GRAPHics, this is a convention of theirs)

I'd say you're right and the originating group is probably more important than where it is being demoed, but I think that (possibly plus the music) is the "why" on the Asia tag.

ForgedRealitysays...

So if you thrust it upwardly whilst holding it, and never let go, simply pull it back down quickly, after a few seconds, it would snap a panorama while it rests in your hands since it doesn't use a gyroscope to tell where it stops accelerating. Right?

This means that if you thrust it upward quickly enough, you could pull it back and hold it there while in amongst a crowd, and when the mechanism reaches the predicted time based upon initial acceleration for predicting its apex, then it will take the photo from within the crowd. Seems like it would make more sense to detect DEceleration, as that would facilitate either an upward OR a downward motion, and it wouldn't be reliant on possible bad guesses at when it would stop moving (dependent on environmental influences such as air viscosity, temperature, wind, obstacles in the path, etc).

Cool idea anyhow. I wonder what it would look like to spin it really fast as you toss it.. Neat psychedelic blurring on MOST of the photosphere, but on the axis, it would be less blurred.

blackorebsays...

Your idea won't work. Once the ball leaves your hand, acceleration on the ball is essentially constant until it hits something. The only variable acceleration will be due to drag and "dependent on environmental influences such as air viscosity, temperature," etc.

The designer can account for your "never-let-go" scenario, as well as the more common "bouncing-around-in-the-back-seat" scenario, by requiring a minimum launch acceleration, followed by a minimum period of constant acceleration, before snapping a picture.

>> ^ForgedReality:

...Seems like it would make more sense to detect DEceleration, as that would facilitate either an upward OR a downward motion, and it wouldn't be reliant on possible bad guesses at when it would stop moving (dependent on environmental influences such as air viscosity, temperature, wind, obstacles in the path, etc)....

ForgedRealitysays...

>> ^blackoreb:

Your idea won't work. Once the ball leaves your hand, acceleration on the ball is essentially constant until it hits something. The only variable acceleration will be due to drag and "dependent on environmental influences such as air viscosity, temperature," etc.
The designer can account for your "never-let-go" scenario, as well as the more common "bouncing-around-in-the-back-seat" scenario, by requiring a minimum launch acceleration, followed by a minimum period of constant acceleration, before snapping a picture.
>> ^ForgedReality:
...Seems like it would make more sense to detect DEceleration, as that would facilitate either an upward OR a downward motion, and it wouldn't be reliant on possible bad guesses at when it would stop moving (dependent on environmental influences such as air viscosity, temperature, wind, obstacles in the path, etc)....


Once the ball leaves your hand, there IS no acceleration. In fact, it becomes inverted, as there are no longer any forces acting upon it to create acceleration, and it is now decelerating. Deceleration is not constant, as it reaches a point where it is essentially weightless. This is the point at which it currently seeks to snap the image. If It actually detected when the ball stopped moving, acceleration wouldn't be a factor.

messengersays...

Nope. Once the ball leaves your hand, there is one significant acceleration force, which is gravity, downwards. There is no such force as "deceleration", just acceleration in a different direction. If by "deceleration" you mean gravity's acceleration downwards, it is constant enough for our purposes today: 9.8 m/s/s).>> ^ForgedReality:

>> ^blackoreb:
Your idea won't work. Once the ball leaves your hand, acceleration on the ball is essentially constant until it hits something. The only variable acceleration will be due to drag and "dependent on environmental influences such as air viscosity, temperature," etc.
The designer can account for your "never-let-go" scenario, as well as the more common "bouncing-around-in-the-back-seat" scenario, by requiring a minimum launch acceleration, followed by a minimum period of constant acceleration, before snapping a picture.
>> ^ForgedReality:
...Seems like it would make more sense to detect DEceleration, as that would facilitate either an upward OR a downward motion, and it wouldn't be reliant on possible bad guesses at when it would stop moving (dependent on environmental influences such as air viscosity, temperature, wind, obstacles in the path, etc)....


Once the ball leaves your hand, there IS no acceleration. In fact, it becomes inverted, as there are no longer any forces acting upon it to create acceleration, and it is now decelerating. Deceleration is not constant, as it reaches a point where it is essentially weightless. This is the point at which it currently seeks to snap the image. If It actually detected when the ball stopped moving, acceleration wouldn't be a factor.

ForgedRealitysays...

>> ^messenger:

Nope. Once the ball leaves your hand, there is one significant acceleration force, which is gravity, downwards. There is no such force as "deceleration", just acceleration in a different direction. If by "deceleration" you mean gravity's acceleration downwards, it is constant enough for our purposes today: 9.8 m/s/s).>> ^ForgedReality:
>> ^blackoreb:
Your idea won't work. Once the ball leaves your hand, acceleration on the ball is essentially constant until it hits something. The only variable acceleration will be due to drag and "dependent on environmental influences such as air viscosity, temperature," etc.
The designer can account for your "never-let-go" scenario, as well as the more common "bouncing-around-in-the-back-seat" scenario, by requiring a minimum launch acceleration, followed by a minimum period of constant acceleration, before snapping a picture.
>> ^ForgedReality:
...Seems like it would make more sense to detect DEceleration, as that would facilitate either an upward OR a downward motion, and it wouldn't be reliant on possible bad guesses at when it would stop moving (dependent on environmental influences such as air viscosity, temperature, wind, obstacles in the path, etc)....


Once the ball leaves your hand, there IS no acceleration. In fact, it becomes inverted, as there are no longer any forces acting upon it to create acceleration, and it is now decelerating. Deceleration is not constant, as it reaches a point where it is essentially weightless. This is the point at which it currently seeks to snap the image. If It actually detected when the ball stopped moving, acceleration wouldn't be a factor.



Okay true enough, but now you're arguing semantics when you know full well what I meant.

blackorebsays...

It is true, but it is not just semantics.

Once the ball leaves the hand it will experience constant acceleration (ignoring drag). With just constant acceleration, the accelerometer can't tell us when the ball will reach apogee. Velocity and displacement are not being measured, so whether the ball is moving up or down won't register.

With only an accelerometer to work with, the only practical to way to predict when the ball will be at its highest point is to use the initial upward acceleration and a little bit of math.

>> ^ForgedReality:

>> ^messenger:
Nope. Once the ball leaves your hand, there is one significant acceleration force, which is gravity, downwards. There is no such force as "deceleration", just acceleration in a different direction. If by "deceleration" you mean gravity's acceleration downwards, it is constant enough for our purposes today: 9.8 m/s/s).>> ^ForgedReality:
>> ^blackoreb:
Your idea won't work. Once the ball leaves your hand, acceleration on the ball is essentially constant until it hits something. The only variable acceleration will be due to drag and "dependent on environmental influences such as air viscosity, temperature," etc.
The designer can account for your "never-let-go" scenario, as well as the more common "bouncing-around-in-the-back-seat" scenario, by requiring a minimum launch acceleration, followed by a minimum period of constant acceleration, before snapping a picture.
>> ^ForgedReality:
...Seems like it would make more sense to detect DEceleration, as that would facilitate either an upward OR a downward motion, and it wouldn't be reliant on possible bad guesses at when it would stop moving (dependent on environmental influences such as air viscosity, temperature, wind, obstacles in the path, etc)....


Once the ball leaves your hand, there IS no acceleration. In fact, it becomes inverted, as there are no longer any forces acting upon it to create acceleration, and it is now decelerating. Deceleration is not constant, as it reaches a point where it is essentially weightless. This is the point at which it currently seeks to snap the image. If It actually detected when the ball stopped moving, acceleration wouldn't be a factor.


Okay true enough, but now you're arguing semantics when you know full well what I meant.

messengersays...

I did know what you meant, and I wouldn't have said anything, except that you chose your words in contradiction to someone saying, "Once the ball leaves your hand, acceleration on the ball is essentially constant until it hits something." That is correct. You saying there is no acceleration is wrong.

http://xkcd.com/386/>> ^ForgedReality:
Okay true enough, but now you're arguing semantics when you know full well what I meant.

Send this Article to a Friend



Separate multiple emails with a comma (,); limit 5 recipients






Your email has been sent successfully!

Manage this Video in Your Playlists




notify when someone comments
X

This website uses cookies.

This website uses cookies to improve user experience. By using this website you consent to all cookies in accordance with our Privacy Policy.

I agree
  
Learn More