Part 1.4 – Supercharge motors to help them along.

Speeding up and slowing down is great and all, but can the platform move the camera along with itself?

…so if I decide to waiver my chance to be one of the hive,
will I choose water over wine and hold my own and drive?

1999 © Incubus, Drive

Speeding up and slowing down is great and all, but can the platform move the camera along with itself? As it stands, it needs to be able to safely [and smoothly!] move around a loaded DSLR camera with a typical lens, an external monitor, zoom and focus motors, a cage to mount all these to, control boxes with the electronics to run the whole thing…

…but let’s not get ahead of ourselves here. [*]

[*] This post is bound to be longer, so bear with me.

A few writings back, I elaborated on our choice for the Bescor MP-101 as the basis for the project. Within that same post, there are links to the patent applications for the inner workings of the Bescor. It makes for an interesting read – for what it sets out to be, it is a wonderful product in its original form. But as production costs dictate, the resulting product mates quite a mechanically sound platform with less than stellar control electronics. In addition from the limit switches and the integrated motor drivers, it is bound by the requirement to work with both batteries and wallwarts, use a wired remote and implement basic automated panning.

And since we are already using a microcontroller with some power and programming capabilities, it is only natural to move all functionality to the internal logic and eliminate the superfluos electronics in the Bescor. Controlling the motors directly from the Moteino makes sense for at least three reasons [1] simplification, [2] increased power and torque, and [3] extended movement control.

Operating on the Bescor

Being happy with the mechanical base of the Bescor, we are setting out to remove offending electronics and interface the DC motors directly. Why do so? Up until this point, all of the electrical paths towards the Bescor were done through the stock DIN port, used for the original remote. This is a simple approach as it allows for the Bescor to remain in stock form, as well as retaining the ability to use the original remote. Unfortunately, we have done as much as we can using the stock port – the imposed limitations on the original scope of the work for the Bescor will not allow for further explorations into extending the operational capacity of the platform.

Luckily, getting at the electronics of the Bescor is not a difficult task, as most of it is mounted on the back plate. A long thin Philips-head screwdriver is all that it is needed to remove the six [6] screws holding the backplate together. Once the screws are out, the backplate needs to be slid down from the top as it is embedded into a channeled groove. All of the electronics rest on a small PCB bolted to the plastic backplate along with the DIN connector and the operation mode switches. Several thin wire bundles connect the electronics to the rest of the platform, including power wires, direct motor wires as well as operation of the limit switches.

Internal Bescor controller PCB. Wire jumpers added for prototyping.
Internal Bescor controller PCB. Wire jumpers added for prototyping.

We will not be using any of those [power, motor and drive], because, [1] power for the motors is to come courtesy of the Moteino and an external power source, [2] motors will be directly interfaced with the motor driver and [3] operational drive limiting shall be done from within the code logic.

So I cut all the wires, neatly bundle up the ends in case future reversal is needed and go get a Coke.

Applying the Stitches

Spoke prematurely – we will still need some of them. At the very least, each individual motor needs to be interfaced by two wires to an external power source, controlling its speed and direction. However, leaving wires hanging from a plastic box is neither convenient nor pretty. Hence, we are to interface the wires to the external world via a connector of some sort, and close the plastic box. Originally, the plan involved reusing the DIN connector on the backplate, but 7 pin DIN connectors are neither ubiquitous nor cheap.

The better choice is the both easy to find and inexpensive RJ45 connector, allowing for up to 8 wires to be interfaced, leaving some room for future expansion if needed. Additionally, RJ45 cables are easy to find and easy to make even without soldering, solidifying the selection. We decided on the panel mount, PCB traced, D-series locking Ethernet RJ45 socket [*], the NE8FDV-B from Neutrik.

[*] Yes, that is a handful.

Looking at the photo above depicting the small PCB, identification of the motor wires is fairly easy. Near one of the PCB angles, the motor driver chips are easily spotted. Leading up to the motor driver chips are the two pairs of wires. Make a note on the wires, as different versions of the Bescor might have them differently, although in the several platforms I opened, even when ordered from different vendors, the wires were always the same.

