Hello, I am using a “Navigator Flight Controller” from BR with BlueOS.
I want to move two of the PPM signals from the local PCA9685PW (Navigator Flight Controller pwm ic) to an external PCA9685PW, both PCA9685PW are on the same I2C bus. This means I need to assign a different I2C address to the external PCA9685PW. In short: I have four thrusters, and I want to split them between two PCA9685PW chips.
Will BlueOS be able to operate correctly in this setup? If so, what steps do I need to take to ensure it works properly?
This is not so much a BlueOS question as it is an autopilot firmware question. ArduPilot (the firmware family that includes ArduSub which we use on our ROVs, and ArduRover which we use on our boats) does seem to have support for multiple PCA9685 chips, but it’s unclear to me whether additional ones would just be considered as extensions of the available servo channel outputs or if they would only be available for LEDs.
We haven’t tried this, so it’s not obvious. It’s possible the extra chip automatically registers as additional servo channel outputs, in which case you would just need to configure its I2C address to one that is checked for, then configure its outputs using the SERVO17-32_* parameters. If that’s not the case then you may need to define a custom hardware setup (e.g. based on the Navigator, but with an extra PCA9685 chip), and build a custom firmware using that hardware definition.
You may be able to get a clearer answer on the general ArduPilot forum, as it’s more likely there’ll be someone there who’s familiar with those aspects of the firmware.
I’m curious what’s motivating you to move two signals to an external PWM generator? Are the 16 channels available on the Navigator not sufficient? I2C is not a great protocol for carrying signals any kind of significant distance, so I’m not sure how well would things would work even if you took the steps Eliot outlines…
I am experiencing noise issues with the PPM signal, for example, the “Lumen Subsea Light” from BR. The noise on the signal is so severe that the algorithm on the microcontroller (Tiny45 - inside the lights) cannot distinguish the PPM signal from the noise, resulting in flickering of the lights. It should be noted that this occurs when there is a ground fault in the thrusters. However, I do not want the lights to serve as a ground fault indicator. For example, if I placed the PCA9685PW chip inside the LED lights, the lights would behave differently. If no signal comes through due to corrupted I2C packet, the lights will remain in the state set by the last I2C packet. Alternatively, we can skip the PWM chip and configure the Tiny45 as an I2C slave. However, this is a different discussion; the lights are as they are (and we need one wire more on the lights!).
Regarding I2C, I generally have good experience with it, and it can be made more robust. One option is to use I2C extenders such as the P82B715 gives us 50m I2C on a twisted-Pair.
Moving the PPM signal generator to the Lumen, and relying on I2C just doesn’t seem like a workable solution to me! In general, I’ve not seen Lumen lights flicker like you describe so I’d suspect a different issue that may be possible to resolve. The servo-style PWM signal is typically very robust to long wires and noisy environments!
Can you share what revision / how old your ROV system is? Are you using the Navigator in your own ROV, or a BlueROV2 kit?
What type of thrusters are you using? By “ground fault” do you mean the thruster windings are leaking voltage to the water? Is your battery or power supply ground also connected to the water?
Any details on your wiring or setup, including pictures, would be helpful in troubleshooting.
We are not currently using BR thrusters (or ESC), but we are in a transition phase that will enable us to operate with multiple types, including BR thrusters in the future.
Yes, we observe cracks in the epoxy, which allow saltwater to leak in. We input 380V DC and step it down to 24V using a galvanically isolated DC/DC converter. The ROV chassis is not connected to ground. What happens is that we experience capacitive coupling to the electronics. The entire setup “shakes.” This is due to the combined effect of the dielectric constant of saltwater (approximately 80) and oil (approximately 2), which we use in the ROV. And of course, the saltwater conductivity .
Trust me on the flicker—it’s definitely there. We have a good filter on the 24V supply to the lights, providing a relatively stable 24V. However, the PPW signal is quite noisy. I believe adding a ferrite bead could help improve this issu e.
When it comes to the PPM signal, can one solution be to convert the voltage signal to a current signal? By putting a resistor in series and having an optocoupler inside the light? in princip le!
Regarding the light and Tiny45 and its port PB0, it is most natural to set it as PCINT0 and not AIN0. I don’t know the exact impedance for PCINT0 (CMOS input), but it should be very high, around 100 MΩ. The PPM signal has a relatively high input impedance. The signal sees 300 kΩ at port PB0 itself. So a voltage to current can be a solution?
