New Product: clickPAN-SDM



  • I will try that tonight. Unfortunately, the G9 and G11 are the only SDM compatible cameras. I do have a SD900 that is running a beta port of CHDK, but no SDM for that yet. I will be around all weekend, and can start testing tonight. Otherwise, I can get up early or stay up late to test when you're online. I use Skype, Gtalk, and Oovoo if you wanted to see what I was doing.
  • Mike,

    I have emailed you a version that works.

  • Thanks. I responded to your e-mail with the results. For everyone else who is sitting on the edge of their seat...

    The new version of SDM for the G9 100j works perfectly now! I get the auto-focus lamp to illuminate with the clickpan-sdm scripts. Unfortunately, my clickpan-sdm device still does not move the servos, so I think that I'll send in for a replacement. Thanks David for putting in the effort to help me. I'm confident that we'll get the G9 and G11 working with this!

  • I received a clickPAN-SDM from James yesterday and have been able to get a pan/tilt/shoot script working on my rig, which has a 360 degree pan servo. The exact same script is working perfectly with both my SD870 and with my A570.

    Only two things didn't go smoothly during setup.

    1) Getting power to my clickPAN-SDM. Both my battery box and the clickPAN-SDM had male connectors. James did include an adapter which was female on one end and seemed to have a male connector in the other end with bare black/red/white wires attached. I thought I could remove that male connector with wires and just use the adapter as a female/female, which would have been perfect. I was unable to remove the male connector from the adapter, however, and didn't want to pull any harder than firmly, so I ended up soldering the bare wires to another 4AAA battery box. My soldering skills are absolutely atrocious, but after a short while I finally got a good connection. If possible, it would be nice to be able to choose the ideal connector type, male, female, or bare wires, when ordering the clickPAN-SDM.

    2) SDM's default mode is for Stereo shooting which requires synchronization of 2 cameras, so the shoot command doesn't work properly for our purposes until synchronization is turned off. I accomplished this by adding the statement "Sync_off" at the beginning of the :init portion of the script.

    Once everything was working properly I also added a "turn_backlight_off" statement to the :init statements to turn off the LCD between shots and conserve battery power.

    SDM, the clickPAN-SDM, and the scripts (with accompanying scripting documentation) are all fantastic bits of engineering.....a veritable "TRIFECTA".

    David, James, and Dave, absolutely fantastic work. My glass is raised to you!!
  • To Michael, you've jumped past me already in your progress. My rig is finished and I am reprogramming the 360PT.bas for my needs but keep getting myself confused. I did find one questionable statement, "V = u". "u" is not defined anywhere so I'm puzzled what V really needs to be set to. (That command doesn't match anything in the other samples as far as I can see.)

    Also, thanks for the two initialization commands, the "Sync_off" will probably solve my program's slow performance. I knew about turning the backlight off but still need it for debugging.

    It's fun watching the rig dance around on the pole in my office when I "rem" out the "shoot" command for testing. Unfortunately, it's doing the foxtrot and I wanted the samba.
  • PokyTom - that's a bug - the line should be "V=h". In an earlier version of the scripts the 'h' parameter was 'u' and I obviously forgot to change it. Will update the web zip asap.

    And Michael's right - that "Sync_off" (or turning sync off in the SDM stereo menu) will speed things up - it cuts out the 10 second timeout wait for a sync signal! I'll add a note about it in the "init" routine section.
  • Dave,

    Turning sync off in the SDM Stereo menu only works while the camera is on. Once it's turned off it reverts back to sync enabled. If there's not a way to make the menu setting hold until changed, I think it's most foolproof to have the "Sync_off" staement in the script.

    Poky, The only things I changed in the script were the servo calibration settings, and adding the sync_off and turn_backlight_off statements . Looks like you're going through it line by line.
  • Yep, that's me! Line by line. Whatever trouble I'm getting into is my own fault. But I'll be ready for "Dancing with the Stars" when I'm done. :-)
  • Yes, 'sync_off' needs to be at the start of all KAP scripts otherwise users will complain it is taking a long time to take the photo.

  • edited April 2010
    Then I should definitely add it to all my sample scripts. (New version of the zip has just been uploaded).
  • I finally finished my pole rig for the click pan-SDM controller and my first program. Of course, the program will still get some tweaking as I learn how it actually behaves in the field.

    I've loaded a picture and a short video of the rig on Flickr:
  • Looks great Tom! Looking forward to some great PAP images and panoramas!
  • I'm still finding it quite surreal that my camera is controlling the servos.......
  • Plus, you are controlling everything through a uBasic program of your own design! That's liberating.
  • Excellent work Tom - the photos and video really explain ho it all works. Can I have your permission to put a pointer to your images (and even a copy of your script) on the clickpan-sdm scripting page?
  • edited April 2010
    Michael - just a quick note about power connections. If you buy the sort of R/C switch used on model planes you'll find that you can plug the battery in one side and the click-PAN-SDM the other. They also have a spare plug that lets you plug into a battery charger. Having a switch to turn the clickpan-sdm on and off is no bad thing anyway - saves pulling plugs out. See my rig here.
  • ...and more on power...

    The unit is supplied with a "servo" type plug, this means the unit can plug straight into a RC receiver if you want to design a rig that does autoKAP AND RC KAP - A challenge for someone?

    Apart from a few early shipments units ship with a servo socket to wire-end adapter that allows you to solder up your own battery box like Michael above.

  • James, is there any chance of also including an optional female-female adapter? It would match up nicely with the excellent compact 4AAA battery boxes with switch that Brooks sells, which also have a male connector.
  • Michael and James, I just stripped back the wiring on the provided socket, twisted it with original wires and covered it with electrical tape. It isn't pretty but it works. I would have preferred to do no splicing.

    I will post my script here shortly and yes, James, feel free to link to my pictures and/or use my script (and modify it for any purpose).

    Remember, my rig and script are untested in the field so I fully expect to make programming changes. One area of particular interest is the amount of sleep time between moves and photos. Another is the amount of sleep time to start the program to allow getting the pole in the air and stabilized pointing at my subject. And, finally, my script currently allows continuous looping so that I can do matrices of pictures from multiple viewpoints. I'll need to tweak the sleep time at the end of each matrix that allows me to move the pole to the next location. Of course, most of these pauses will be parameter-controlled rather than hardwired into the script.

  • Here is my script as it is right now. Later, I will explore changing the "shoot" command to one that waits for the camera to be still.

    rem Photo matrix for poles script for ClickPAN-SDM
    rem by Tom Gautier, April, 2010
    rem "Code" refers to the specific servo reading.
    rem "Angle" refers to the human perspective.
    rem I assume one step in code equals one step in angle.
    rem This script is for inverted tilt code values.
    @param a start tilt angle
    @default a 0
    @param b end tilt angle
    @default b 90
    @param c tilt angle step
    @default c 30
    @param p secs to start
    @default p 60
    @param q wait after moves
    @default q 2
    @param r # pan steps
    @default r 5
    @param s pulse str. (1-10)
    @default s 5
    @param t pan pulses
    @default t 2
    @param u pan dir. (1,-1)
    @default u 1
    @param z take picture
    @default z 1
    rem Pan arc movement is set by r, s, t, u.
    rem f tilt up limit code (servo specific)
    rem g tilt down limit code (servo specific)
    rem e tilt origin code (servo specific)
    rem z allows rig testing without pictures
    rem i = incrementer
    rem j = incrementer
    rem x = pan value to get to starting position
    rem y = calculated tilt position

    f = -100
    g = 90
    e = 30
    if z <> 1 then z = 0

    gosub "init"
    gosub "setcodes"

    while 1
    rem Matrix loop
    gosub "home"
    for i = 1 to r

    rem Tilt loop
    y = a
    while y >= b
    send_data -128, y
    gosub "photo"
    y = y-c

    rem Pan to next position
    for j = 1 to t
    send_data S, -128
    next j
    sleep q*1000
    next i

    sleep q*1000



    if z = 1 then turn_backlight_off
    rem park tilt servo
    send_data 127, 123
    sleep p*1000

    a = e-a
    b = e-b
    if a < f then a = f
    if a > g then a = g
    if b < f then b = f
    if b > g then b = g
    if a < b then a = b

    rem Photographer points rig at center of subject.
    rem Rig then moves to one side to begin
    rem shooting and works its way to the other side.
    rem of the matrix.
    x = r*t/2
    if s < 1 then s = 1
    if s > 10 then s = 10
    S = (100 + s) * (-u)
    for i = 1 to x
    send_data S, -128
    next i
    S = -S

    if z = 1 then shoot
    sleep q*1000

    Have fun!
  • It was a nice afternoon and there was a good breeze, so I thought I'd try my first field test of my clickPAN-SDM rig. I attached the camera to the rig while I was still home, switched on the power, and started the camera script. The camera started shooting but the servos didn't move. After making sure that I was running the correct script, I checked to make sure the clickPAN-SDM was getting power. The servos weren't twitching each time I supplied power, so I figured it was my crummy soldering skills. I got out the soldering iron and did a better job of re-soldering and taping the connector to the battery box. I reconnected the battery to the clickPAN-SDM and tried again. Same result. I turned off the power, then turned it on again repeatedly. The servos again only twitched some of the time when supplying power. I turned on the camera and ran the script again to make sure it was running properly and that the autofocus assist lamp was flashing properly. Everything seemed to be in order. I disconnected and reconnected the servos to the clickPAN-SDM, checked the battery connections again, made sure the optical sensor was velcroed in front of the AF assist lamp, etc. I got the same result when restarting the script: camera shooting, but no servo movements. While the power was on, I gently wiggled the various connections, thinking there might be a loose connection. Still the servos didn't move.

    I turned everything off for a few minutes, then tried once more and the rig started working perfectly. Strange! So I grabbed my gear and headed off to the park around there corner. I launched the kite, and attached the rig and everything worked perfectly for about 35 minutes. Success!

    I went home and looked at the photos and recharged the batteries. Afterward I tried the rig and once again the camera began shooting but the servos remained stationary. I then got out the voltmeter to confirm that the voltage coming out of the battery box was correct. It was. I turned the switch on and off repeatedly and the voltage was always good. I then started playing with the placement of the optical sensor over the autofocus assist lamp and the servos started working, but only sometimes. I started thinking that the wire connections to the optical sensor were intermittently failing. I then held the optical sensor about half a centimeter from the AF assist lamp and angled it so that the light from the AF lamp reflected off the optical sensor directly into my eye. Each time I saw a strong flash, the servos moved properly. I then tried to place the optical sensor above the AF lamp, attached by velcro, and the servos stopped moving. After repositioning the sensor over the AF lamp, the servos started working again. I was still not totally convinced that the problem wasn't a faulty wire connection at the optical sensor, but after repositioning the sensor above the AF lamp many times and restarting the script, everything now seems to be working properly every time.

    I'm fairly surprised that the placement of the sensor is so sensitive, because I had absolutely no problem with this when I first started using my clickPAN-SDM during servo calibration and script editing and debugging. It's possible that the velcro has become fuzzier from the sensor being attached and removed, and that this is contributing to the problem. Maybe the velcro needs a bit of a shave? Now that I'm fairly sure what caused my problems, I'm a bit concerned that the once the rig is started and working properly, the sensor placement is so delicate that a small shift while airborne might result in a failure to move the servos.

    Any advice would be appreciated.
  • The camera AF led is very directional and maybe the clickPAN_SDM sensor also is.

    That said, the AF led is very bright.

    As it did not work indoors, it cannot be due to very bright ambient light interference.

    You could try a tiny piece of some diffusing material like Melinex draughting film over the LED or sensor.
  • After going through similar problems with intermittent operation that turned out to be my poor twisting of wires, I have had no problems with the sensor sensing. I just "slap" on and go. Maybe it is a camera-specific sensitivity or maybe the velcro opening needs trimming. For me, everything is great, except for the snapped pole.
  • Snapped pole? Yikes. Which pole and what was the mode of failure?
  • Sorry to hear the sad news, Tom. Gotta start a new Lessons Learned thread.
  • The only lesson to be learned is "Don't be STUPID!". I am too embarrassed to completely describe the incident but it had absolutely nothing to do with the weight of the rig nor the design of the pole. Oh by the way, don't try to lift a 34-foot carbon pole by the skinny end.

    I snapped the section just down from the rig section. I may be able to jury-rig a splice. Obtaining a replacement section is probably out of the question. If I completely fail, I still have a 24-foot pole.

    This will not deter me from continuing the development of the click pan-SDM program I have been working on. However, it has heightened my interest in using click pan-SDM for KAP. Damn!
  • edited April 2010
    Tom, if I was a little more local I'm sure I could help you with a repair. Or maybe mail the section to me??

    If you want to try it yourself I'll see if I can find you some links to use the right technique and materials. You'll have to add a little bit of weight but I think you will be able to make the break stronger than the rest of the pole.

    I've been basing my work on DIY carbon fiber bicycle frame -- such as:

    The important thing is to have the right viscosity epoxy, apply compression equally, and wick or push away excess epoxy.
  • Wow, David, I really appreciate the ideas. I really wasn't considering a full-blown epoxy solution. My first two ideas are much more primitive. 1) Since the break is just above the lower joint, I'm going to see how far the longer portion will slide over the lower, unbroken segment. If it is acceptable, I may just reinforce the "new" joint area with strong tape and move on. 2) I may use an appropriately size and shaped wood dowel as an internal ferrule to join the two segments. With each of these options, I would lose no more than a foot of length. Option 2 would probably be stronger but add more weight. The weight of my rig is not a problem at all so far.

    I may also consider whether I ever want to lift this pole in its 34-foot configuration from horizontal to vertical and back. Avoiding that situation requires engineering a vertical stabilization system to assist me in assembling and disassembling the pole since I can't see myself singlehandedly (literally) holding vertical 30 feet of pole with camera rig on top while I reach for the next segment with the free hand. I envision something like a double tripod or a suitably adapted handcart. Mobility is still essential.
  • edited April 2010
    So it broke just above the overlap? I'd be happy to fix it with two thin new layers of carbon if you want (have all the materials handy), but you'd be out of a pole for the time of shipping back and forth.

    I was considering reinforcing around the overlaps on mine. I've been raising it from horizontal but I'm distributing the weight of my rig over 2 and a quarter sections. Still with wind gusts or lousy handling (a stumble?) I can see how the top might pop.
  • David, let's move over to e-mail.

    As for lifting, I found that I could easily lift (and lower) from the base of the pole, even at 34 feet. Walking the pole up may actually be riskier in terms of unexpected stresses. This is not how I broke my pole, however. I simply turned off my brain and tried to move the base of the pole into a ground divot--from the pointy end of the pole. Like I said: "STUPID!"
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion