Lens Motor for Red....

Curt already confirmed by PM. It will ship with all necessary gears and pitches, included in the price. And the weight can be lighter than that. Good news indeed!
 
Sounds great Curt, whilst you can't get into it too much do you have any rough estimates on how much the UWB system might end up costing? I'd be even more interested in the motors if I can see something like this at NAB even if it's just a very basic prototype, it would fit the philosophy of modularity that makes Red attractive.
 
Hi Curt

Is it possible to program in a custom transfer function so that the response to the remote contoller is non linear? specifically so that controlling focus on a still lens could be made easier with an expanded range where the range on the lens gets quite tight.

Martin
 
The new generation of wireless focus devices are changing the way you calibrate the units.

On old generations you would calibrate the device focus scale to match the lens. You did this by making knob marker rings for every lens, so when changing lens, you'd also change the marker ring.

On the "to be released" generation, you have a pre made ring and map the lens to the ring. When all lenses are mapped you just change the mapping presets on the hand unit when changing the lens. You don't change the marking ring.

This means that all your lenses will have the exact same spreading on the focus knob on the hand unit. Only the minimum focus distance will change.
You can also have different rings with different spreads.

I believe that Curt's unit is using a similar method...
 
But of cause the old generation will still spread a 90° degrees focus travel of a still lens into the >270° of the hand controller. this happens automatically when you (Auto)calibrate the servo for the lens.
All lenses will have the same spread Still or cine.

The good thing about the new way, especially in relation to motion control, is that after you have programmed the focus distances you can actually change the lens and still use the same keyframes. They should match since both lenses are calibrated to the device.
 
Last edited:
Martin and Anders.. yes, we will have a linearizing method for this system. When you first place the motor on the lens you have to press a calibration button that automatically finds the limits of the lens. Once the limits are known and you have a few key points to map the lens, the system will fuly linearize the slider on the controller to the lens. Like anders said, the cool thing about being able to do this is that you can exchange lenses and the feel of the control, the range, and the keypoints will be exactly the same. You can save that lens data and use it later or we were thinking of starting a lens database (which probably already exists somewhere) that you can download from to use on your setup.

One other thing to keep in mind is that we don't have a focus ring on our setup... its a slider. If demand is there we could make a rotary focus knob but once you try this out we hope you'll be hooked :) We know the slider for focus bucks convention but with a motion controlled setup it works quite well. Since the system can adjust damping and velocity all it needs to know is position. The look of the shot is determined by the profile that is user-programmed into the motors.

On future firmware releases we can take this concept a step further by having macros and filters that can be applied to the motion profile to add random glitches or a wavy feel to the shot. The skys the limit.

BTW, the remote has an OLED display that shows all the info that you could possibly want. As you adjust the focus/iris/zoom it updates the screen with the info. If you guys have any suggestions on what you would like to have in terms of user interface keep the ideas coming.
 
Last edited:
changed diameter to circumference...

changed diameter to circumference...

This relates to live use and not Motion Control use:

Well, display of and live calculation of DOF would be very useful and pretty easy to calculate if you map F+I+Z, and know the image gate size.

Multiple controllers would be great as well. Sometimes a focus puller will control focus while the DP would like to do ramps on the Iris channel.

Don't know about the slider, a large knob seems to be both more precise and space saving than a slider. The knob circumference of most focus devices seems to be around 20 cm, that would equal a pretty large and unhandy slider...

And lastly as little latency as possible. Some package based protocols introduce latency in the data buffer to prevent dropouts.
 
Last edited:
Hi Curt,

Is that system you mentioned for 5500 $ a wired one or is it already the wireless setup ?
In my opinion the slider-concept for focus control sounds interesting, I have the feeling that it could be more intuitve than having to turn a wheel. But that´s only my 2 cents
 
Anders Holck said:
Well, display of and live calculation of DOF would be very useful and pretty easy to calculate if you map F+I+Z, and know the image gate size.
Click to expand...
Should be fairly easy to implement. Ill start looking into that.

Anders Holck said:
Multiple controllers would be great as well. Sometimes a focus puller will control focus while the DP would like to do ramps on the Iris channel.
Click to expand...
All the axis of are mappable to multiple remotes, so splitting Iris and focus out to two remotes is easy. We are going to have a full-featured remote thats included but also offer another dumbed-down candy bar remote for handing off control of one axis. The other benefit to this smaller single axis remote is that we could make bar clamps so you could control the system while running solo.

