Adi Soffer

I sure hope so.

On the right side, featuring 4 LED buttons and a jogger, you can see the remote sending unit - - 

On the left is the receiving module that will reside next to the camera and will control the stepper motor. Preliminary 3d printing tests are being conducted as I type and soon pictures will be posted! 

If indeed all parts (Nano, Xbee, EasyDriver, LipoRider, Battery) will fit in nicely, I’ll need to decide where the final printing will take place and what will be the technique/materials used.

These are exciting days. 

It’s so much fun to go from this:

To this:

The circuits are finished, and both have a nice backside :-)

Next stop CNC to create and test the casing.

Updates soon.

…I hope…

Moving forward: the receiving end incl. Nano, Xbee, and the EasyDriver. It’s just construction now. No small matter though :-)

- - that It’s done. Wireless stepper motor, optical encoder Follow Focus with lens calibration and user controlled speed.

After all these months of not having a minute to finish this, I was quite intimidated by my own project… Seriously. But all the parts arrived and I had a few hours and I looked at my code again and things began falling into place again, and I could (contrary to all my fears) figure out all that I’ve done up until my (too long) break.

And so I’ve added the lens calibration function, and soldered and tinkered with my lipo rider to get it to like my battery and now it actually works.

I hope to find a few more minutes next week to clean up the code, and then it’s packaging time: finishing the design of the various parts, 3d printing prototypes, blah blah blah…

(I do have a small itch, and that is to add a circular LED ring around the optical encoder, just to make things even more refined and friendly, but this will again take more time. Should I…?)

Almost everything I need to finish my project has arrived by mail. Only waiting for 2nd Liporider, and yes — would love to be able to mail order some extra time…

The parts stare at me and wait…  

Oh, the daily silly, stupid, dumb, foolish, rash, erroneous stuff I do when trying to find my arms and legs in this field which is still fairly new to me.

I thought I should share the various embarrassing things I do and surely will repeat simply because — it’s OK. I keep telling myself it’s all a major part of learning, and most of a the time - except for hitting my forehead with my hand and sounding the all familiar Homer sound signalling frustration at myself  - I just crawl out of the other side just a bit more experienced.

So here’s a short list which will no doubt grow in time:

1. Miss a hole in the breadboard: Only a few days ago did I seek help in trying to find what’s wrong with my Xbee module. It simply sent but never received. Was I to learn the secrets of API for this function to work? What was wrong with my module? Well, 0.1 inch is a short distance to err. I simply put the wire in the wrong hole and so the data that indeed was received, never made it to the arduino.

2. if (x=1); Oh Hell! Only after repeating and correcting this error for about 20 times did It burn into my mind to use ==. The mess this small error creates is maddening.

3. What? Is my board going crazy? No. Actually it’s the battery that’s dying and messing around with the board. LED’s not working, servo moving erratically, the list is long but the outcome is the same: I simply want to throw the entire project out of the window. Instead I out a new battery and move forward to my next mistake…

4. Wrong port, wrong board - avrdude isn’t happy. Need I say more?

5. Never leave a stripped wire unattended. This is obvious right? Think again.

6. Trying to program the board when the Xbee is connected will never, never work. No matter how many times I’ve tried, trust me - It never works. Nor should it. Simply disconnect the damn thing before uploading the sketch. 

7. This one’s a pain and took some time figuring out: when using Serial.print for debugging, Serial.write goes crazy! It’s a problem for a beginner such as myself and the values that are being sent go simply crazy. So don’t.

I suspect I shall add a few more later on, and would appreciate a contribution here. So be my guest and embarrass yourself as I did, and maybe along the way help an innocent beginner avoid some mind-wrenching time-wasting nerve wracking errors.     

Since this library (AccelStepper) is nothing short of amazing, writing the code turned out to be quite a breeze.

I’m still no contestant for the most stylistically inclined coder so be warned. Still, I think I’m getting better at this…

Next stop - wireless which is quite messy. Previous prototype had values of up to 180 sent over Xbee; no problem for a simple byte sized Serial.write. This time I need 2 bytes and I’m going deeper into the bitwise operation. I wrote I kind of liked it, right? Now it seems to get back at me with a vengeance…

Anyway - here’s the code…

Code

Update:

Things are looking good. Every minute I’m able to steal is dedicated to working the code. Another library is included (oneButton) to simplify the button operations and it seems to be working fine. I had to edit the lib itself for some timing issues and it feels responsive and good. I’m also refining my style, using function, cases and Booleans in a more elegant way. 

One other thing I’ll need to add to my vocabulary is the “sleep” function and usage of pins for the stepper. This will make the unit save more power as well as not get too hot. Came across this guy’s blog and hope to figure out this function and implement it.

