@EliotBR I updated the Qground control, still the same problem. In the preview of the BlueOS is fine and in the QGroundControl it isn’t.
1 Like
@bajaMike you said you were curious about the logs, here it is:
Just when I start QGroundControl this appers:
Do you guys have more suggestions?
1 Like
No updates here - I am hoping to put a full day into it in the coming week, but am honestly past my depth in troubleshooting. I think disassembly and trying to just get the RPi and the camera working standalone is the next step for me.
1 Like
Hi @mdares, welcome to the forum 
Apologies for the delay on this.
A couple of questions to clarify:
- Can you specify which camera you have?
- If it’s a USB camera, does it work / is it detected when you connect it to a normal computer (e.g. in your operating system’s Camera application)?
I believe there’s an issue we’re investigating at the moment of some of our USB cameras dying due to a Raspberry Pi firmware problem, but I’m not certain if that’s what you’ve run into here.
@EliotBR I am back at work this week and will find some time to answer your questions. Sorry for the delay. I know the connection between the camera and the Pi is by a ribbon cable.
Ok, that’s a Raspberry Pi camera (not a USB camera), which is not supported in BlueOS 1.0 (the latest “stable” release).
If you turn on Pirate Mode you should be able to update to a recent BlueOS 1.1 beta version (from the Version Chooser), after which there’s a new settings icon in the bottom right of the Video Streams page where you can enable Raspberry Pi camera support, then reboot BlueOS and the camera should be detected.
Note that there are quite a few interface changes from 1.0 to 1.1, including a different way to control Pirate Mode (so that you can turn it off once you’ve updated).
@EliotBR So this all seems to have worked (I was able to enable legacy mode) but getting this message when I hit the video streams page:
And QGroundControl does not connect to video either - everything else seems fine.
Can also confirm:
I was able to login to the host PI OS and take a photo with raspistill
Just got this message:
Last question - if I opt to try out the USB Camera - do I need to replace the motor mount too?
This is about the streams you have configured in BlueOS, and the way you’re connecting to BlueOS. Is the Raspberry Pi camera appearing as an option in the Video Streams page (in mine it appears as “mmal service 16.1”), and is there a stream configured for it?
Our Low-Light HD USB Camera does not have the same mounting hole locations as a Raspberry Pi camera, so they cannot use the same mount.
If you have access to a 3D printer you can print a mount for the USB camera, but we do also sell an injection moulded one that comes with the relevant screws, if that’s preferred.
I’m sorry for delay in reply, but today we were working on field and issues with the camera arose again…Everything was working yesterday but today suddenly the problem with the camera came up again. We are wasting time and money. I believe that @Bluerobotics has to give some answers since the last few emails the assistance didn’t even consider us.
1 Like
@UBICA do you have some other email we can respond to? I’ve been told our support team has responded to multiple emails that didn’t seem to get through, and from the emails I have access to in our system it seems there was a similar issue last month between your email address and multiple people in our sales department.
Feel free to send an email address as a private message to me here on the forum, and I can pass it along to our email support people.
I ordered your USB Camera and reverted to BlueOS1.01 and everything seems to be working good with the camera now. Thank you!
Since this is happening with multiple people, I think it would be nice for you guys to share the solution that you found through private messages @EliotBR and @UBICA. I stopped trying to fix this issue, but when I come back, it would be nice to know if there is a common solution.
1 Like
Hi Matosinho, sorry for the delay.
We changed the camera and the video streaming started working again. One day everything crashed again and after 2 hours it started working again. At the moment we have about a 1.5 second delay in streaming but at least we have been able to get the work done. We are now trying to figure out why there is a delay and why the streaming sometimes crashes unpredictably. We will try to reinstall the newly released software versions and see if the problems are resolved. We will update you as soon as possible.
1 Like
Hello!
Thanks for the answer BTW. I took the same approach, I’ll try again in a month. What about you? Any luck?
Ah, here it is a post that might help:
TL/DR - manually change camera configuration ISP to 192.168.2.1 and unplug and restart everything after each minor update or change.
We were getting these same errors working with the BlueROV2 R1 low light USB camera using a laptop PC with Windows 10v22H2. I believe we are using Qgroundcontrol v 4.5.2, but I’d have to check. We updated to the latest master BlueOS yesterday (but not really sure what version it is since the user interface doesn’t seemingly state the current version you are running in a simple way that doesn’t leave you guessing).
We had to play around with this camera issue a lot and it seems like we started to make progress as we slowly realized we had to power down/ restart each device after each update. So I highly recommend closing your browsers and shutting down all instances of BlueOS and Q-ground control, and restarting the computer. I also recommend powering down the BlueROV2 and unplug it from its battery source and restart it.
When we had to manually add and configure our camera in BlueOS, we were using the same IP address we thought we were using in our previous (pre-BlueOS) setup. We noted the warning message above “It looks like there’s no video stream accessible from your device’s detected IP address (192.168.2.1)”.
Sorry, I can’t recall the next step exactly and I’m not on the computer we were using, but we tried both of the following to confirm what IP address was assigned to the Ethernet 2 port and to the USB.
Option 1 - We opened up Windows Settings/Control Panel/Network and Internet/Change Adapter Settings. Then right-clicked on the Ethernet 2 icon and entered the System Admin Password. I believe that was were we checked what IP address was assigned.
Option 2 - If not there, it was within Windows Settings/Control Panel/Device Manager/USB.
Back in BlueOS, under the video stream menu/configure/edit, we had to manually edit the IP address there so that it was 192.168.2.1 instead of 192.168.2.2 (I don’t recall if that IP address was automatically popped in there when we first configured it, or we typed it in, but we were going by some old notes we kept for how we set things up the first time before BlueOS.
Anyways, after updating to the 192.168.2.1 and restarting everything again and powering stuff back up, we were able to finally get video to show in Q-groundcontrol. Although it is real finicky and definitely doesn’t like the 30fps. We noticed that things seemed to stall when we selected the 1080p with 30fps combo (presumably the board or camera or cords are not rated for that plus whatever else might be drawing from it). However, when we notched down the resolution and or fps settings, we noticed that the camera and video options didn’t disappear as quickly as they did in the highest resolution and fps setting. Its buggy, and we found that closing the browser window or restarting would magically give us back some of these video and camera settings when we restarted again.
We were successful in seeing the video and camera in the Q-groundcontrol, but now I’m wondering, if BlueOS is basically trying to replicate that within its system and eventually Q-groundcontrol will not be needed? (I’m a newb, so forgive my ignorance).
As for the operation and checking our controller settings, something real wonky was happening that seemed to be a conflict between BlueOS and Qgroundcontrol where it would just arm and disarm the platform on its own and not react to our button clicks. I’m saying this here because other users reported lag in the video in this thread and we recall having that issue way back when we were first setting things up and it seemed to happen after a long day of troubleshooting the BlueROV2 on the benchtop and the core temperature was rather high (I don’t recall what exactly). We were also using a super long (300m) tether at that time. We weren’t able to get the UGPS to work with it so switched to a 100m tether. We didn’t experience that video lag afterward (but this was pre-upgrade to BlueOS). We chalked up the weird issues with controller settings to possible overheating and closed down yesterday. We will continue to troubleshoot to see if that issue gets resolved.