hodapp/blag
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Pi pan tilt, first two parts: fixed some links, updated titles

Browse Source
This commit is contained in:
Chris Hodapp 2016-10-05 15:33:05 -04:00
parent f13034380d
commit 3aaffefc87
2 changed files with 17 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
posts/2016-09-25-pi-pan-tilt-1.md
View File

@ -1,5 +1,5 @@
---
title: Raspberry Pi pan-tilt mount for huge images, part 1
title: Pi pan-tilt for huge images, part 1: introduction
author: Chris Hodapp
date: September 23, 2016
tags: photography, electronics, raspberrypi
@ -91,7 +91,7 @@ produce:
[![](http://i.imgur.com/zwIJpFn.jpg){width=100%}](http://i.imgur.com/zwIJpFn.jpg)
More posts will follow soon on this!
Follow along to [part 2](./2016-10-04-pi-pan-tilt-2.html).
[cs6475]: https://www.omscs.gatech.edu/cs-6475-computational-photography
[ArduCam]: http://www.arducam.com/camera-modules/raspberrypi-camera/

33
posts/2016-10-04-pi-pan-tilt-2.md
View File

@ -1,5 +1,5 @@
---
title: Raspberry Pi pan-tilt mount for huge images, part 2
title: Pi pan-tilt for huge images, part 2: Hugin & PanoTools integration
author: Chris Hodapp
date: October 4, 2016
tags: photography, electronics, raspberrypi
@ -44,20 +44,22 @@ really curious). We may end up with images for which optimization
can't really improve the estimated position, and here a guess based on
where we think the stepper motors were is much better than nothing.
If we look at the [PTO file format][pto] (which Hugin & PanoTools
use), it has pitch, yaw, and roll for each image. Pitch and yaw are
precisely the axes in which the steppers move the camera (recall the
pictures of the rig from the last post); the roll axis is how the
camera has been rotated. We need to know the lens's angle of view
too, but as with other parameters it's okay to just guess and let the
optimization fine-tune it. The nominal focal length probably won't be
exact anyhow.
If we look at the [PTO file format][pto] (which Hugin & PanoTools use)
in its i-lines section, it has pitch, yaw, and roll for each image.
Pitch and yaw are precisely the axes in which the steppers move the
camera (recall the pictures of the rig from the last post); the roll
axis is how the camera has been rotated. We need to know the lens's
angle of view too, but as with other parameters it's okay to just
guess and let the optimization fine-tune it. The nominal focal length
probably won't be exact anyhow.
Helpfully, PanoTools provides tools like `pto_gen` and `pto_var`, and
I use these in my script to generate a basic .pto file from the 2D
grid in which I shot images. The only real conversion needed is to
convert steps to degrees, which for these steppers means using 360 /
64 / 63.63895 = about 0.0884, according to [this][steps].
grid in which I shot images. All that's needed is to add up the steps
taken to reach each shot, convert steps to degrees, which for these
steppers means using 360 / 64 / 63.63895 = about 0.0884 (according to
[this][steps]), and making sure that the positive and negative degrees
correspond to the right direction in each axis.
With no refining, tweaking, or optimization, only the per-image
stepper motor positions and my guess at the lens's FOV, here is how
@ -110,11 +112,6 @@ However, you can look up close and see how well the details came
through - which I find pretty impressive for cheap optics and a cheap
sensor.
TODO:
- This was done completely with a raw workflow, blah blah blah
- How did I wire the steppers, vs. how does Hugin see things?
[ArduCam]: http://www.arducam.com/camera-modules/raspberrypi-camera/
[forum-raw-images]: https://www.raspberrypi.org/forums/viewtopic.php?p=357138
[raspistill]: https://www.raspberrypi.org/documentation/raspbian/applications/camera.md
@ -129,4 +126,4 @@ TODO:
[hive13]: http://hive13.org/
[projection]: http://wiki.panotools.org/Projections
[szeliski]: http://szeliski.org/Book/
[pto]: ???
[pto]: http://hugin.sourceforge.net/docs/manual/PTOptimizer.html