View Single Post
      05-12-2014, 02:51 PM   #29
regular guy
Drives: Sprint car
Join Date: May 2013
Location: California

Posts: 1,375
iTrader: (0)

I've been continuing my work on the remote controlled camera system. I've made enough progress that I think an update is in order.

Originally Posted by regular guy View Post
The Limitations:
I worked on this for weeks before the Shift-S3ctor event. I worked on it literally until I went to bed the night before. I had no time to test it or discover the limitations. Even if I found limitations, time was out and I couldn't fix it. As I found out, there are some limitations.

1. The range of the RC controller wasn't good enough.
Even though the RC controller is supposed to be good for a mile or more, that's not what I got at the event. I'd say it was good for 500 yards, and nothing more. To fix this, I'll switch the controller to a UHF setup called DragonLink. The DragonLink plugs right into the RC controller and is seamless integration. This unit is good for 25-40 miles. DragonLink should arrive next week. Cost: $270.
The DragonLink arrived. Indeed it has much farther range than the original RC radio transmitter/receiver. I've tested it to 1+ mile distance, which for now is enough of a proof of concept. The downside to the DragonLink is that it only supports 12 servo channels. For an RC airplane, this is overkill. But for a remote controlled camera system, I can only control two camera's. I always wanted the design to support three camera's, so this is a disappointment. But where there's a will, there's a way. Below, I'll discuss a workaround for this limitation.

2. The video transmitter couldn't transmit far enough.
Even though I had a 1W transmitter and 10db gain antenna, it still wasn't strong enough to get past 300-400 yards. Because of this limitation, we had to come up with a creative solution. To solve this problem, I placed my son with the RC controller and streaming video receiver in the car racing Drew (DLSJ5). Placing my son in the car would guarantee real-time control of the cameras without any drop outs while operating. I investigated this video limitation and discovered that professional systems are cost prohibitive (starting at $6k, and up to $100k). But there may be a middle ground. An entry level professional digital video transmitter/receiver cost about $1500. This system is designed specifically for race cars. But it's only guaranteed to transmit a little over 1/2 mile (1000 yards). This spawned a hybrid idea of using the digital system and strategically place the digital receiver 800-1000 years down the track. The digital receiver would feed my 1.2 GHz analog transmitter. I could then use a high gain directional antenna pointed directly at the 1.2 GHz analog transmitter. This hybrid approach should guarantee 1-2 miles of range out of this design. But before I consider more expenses like the digital video system, I need to exhaust all other possibilities and debug the system I have.
Testing around my home found that with this system, I could only reliably get 100-150 yards of streaming video. This was a huge blow to my idea of streaming live video to a stationary guy watching and operating the remote control. The digital/analog hybrid design was sounding like it would be absolutely necessary. But before I invested another $1500 in another video transmitter/receiver, I wanted to explore a different brand video transmitter/receiver that has more advanced filters. I purchased a 2500mW transmitter, and receiver with advanced SAW filters. While I was waiting to receive the new transmitter/receiver, I noticed that my transmitter wiring was frayed, and literally hanging on by a single strand of copper. That strand of copper broke as soon as I touched it. It's almost certain that this frayed wire was contributing to the poor video transmission distances. Since a newer, better receiver was already on its way, I wasn't going to try to fix it to see if it improved.

The new transmitter/receiver features a much better cable design that is much less prone to stress and failure. I hooked it all up and drove down to my testing location. On my first test, I literally ran out of road at 0.7 miles. The video transmission was still clear. This is a huge trial success. I moved to a longer road, and finally maxed out the video transmission at 1.1 miles before it became unusable. Again, this seems like a huge succes, and means that the hybrid (and expensive) digital video system wouldn't be required.

3. Some glitches during power up/down cause the relays to trigger, which causes the camera's to turn on and record without my permission! This is more annoyance than real problem. But I have some ideas to fix it. I actually think the DragonLink UHF RC adapter might fix it because I suspect the bug is in the Taranis receiver.
There's more bad news on this front. The glitch that was turning on/off the camera's wasn't really a glitch. It's a normal occurrence when the RC transmitter and receiver establish communications. I was hoping I could program this out by setting different "failsafes" or "starting and ending values" on the servo controls. But nothing worked. The same problem that occurred on the Taranis receiver, was occurring on the DragonLink as well. It's not a deal killer, but it's a royal pain in the a$$ to have the camera's turn on and start recording without your will. With stable video transmissions, it's not a deal killer because I can always see the state of the camer's through the video transmission. But it's a major pain in the a$$. Even after checking with some RC experts, they said this was all normal and nothing I could do about it. But as I said where there's a will, there's a way. And I think I found the way.