Anders Holck said:
Don't know about the slider, a large knob seems to be both more precise and space saving than a slider. The knob circumference of most focus devices seems to be around 20 cm, that would equal a pretty large and unhandy slider...
Click to expand...
Point taken... its easy enough to add in a knob instead of a slider, its just difficult to make it work cleanly with our setup. We have position presets that you can press to have the motors goto a position with one button press - no turning anything. If you have a knob with markings on it then when the button is pushed you have a situation where the actual position of the motors doesn't match what the knob is set to on the remote. Next time you turn the knob the motors will have to rapidly traverse back to the knob position for realtime control.

Anders Holck said:
And lastly as little latency as possible. Some package based protocols introduce latency in the data buffer to prevent dropouts.
Click to expand...
I've run multiple axis on ethernet before and have found that as long as you keep the buffer small and don't run too many axis on the network there shouldn't be any problems. We will also have a number of safeguards in place that keep track of the latency/bandwidth/signal strength.

adaml said:
How much travel do you intend for the slider?
Click to expand...
The slider control currently has about 5 inches of travel. Its a capacitive sensor like the ipod wheel with the exception that ours works with gloves on. The whole unit will be ruggedized and water resistant. I have a few other concepts that might be better than the slider... I'll post some renderings and maybe you guys can vote on which one you like the most.
 
CVB said:
If you have a knob with markings on it then when the button is pushed you have a situation where the actual position of the motors doesn't match what the knob is set to on the remote. Next time you turn the knob the motors will have to rapidly traverse back to the knob position for realtime control.
Click to expand...

Two solutions that are common in pro audio equipment:

Motorized controls: if a 'quick button' is used to change to a preset value, the knob or slider moves with it. That way the relationship between control and lens is always kept.

Or instead of fixed markings use a ring of tiny LED markings. Then the marking would move to correspond.

Bar3nd
 
Yeah, I'm familiar with both of those.. I think a good compromise would be to have a virtual dial... an encoder based knob that has a screen next to it that shows the markings , that way the position of the knob doesnt matter. The motorized route seems like a manufacturing nightmare and from a reliability standpoint I'd much rather have minimal moving parts.
 
Well if you make a virtual wheel, I think the main thing is for the display to be as fast as possible, and always reflect the value of the controller not necessarily the current position of the servo as that will be a bit delayed because of the friction in the lens. Otherwise you'll get that weird sloppy fly by wire feeling. Also if you rely on the display for sole feedback, it's very important that the display has a fast refresh and doesn't have ghosting ad is visible in direct sunlight.

Otherwise make a resistor based dial, with a override button to enable it, and a "enabled" LED.
You can use the dial when you have enabled it, the LED is green.
If you hit a preset or use another unit or computer, the LED will go red to indicate that the dial is not representing the actual servo position.
Turning the dial now doesnt affect the servo, until you click the override button, the LED goes green and the servo now shifts to the dial value and continues to follow that.

Could work pretty well, and is easy and cheap to implement.
Maybe put a learn mode on it as well to be able to "punch in-out" recording of keyframes on the Motion control system.
 
Thanks for the feedback Anders.. Great solution to the dial position problem. The other option could be to just have two different styles of remotes :) The interface portion of the design is pennies compared to the processors/wifi stuff.

BTW.. the display is OLED and from what I've seen so far it looks awesome in direct sunlight. The refresh rate is better than LCD so that should be OK too.
 
To add to Anders's sugestion...

Same system with the colored LED to show when the wheel is disengaded, but how about have a "pickup" mode to regain manual control. Basically you hit a "pickup" button and move the wheel to the point the motor is at. Once the wheel matches the motor it "Picks up" the control back into manual mode.

- Mikko
 
Thats a good way of solving the problem... another thing is that we could indicate the direction to move the dial to sync the position. I think we can persue a couple of these and come up with something really nice. The other thing we were thinking about implementing was a virtual hardstop...basically it allows you to turn the wheel until the motor reaches one of the limits then it tells the pendent to lock up the control knob in one direction, it makes it seem like you are really using a ff.
 
You must log in or register to reply here.
Back
Top