For the pan motor, the wires are [1] blue and [2] green. For the tilt motor, the wires are [3] yellow and [4] orange.

To facilitate future work on the internals of the Bescor, I used machine pin headers to attach the wires to the PCB contacts of the connector, instead of soldering them directly, as the machine pins easily fit on the PCB contacts of the Neutrik connector [as long as you use standard pins spaced at 0.1″]. This allows for easier mounting of the connector and quicker future swapping, if need be. Due to the narrow operating space, the PCB contacts needed to be bent slightly upwards at an approximate angle of 45 degrees, while the wires are connected along the top row of PCB pins, namely 2, 4, 6 and 8.

Once the wires are in, all that remains before closing up the Bescor is a mounting plate for the connector itself – easiest to do is modify [drill out] the original plastic backplate to fit the connector. Made out of cast plastic, we could trim out the various protruding bits and bobs and drill out a larger bore for the RJ45 connector and the attaching screws. Looking at the original plate it should be clear from the get go that there is no chance in making that look anything remotely pretty, compared to the stock form:

Stock backplate for Bescor MP-101.

That kind of modification also eliminates any chance of restoring the Bescor to a stock form. Manufacture a new one, you say? Manufacturing was out of the question until we heard of a cheap 3D printing service in the vicinity, so that way we go. I am to measure the original back plate, mock a new flat one up in a CAD environment, and deliver a model for 3D printing based on the cutouts in the Neutrik connector data sheet:

Wireframe [hidden] view of the Bescor / Neutrik backplate.
Wireframe [hidden] view of the Bescor / Neutrik backplate.

The full STL file [viable for 3D printers and 3-axis CNC routers] available in the GitHub repository. A few days later the roughly finished updated backplate is back, and looks the part quite nicely:

3D printed custom backplate for the Bescor MP-101 and a Neutrik NE8FDV-B.
3D printed custom backplate for the Bescor MP-101 and a Neutrik NE8FDV-B.

The connector attaches to the backplate using the supplied metal front plate and the self-tapping screws. With the connector attached to the backplate, the machine headers are connected to the PCB pins of the Neutrik, and the entire assembly slides easily in the grooved channels of the Bescor body. As the plate fits snugly in, the closing up of the electronics compartment is achieved via just two of the long screws as opposed to the original six:

Reassembled Bescor MP-101 with electronics removed and custom back plate.
Reassembled Bescor MP-101 with electronics removed and custom back plate.

I’m happy.

Interfacing the Motors

We discussed the plight of the Moteino running DC motors already here and here. The DC motors that form the basis of the Bescor pan/tilt platform are rated at 6VDC, where as the Moteino can supply 3.3VDC at most out of its PWM enabled pins. I had also mentioned that it might not be the best idea running two DC motors directly off of the Moteino pins, so there is also that…

…which leads us to the issue at hand. We need to [1] supply the motors with 6VDC from an external supply, [2] range the voltage between 2.2VDC and 6VDC to provide for speed control and, [3] swap polarity so we can control direction of said motors.

Now, [1] and [2] can be done through the Moteino by implementing a transistor that switches an external power supply – varying the value at the PWM pins will result with a varied voltate. And [3] can be achieved by implementing an H-bridge.

Luckily, there are integrated circuits that do all three, and for two motors at once.

Testing the waters with L293D

A popular choice seems to be the L293D, as it is readily available, and fairly cheap. Looking through the datasheet, it seems to provide for our requirements, so why not go with the popular vote:

Basic connection between Moteino and L293D, controlled by a potentiometer joystick.
Basic connection between Moteino and L293D, controlled by a potentiometer joystick.

[*] Yes, I finally found a Fritzing part for a Moteino.

