Hello, all. I had the pleasure of meeting Ed Nisely recently. He’s an experienced engineer and was kind enough to take a look at the v2 Kinograph designs and offer his ideas. I’ve tried to capture them below along with my thoughts. Let me know what you think!
1. Drive system (motors, etc)
In a nutshell: get rid of the tension hubs and replace the direct drive design with a friction drive.
I will admit, I did not see this coming. I have been quite confident in the motor design thus far, but once he pointed it out, Ed awakened a small voice in me that has been saying since the beginning: “This PID feedback loop isn’t quite right and it’s a pain to tune.”
Ed’s point is that simpler is better. His reference is a reel-to-reel tape machine, which often used a friction drive to achieve the very same things Kinograph is trying to achieve.
Also, because PIDs loops have to be “tuned” to be good at what they do, that means that every owner of a Kinograph would (at some point, maybe) have to tune their machine’s PID loops, which is intimidating for anyone without an interest in tinkering with machinery and code. We could write some kind of auto-tuning routine, but as Ed said to that idea, “There lies madness.”
By removing the PID we reduce the complexity (physically and mathematically) of the system while achieving the same results.
I think the idea is interesting enough to merit a test to try it out. What do you think?
2. Getting constant linear speed at the capstan drive
In a nutshell: use a flywheel
Again, Ed reached for simplicity in this solve. By adding a flywheel, we smooth out the torque of the motor and, in Ed’s words, “make it expensive to change our speed.”
I think it’s a great idea and won’t cost much to implement.
3. Frame detection (or, when to take a picture)
In a nutshell: use a simple sensor and you have all the data you need
If the flywheel is giving us steady linear speed, then we can make some calculations based on when we sense perforations. For the sake of argument, let’s just say we have a sensor set up that works and accurately tells us when it see’s a perforation. If we know the circumference of the capstan’s PTR roller, and we know how frequently we are seeing perforation holes, then we should be able to calculate the distance of film we have traveled at any given time.
Let me put it another way. We know the circumference of the PTR roller. We know the length of 1 frame of film (depending on your gauge, aspect ratio, etc - which the user can input into software), and we know the distance between perforations. Of course, the film may have shrunk or warped, so we start with the assumption that it is perfect and all lengths are standard. Then, as we begin scanning, we measure the actual distance between perforations (# of perfs over time on a known circumference length) and then make adjustments in our calculations as needed. More perfs/second than we anticipated? Film must be shrunken! Shorten the time between captures!
As for missing or damaged perfs, we can try out different averaging algorithms that allow these to be ignored.
Lastly, in order to know how far the PTR has rotated, we will need to install an encoder.
I like this idea a lot and it gets rid of any computationally expensive CV during the scan and would greatly reduce the amount of CV required at the end if we were to go with my latest idea.