Hi all,
I am planning a submersible build. I want to use an off the shelf camera, two BR thrusters, and two BR lights. The camera will require cat5e. I am looking for a cable type that can accommodate cat5e plus the controls for the lights and the thrusters.
The tentative plan is the following: the underwater housing will have the battery, the camera, the board, the drivers, and an extender transmitter balun [ for USB from camera to cat5e]. Up top, the other transmitter balun will accept the cat5e, and output USB which would go into a laptop.
It’s just a tethered cylinder with a hi def camera that uses thrusters to rotate about 350 or so degrees.
Hi!
If you use BR concept with Fathom X you only need one pair, use BR Slim tether.
If you want your own ethernet solution, use BR regular 4 pair tether.
One option here would be to order a custom cable (from a cable manufacturer) with different wires for the different purposes. A more common approach would be to use ethernet communication along a tether, which then goes through something like an Ethernet Switch, which splits out relevant signal to the camera(s) and the other peripherals (likely via some form of onboard computer like a Raspberry Pi).
Depending on your tether requirements, it may be helpful to use something like our Fathom X boards, which allow an ethernet signal to be transmitted over a single pair of wires (like our Fathom Slim), instead of the four pairs in a cat-5e cable (like our Fathom Tether), as @Boko suggested.
I’m not sure how your camera stream is encoded, but if you already have a Raspberry Pi (or similar) onboard then you can potentially use that to pass the video stream on to the tether connection. A Raspberry Pi has GPIO pins that can be used for sending PWM signals, so it should be possible to use that to control the thrusters and lights (with some code)
Ok Thank you. So if I use the Fathom X boards and the Fathom slim tether, I would be running the camera on one pair of wires out of a total of four pairs. That leaves three pairs for the thrusters and the lights.
In this scenario, I would need a board and drivers for the light and thrusters and then the fathom x boards to run the signal from the camera to the surface?
Is there a resource that you are aware of to get a better sense of how to put all of these pieces together? For me, the housing is the easy part. It’s the electronics that I have to figure out.
No, the Fathom Slim has only a single twisted pair inside. If you’re using a USB camera that has a H264-encoded output option then it should easily be able to be streamed via the Raspberry Pi. It should also be possible to control some lights and thrusters via the Raspberry Pi, although it would require some custom code to get working.
the specific Raspberry Pi pins to connect the lights and motors to will depend on the controlling code
the thrusters and lights would actually be outside the enclosure
the battery may be in the same enclosure as the electronics, or in a separate one
while our camera would be inside the enclosure, a depth-rated waterproof camera may be outside the enclosure
if you wanted to use one or more IP cameras, an Ethernet Switch would go between the Fathom-X and the Raspberry Pi, and the IP camera(s) would connect to that instead of the Raspberry Pi’s USB port(s)
This comment may also be relevant/useful to refer to for understanding the software requirements
Thank you Eliot. Would the quality of the signal to the computer degrade over a certain distance? Part of the motivation for this project is to get really good video quality. That’s the reason I didn’t want the camera looking out of a dome, or from inside of an acrylic cylinder. (These would have been much easier I think, because I could just rotate the camera inside, without having to rotate the entire sub.)
Hi!
Video quality will not change over distance.
But you will have a maximum distance where you can keep the bandwith.
For full HD (1920x1080) there is no problem to at least 300 meters.
It’s a digital signal, so it’s not any issues that are caused will be due to lost/corrupted packets, from electrical noise or insufficient bandwidth. Effectively, any frames that get through will have the same quality regardless of distance (which is what @Boko was referring to), but if the tether gets too long there might be some missed or damaged frames.
I don’t believe you mentioned that earlier - does that imply you’re using a flat window, or is your camera external and has a waterproof lens? If it’s the former, you may be interested in this:
Hi Eliot, Sorry to revive this two years later it just seemed easier because all the information is here. I have this diagram that you provided above and I’m starting to build this camera. I need a way to control the thrusters and the lights using the above configuration.
You mentioned custom coding… did you mean custom coding in the Raspberry pi to control the lights and thrusters? I know pixhawk is being retired. Is there an easier way to arrange control over the lights and thrusters using ardusub?
Hi @jim_p -
If you’re only intending to control two thrusters and the lights, you could plug them directly into the Pi and setup the appropriate pins in your own (python?) code to output servo-signals to them. If you want all the magic that is QgroundControl, Cockpit, etc. without writing any code, you would need a device to install Ardusub on. This could be a pixhawk (legacy) or our Navigator hat for the Pi. This would let you run Ardusub, pick the correct frame-type for your build, and eliminate the need for any custom code. I hope that helps clarify things for you!
Hi Jim -
To clarify the pixhawk lumen situation.
A standard pixhawk should work with Lumen lights without issue.
Our supplier of pixhawks at one point provided us a batch of hardware that would cause flickering, due to a defective chip.
Generally, past ROVs that shipped with Pixhawk hardware, or Pixhawks purchased from other vendors should not have this issue.
We updated the warning on the product page for the pixhawk to specify this, and if they are again made available from our stock they would indeed have the flickering issue with Lumens.
Hi Jim -
If you’re going to use a full autopilot, the Navigator may be a safer, if more expensive bet. However it’s worth noting that you can connect lumen lights directly to a Raspberry Pi GPIO pin, and using basic libraries easily generate the PWM Servo style signal necessary to control the light and/or thrusters. The autopilot provides more GPIO pins, and critically breaks out serial ports and hosts motion sensors - all things you may not need for your drop cam? Unless your drop camera has more thrusters than dedicated GPIO pins available… 2x thrusters and lights should be easy to accommodate!
Hi,
The wiring diagram that I have from this forum shows the ESC to Raspberry Pi connection having a plum wire. But the ESCs have a pair of black and white wires. Likewise, from the same diagram, the 5V/6A power supply to the Pi is a blue wire and a yellow, but that power supply has two pairs of red and black twisted wires.
I’m trying to figure out these attach to the Pi GPIO. (Without wrecking anything.)
Also: the header housings on these connections have 3 receptacles. I’m guessing that I will have to ditch these and make each wire a single connection?
Hi @jim_p -
The ESC wires should be connected with the black wire to Ground, and the White wire to the pin you intend to output the Servo style PWM signal on. This same style signal is used to control the Lumen lights via the yellow wire. The black and red wires from both ESCs and Lumen connect to battery voltage directly.
The Raspberry Pi can receive 5V on it’s header pins, we typically used pin #4 & 6 for this before the Navigator provided another location to connect power (these are closest to the corner of the pi, on the outside edge):
No need to move the connectors from their 3 pin connectors! You can plug it in with the empty port at the very end of the pin column.
You should only need one of these connectors to power the Pi - you could use the other to distribute 5V to any other loads that may need it.
