was able to test in a pool but kept losing connection every time the thrusters engaged. Everything is from blue robotics. Running heavy configuration.
The power system wasnt delivering enough so i added a step up and then a step down converter.
24/12-Volt 70 amp DC-DC Converter. 16 volts at the rov. Im not getting any kind of connection at all with qground.
The computer just updated to macOS 12 Monterey
Fathom x top side illuminates showing the “Power” and “Link” status. Link status does go out after a few seconds.
I’d recommend reading the first few comments in this thread to see a few strategies for limiting power usage by the flight controller, and making sure you have a sufficiently high capacity supply/regulator for the onboard computer to operate without disruptions.
What’s the current-capacity of the converter at each end, and have you considered voltage drop through the tether? This comment may be a useful summary for the parts to consider when determining topside powering requirements and efficiency. In particular, a single T200 thruster at 16 V can use up to 24 A at max throttle, so running 4 or 8 thrusters at once would need significant throttle limiting to avoid under-powering and shutting down the control electronics.
I’ve been using Monterey for several months without issues, so that shouldn’t be a problem
Mine only does that if the tether is disconnected or something equivalent (e.g. the Fathom-X in the vehicle has insufficient power to communicate).
I brought this up internally and the main suggestion beyond ensuring you have sufficient power is checking that the FXTI is connected to the same tether pair as the Fathom-X in the vehicle.
It’s sometimes possible to get a low bandwidth / intermittent connection across pairs because of cross-talk, so making sure both ends are actually on the same physical wires can be a significant improvement.
Recapping, our system will power up with a transformer (120 VAC) through a series of two converters:
Input voltage: AC 110-220V ± 15%
Output: DC 0-24V 20A.
Rated power: 480W
Input voltage range 18-35 Volts
Output volage is factory set to 13.2 Volts but can be user adjusted between 10 and 15 Volts
Continuous output current 70 Amps
Max momentary output current 85 Amps
Off load current < 20 mA
This architecture allows us to supply at the end of the line around 15 volts at 70 amps to our system, this due the amount of power needed for 8 thrusters. It was designed taking considering power loss through the power line (200ft). This works at high current, but at low current, the power loss is minimal, thus, at the end of the line we can perceived a higher voltage (higher than recommended). I comment this because is relevant.
We always suffer of connection loss between the host computer and the companion (Pixhawk), we granted this behavior due the lack of power (of our previous architecture), power that was directed to the thrusters, that is why we came up with this configuration.
The issue is that after some tests, we couldn’t connect any more the Pixhawk/raspberry to our computer. We thought that maybe one of them got damage, but testing in a windows computer, everything seems fine.
We flashed once again the raspbian image to the raspberry, but couldn’t connect to the Mac.
We reset the Mac network configuration, but now we are not seeing the Ethernet option on the Mac to do the network configuration as said by the blue robotics network settings post.
Mac settings : macOS 12 Monterrey.
Mac issue is not something that correspond to this blog, but, and idea of why we are not seeing it?
If you’re able to connect fine to a different computer then the issue is with either the hardware or software (e.g. configuration) on your Mac.
There should be a USB 10/100 LAN element in your Mac’s “Network Preferences” page, corresponding to the FXTI connection. If that is not available, or not connected (red instead of green), then there’s a problem with either your FXTI, the USB B to USB A cable between the FXTI and your computer, or the USB port or hub being used on your computer.
Assuming the connection is working well to a different computer as you described, then you should probably try a different USB port or hub with your Mac, since the rest of the system is the same.
Nothing has ever been removed since we originally tested when it comes to those wires. if I recall its the light blue wires and one has white line on it.i checked that every time thinking maybe they are crossed.
when we were delivering very minimal power we had a power drop out and disarm on QGC.
I can hook the pixhawk up to my desktop. FYI I have double everything in case something broke. Pixhawk runs as it should with the windows but doesn’t connect with Mac at all. The ports are working fine with everything else I’ve tested on them so that eliminates that.
At first when I was running very low voltage I lost connection due to power loss. Now I can’t get a connection at all. I just discovered the fathom x on the rov had 0 voltage to the tether. Just trying to get stabling any connections currently.
Ok, is it configured to IP 192.168.2.1, with subnet mask 255.255.255.0?
To clarify, are you saying when plugged in by itself the Pixhawk shows up on a Windows computer, but does not come up when plugged directly into a USB port on the Mac? But also that the Mac USB ports have seperately been tested with some other device that did work correctly?
Not sure what you’re referring to by “tether x board wire connection” - could you explain what’s on your tether lines, and how the data and power are connected at the vehicle end?
The Fathom-X inside a BlueROV2 is generally powered directly from the battery, which in your case should be from the output of the step-down converter between your tether and your vehicle’s electronics.
You should have permissions to, so perhaps the photo is too large, or has an unusual file extension? Are you getting some kind of error message when you try to add it? If possible try uploading a jpeg.
Where is the 4.7 V?
Separately, do you have a 5V supply/converter somewhere for powering your Raspberry Pi? We generally use a 5V 6A supply to ensure there’s sufficient capacity to power the Raspberry Pi + Pixhawk/Navigator + camera + camera servo. If there’s insufficient power for the Raspberry Pi then it won’t be able to communicate with the topside.
It you’re talking about the voltage across the two tether wires, the Fathom-X output over the tether is a differential high frequency analogue signal, which will be difficult to measure without an oscilloscope. I just checked with a cheap multimeter on my working system and the voltage between the Fathom-X’s “Tether Input” + and - was showing up as <10 mV.
Tested all ports today. All are working. No lights were on the fathom x tether interface board so I replaced it. Now I am getting two green lights on the top side and at the rov. Also replaced the pixhawk that would some times connect to windows. Do I need to have different firmware for different operating systems?
Ok, so most likely the hardware connection from the onboard Raspberry Pi to the topside is working (although if you bought your Fathom-X boards between May and June this year you should do a quick check for this issue).
From there it’s a question of topside network configuration, and the software running on the onboard computer. If the network configuration is correct then assuming the onboard computer is working properly and running expected software you should be able to access the web interface at http://blueos.local or http://192.168.2.2 if you’re running BlueOS, or http://192.168.2.2:2770 if you’re running the old Companion Software (the web interface may take a minute or two to become available after turning on the vehicle). If that doesn’t work then your SD card may be corrupted, in which case you can try flashing on replacement software (BlueOS or the old Companion Software).
Once you have access to a web interface you should be able to see if there is a vehicle registering as connected, and a camera for the video stream. If those are present then try QGC and see if it shows the video stream and the vehicle telemetry.