h a l f b a k e r yGet half a life.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
In time-lapse photography, the camera is placed in a fixed
position and photos are taken at equal intervals over a
period of time, then combined to make a movie of greatly
sped-up action.
This process is similar, except the camera is attached to a
vehicle, and instead of taking photos at equal
time
intervals, the camera is connected to a computer that
takes
photos at equal *distance* intervals. Additionally, the
computer knows how fast the car is moving at any given
instant, and adjusts the shutter speed and aperture (and
other camera settings like ISO) to provide a balanced
exposure where the shutter is open for the same distance
each exposure. For example, the shutter speed might be
1/20 at 30mph, but 1/40 at 60mph.
The net result, when the images are combined into a
movie,
should be a speed-normalized version of the trip. Unlike
existing sped-up trip movies that can be found on the
Internet, there will be no stops and starts, and the terrain
should move at the same apparent speed regardless of the
actual speed of the car when a specific photo was taken.
It
would appear as if you're floating through the landscape
at a
constant speed.
Dash cam
Dash_20Cam
Clicks a shot every X mile based on the odometer. [tatterdemalion, Aug 28 2013]
[link]
|
| |
Note: I have actually made progress towards implementing this idea, but since it got stalled
over a year ago and I haven't worked on it since then, I figured I'd post it here. |
|
| |
I did some tests and discovered that a GPS receiver wasn't as accurate at determining
speed as would be needed, nor was the update frequency even close to what I was hoping.
However, I managed to modify my car to add a jack that taps into the speed sensor wire,
and read the data via an Arduino circuit connected to a laptop. So I can get the speed
information with a high degree of precision. |
|
| |
I also started working on writing a driver to control the camera from the laptop. I got about
50% done with that when I got distracted by something shiny, and never finished it. That's
the easy part, though—I just need to find the time for it. |
|
| |
I also need to figure out how to mount the camera in my car so that it's stable. I fear this is
going to be the hardest part. I'm not really sure what the best way to do it is. Rigid mount?
Gyroscopic gimbal? No clue. I think it would need to be really stable and free from vibration
for the effect to work. A frame that's a bit “buzzed” from vibration during exposure could
totally ruin the effect. |
|
| |
I would imagine that this is how the Googlemobile does its thing (or, to be more exact, how I imagine it would be accomplished efficiently). |
|
| |
They're a bit similar, but not really that much. The
Google van is only concerned with taking pictures at
specified locations, and doesn't really care about
modifying the exposure based on speed. It also has
a fairly coarse spatial resolution (e.g. one photo
every 50 feet or so), so a GPS
receiver
is perfectly suited for that purpose. For this
application, the location isn't specified, and indeed,
doesn't really even matter. The only things that are
important are instantaneous speed and distance
travelled—factors that are irrelevant to the Google
van. |
|
| |
It would be nice to implement this using only mechanical means, using a series of levers connecting the dials to the camera. If your car only has a digital odometer you could build a mechanical integrator out of mechano. |
|
| |
// So I can get the speed information with a high
degree of precision.// |
|
| |
Legislature decrees that motor vehicles have some
indicator of speed for the driver, and also that
vehicles keep within speed limits on designated
roads. In order to avoid the obvious litigation
when motorists charged with speeding blame the
readout on the car's speedometer, the speedo
always reads higher than true. Tolerance may be
5%, so when travelling at 50mph your speedo may
read anything between 50 and 55. The spread
varies with speed and the way the speedo gets its
data may also give rise to further discrepancies. If
it counts the number of revs your road wheels
make, as a function of the drive shaft/axle and
gearing ratios, it's also going to be affected by the
amount of tread remaining on your tyres and the
overall wheel size. The difference between new
and bald tyres may be 200 revolutions per
kilometre. |
|
| |
Even a cheap GPS sensor should be more reliable
than your car's mechanical measurement. |
|
| |
Surveyors and road planners use a "wheel on a
stick" as their preferred measurement device,
with controlled circumference and accurate
gearing. Trail one of those around attached to
your car and use that as your trigger instead. |
|
| |
I don't care what the *actual* speed is, so long as
the reported speed is consistent between
measurements. The way the speed wire works is it
pulses as the car moves. The pulse rate increases as
the car speeds up. |
|
| |
//Even a cheap GPS sensor should be more reliable
than your car's mechanical measurement.// |
|
| |
In actual fact, I've done some testing and compared
the car's reported speed to the GPS speed and
found it to be more than accurate enough for my
purposes, and it updates significantly faster and is
more consistent as well. The GPS speed tends to lag
behind the actual speed by as much as a few
seconds, and it has random dips and spikes from time to time. That simply
won't do. |
|
| |
By “precision” I mean ability to get a measurement
that reflects the speed of the car in as close to real
time as possible. GPS receivers just aren't capable
of doing that; at least, none of the ones I've ever
used are. But even if there is some receiver out
there capable of the degree of precision I need, I
don't really care that much, since I already have it
from the car's sensor wire. |
|
| |
Quite so; a car's speedometer has high precision, but low accuracy. Conversely, GPS has high accuracy, but low precision. The obvious upshot of which is that you can combine the two data streams to calculate position and velocity with great precision _and_ accuracy. |
|
| |
//update frequency// yeah, that's a problem - I
have an old Magellan that updates the display
every second, but the data out lines only update
every 2 seconds. It's set up to give it time to cycle
a full set of NMEA sentences at 4800 baud, and
even if you select less output data, you still have
to wait. |
|
| |
However, there are some GPS units I've noticed on
Adafruit which update at 10 Hz, which may be
much more like what you want. I don't know the
output format, but I'm sure it's something
reasonable. |
|
| |