Loading
klakar

GoPro Hero3 Panorama Rig - No-Parallax

by klakar Jan 5, 2015
Download All Files

Thing Apps Enabled

Please Login to Comment

Hello,

would you, please, share also FreeCad files? I would like to modify the goprobas.stl for stepp motor. 28BYJ-48.
Thank you very much. Leon

Don't Print it! Or remake a model by you own!
minus
1) It has HUGE parallax problems on pan axis.
2) Gopro prame is in contact with lower (pan) motor. Need remake.
3) Wires all outside out. Electronic with battery must be on the upper (moving side) to have no problems with twisting wires.
4) ABS print is to loose and not acurate. May be need to make wider or some parts from PLA.
Plus:
1) May be a good starting point for total remake.

What do you mean "I haven't figured out everything my self yet, and I'm not a 100% sure the rig is completely parallax-free."
???Why to to upload something without to be shure it's working and name in such way?

It works just fine! The statement is in part a reference to a complete electronics package, which I will not publish on thingiverse, and partly because it's very hard to be 100% certain of anything! Especially issues of no-parallax. The key is to get the lens nodal point exactly in the same location in every single frame! This is very hard to measure without some serious lab equipment. You will also take into account the low accuracy of the production process when it comes to 3D printing. It is not a multi million dollar CNC machine that has produced parts with nano meter precision! So, even if the rig works just fine for me and produces perfect spherical panoramas it doesn't mean it will for you.

Hello, this is nice project.
What about to combine it with: http://www.thingiverse.com/thing:1728791. It would create full control panorama maker with GoPro controlled by micro controller Wemos through WIFI.

Full automatic 360 panorama V2
Comments deleted.

Ah.. i see.. so your not running any code on the gopro?

my idea was to run a script using the autoexec.ash hacks.

that way you can tell the camera to control the robot..

(macro code)
set camera to "photo mode"
Lock the exposure.
take a picture
blink led to move robot..
repeat x n

probably something like this code... 100% UNTESTED!!!

t app appmode photo (gopro in picture mode)
t ia2 -exp lock 1 (lock exposure)
sleep 2
t app button shutter PR (take picture)
sleep 1
t app led red_top_bottom on (turn on LED)
sleep 1
t app led red_top_bottom off (turn off LED)
sleep X (custom delay for robot movement)

havent figured out how to do a "For loop" yet. but i guess you can just write it out for the amount of pics.?

i guess a photo resistor works. but i would use a Photo transistor gives a really clear digital signal..

i have been playing with a script that looks like this tonight..
might be of interest to you

t app appmode photo #set camera in photo mode
sleep 2
eval
t ia2 -exp lock 1 #Lock Exposure
t ia2 -ae off #Auto exposure off
t ia2 -af off #Auto focus off
t ia2 -awb off #AWB off
t app test vin_rotate 270 #Rotate Picture 270 degrees
t app white_balance 3000 #force White Balance

t app white_balance 5500 #force White Balance

t app white_balance 6500 #force White Balance

t app fp_show 4
t app fp_string 'ROBOT' #Print to LCD
sleep 2
t app button shutter PR #push shutter button
t app led red_back on #LED ON
sleep 1
t app led red_back off #LED OFF
sleep 3 #delay for robot movement
t app button shutter PR
t app led red_back on
sleep 1
t app led red_back off
sleep 3
t app button shutter PR
sleep 1
t app led red_back on
sleep 1
t app led red_back off
sleep 3
t app button shutter PR
sleep 1
t app led red_back on
sleep 1
t app led red_back off
sleep 3
t app button power P #Turn off camera
sleep 3
t app button power R

i'm working on doing something just like this.

my current robot is using a Canon P&S camera running CHDK
https://www.youtube.com/watch?v=TWPbzo4Mfio

its using a Lua script to lock exposure. and the robot waits for the camera to blink an LED when the picture is done
that way i can have pretty low latency.. takes only about 35secs to do a 180x360 at normal exposures
i can do HDR's and Long exposures for night too

i'm interested in your idea of running the script on the gopro. and similarly use the LED to
trigger the robot motion..
how would a script like that look for the gopro ?

My code is just looking for changes on the analog port the sensor is connected to, and if triggered advance the sequence one step. All that remains is to find the right intervall for the time-lapse in the GoPro so the next photo isn't taken before the move is completed.

There's ample examples of analog input in the Arduino IDE to play around with and modify to suite your specific needs.

I've now tested the rig for parallax errors, and it seems to be pretty parallax free.

In one of the photos there's a photo with five close-ups with the target att center and the camera moved up/down, left/right.

The fork is at 3 meters and the newspaper at 11 meters.

@fma

I haven't got the exact values for fov or the nodal point. At the GoPro site (http://gopro.com/support/articles/hero3-field-of-view-fov-information) you can find values for the Hero 3+, and the standard 3 is very close, at least for still photos. The 3+ has a superwide mode for video, that is a bit wider.

I created the rig by observing the lens while rotating the camera. Since I only built the rig yesterday, I haven't tested it fully, and some adjustments may be required. The actual nodal point may also vary depending on the selected fov, so my my estimations for now is just that, estimations.

In an early prototype I oriented the camera vertically, to cover more space vertically in simple panoramas, but I then decided I wanted to use the rig in other applications (ex: FPV) and a horisontal orientation would be better. A diagonal orientation may be better for spherical panoramas (fewer required shots, but truthfully not that much overlap), but pretty useless in other cases.

I think I'll get away with 9 images at the widest setting of the camera. Four at +45 deg inclination, four at -30 deg and finally one straight down. The optimal case would be to have eight images not necessary to mask in Hugin, and a ninth handheld photo to cover the last 10 deg (est).

I use Papywizard for my Panogear DSLR rig, but recently I've tested an Android version to control it (PandroidWiz). I haven't tested the Pololu module. Is it stand alone, or does it require a computer or, controlling microprocessor (i.e. arduino/raspberry pi).

I think I know how to retreive exact fov values of the Gopro: when assembling a pano, APP/APG gives all parameters. It has to computes them to make the pano.

Polulu maestro module can operate in standalone mode: it has a script language (https://www.pololu.com/docs/0J40/6.a). I never tried it, but I'm pretty sure it can do the job. Your idea to use the Hero as master, with the timelapse mode, is really clever, and could be used with the Pololu module, which has input mode (https://www.pololu.com/docs/0J40/4.e).

Nice! I own a Hero3, and would like to build such panorig for a long time.

Do you have information about precise fov of the Hero3 (h and v)? And about the nodal point? I'm wondering if we could rotate the camera so the image diagonal is vertical, to minimize the number of pictures needed to do make a full sphere...

BTW, I'm the author of Papywizard (http://www.papywizard.org), a panoramic application to drive motorized panorigs. I made a similar servo-based panorig, for DSLRs, using (bigger) servos, and a Pololu maestro module, which is supported by Papywizard.

Now there's an optional GoPro mount that enables almost any camera orientation...
Just get the goprolight.stl

I think I fixed the misalignment of the gears by redesigning two parts...

Should be ok by now in the STL-files.

Comments deleted.