Here’s where the code is now:

Code

People can be so great. Have you heard about bildr.org? You should visit this great blog if you find arduino interesting.

So what’s my point?

Researching optical encoder, arduino and stepper, I came across bildr’s tutorial “Rotary Encoders and Arduino”. I figured out some things thanks to that post, and was left with some new  - more refined - questions. I happily posted my questions there, specifically wondering if there is a way to create a modified “knob sketch” using a stepper and an optical. Soon enough I was answered by Adam, who happens to be the founder of bildr, saying that this seems like an interesting query, and that my project seems interesting enough and well —- “awesome” — so he’d gladly help. Is this great and awesome, or what? e mail correspondence ensued and I was delighted to learn of a library called AccelStepper that helped me get to the desired goal, as is visible in the video.

The code is fairly simple once you understand that steppers are so much different than servos. I admit I had to check, recheck, ask, research until I finally figured what the hell was going on there. But that’s what friends are for, right? :)

I’m posting the code and finishing this with 3 important notes:

1. I had to push up the baud rate or else Serial.print delayed the hell out of the motor. Serial.print will be replaced with Serial.write for the Xbee, and so had to be checked early on.

2. Check out the void updateEncoder() function. This is the first time I understood what all the “bitwise operators” talk actually means, and I find it simply beautiful…

3. I will now proceed with the implementation of the various modes for the follow focus. I suspect I’ll have some issues and problems along the way, but otherwise there would be no sense of accomplishment, right? 

Code

One optical encoder

One stepper motor

One easydriver

And a whole lot of mess.

Am I really back to square one?

Well, on the one hand - no. When I began this project (29 Feb, just checked. That’s less than 6 months ago!) I had no idea what I was getting myself into. No knowledge in programming, the art of soldering or electronics, nor any info about the different arduino models, shells, motors, circuits and tweaks. The most important thing I had no clue about, was the supporting community that is both absolutely necessary and no less just plain good old fun. 

So now I have a better idea of what I’m doing and where I’m headed.

But on the other hand… Optical encoders work in a dramatically different manner than simple potentiometers, and stepper motors are a far cry from your average servo… And this makes me feel like a complete ignorant once again!

So why bother if my Follow Focus project already works? Well, because I want to make it better! More accurate, less noisy, more professional and really really complete. I want to refine some functions, and dump other functions; I want to make the user interface consistent and fool proof; I want to design its casing and make it as comfortable and usable as it can be; I want to be able to hand it to someone and watch him/her operate it without too much messing around. In short, I want to make it as close to perfect as I can. 

And of course, I’m once again enjoying making myself jump through hoops…

Back to work. 

And if that should ever happen to you, I hope your Ebay seller be as nice as mine and send a replacement board. :-)

Now X-CTU recognizes the XBee modules. 

Yep, here are the circuits for prototype V2 made as designed on the Fritzing. 

First is the sending unit containing the Nano, Xbee and the circuitry required for the switches, LEDs and potentiometer. Of course both the arduino and the Xbee are not soldered directly onto the board; instead, on both boards these parts are fitted into place with some headers.

It’s time to begin and design the internals. These should be small, sufficient and feeling less feeble and temporary…

I’m using Fritzing for these preliminary designs and will probably use a more professional friend for the soldering - since now it’s 0.1” time… 

This is the Follow Focus sending unit, packing an arduino nano, Xbee S1 and all the wiring and resistors for the LED switches. 

And here’s the receiving unit, handling an additional power source for the servo.

Why the Nano you (should!) ask? Why not use a ATmega chip and save the costs? Because this is still a prototype, albeit an advanced one (v2!), and I guess I will meddle with the code some more; it would be a waste of time to do this any other way.

What do you think? As always your thoughts ideas are more than welcome.

The Xbees do notice each other, but I’m not sure they’re speaking the same language… Will I have to use X-CTU? According to some, not at all. According to others - hell yeah. 

Here are the links to the Receiving and Sending ends of the Follow Focus. No matter what data I send, I receive values of 52-49. See if you can help me find what’s wrong with this picture…

Sender code.

Receiver code.

UPDATE: the infinite loop of learning strikes again. Check the comments.

:-)

The XBees are finally talking to each other.

And the lesson is: Take your time to read what the different LEDs mean, goddammit!

RSSI is just for receiving, and not for sending!

I finally took an advice and skipped the USB exploring procedures, wrote a simple code for randomly sending data, connected 2 XBees (one to an UNO, the other to a Nano), and watched in awe as the RSSI LED came up upon receiving data. Then I switched the data flow and voila - the 2nd XBee RSSI LED lights up!