4. The Tarot T2D gimbal didn't work as well as I had hoped. It may be great for quad copters and airplanes, but in a car I found that it couldn't recover fast enough to g-force changes going around corners. The Arris CM-3000 3-axis gimbal seemed to work much better than the Tarot T2D. Arris also makes a 2-axis version: CM-2000. I already ordered one, and it arrives tomorrow.
The CM-2000 arrived, but I haven't tried it. I haven't even taken it out of the box because I've been preoccupied working on and fixing these other problems.

Where there's a will...there's a way:

The two biggest problems that still exist are 1) Extending the design to three (or more) camera's in spite of only 12 available receiver channels on the DragonLink; 2) Stopping the servo controlled relays from false firing and turning on the camera when I don't want.

So taking a hint and design from embedded systems control, I found a little (and cheap) CPU powered control module -- called a "Teensy board." The Teensy 3.1 is controlled by a pretty powerful 32-bit ARM processor (just like the ones in your cell phones). It's cheap @ $20 per board. It has about two dozen programmable digital input/outputs. It has 12 PWM outputs (can be used directly for RC servo motor controls). The list of capabilities goes on and on, and makes it a very suitable microcontroller for this project.

Solving the 3-camera (12-channel limitation) problem:

The DragonLink controller uses a standard transmission protocol called PPM (Pulse Position Modulation). The Teensy-3.1 can read and decode PPM signals. In theory, this means I can use the Teensy-3.1 to read the PPM signals, and assign my own functions. To solve the 12-channel problem, I would use of the RC 3-position switches to select the camera. The Teensy could read the PPM stream and know that this particular stream is meant for "Camera-1" (or 2, or 3). Then all of the other controls remain the same. If the camera controls only need four servo channels, then using the Teensy to read the PPM stream to know when to talk to "Camera-1" (or 2 or 3), the Teensy could output the appropriate PWM channels only to that specific camera module. This approach would allow me to multiplex multiple camera's onto only five servo channels. 12-channel problem: solved!

Solving the servo/relay flutter that turns on my camera's when I don't want:

The Teensy-3.1 helps solve this problem also. The Teensy has dozens of digital outputs. By writing a small program to read the PPM stream, I know when I want to turn on/off my camera's. Instead of sending these signals to the PWM servo controller, I could instead output an "on/off" message to one of the digital I/O pins on the Teensy. Add a resistor, transistor, diode, and 5V relay switch, and I can use the Teensy to directly control the relay without using the servo controller. Without the servo controller means no servo flutter; this means no false on/off signals to the camera. ON/OFF problem: solved!

Designing the Teensy board:

This is the easy part. Just go down to Radio Shack or just about any decent electronics store to buy the parts to create your own breadboard circuits. Using the breadboard, I was able to prototype everything. Then once I got it working, solder the components down to the real circuit board. You might remember this picture from the original design.

That was the old design. And compare it to the new design.

I've made some color circles on each photo to see what has changed, and how it is being replaced.

RED: Everything circled is red is gone and no longer needed with the new design.
YELLOW: Everything circled in yellow on the original board is replaced by the Teensy-3.1 on the new board. The Teensy-3.1 board is approximately 2 x 0.75 inches.
BLUE: The servo controlled relays on the old board are replaced with transistor controlled relays on the new board.
MAGENTA: The voltage regulators on the old board and new board are the same. This will provide a really good size reference between each board. The original board was approximately 0.75 square feet (12 x 9 inches). The new board is approximately 3 x 8 inches.
GREEN: This is the power switch to charge the GoPro camera's while in use. The original servo-controlled power switch is replaced by a simple power transistor. No more servo controlled switches.
BLACK: These are new jumper switches. By installing jumper switches, each board can identify itself to the software as "Camera-1" (2, 3, or 4). This allows each board to run identical software, but control a different camera depending on the selection of this jumper block.
regular guy is offline  
Reply With Quote