Hi,
I’m slowly plugging away in setting up the electronics, companion and camera system. I’m running into an issue where in BlueOS, I can see that it is streaming and the camera is detectable.
However, at the top, I also see the following message:
This message is the same if I change the endpoint to udp://192.168.2.1:5600.
When I start Cockpit and head over to Video, there are no Streams being mapped:
I came upon this thread: https://discuss.bluerobotics.com/t/usb-camera-setup/16802/9
but still a bit lost - Do I need to add a stream via RTSP like Tony mentioned - or did I miss something not related?
The hardware that I am using is:
Innodisk EV2U-SGR1
1920 x 1080 @ 30fps
low-light
USB2.0 and UVC-compliant
Companion Computer: Raspberry Pi 4b
Regards,
Ron.
Hi @blacksheep -
It looks like your camera only has an MJPG stream available - do you see a /dev/video# device that has H264 available?
While (limited) MJPG support is available, this type of video is not compatible with QGround Control, and only works with Cockpit in limited circumstances - @joaoantoniocardoso can comment on this. It also uses an incredible amount of bandwidth! If H264 is not available from your camera, your best option may be using a different camera…
The thread you link to was referring to RTSP in reference to IP cameras that make that type of stream available. It is possible to setup your USB camera to output a RTSP stream, rather than UDP as you’ve shown configured.
Thanks Tony - much appreciated on the explanation. You’re correct - this camera does not have H264 camera support and only MJPG. And I read a bit more about MJPG as to why it uses a lot of bandwidth and why H264 is used.
To pipe MJPEG to RTSP, I would first have to convert the MJPEG into H264 before sending it out. Seems like a bit of work for now and I have a deadline for this first phase.
In the meantime, I’ve ordered another camera from RobotShop and hopefully, it will arrive in time before this weekend - planning a submerge test for the electronics enclosure. This first test will be using POE++. The temporary RAILs are made with SLS (surprisingly it has very little flex) and to minimize on the flex, I’ve modified the circular plates with added ‘feet’ that extends about 4mm each end to support the mid-section as well as at the end-caps.
Unfortunately, the full system won’t be ready until next month when the rest of BRs components from RobotShop arrives - can’t wait!
Hi!
For a temporary solution, if you can set up your MJPG camera stream using RTSP, you’d be able to receive the video using some RTSP-capable video player, like VLC or MPV. Note, however, that those players might introduce some latency.
If you have bandwidth problems, you can set up the stream with a lower resolution, like 480p instead of 1080p – assuming it’d be better to have some video feed than nothing.
A tip: once you get your new (the H264) camera, delete the MJPG video stream before disconnecting the MJPG camera from the Pi. This avoids problems and easy the setup with the new camera. After that, turn off the vehicle and switch the cameras. Then, with only the H264 camera connected, BlueOS should automatically configure the video stream for you during startup, being ready to be used with Cockpit.
Thanks
2 Likes
Hi @blacksheep -
Very cool setup! While your printed RAILS seem to be working, I would expect them to be quite brittle especially if made via SLS. A hard impact to the enclosure may fracture them - that’s why they are made from aluminum!
An alternate camera is definitely the best path if you want to minimize latency. Stay on the lookout, we’re launching an option you may be interested very very soon!
Thank you @joaoantoniocardoso , I just might have to give that a try - Robotshop’s shipping out today so it’ll be tight to arrive Friday, possible but tight. In any case, I’ll try and have this setup first as plan B and if the camera arrives in time, I’ll swap it over to the H264 (and to remember to remove the MJPG camera first). Plan C, if all else fails, is to drop in my Garmin Virb X (no streaming but at least recording).
@tony-white - hmmm, I can see what you mean - which was one of the reasons why I added ‘feet’ to each of the circular trays so that they would take some/most of the load. To your point, I am concerned at the flange now where the two screws secure the bay - that is where it should fail first (I think). Either way, I’ll report my findings - even if it survives the first few dives, its definitly not future proof and the aluminum RAILs is the way to go.
Stay on the lookout, we’re launching an option you may be interested very very soon!
Definitely will stay tuned!
Thank you again!
Ron.
