I hope this email finds you well. We recently purchased Blue Robotics components for an underwater robot project. It includes navigator, thruster, enclosers, and other essential parts. Currently, we are developing a single-thruster underwater glider and have encountered an issue during the setup and we hope you can help us.
We have set up the Navigator and Raspberry Pi, configured BlueOS via Ethernet, and attempted to control a servo motor using an FrSky transmitter paired with a receiver connected to the Navigator. We were trying to actuate the servo in 1st channel of the receiver. An external 5V supply is provided to the AUX pin, configured the ArduPilot parameters (Servo1_function = RC1N, Servo1_Max = 2500, Servo1_Min = 500, Servo1_trim = 1500) and the servo connected to PWM Channel 1 does not respond to transmitter input after arming the setup in BlueOS. Though the servo works fine if directly connected to the receiver but not using the Navigator.
We had also setup the transmitter directly via USB to the PC—Cockpit, to check the joystick input, but the servo remains inactive even after setting the axis as RC Channel 1. We have gone through these articles from your website during the setup.
Are there any alternative methods to resolve this issue? Is the because of signal-mapping or incorrect setup ? Additionally, we are exploring using VS Code and Jupyter Notebook extensions—could these tools help map the signals effectively?
Your prompt guidance would greatly help us move forward with our project. Thank you for your time.
About the direct connection to the RC, and Navigator setup, @williangalvani will be more of a help than me.
About the Cockpit side of things, you’re connecting your RC Transmitter to your computer via USB, right? If so, can you access this website and take a screenshot of the screen? Also try moving your sticks and using the buttons to see if everything works as expected.
In Cockpit, is the joystick icon in the top-right corner turning white when you connect the joystick? You just need to click a button or move a stick after opening Cockpit for it to light up.
Can you add a couple of Plotter widgets in Cockpit, and set them to RC_CHANNELS.chan1_raw and SERVO_OUTPUT_RAW.servo1_raw? That should allow you to see the input the Navigator is receiving (e.g. whether your communication hardware is working and set up correctly), and the pulse durations it is trying to output to the ESC (e.g. whether the autopilot is configured as you want it to be).
I believe arming only affects MotorN values for the servo output functions, so this shouldn’t be relevant - all other output types are active at all times.
By the way, I am curious how this is connected, and whether you’re testing it in air or water.
Thank you very much for your prompt and detailed response. We sincerely appreciate your guidance, and we followed your instructions carefully. While we were able to make progress initially, we are now facing another issue that is proving to be quite challenging, and we are reaching out in the hope that you can assist us in resolving it.
We are currently using an FrSky RX8R receiver along with a Taranis X7 transmitter. Channels 1 and 2 were assigned in the transmitter, and we configured axis 0 and 1 in the BlueOS Cockpit accordingly. After uploading the standard BlueOS rover parameter set to our system, we armed the system and performed a test. At this stage, the thruster connected to PWM channel 1 and the servo connected to channel 2 both functioned correctly.
The issue arose when we connected the transmitter directly to the PC via USB and repeated the same procedure. In this setup, both the servo and thruster responded simultaneously to any input provided, regardless of how the inputs were assigned, which was unexpected. The problem became more severe when we disconnected the transmitter from the PC and relied solely on the receiver. Despite the system arming successfully, neither the servo nor the thruster provided a proper response, and their behavior became unpredictable and inconsistent.
We are currently unable to proceed further due to this issue, and we suspect that there may be a problem with the receiver-transmitter integration or how the PWM signals are being interpreted. We would be extremely grateful for your guidance on how to address this situation and ensure stable and accurate control using the RX8R receiver and Taranis X7.
Thank you once again for your continued support.
Warm regards, Njanaprakasam K.S.
(On behalf of the development team)
We’ve been working on getting our RC setup to communicate properly with the Navigator board, and over the past few days, we’ve tried various approaches to troubleshoot the issue. We tested with both QGroundControl and Mission Planner, and also used a **433 MHz 500 mW telemetry module for the connection.
From what we observed, the receiver is successfully responding to our transmitter inputs—we can see that it’s generating output. But the problem seems to be that the Navigator board isn’t picking up that signal, or at least it’s not passing it on to the PWM channels as expected.
We’re wondering if there are specific parameters that we need to configure—like SERIALx_PROTOCOL,SERIALx_BAUD,RC_PROTOCOL or RC_OPTIONS to get the RC input properly routed through the Navigator.
If there’s a specific procedure we should follow for this within BlueOS, could you please help us out with that?
Thanks in advance for your help—we really appreciate it!
Best regards,
Njanaprakasam K S
(On behalfs of our development team)
Hi @Njanaprakasam -
Can you share your intentions for using RF communications with a subsea vehicle? Are you operating at the surface? Once the vehicle submerges, no RF signals will reach the system, are you routing them another way in this circumstance?
ArduSub expects a TCP/IP telemetry connection, with joystick control routed from the control computer over this link. ArduRover has RC controller support, which was recently added to ArduSub, but again once your glider goes underwater, signal will be lost!
Does your RC Receiver support SBUS? How is it connected to the Navigator? From the BlueBoat FAQ:
“Any receiver that supports SBUS can be connected to the Navigator for use with ArduRover 4.4 and later. To use, connect the SBUS to the RC port just above the 6.6V ADC input on the Navigator. Then, make sure there’s nothing connected to Serial1 (this cannot be used in conjunction with SBUS input.) Set SERIAL1_PROTOCOL to RCIN, and set RC_OPTIONS to 36. Restart the autopilot and perform the necessary calibration and setup of the RC controller in QGroundControl.”
In response to your earlier question, our objective is to develop an underwater single-thruster glider designed for scanning and collecting underwater data. As an initial step, we aim to operate the system at the surface level to establish communication with GPS. Once surface testing is complete, we plan to proceed with underwater trials, utilizing a surface-mounted GPS for localization.
Our receiver, the FrSky RX8R , is successfully paired with the Taranis Q X7 transmitter and supports SBUS OUT. As per your instructions, we have configured the relevant parameters, and we can confirm that the signal is reaching the appropriate PWM channels.
However, we are currently facing a new issue: the PWM channel appears to be receiving unwanted or noisy signals. When operating the servo via the transmitter, it responds as expected. However, even when the transmitter is inactive, the servo continues to fluctuate erratically. This suggests that some form of unintended signal is affecting the servo.
To investigate further, we connected the system via telemetry and used Mission Planner v1.3.76. During servo calibration under the Setup tab, we observed that the PWM channel output values were fluctuating even without user input.
We would greatly appreciate your guidance in resolving this issue. At present, the system powers on and becomes active, but it remains unstable when disarmed. Even when armed, the system does not respond consistently. The only scenario where the servo and thruster respond properly is when we explicitly set SERVO1_FUNCTION to RCIN1 and SERVO2_FUNCTION to RCIN2.
We look forward to your suggestions to stabilize the PWM signal and ensure reliable system performance.
