Note wrong lens in 2016-09-25 pi-pan-tilt post; part 2 draft

This commit is contained in:
Chris Hodapp 2016-10-04 14:55:21 -04:00
parent 2e7c7dc8e3
commit a70665b03f
2 changed files with 53 additions and 0 deletions

View File

@ -55,6 +55,11 @@ run:
[![My shot's not slanted, the ground is](../images/2016-09-25-pi-pan-tilt-1/IMG_20160918_160857.jpg){width=100%}](../images/2016-09-25-pi-pan-tilt-1/IMG_20160918_160857.jpg) [![My shot's not slanted, the ground is](../images/2016-09-25-pi-pan-tilt-1/IMG_20160918_160857.jpg){width=100%}](../images/2016-09-25-pi-pan-tilt-1/IMG_20160918_160857.jpg)
(*Later note*: I didn't actually use the 25mm lens on that shot. I
used a 4mm (or something) lens that looks pretty much the same, and
didn't realize it until later. It's a wonder that Hugin was able to
stitch the shots at all.)
The laptop is mainly there so that I can SSH into the Pi to control The laptop is mainly there so that I can SSH into the Pi to control
things and to use [RPi-Cam-Web-Interface][] to focus the lens. The things and to use [RPi-Cam-Web-Interface][] to focus the lens. The
red cord is just Cat 6 connecting their NICs together; the Pi is red cord is just Cat 6 connecting their NICs together; the Pi is

View File

@ -0,0 +1,48 @@
---
title: Raspberry Pi pan-tilt mount for huge images, part 2
author: Chris Hodapp
date: October 4, 2016
tags: photography, electronics, raspberrypi
---
In my [last post](./2016-09-25-pi-pan-tilt-1.html) I introduced some
of the project I've been working on. Those of you who thought a
little further on this might have seen that I made an apparatus that
captures a series of images from fairly precise positions, and then
completely discards that position information, hands the images off to
[Hugin][] and [PanoTools][], and has them crunch numbers for awhile to
derive *the very same position information* for each image.
That's a slight oversimplification - they also derive lens parameters,
they derive other position parameters that I ignore, and the position
information will deviate because:
- Stepper motors can stall, and these steppers may have some
hysteresis in the gears.
- My pan and tilt axes aren't perfectly perpendicular.
- The camera might have a slight tilt or roll to it.
- The camera's [entrance pupil][] may not lie exactly at the center of
the two axes, which will cause rotations to also produce shifts in
position that they must account for. (More on this will follow
later. Those shifts in position can also cause parallaxing, which
is much more annoying to account for.
[No, it's not the nodal point. No, it's not the principal point.][npp])
That is, the position information we have is at best a guess; it's not
sufficient on its own. However, these tools still do a big numerical
optimization, and a starting position that is "close" can help them
along, so we may as well use the information.
- We're using Panotools and our apparatus together; they can
cross-check each other.
- Our position info also turns readily into a .pto file which Hugin
can visualize.
[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
[25mm-lens]: https://www.amazon.com/gp/product/B00N3ZPTE6
[Hugin]: http://wiki.panotools.org/Hugin
[PanoTools]: http://wiki.panotools.org/Main_Page
[entrance pupil]: https://en.wikipedia.org/wiki/Entrance_pupil
[npp]: http://www.janrik.net/PanoPostings/NoParallaxPoint/TheoryOfTheNoParallaxPoint.pdf