Hi,
I recently upgraded from Companion software to BlueOS (1.3.1) in my BlueROV2 R3, and I managed to connect to cockpit, view logs, etc. Nevertheless, I was having problems with other accesories like waterlinked UGPS and ping1D (I could not connect to them, even though I had installed the extentions and updated them).
I rememberd that during the installation of BlueOS onto the new microSD card, a “need to format” message appeared. At the moment I ignored it, but now I decided to format the microSD and reinstall BlueOS. During BlueOS set up wizard, I wasn’t able to install stable sub firmware (see photo) ( error: failed to fetch available firmware: Error: Request failed with status code 500), which I believe it didn’t appear the first time I installed BlueOS. Now I can’t control the ROV, and the lights turn on unwillingly when connecting the battery. In QGC I have video feed, but in the top-left corner it appears the “Disconnected” status. In cockpit, not even video feed.
I don’t now if this error is causing the problem, or some other step of the set up wizard, like the scrips or parameters of the ROV, which I left as shown in the photo below (no other options where available):
Hi @eri3t -
I think everything was working the first time, at least as far as your autopilot goes! That “need to format” message happens post flashing an SD card, as Windows won’t recognize the linux filesystem that was created.
I’d assume your system is using a pixhawk and a pi3?
Have you connected BlueOS to WiFi with internet, via the icon in the upper right?
There are no scripts for sub, but you will need to load the default parameters for your vehicle type. This is failing, as is updating the ArduSub firmware on the pixhawk, because of the limited system resources of this old hardware.
To correct, try navigating to the Video Streams page and removing the video device - don’t worry, we’ll add it back! But when this process is running, insufficient RAM is available to flash the Pixhawk. Once you’ve removed the video stream, navigate to Autopilot Firmware, and flash the latest stable ArduSub version. If this doesn’t work, you may need to connect the Pixhawk directly to your computer via USB to flash via QGround Control.
Once your autopilot has valid firmware, you can add the /dev/video2 device. back (H264, 30fps, 1080p, and I prefer RTSP to UDP for performance, but this requires adjusting QGC settings… it will “just work” for Cockpit tho!)
Finally, navigate to Vehicle Setup and load the default parmaters for your frame type. You can then calibrate your accelerometer and compass normally, or even from within the BlueOS Vehicle Setup page.
Once you have the ROV working as expected, we can dig into what might be the issue for your UGPS and Ping. The latter can be configured with assistance from the “surftrack fixit” extension, which validates parameters necessary for the ping sonar to send distances to the autopilot necessary for the (new) SurfTrack flight mode. The UGPS setup should follow the documentation linked in your original thread, and may require updating the software on your UGPS itself?
Hi @tony-white ,
thanks! I partially “solved” the problem.
I’d assume your system is using a pixhawk and a pi3?
Have you connected BlueOS to WiFi with internet, via the icon in the upper right?
Yes, I’m using a pixhawk and a pi3b, and I have connected BlueOS via WiFi.
I followed eveything you mentioned to update ArduSub to v4.5.3 (latest stable), and I was succesful! I was able to have video feed both on QGC and cockpit.
Afterwards I updated BlueOS from factory version to 1.3.1 (after the Ardusub update, BlueOS reverted to factory version, displaying the following message: “this vehicle is running it’s factory version of BlueOS. This generally means something went wrong, and the system reverted to this version in order to recover”). I also completed a Bootstrap update.
I then loaded the defaul parameters for my frame type (heavy) and some errors showed up (PreArm: Battery 1 low capacity failsafe), and couldn’t control the ROV:
I don’t know why but now I’m able to connect to the BlueROV via QGC, but not through cockpit (the following message appears: “Server status: Available streams arrived; Stream status: waiting…”). In top on that, everytime I access to BlueOS it seems like the Heavy BlueROV2 parameters are loading from 0. Is any of this fixable?
I still can’t connect to ping1D nor BR-ROV deepvision sidescan sonar (I was able to connect to the sonar just after the Adusub update, but I lost connection after updating the bootstrap). I haven’t tried to show UGPS data via QGC but I imagine it still doesn’t work.
This may be due to having QGC open at the same time? Or needing to adjust your Cockpit video configuration to show the correct stream - please share a screenshot of your Cockpit video settings, and make sure that the video widget (under edit interface, gear icon next to the video widget in the list) has the correct stream selected.
If by “loading from 0” you mean a progress bar appears and the parameters load, this is the normal and expected behavior as BlueOS fetches the list of parameters from the Pixhawk.
Have you tried restarting the vehicle and loading the parameters? The battery capacity error you see in QGC is due to the parameter not having the correct value (0.)
Is the WaterLink UGPS extension installed? Have you been able to reach the web interface of that system per the documentation, or followed those instructions yet?
how is the Ping sonar connected? Have you enabled it under ping sonar devices?
The BR-ROV deepvision sidescan is not hardware I’m familiar with, and it doesn’t seem to be available for purchase anymore. From what limited documentation I can find, it seems they need to connect to power and an ethernet switch, and you access the data via a web interface? This data will not be visible in BlueOS… if it comes via a webpage, you can embed this in Cockpit with an iframe widget.
It was a Cockpit video configuration issue, thanks for the info . I’m using UDP over RTSP because for the moment I use QGC, and I’m afraid of doing extra changes before having everything working properly. What does using RTSP reflect on? Does it make a huge difference? I need the ROV to work consistently for coral surveys in southern Spain, and I’m facing new problems constantly.
Yes, the day after encountering that problem it stopped (I guess because it completed to write the parameters).
Yesterday we tested the ROV in a reservoir. Everything was working except for the light commands on the joystick (lights didn’t turn on, and pressing those buttons resulted in the movement of the newton subsea gripper, even though that was not their funtion, as it’s shown below).
Buttons 14 and 15 control light behaviour (and their “shift” function doesn’t relate to newton gripper movement).
Yesterday, after the first deployement, I disconnected the batteries. For the second immersion of the day, camera tilt buttons stopped working, while I didn’t change any setting; this happened just after reconnecting the battery and opening QGC/Cockpit. I then decided to reset all parameters (see below), which only made the situation worse (thrusters stopped working properly). I loaded the recommended Parameter Sets for the heavy configuration, and it froze the ROV (lights turned on permanently, no possible control over the ROV).
Is there a relation between joystick correct functioning and these Parameters loads? It had never caused a problem before the Ardusub firmware update. Now I have camera tilt buttons functioning again, but light controls won’t work. Is there something wrong with my configuration? I’ve tried Servo 10 but nothing changed.
Yes I have installed the WL UGPS extension. I couldn’t try the UGPS yesterday, but on other occassions I could see my position in Watherlinked’s GUI, but not in QGC or Cockpit. I have a bridge connection (as the documentation says for locator U1), and I’ve followed every step carefully. Nevertheless, next time I want to do some tests, as on all other occasions Ardusub firmware wasn’t updated (although not sure if it’s related).
The connection is through a USB to serial adapter, and a green light lights up as I documented here. Yesterday the ping sonar appeared in Pingviewer and worked perfectly, but I didn’t change any setting (I’m worried about reliability, because for the moment I don’t know when something is going or not going to work).
Yes, it’s connected through ethernet switch, and visualization is through DeepView software. I contacted DeepVision, and they told me the steps to activate the sonar for the first time, which I leave here for whom it may concern, since there’s no indication in their documentation:
After installation of BR-ROV deepvision sidescan and downloading the DeepView software, you should activate the DSSP file that comes with your purchase (Settings>Sonnar Setup File> Open DSSP_BR_ROV). You can make sure the sonar is properly connected pinging it at 192.168.2.62
The fist time after installation you should select a range (if not, no image will ever show up). This is done clicking the icon right of rec/play button in DeepView software (recording properties>sonar setup>select range)
Apparently there is some windows issue if you have your wifi turned on. I turned it off and the software immediatelly started to work. Here I leave the first (and improvable) test we did:
Hi again @tony-white ,
I’ve been doing some research and I found a similar problem here. Apparently there’s some misconfiguration of the joystick controls after upgrading the Ardusub firmware, to which you suggested the following:
I’m wondering if you could explain it more thoroughly, step by step. In that case, @EricLiu downgraded from Ardusub 4.5.0 to 4.1.2. Your solution involves upgrading again to 4.5.x? I have already loaded the default parameters multiple times, and it only caused more trouble. Thanks in advance.
Hi @eri3t -
Sorry for all the hassles! I think the information you’ve been missing is how the parameters need to be setup - and resetting them has been causing you issues - like losing your thruster direction mapping and vehicle motion sensor calibrations!
Navigate to vehicle setup > PWM outputs, and verify that you have things setup for your type vehicle - a Pixhawk Heavy - the outputs should match what is listed here.
Once you have the lights1 and camera tilt configured to match where things are plugged in, and the gripper connected to the servo# you’re trying to map buttons do in Cockpit, everything should work! You may need to restart the autopilot process (from the power button in lower left of BlueOS) after changing settings to apply them.
I would guess that the parameters necessary for the UGPS to work aren’t set, as they were likely reset if you did set them when working to correct your other issues. I’d recommend verifying you can communicate with the DVL, and following the WaterLink instructions again.
Hi @tony-white ,
I’ve been following the vehicle setup for the pixhawk heavy as listed here, but my setup is slightly different (?). I have 2 pairs of lights, while in the default BlueROV2 Heavy configuration there’s only “Lumen lights” (RCIN9) associated to SERVO9. In the image below there’s an option to configure “lights 2” to RCIN10, but I don’t know if I should touch that (I want all the lights to behave in the same way).
When selecting the value for the SERVO9_FUNCTION, I have tried with “Lights 1” value, but I have no light control (in cockpit, pressing the buttons asosociated with light behavior caused the newton gripper to open/close). I’ve also tried configuring “lights 1” to SERVO 9 (RCIN9) and “lights 2” to SERVO12 (because SERVO10 AND 11 already have associated parameters according to the standard configuration). None of that has worked. I’m wondering what is that I am missing. For the moment I don’t have light control, and “lights1” apparently controls only the top pair (as seen in the 3D ROV visualization in the PWM OUTPUTS section in BlueOS). I’m completely new to this world and I feel super clumsy… it is what it is. See attached image of my current setup down below.
I was wondering if this setup must also be done in QGC, because in there I don’t have any tipe of control over the camera tilt, gripper movement or light behaviour (I do for thruster movements). I have checked vehicle setup>parameters, but I feel it’s more counterintuitive than in BlueOS and I don’t want to mess this up. Can you confirm if this configuration has to be done also in QGC? (for the moment I feel more comfortable working with the ROV over there). If so, is there any documentation for “newbies”?
Hi @eri3t -
Sorry, we only have one set of instructions and they are intended to be as straightforward as possible!
Lets compare your setup vs. the link I sent:
Please change Servo9 function to RCIN9 (not Lights1)
Please change Servo14 function to SOS leak detector (assuming you have one of those - it is good to have!)
Next, in Cockpit, verify you are mapping servo3 to the buttons you’d like to control the gripper. The buttons you want to map to light control should be mapped to lights 1. If you’d like two sets of lights, controlled with the same brightness level, you can configure another output to be RCIN9, or simply splice the yellow signal wires together so they both connect to the same pin of your pixhawk. If you want independent control, setting Servo12 Function to RCIN10 should do the trick (this means your second set of lights would be connected to Aux Out 4. )
You can absolutely modify these parameters from QGround Control, by clicking the “Q” in the upper left, selecting Vehicle Setup, and then the Parameters at the bottom of the left menu. We’re generally moving away from QGroundControl at Blue Robotics, in favor of Cockpit + BlueOS.
If you’re still having issues, please share a screenshot of your joystick button mappings in QGround Control.
Hi @tony-white ,
through trial and error I’ve managed to get lights and gripper controls working on the joysticks, but not by following your steps (although it may be me not undersanding how it works). My current parameter setup (left) and the recomended one (right) are the following:
In my case, SERVO9 function is RCIN9 (even though in the value column it’s marked as “lights 1”). In the dropdown list, RCIN9 option has “lights 1” in parenthesis. Could this be due to pin output configuration of the lights in BlueOS? (see below).
I do have a leak sensor, but I don’t have this “SOS leak detector” option in the dropdown list! Is there any other name for that function? I haven’t found any value related to leak detection. I’ve also searched for the “AUX6” option, which is the leak 1 pin by default (see below), but haven’t found it either on the dropdown list.
In my case (see photo below), buttons with the SERVO 1 function (buttons 4 and 5) are controlling gripper movement, while SERVO 3 (buttons 14 and 15) are controlling the lights. Mapping “lights 1” won’t contol the lights.
I guess this would be done from the light configuration tab (shown in the second image from this post), right? BlueOS won’t let me configure lights 1 and 2 to RCIN9 at the same time.
For the moment I’ve configured “lights 2” to Servo12, and I can control all 4 lights at the same time.
As you can see, although everything is working (except leak sensor detection), nothing seems in the “right” place.
I’ve read this post and I see some common ground (in QGC I don’t have any option to select the light output channel, see photo below). @EricLiu started having issues after upgrading Ardusub to v4.5.0, and apparently downgrading to 4.1.2 solved some of his issues. I also found these problems after upgrading the autopilot, so I’m wondering if I should do the same. For the moment it’s OK because I can work with the ROV, but the fact that I don’t know how my setup is functioning is concerning.
. I’m using UDP over RTSP because for the moment I use QGC, and I’m afraid of doing extra changes before having everything working properly. What does using RTSP reflect on? Does it make a huge difference? I need the ROV to work consistently for coral surveys in southern Spain, and I’m facing new problems constantly.
