Lowcost 3d Fpv Camera for Android

Intro: Lowcost 3d Fpv Camera for Android

FPV is a pretty cool thing. And it would be even better in 3d. The third dimension does not make very much sense at big distances, but for an indoor Micro Quadcopter it's perfect.

So I had a look at the market. But the cameras I found were all too heavy for a micro quadcopter and you need expensive goggles for it. The other possibility would be to use two cameras and two transmitters. But again you have the problem of the expensive goggles.

So I decided to make my own. All cameras on the market use a FPGA for making the 3d picture. But I wanted to keep it cheap and easy. I was not sure if it will work but I tried to use two Sync Separator ICs, a Micro controller to manage the syncing and a analog switch IC to switch between the cameras. The biggest problem is to get the cameras synchronized but it is possible to do that with the controller. The result is pretty good.

Another problem were the 3d goggles. Normally you need special 3d goggles which are pretty expensive. I tried a few things, but I was not able to solve it just with electronics. So I decided to use a USB video grabber and a raspberry Pi with google cardboard. This worked pretty well. But it was not very nice to put the screen into the cardboard and have all the electronics around. So I started to write an android app. In the end I had a complete 3d FPV system for android for less than 70 Euro.

There is a delay of about 100ms. That's because of the video grabber. It's small enough to fly with it.

You need pretty good soldering skills to make the camera because there is a self made circuit board but if you are a little experienced you should be able to do it.

OK, let's start with the parts list.

STEP 1: Parts List

3D Camera:

• PCB: you can get the PCB with the parts here (about 20 Euro
• 2 Cameras: It should work with almost any pair of FPV cameras. They must have the same TVL and the same clock speed. A good choice is to use some cams where you can easily access the Christal. I used a pair of these small cameras with 170 degree lenses because I wanted to use it on a Micro Quad. (about 15 to 20 Euro)
• FPV transmitter: I use this one (about 8 Euro)
• FPV receiver (I had one laying around)
• 3d Printed Frame
• Easycap UTV007 video grabber: It's important to have the UTV007 chipset. You can try other UVC video grabbers, but there is no guarantee that it's working (about 15 Euro)
• USB OTG cable (about 5 Euro)
• 3d FPV Viewer Android App: Lite Version orfull version
• some sort of google cardboard. Just google for it (about 3 Euro)

Additional needs:

• Soldering Iron
• Soldering experience
• magnifying glass
• AVR Programmer
• PC with avrdude or some other AVR programming software
• Android smart phone with USB OTG support
• 3d printer for the camera holder

STEP 2: Assemble the PCB

Order the PCB. You can order it directly from Aisler with all the parts you need. After you have received the PCBs assemble all parts. It's pretty small, but with magnifying glasses it's easily possible. (I use desoldering wire to remove the soldering bridges from the ICs. I'm sure you find some soldering howto in the internet)

If you want to make the PCB yourself or order it somewhere else, you can download the eagle brd file and the parts list (3dcam_mini_tiny24.txt).

The size of the PCB is for 20mm * 20mm or 16mm * 16mm mounting holes. If you use the 16x16 holes you can cut the PCB at the outer slits.

When you are finished with soldering and you have checked all connections again you can connect the isp wires. In the first picture you see where to connect SCL, MOSI, MISO, RESET, + and -. In the third picture you can see the pinout of the AVR ISP programming wire. The fourth picture shows how my connections looks.

Download and extract the '3dcam.zip' file from the link on the bottom of this step. The hex file is located in the Debug folder. The fuses should be programmed to LFUSE 0xe2, HFUSE 0xDF and EFUSE 0xff. If you use linux and avrdude you can use the flash.sh file in the Debug folder. The avrdude command line is: "avrdude -c avrisp2 -p t44 -U flash:w:./3dcam.hex -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m". If you use windows you will find a howto with google.
If programming worked and you soldered alright, the LED blinks fast. This indicates that no camera was found. You can now remove the programming wires.

The source code is included. Feel free to upgrade the code.

Here is the LINK TO THE AVR PROGRAM

STEP 3: Connect the Video Transmitter

Now its time to connect the video transmitter. I connected it with some strong wires to have it mechanically fixed. Connect + to +, - to - and the 3d video output to the video input of the VTX. You can see it in the second picture. If you use a 5V video transmitter like me, you can connect the internal 5 V pin to + with a soldering bridge.You can see in the third picture where the connection should be.

It's also possible to use a video transmitter with a different supply voltage. If you use such a transmitter don't connect the internal 5V to +. Instead connect your supply voltage to + at the video transmitter connectors on the PCB.

STEP 4: Print the Cam Holder

Print the three stl files. I printed it with PLA, a 0.3 mm nozzle and 100% infill. Feel free to design your own cam holders if you don't like mine or you use different cameras.

[Update] I designed a new camholder. You can put the cameras in 8 directions now and it's more stable. Download Camholder2.stl and clamp2.stl

STEP 5: Connect the Cameras, Download the App and Test the 3d Camera

Now you can test the 3d camera. Connect the two cameras to the PCB like in the picture. You can solder the cameras directly to the PCB. I just use plugs because I tested a few different cameras.

Download the App 3D FPV Viewer Lite from google play store. Start the app and connect the UTV007 video grabber with a USB OTG cable. (The app also supports UVC video grabbers with a resultion of 640x480, but it is only tested with the UTV007 video grabber. I tried a Eachine ROTG01 receiver, but it didn't work because it deinterlaces the video). Tap on START and power the 3d camera. The LED on the PCB blinks a few times. Then it flashes constantly for NTSC cameras or is off for PAL cameras. If it is blinking fast, the circuit could not detect the cameras. After a few seconds you should see the pictures of the cameras on the android screen. Maybe you see a part of the first camera at the picture of the second camera like in the third picture. That's OK for the moment. I will give some tips how to solve that at the end of the instructable. If you get no picture, just one picture on both sides, a very small picture on one side or a picture that is not aligned alright, try to restart the camera a few times until it's OK. You can close the video window on the upper left side where the 'X' is. Even if it's working you should go on with the next step.

STEP 6: Connect the Clocks of the Cams for Syncing(not Needed But Strongly Recommend)

To get the cameras synced good they have to run from the same clock. You don't need to do that but it is strongly recommend. If you don't sync them you will get bad color distortions or it doesn't get synced at all. It depends on the cameras you use. Sometimes the clocks of the cameras are far away from each other.

To connect the clocks you have to remove the crystal, the capacitors and the resistor of the oscillator from one of the cams. Then you must connect a cable from the second cam's crystal to the desoldered pad of the first cam. In my case it worked without removing the capacitors and the resistor. With some other cams I had to remove them.

If you use big cameras this is pretty easy. With the small cams I use it's pretty hard but possible. Sadly I have no good camera to make good photos, but I added some pictures to make clear what to remove and where to put the connection cable. I used a small side cutter to remove the crystal. After you have added the connection cable you should fix it with some super glue.

If you have an oscilloscope power both cams and check the output signal to be sure it's working.

UPDATE 6th September 2018:
It is not necessary to remove the crystal and the capacitors/resistor. I have some new cameras and it's also working if you just connect a cable between the clock signals without removing anything. One crystal will force the other one to it's frequency. Try this before you remove the crystal of one camera.

STEP 7: Conclusion, Additional Info and Some Tips

Conclusion: The camera is working pretty well. Even if it's not perfect, It's usable. There is a delay of about 100ms, but for normal flying and to test 3d fpv it's ok.

Info and Tips:

- If you don't have an android smartphone which supports the easycap UTV007 or UVC you can easily get one on e-bay. I bought an old Motorola Moto G2 2014 for 30 Euro.

- The camera is not syncing every time. If you don't get a picture or the picture is not OK try to restart the camera a few times. For me that always worked after a few tries. Maybe somebody can improve the source code for a better syncing.

- If you didn't sync the clock of the cameras, one picture will slowly go up or down. It's less disturbing if you turn the cameras by 90 degrees, that the picture is going to the left or right. You can adjust the rotation in the app.

- Sometimes the left and right sides are changing randomly. If that happens restart the camera. If the problem still remains try to set the DIFF_LONG parameter in the 3dcam.h higher, recompile the code and flash the hex file again.

- You can set the standard to PAL by putting PB0 and PB1 to +5V

- You can set the standard to NTSC by putting just PB0 to +5V

- With PB0 and PB1 not connected the auto-detect mode is active with big difference (standard)

- With just PB1 connected to +5V the auto-detect mode is active with small difference. Try this if you see a part of the first picture on the bottom of the second picture. The risk for randomly changing pictures is higher.

- I use the standard mode with clock synced PAL cameras, but I set the app to NTSC. With this adjustment I have NTSC resultion and no risk of randomly changing pictures.

- I had very bad color distortions with not clock synced PAL cameras. With NTSC cameras this did not happen. But anyway, syncing the clocks is better for both standards.

Details about the code:

The code is just documented in the 3dcam.h file. All important settings can be done there.
Some comments on the defines:

MIN_COUNT: After this number of lines the side is switched to the second camera. You should leave it how it is.
MAX_COUNT_PAL: This option is just used in PAL mode. After this number of lines the picture is switched back to the first camera. You can play around with this parameter if you use PAL mode.
MAX_COUNT_NTSC: The same for NTSC
DIFF_LONG/DIFF_SHORT: These parameters are used in auto detect mode. This number is subtracted from the auto detected switch time. You can play around with these parameters.
MAX_OUTOFSYNC: This was meant to check the syncing of the cameras, but it never worked alright. Just leave it like it is or try to implement it yourself.

If you use my PCB you should leave the rest of the defines like they are. A makefile is located in the Debug folder.

That's it. I will add an inflight video and an instructable for the quadcopter soon. For the moment there's just the camera test video.

Update 5. Aug. 2018: I made a new AVR program for clock synced cameras. I don't know if it works when you don't sync the clocks. If you have synced cameras you should use it.

It can happen that there are colour distortions with PAL cameras. Reset the AVR until you have a good picture for both cams. I added a reset button to my PCB for that.

It can happen that you have randomly changing pictures with NTSC cameras. Reset the AVR until it stops to change randomly. You can also play around with the DIFF_SHORT parameter in the source code.

There are a few changes to the last version:

• PAL/NTSC gets autodetected. The manual selection is removed.

• To set DIFF_SHORT put PB1 to +5V. You should do this if you see a part of the second picture at the bottom of the first picture.

• The cameras are always syncing now.

Here is the link

Update 22. Jan. 2019: I had the chance to test the camera with field alternating 3d goggles. It works without delay. (Tested with very old Virtual IO iGlasses and Headplay 3d goggles)

Comments

[antdavison]

I want to port your v2 code to Nano (instead of ATTINY, and currently going through it line by line
can you double check these proposed changes ( I changed you naming format so I could read it a little easier)

code block is ---- void init(void) //void setup()

//original code used .OddEven2Pin.
OddEven1DDR &= ~(1 << OddEven1Pin); // pinMode(OddEven1Pin, INPUT);

//original code used |=
VidStdDDR1 &= ~(1 << VidStdPin1); // pinMode(VidStdPin1, INPUT);
VidStdDDR2 &= ~(1 << VidStdPin2); // pinMode(VidStdPin2, INPUT);

thanks in advance and hello from New Zealand

[kolibrif282]

Hello,

thanks for posting this, it is an amazing project!
I am already flying with a stereoscopic setup on a tiny whoop, but with Skyzone 02X googles (with 2 VTXs). It works great with two independent cameras. However, I wonder if synchronization of the cameras would improve the 3D effect even further. I am using 2 Caddx Ant Lite cameras and the crystal is also accessible, however it looks slightly different (see attached figure). I would solder either to pin 1 or 2. Does it make a difference or do you have a recommendation?

Many thanks in advance!

[Andi23456]

Hello. I think you would not have a better 3d experience with my camera. Maybe it's even worse because with your setup you have two pictures with the full resolution. In my setup the horizontal resolution is halfed, because one camera picture is mapped to the odd field and the other one to the even field. Syncing should not make a big difference I think. I just need it for splitting the pictures.
The advantage of my system is that you need just one VTX, so you would have less weight. Also you don't need expensive 3d goggles with my system, just an android phone, cheap android 3d goggles and a USB video grabber. My system will only work with the skyzone goggles when they support line alternating 3d.
If you want to try anyway, your cameras would work. You should solder to one of the white capacitors. Just measure which side is GND and solder to the other side. Use the same Solder point at both cameras.

[kolibrif282]

Hello, thank you for the quick reply!

I am currently playing with 3D recording and noticed (as expected) that fast moving objects are slightly off between left and right images (I tested with a fast spinning wheel). My plan was to synchronize both cameras so that they capture both images at exactly the same time. As mentioned, I do not know if that will improve the 3D impression at all, but maybe worth to test.

So, my goal of the camera synchronization is that both cameras start to capture the first line of the image at the same time (and also output as video signal). Please correct me if I am wrong, but this is how I understand the purpose of Step 6. Synchronizing the shutter of the camera and the video signal are maybe be two different things. If that is the case I guess it gets more complex then.

I will do further testing and trying to solder to the capacitor (already did some experiment connecting to pin 1 at the resistor, but it seems that there are still differences).

Regarding your solution: From FPV googles I know side-by-side and interlaced mode. Correct me if I am wrong, your solution is transmitting full frame with alternating lines in each frame (e.g. odd lines = left, even lines = right image)?
So, it is not an interlaced solution with 50 or 60 half-frames and also no field sequential solution with alternating full frames, correct?

Many thanks again!

[Andi23456]

Hello,
to synchronize the pictures it's not enough to just sync the clock. My circuit is measuring the start up time of each camera and switches them on with the right delay, that each frame change is at the same moment. Then the analog switch is switching between the cameras at every field change. I do clock syncing, because one picture would move over time in the 3d view if the clocks are not exactly the same.
For your plan you would need the two LM1881 and the microcontroller + two transistors to make the same camera syncing like me. You don't need the analog switch if you use two VTX. You can send each signal via a separate VTX and you should see no time difference between pictures.

You are right. My circuit is transmitting one cameras picture in the odd lines and the other cameras picture in the even lines, also known as line alternating 3d. You have for each side 25 fps in PAL or 30 fps in NTSC but only half horizontal resolution, because just one field is used. That is also the reason why videograbbers with automatic deinterlacing like the ROTG01 are not working to display the 3d view on smartphone or pc.

[kolibrif282]

Hello, thanks for the clarification! It would have been too nice if one wire would do the job ;-)

So, the trick is to switch on both cameras with the right delay. Once they are started (and connected with the clock wire), you do not need further synchronization. Correct?

I have some experiences with Arduino programming, but I am definetely not on your level in electronics. I guess your PCB + AVR sketch could be used as is for synchronizing the cameras. I need to check if I can follow you description in all detail. Using the suggested simplification would be interesting. Do you have a wiring diagram for the described solution?

[Andi23456]

Yes, that's the trick. You can use my program without any changes. The circuit is the same like mine just without the 4066 analog switch IC. You can connect your VTX in parallel with the Video Input pins. If your VTX have an input impedance of 75 Ohm(which is standard) you can leave R4 and R5 out, too.
For testing you don't need to sync the cameras clocks. It should also work without it, but the pictures will go out of sync over time.
You could also use an arduino for the circuit, but then you have to rewrite the program for your controller.

[kolibrif282]

Thank you for the layout and further information!
I am trying to understand your code. Power switch of both cameras are controlled and in the code I saw the comment that if they are out of sync they will be restarted. To get a feeling with low cost cameras, how often does this restart happen?
Also, I was wondering if power control for one camera would be sufficient (one running all the time and the other is powered on and off for synchronization). Just trying to understand what kind of simplification would be possible for my scenario (of course with modifications of the code).

[Andi23456]

Yes, I switch both cameras power. But you are right. It should be enough to control power of one camera, when you measure it's switch on time and power it at the right time before the next field change. When the sync is not alright make the switch on time longer or shorter as needed. The best way is to measure the time difference with burst signals after field change. Then you know your line offset between the two cameras. I never got it perfectly synced, but this is not necassary for a good 3d view. A few lines offset is no problem.
If the cameras are synced by the program via power on delay and the clocks are synced as well it never happens that they go out of sync. The program code for this condition is in there because it's also possible to use cameras which are not clock synced. The restart just happens with when there is no clock sync.

[kolibrif282]

Not sure if I understood everything correctly. I tried to simplify the wiring diagram accordingly (still struggling a bit with the TP numbering).

Beside removing the ICs 4066 and one transistor for the power switch of one camera, I also removed the ODD/Even pins to IC 1881 (assuming that Burst pin can be used for camera synchronization). If simplification is correct I could maybe even replace the Attiny44 by an Attiny45.

I also tried to have a look at the PCB layout with the free version of the Eagle software. The wiring diagram is not include there, right?

[Andi23456]

The testpoints are the connections for the ISP programmer.
TP11 -> GND
TP12/TP13 -> +5V
TP14 -> SCK
TP15 -> MOSI
TP16 -> MISO
TP17 -> RESET
https://www.google.com/search?q=isp+pinout&tbm=isc...
The circuit on the upper right side are the stabilization capacitors for 5V and the power connections of the ICs.
The 10K resistor at PB3 is a pullup resistor for the reset pin.

I don't think that you can remove the odd/even signal. You need to know, when a field change happens. I think this is not possible with burst signal and a relatively slow microcontroller like the AVR. But for your usage doesn't need the exact line count. So maybe it works when you use just the odd/even signal and remove the burst signal.
I think the program should do something like: switch on the camera -> measure the switch on time -> switch off the camera -> wait for a odd/even signal of the 'always on' camera -> wait '20ms-switch on time' -> switch the second camera on -> measure the difference between the two odd/even signal -> if difference is to big switch off the camera again and repeat with a slightly smaller or bigger switch on time. -> if difference of the odd/even signals is below a certain threshold you are in sync.
There should be a big enough delay between switching off and on the camera, because the switch on time is lower if you wait not long enough. I think that is because of some capacity at the camera.

There is no wiring diagram file included with the layout file. But it is the same like the one I gave you.

[kolibrif282]

Thanks for your patience with me, I misunderstood the burst signal then. I checked the product sheet of the LM1881 and still do not understand the purpose of the burst signal. Does it allow to get better sync results? Even/Odd signal seems to be sufficient for my purpose.

20ms are for PAL/50FPS, right? (17ms for NTSC/60FPS)

[Andi23456]

The burst signal is used in analog video transmission to sync the color oscillator. It is sent with every line. The LM1881 fires a signal when it detects the burst pulse. I used it to count the lines and to switch between the cameras after a certain number of lines.
https://en.wikipedia.org/wiki/PAL#Colour_encoding
20ms are for PAL, 16,67 ms for NTSC.

[kolibrif282]

Thanks a lot! I ordered two LM1881 and will do some tests on a breadboard with an Arduino (reading ODD/EVEN pin and trying to check the time shift). If I get this working I will try to synchronize both cameras with a transistor.
Transferring to an Attiny might be the final step (but so far I do not have experience with it) ...

[Andi23456]

No problem. Sounds good. Would be nice to hear if it's working, when you are finished. If you need further help, don't hesitate to ask.

[tonykemp]

I have been looking all over for a 3D FPV drone solution, and I finally found this. I have no experience in making things like this and would prefer to buy one (providing all the kinks have been worked out of course). Have you considered producing a unit that you could sell? Besides other practical uses, having a 3D FPV would make you feel like you were actually flying. Imagine going to some natural wonders out there and flying around them, seeing them in 3D like you were actually flying. This is a kind of VR experience I think many would pay for and use again and again.

[Andi23456]

Hello, actually I have made a new board. It has no problems with color distortions or syncing anymore and it weights only about 9 gram including VTX and cameras, so it is possible to fly a small indoor quadcopter with the 3d cam. If you are interested please send an e-mail to [e-mail] to clear the details of your fpv setup and the price.

[YannickC3]

Hello,
I would like to make this project but I can't order the PCB when following your link. Have you an updated link or maybe the PCB sources?
Thanks!

[Andi23456]

Hello,
the link was broken. I updated the link to a zip file with EAGLE brd files and BOM inside.
There are two different versions in the zip file. One is the version of the instructable, the other one is with smaller analog switches and a smaller version of the micro controller, but harder to solder.
Here is the link:
https://drive.google.com/file/d/1wn5jFZf8-OaWYI_UG...
I also have a few ready to use boards left. If you are interested in buying a board contact me again.

[YannickC3]

That's great thank you!