So, a few things here. The chip, which is technically labeled “a dual H-bridge motor driver”, takes 6VDC from the external power supply, and routes the power to the output pins, connected to the RJ45 connector [see above for pinout]. The chip has two separate “enable” pins that control the activation of either motor. Additionally, each side [acting as a single motor controller] has two input pins, in addition to the output pins.

Motor direction control is achieved through setting different values for the input pins. Setting the first input pin HIGH, and the second input pin LOW moves the motor clockwise, whereas setting the first input pin LOW and the second input pin HIGH moves the motor counterclockwise.

Speed control is achieved through the enable pin for each motor, by connecting it to a PWM enabled Moteino pin, and then writing a value in the 0-255 range through AnalogWrite().

Here is a code snippet that seems to work, for one of the motors [duplicate for both]:

Well it seems to work – what is the problem, you say? Simply, logic level incompatibility. The L293D expects a logic supply voltage higher than 4.5V, which is why it is popular with typical Arduinos that have a 5VDC VCC rail. In the case of the Moteino, the value of 3.3V for the VCC rail seems to produce inconsistent results. At the very best, the motors run, but the output for the motor voltage never seems to go above 70% of the available voltage.

So we scrap it.

Moving ground with TB6612FNG

Now we need a chip that has a dual H-Bridge, can handle a minimum of 0.5A of current per motor, and runs at a VCC of 3.3VDC? Enter the TB6612FNG, a nifty little IC by Toshiba, handily broken out on a daugherboard by SparkFun, available here. It does everything we needed the L293D to do, handles a little bit more power, and is already prepared for breadboard use, including decoupling capacitors for the outputs as well as low voltage protection. It also has thermal protection shutdown, meaning we technically cannot overheat it. Technically.

Connections are pretty similar to the L293D above, with the exception that, this time, all inputs are aligned to one side of the board, and all outputs aligned to the other. Motor direction control now has a fourth option, in addition to CW, CCW and stop, we now have the option of short brake. [*]

[*] Short brake is typically used with high speed DC motors when their movement needs to be halted pretty drastically. In the case of the Bescor, and our usage scenario, it is difficult to understand whether this would be needed. However, for the future, a short brake function might be used to eliminate possible motor drift during typical pan / tilt movements.

Having said that, the wiring is quite similar:

Basic connection between Moteino and the SparkFun TB6612FNG breakout, controlled by a potentiometer joystick.
Basic connection between Moteino and the SparkFun TB6612FNG breakout, controlled by a potentiometer joystick.

The code running this whole contraption is quite similar to the approach I took last time without the motor driver. We are replicating the input code, along with the input data struct, since the type of input data remains the same:

But, before we get on to the movement, a few words about the connections to the Toshiba IC.

Within this sketch, three pins each are dedicated per motor. Two of them are digital and control rotational direction [see above], while the third one [per motor] needs to be a PWM enabled pin in order for motor control to be operational. Additionally, a stand-by pin is needed as the most economic way of stopping both motors.

That said, the movement logic has been moved to two separate procedures – PTH_Move() and PTH_Stop():

Lastly, the Moteino is still USB powered, while the VM pin of the motor driver breakout is connected to a 6V wallwart. Which brings us to the final iteration of the code for this session:

The clean files, as usual, located in the GitHub repository.

Finally, man! Does it work?

Yes, it does. Using the PTZ joystick, fine control is possible, and the Bescor can handle a typical 2.5kg load gracefully. The movements are smooth, continuous and very responsive to the input from the joystick. There are a few glitches we spotted occasionally, but those have a bit more to do with rotational intertia of the entire contraption than with the code and motors within the platform. Future iterations might tackle procedures for ramping speed up and down to provide for smoother starts and gentler braking.

Next time, we take to the air.

An avid tinkerer, Marjan has dabbled with software, hardware and the occasional guitar (he is not very good at the latter). Could hardly wait on the emergence of IoT, and now will simply not let it go...

...burns fingers regularly on soldering irons.

Leave a Reply

Your email address will not be published.