Yes, it’s so much simpler than I had initially thought, and that’s exactly why I got tangled up.

Now it’s time to adapt my original code and move on (to the next head banging riddle).

Later I’ll explore the USB conundrum…

:-)

I think it’s important to remember that moving forward involves quite a lot of leg work..

It’s not that I have made further progress in my project that I wish to share; quite the contrary. It is actually the “backstage” part of the progress that I wish to share: the frustration.

See this little cutey here? It’s driving me MAD! It’s not doing what it’s supposed to do and so I’m left staring at it in total bewilderment and frustration. No doubt an achievement of engineering, this little fellow was supposed to arrive and work its magic and not make me labor for it, right?

Well no, actually. Wrong. 

I’m trying to push my project forward and that involves adding some new variables and learning new stuff and the most obvious outcome is a momentary standstill. Or at least an apparent standstill. Because even when one is busy banging his head against the wall - or in my case wishing this damn thing to work as imagined - new information is gathered and internalized; and that info is sometimes relevant to the core of the problem and sometimes peripheral and it will come in handy now or later on. And this is quite contrary to what the definition of a standstill is.

So this post is both for me and for the reader; a reminder that behind all finished pictures and working codes are hours of (healthy) frustration and wrong turns.

I think it was Thomas Edison who said “I did not fail. I just found 10,000 solutions that do not work”. 

Wow. This is such a great speech. Don’t miss it.

slartibartfastibast:

Chris Anderson, “The New Industrial Revolution,” 4/10/12 International House @ U.C. Berkeley (by IHouseberkeley)

Smaller than I thought, cute and adorable, I find myself simply in love with the 2 XBee modules that arrived today.

The one funny thing that ordering on the net makes is that the delay between paying for something and actually receiving it makes you feel like you just got a present. No - you did paid for it…

But look at the small modules that will free my follow focus from the shackles of the wired past! As I said, I’m now in the process of creating the next prototype of my FF, and one of the steps is going wireless. A fellow arduinian mentioned that using XBee modules for such a simple project may be an overkill, but I’m aiming high with the parts, the design and the details. I’ve ordered nice little led switches

and am waiting for the 2 XBee breakout boards to help me connect to my arduino nano.

In some blogs it sounds fairly easy to “plug and play” wireless, and on others it seems more complicated; but I guess it’s just a matter of time and patience - I need to adapt the code and enjoy once again the endless loop of challenging oneself - and meeting the challenge. 

:-)

I’ve been asked by my fellow arduinians to post a few pictures of the Follow Focus box itself, integrating the different parts. This I do with pleasure mixed with some embarrassment… I find the visual side of things to be most important but since this my 1st project ever, I could not bring this sensitivity to the aesthetics come to completion. Indeed I’ve drilled and cut 3 boxes before this one, only to understand that this is my prototype v0.1… Ugly and cumbersome, but working! :-)

I post these pictures only because I can also post a preliminary sketch of what I intend this project to look like in its next version. As always, I’d appreciate your thoughts and ideas.

 This then is the box from outside. Each switch has an LED assigned to it, signaling the different functions:

The servo connects to the power and data with a stereo PL connector:

Finally, here are the guts of the project: Arduino mini on its breadboard, a rocker switch, the LED and switches circuits, and left (hidden in some shadow) the voltage regulation circuit for the servo. 

The way the servo connects to the camera was shown at an earlier post, as well as some close ups of the different circuits. 

And now for the fun part. Some sketches of how the FF could end up looking like:

Indeed, I have some plans.

This seems like a good time to end this post. 

Any thoughts?

:-)

I’ve created a short video demonstrating the FF in action.

If you’ve followed the previous posts (parts 1 through 4), you can now see the different parts in action. I’m happy to say that it works fantastically, a fact that does not stop me from furthering the design and build, because, as I’ve stated earlier, this is a work in progress and that’s actually the really great thing about it.

Hit “read more” and (I hope you’ll) enjoy. There are some conclusions at the end of this post obviously.

What do you think? Any suggestions or comments?

And what now, you ask?

First of all I have ordered some Atmega chips to create a smaller, more professional version, and am also working on a more aesthetic and handy configuration for the whole thing. I have a most generous friend who’s helping me out with designing a custom box for the whole thing - actually something that is a far cry from the “box” I’ve used for now. Check out her blog and her beautiful works here.

I’m also doing some research about stepper motors which are more silent and could have a higher resolution. Although “staircase” effect is not visible with this particular lens, I think it may pop up later on with different lenses and slower pulling. Of course stepper motors are a whole different ball game in terms of coding so I’m really trying to figure out as much as I can before jumping in. Any thoughts are more than welcome.