Welcome to Synthiam!

The easiest way to program the most powerful robots. Use technologies by leading industry experts. ARC is a free-to-use robot programming software that makes servo automation, computer vision, autonomous navigation, and artificial intelligence easy.

Get Started
Asked
Resolved Resolved by DJ Sures!

USB Connection To EZB V4

OK guys I have another question for everyone can you use the UART on the EZB V4 to connect to a USB rather than the camera port?

I want to hardwire my EZB's to my onboard PC but I also want to use my ez-robot camera with one of my EZB V4.


Related Hardware EZ-B v4

ARC Pro

Upgrade to ARC Pro

Experience early access to the latest features and updates. You'll have everything that is needed to unleash your robot's potential.

AI Support Bot
Related Content
Synthiam
PRO
Canada
#51   — Edited
Sorry man, I understand how it works I guess I used the wrong terminology.
PRO
Synthiam
#52  
Do you have the rts connected? Also - does the led flicker? I think it flickers with every packet or something. So if it's not flickering then it isn't sending. The camera won't send unless the rts is held low.
PRO
Canada
#53  
Yeah I held the camera side RTS low, and swapped TX/RX back and forth just to make sure I didn’t get it wrong. I also provided 3.3V and GND to the correct pins. I’ll look at it more tonight or tomorrow.
PRO
Synthiam
#54  
Hmmmm. Check with the camera on an ezb and see if the led blinks. That will let you know if you can see if it’s transmitting
PRO
Canada
#55  
Well, I am at a loss. I have tried the following but I can't seem to get the camera to communicate over the USB-TTL adapter:

- Confirmed PL2303TA USB-TTL adapter is rated to a maximum 6Mbaud of communication speed
- Confirmed that the USB-TTL adapter is working using remote echo
- LED on the camera is on but doesn't blink, this is normal for V2 camera, I believe only the Camera v1 blinked during communication
- I confirmed that the camera does work by connecting it directly to an EZ-Bv4, double-checked the LED was solid while working
- Tried multiple V2 cameras with different firmware versions (Green LED versus Blue)
- Tried swapping TX/RX in case of mislabelling 
- Tried tying RTS and CTS to GND in separate tests
- Tried lowering the communication speed (COM4:115200) but it didn't have an effect

Here are the two errors I get depending on which way TX/RX are connected:

User-inserted image


User-inserted image


@DJ any ideas?
PRO
Synthiam
#56  
The first msg implies that the tx and rx are wired correctly. But the message appears that it’s missing the header. So either

1) the baudrate isn’t supported and the data is unreadable and garbled 

2) there’s too many missing because the converter can’t keep up so the packets and the header can’t be found. or there’s too much noise on the line. Although you’d think at least one header would be detected
#57  
Following post #33 link, DJ states not to put the baud rate in as it would default to 3,333,333 bps .
Did you happen to try that?
Just a guess on my part.
PRO
Canada
#58  
Thanks guys! I’ll try removing the wire on the adapter side to limit noise. This will also give me access to the RTS pin on the adapter side. I forgot to mention that I also tried switching the baudrate in the device manager to match the lower baudrate when I entered it manually in the camera skill.

@Herball yeah I was mostly testing at the default speed (ex:COM4) without the additional baudrate added.
PRO
USA
#59   — Edited
Hey guys still working on Guardians 3 so I am away from my computer/robots/parts etc. And I have brain rot, so I've gone back over the old thread to see if anything has jogged my memory. 

