I’m looking to upgrade our BlueROV2 from a Raspberry Pi 3B + Pixhawk setup to a Pi 4 + Navigator, and had a couple questions.
First, regarding the Navigator upgrade — on the Blue Robotics site there are a few additional components listed with the Navigator package. I’m wondering which of these are actually required versus what would already be part of a ~2022 BlueROV2 configuration.
Second, we’re trying to get the system operational for a science cruise next week using our current setup. Right now we have a Pi 3B + Pixhawk running BlueOS 1.4.3 with Cockpit 1.17.0. We’re able to connect and see video without issue.
The main problem is that I can’t get the browser-based Cockpit to recognize an Xbox controller. Windows is detecting the controller correctly (it shows up and responds in joy.cpl), but it does not appear in Cockpit. I also tried mapping controls in the standalone Cockpit app, but those mappings did not save.
Since we likely won’t be able to complete the hardware upgrade before next week, I’m mainly looking for advice on the most reliable way to get the vehicle in the water in the short term. Is there a known stable configuration for Pi 3 + BlueOS that people recommend? We have also been unable to even revert back to QGroundControl as a fallback - the video will not stream.
Any guidance would be greatly appreciated — just trying to get things working reliably for the field, and then we’ll focus on upgrading afterward.
As far as upgrading your ROV, you may need a JST-GH to JST-GH cable to go from the power module to the Navigator, as this was a DF13 connection with the Pixhawk. The Navigator lists one of these in the Contents section of what is included, so you should be all set! The only other potential gotcha is the size of the bullet connectors on that power module being different between the current and previous versions, but you shouldn’t need to swap that so it shouldn’t matter.
As for your current system - Cockpit lite in the browser should be able to see your joystick, assuming Chrome can - does it show up on this testing website? If not, it’s likely a Windows issue!
Standalone cockpit should definitely be saving your joystick mappings - are you changing the user in Cockpit? Under general settings, make sure whatever user you’ve setup previously is the one you have selected - those mappings should remain constant! Out of curiosity, what are you changing from the default controller layout?
The configuration you are currently testing with is the known stable configuration… if your video isn’t streaming in QGC, have you verified it is set to a UDP stream (default in BlueOS) under Video Streams? If you’ve changed it to RTSP there, you’ll need to copy the RTSP URL to QGC to get video streaming there…
In true Jessie fashion, I found that retrofit guide about 10 minutes after posting to the forum. Our parts are on order, including the JST GH to DF13 adapter listed in the guide.
I’ll admit user error on the controller situation. The button maps are indeed saving now, so we should be good there. We were only changing a few things, mainly adding suction sampler to the unit, as well as a grabber arm, so we needed to assign these to the bumpers and triggers. We also figured out that we can start/stop recording and take snapshots with the controller, so that was a nice improvement as well.
I had been wondering about the stream settings in QGC but wasn’t able to find documentation in our notes about the correct settings, so for now we plan to go ahead and use Cockpit for next week’s trip, as it seems fairly stable. We decided to try and earlier version of BlueOS so we’re running 1.3.1. If you think we should upgrade back to the current stable version we can, but we were concerned about the Pi3 overheating with the newer versions. It kicked us off once during testing, but that may have been because we were pumping down the enclosure while the system was already close to it’s temp limit. With that in mind, is there a way to display the core temperature within the desktop Cockpit, like it shows in the browser version? That would be quite useful for us until we can upgrade out hardware.
I would indeed recommend sticking with stable 1.4.3! Pulling a vacuum on a running system is not advisable - with no air, heat has a much harder time moving from hot to cold - you could risk damaging your device by pulling vacuum with the system operational.
If you have a widget displaying CPU temp in Cockpit Lite, it should be present in the desktop version of Cockpit, assuming you’re using the same user profile in both sessions?
In an interesting turn of events, when I went to boot everything up this morning (and everything worked last night - camera, buttons/mapping, aux instruments, etc.) I had a different issue with the controller entirely. It connected and the button map was saved, but only a few of the buttons were actually working - i.e., only the two trigger buttons were working and lighting up in cockpit’s controller window, though the maps were correct. Then later, is just randomly started working again and I got button functionality back. We are at a loss as nothing changed from the previous evening.
Also, it seems odd that the standalone cockpit app can’t establish communication without first opening the ip/browser cockpit. A strange bug.. but at least for now we have a quick fix.
We are also getting a lot of compatibility warnings when opening cockpit, and I don’t really know what any of them mean. It’s hard to keep track of them all in real time too. Is there a log file that we could send over for review?
Yes, please attach a .BIN log file found under log browser.
Your controller issues sound like a low battery in the controller, or a unit that has been splashed before. I’ve killed quite a lot of controllers with a bit of moisture…
Under Cockpit settings / General / vehicle network connection are you using blueos.local or the 192.168.2.2 IP address for the vehicle?
Hmm, I only see .tlog files under the log browser in BlueOS. I tried to attach them here but it tells me that new users cannot upload attachments. Let me know if I should be looking somewhere else for .bin files - is there a log file that I can access via cockpit (desktop)?
I see the vehicle network connection setting and the default was “blueos-avahi.local”. I changed it to 192.168.2.2 and it connected to the vehicle right away but video did not, until I opened the browser version again, then it connected in the desktop version right away.
Re: the controller - we are connected to the laptop via cable. Is that comm only or is it powered too? This will be quite humbling if it’s comm only… we joked about it being a battery issue yesterday. As of this morning my buttons all work again (did not change batteries). I’m scared to touch it until our trip next week, but we’ll attempt a tank test today.
Hi Tony! Here are my logs from this morning. Naturally it threw another wrench at me, and I had to restart Cockpit after establishing video with lite for video to show up in app.
We are using an Xbox One controller. We updated its firmware yesterday too, hoping that helps with the button situation. As of right now, the buttons are all working and correct in the app. No controller shows up in lite, but as long as the app works, I’m okay with that. I’ll be on the water all day today (launching a data buoy!) but I can forward any response to my colleague on shore @pantherrov if he has some time to continue working on this today. Thanks so much!
Can you download the BlueOS logs and share those? You can find them with the gear icon in the lower left of BlueOS. It seems there may be an issue with the video process (Mavlink Camera Manager.)
To confirm, what OS are you using on your computer (Mac, Windows, Linux) and what browser are you using to open Cockpit lite?
