image_raw not reaching desired FPS (BU160M) [closed]
Hello. I am using a Thinkpad P15 Gen2 pc with BU160M to publish a camera video topic. However, when I run the command "rosrun image_view image_view image:=/image_raw", the fps of the topic drops significantly.
I would like to know if there is any solution or countermeasure. Or is it just a ros system thing?
Please describe in more detail how exactly you are "publish[ing] a camera video topic". Which settings are you using for instance?
I ask because the camera you mention is capable of 1440x1080 at 24 bit at max 240 fps (in certain configurations). Assuming 30 fps, 24bit colour at full resolution would already result in an uncompressed datastream of 30x3x1440x1080 ~= 133 MB/sec. At 60 fps that would be double that (266MB/sec).
Even a 1 GBit/sec connection can only transfer about 125 MB/sec (theoretical maximum), so that wouldn't work.
ROS or not.
Thank you for your response.
I am sorry. I am using a program given to me by a third party, so this may not be an accurate answer.
The resolution of the camera is 1440x1080. If we run the camera node by itself, the bandwidth of /image_raw is 1094MB/s and the frequency is 227fps. However, when running with multiple nodes (node for rviz and aruco marker detection) simultaneously, the frequency of /image_raw drops to 70fps.
As a countermeasure for this, if I increase the wired LAN line speed, will it improve the frequency of the topic?
I am new to ros, so I apologize if I am talking nonsense.
please describe (again) how your system is setup, and how things are being published.
if what you write is correct, you'd need at least a 10 Gbit/sec connection to be able to publish that amount of traffic and route it between two hosts. That's not impossible, but not common with current consumer hw.
Or perhaps you are measuring this without actually going outside
localhost, in which case this is all local traffic, and you're measuring (and reporting) (mostly) memory bandwidth.In any case: I'd suggest applying some form of compression. Most on-the-fly compression algorithms incur only a small amount of runtime overhead, but significantly reduce bandwidth requirements (often on the order of 1/10th).
in that case: have you asked that third party whether what you observe is ...(more)