-I went with the revision "D", the PL2303HDX, because I knew it would be running on Win 10 (for drivers). 
-Voltage supplied was 3.3v
-Post #36 was the final wiring diagram that I got it to work.
-Once I had a video feed I got "ripped frames" where the feed seemed to lose sync between frames.(post #37)
-That was resolved by moving to a new computer and therefore a newer USB socket. All my issues went away after that. Not sure why that was. (post #48)

I have these in all my robot heads and they work great. Hope this helps?!
PRO
Canada
#60  
Thanks Will! I appreciate you taking the time to chime in!

Can I ask you if you are using the latest version of ARC with the PL2303HXD, just to rule out if there's something in the software that's different?

Well I'm starting to suspect it's my Laptop at this point. I have tried force switching different COM ports, verifying that I truly have 3.3V powering the camera (I do), tried another USB port, did continuity checks on all the connected GNDs (all good), tried 2 different FDTI FT232RL adapters (at lower baudrate COM8:115200), and tried messing around with connecting RTS/CTS to GND on the adapter side, I can't seem to get it to work. Is there a setting I'm missing somewhere maybe? Do I need flow control on?
PRO
Synthiam
#61  
Jer - I checked, and there hasn't been a change to the uart video code in years. The code also works because it's the same code that the TCP video uses pretty much. The message you're getting about the buffer filling is that the header cannot be identified because the data must be garbled.

Changing the baud rate by specifying it (i.e., COM8:11500) will never work. This is because the camera transmits at 3,333,333 baud, not 115,200.
PRO
Canada
#62   — Edited

Quote:

Changing the baud rate by specifying it (i.e., COM8:11500) will never work. This is because the camera transmits at 3,333,333 baud, not 115,200.
We were able to get 115200 baud to work, proof is in the video you and I did when we were testing for Will. The frame rate was just much slower. Or was this a custom version of the software that allowed it?

PRO
Synthiam
#63  
That was a custom firmware 

uart serial requires both parties involved in the communication to have the same baud. The baudrate is how fast the two devices transmit and receive. If one is not at the same baud as the other, there’s no way either can understand each other. 

this is because one is speaking a different speed than the other. They need to speak the same speed or it’ll never work. 

what’s happening with your setup is there’s data, but it’s skipping bytes or being garbled. That could be due to a slower USB port or the uart usb converter. 

the ARC parser is looking for a header which is EZIMG. It needs to find those 5 characters. Then the next 2 bytes is the packet size as an unsigned int. 

if the data is missing bytes or garbled, it’ll never find the text EZIMG and therefore just continue receiving what ever data is on the wire. 

If you want to test it at a different baud rate, then use an esp32 cam with the firmware I made a few months ago. There’s a version of the esp32 cam that replaces the ezrobot camera and can connect directly to an ezb. But rather than connecting it to an ezb, just connect it to your uart adapter. 

In that firmware, you can change the baudrate to what ever you want including 115200
PRO
Canada
#64   — Edited
Understood, I thought the camera might have a variable baud rate, my mistake. I forgot to mention that I also shortened the wires on the PL2303TA but it didn't seem to have any effect. I also did verify that it was actually communicating properly using an Arduino Pro mini. I was able to program it. At this point, I'm going to see if I can get my hands on a PL2303HXD or equivalent or try with another computer. 

User-inserted image


*Edit: Yeah thinking more about it, I feel that it's likely the advertised baud rate of the PL2303TA is likely not up 6Mbaud, or maybe it is under very strict circumstances. The PL2303GC and PL2303HXD are rated to go to 12Mbaud so that's much higher than 3.3Mbaud, I have much more faith that those will work.
PRO
Synthiam
#65  
when you tried the rx and tx together for the terminal test, did you set it to 3333333 baud?
PRO
Canada
#66   — Edited
I hadn't done that, I believe I tried 3,000,000 and it worked. Anyway, I just tried the PL2303TA at 3,333,333 baud now and it worked with RX/TX jumpered.
PRO
Synthiam
#67  
Try the esp32 cam firmware and modify the code for a lower baudrate
PRO
USA
#68  
Sorry, Jer just had the time to respond. You might be right, the two heads in the science museum in Kuwait are on much older EZ Builder software. I can't remember if the heads at home are using this setup, I won't be able to check for another 2 months.

Hopefully, you have better luck with a newer laptop like I did, or get yourself the PL2303HXD or a completely different brand. Although I did have trouble finding one that was that high of baud. (maybe more avail now i think that was back in 2017/2018?)

Good luck!
#69  
Jeremie,  and the rest of you folks that are working on this question I posted please understand that I would love to know if this could be done, I really don't need this solution anymore because, I followed DJ advice and purchased another USB camera for my current Inmoov build.  I will find another use for my EZ-Camera in some other build.

I just don't want you to pull your hair out on this on my account...
PRO
Canada
#70   — Edited
Well, @smiller29 even though it isn't of immediate benefit I wanted to see this problem through to its end!

After investing in 3 different USB-to-TLL adapters and doing quite the hack to the third one, which was supposed to be a USB-to-RS-232 adapter, today I was finally successful! 

User-inserted image

User-inserted image


The only PL2303HXD chip I could find available was on an RS-232 adapter so I had to make it work. I removed the RS-232 chip and ohmed out the pads where the PL23203HXD RX, TX, and GND pins went to and soldered on some jumpers. I connected everything like Will did, except that I didn't even need to attach the camera RTS to GND, and it worked right away. All I had to do is to connect to COM3 in the camera skill and the picture appeared. It even looked great! No artifacts. Nice and crispy!

So word to the wise the FT232RL, PL2303HXA, and PL2303TA UART-to-TTL adapters aren't able to communicate at the 3.33 Mbaud needed by the EZ-camera but it seems that the only UART-to-TTL chip that can is the PL2303HXD (and possibly the PL2303GC - untested).

Thanks to everyone who contributed, and Will who originally posted the tutorial!