Usually when I power the BlueROV there are two sounds/beep/melodies. However, if I connect a Reach Alpha manipulator from Reach Robotics only the first beep sounds and the second never sounds and the ArduSub (and/or BlueOS?) does not start. I am asuming these sounds indicate when the startup procedure is OK.
1.- What does the sounds actually mean?
2.- Any ideas of what can be causing these issue? I think it might be a power issue.
Any possible solutions?
I am using a BlueROV with a Heavy configuration (8 thrusters), a Bluerobotics Navigator Flight Controller and a Raspberry Pi 4. So far if I unplug the manipulator everything works fine. The manipulator is powered with the same battery as the rest of the BlueROV components. The manipulators serial communication cables are not connected to the Raspberry nor the Navigator Flight Controller, these cables are connected through the tether to the surface PC.
I’m assuming you’re talking about the beeps that the Basic ESCs cause the thrusters to make when they
detect they are connected (three rising tones to indicate the three motor phases), and
confirm that they are receiving a valid PWM input, and that it is neutral (1500µs) so the ESC can be armed (two longer rising tones)
If you’re hearing the first set of beeps then the ESCs are receiving power and detecting the thrusters, but if the second set is not happening then the ESCs are not receiving the expected input, which likely means ArduSub is not starting, or there’s significant electrical noise on the signal wires.
If the onboard computer (Raspberry Pi) is not receiving sufficient power then it will fail to start, in which case BlueOS will not run, so then ArduSub cannot be run with the Navigator, so no output signal will be sent to the ESCs. That said, if the manipulator is powered directly from the battery and has no connection to the 5V electronics then this seems somewhat unlikely, unless there is a short circuit in the manipulator or your wiring or something that is drawing huge amounts of current.
If possible I would recommend measuring the battery voltage when the manipulator gets plugged in, and checking that the Navigator stack is receiving a steady 5V. You can also try checking if the BlueOS web interface is accessible.
If BlueOS is running normally, and reporting ArduSub as running, then the main option I can think of is electrical noise on the ESC signal wires. You could measure that with an oscilloscope (if you have access to one), but could also try moving the manipulator’s signal and power wires away from the ESCs, and/or adding electrical shielding between them (like aluminium foil).
Solutions generally rely on determining the issue first, so it’s hard to give a definitive answer at this stage.
Thanks for your response. Power measurements are normal.
I ran more tests and I found out the problem was caused by some electrical noise produced by the manipulator’s power wires as you suggested. I rewired them to be away from the ESCs and now the BlueROV starts correctly and the systems run well, however I found out another issue:
After everything starts correctly if I run the manipulator’s control interface (Reach Control) it works as intented, however if, after running Reach Control I open QgroundControl then the manipulator gets disconnected from Reach Control, and when I close QgroundControl it reconnects again.
Some considerations:
The BlueROV communicates with my surface PC using the default UDP connection via a tether.
The Reach Alpha manipulator communicates directly to the PC using a serial connection (RS485 to USB).
The manipulator is not connected to any BlueROV electronics except the power terminal block.
The manipulator can be moved using low level messages from a script in python. The problem is visualizing the arm data in real time with the interface.
Let me know if you can help, otherwise I will contact with Reach Robotics.