Low framerate with ace2 cam even with low grabtimeout
michael1309 opened this issue · comments
Hello all.
We started testing the pylon6-dev branch today with an ace2 a2A1920-51gmBAS.
Since commit e07c886 the software works also with this camera :).
We want to build a stereo system and have therefore configured the two cameras with pylon as master and slave. The camera parameters are stored as usersets and then load them via the services of the driver this also works so far.
Unfortunately, in contrast to the pylon software, we do not achieve 20 FPS with mono12 or mono8, but only 7 FPS.
Changing the "grab_timeout" like mentined here :#21 does not bring any improvement.
The CPU load on our system is low during video aquiastion.
Here is the start log of the software:
SUMMARY
========
PARAMETERS
* /pylon_cam_1_node/camera_frame: cam1
* /pylon_cam_1_node/camera_info_url:
* /pylon_cam_1_node/device_user_id: cam1
* /pylon_cam_1_node/enable_current_params_publisher: True
* /pylon_cam_1_node/enable_status_publisher: True
* /pylon_cam_1_node/exposure: 1000.0
* /pylon_cam_1_node/frame_rate: 20.0
* /pylon_cam_1_node/gain: 0.5
* /pylon_cam_1_node/gige/mtu_size: 1500
* /pylon_cam_1_node/grab_strategy: 2
* /pylon_cam_1_node/grab_timeout: 100
* /pylon_cam_1_node/image_encoding: mono8
* /pylon_cam_1_node/startup_user_set: CurrentSetting
* /pylon_cam_1_node/trigger_timeout: 5000
* /rosdistro: noetic
* /rosversion: 1.15.9
NODES
/
pylon_cam_1_node (pylon_camera/pylon_camera_node)
auto-starting new master
process[master]: started with pid [2998]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to 90d9e542-ae68-11eb-a6b9-a100e73c29b0
process[rosout-1]: started with pid [3008]
started core service [/rosout]
process[pylon_cam_1_node-2]: started with pid [3015]
exposure is given and has value 1000
gain is given and has value 0.5
[ WARN] [1620304970.177367578]: Autoflash: 0, line2: 1 , line3: 1
[ INFO] [1620304970.177818169]: Trying to open the following camera: cam1
[ INFO] [1620304970.475140167]: Found the desired camera with DeviceUserID cam1: a2A1920-51gmBAS
[ WARN] [1620304970.751105541]: No User Set Is selected, Camera current setting will be used
[ INFO] [1620304970.781284342]: Cam supports the following [GenAPI|ROS] image encodings: ['Mono8'|'mono8'] ['Mono12'|'mono16'] ['Mono12p'|'NO_ROS_EQUIVALENT']
[ INFO] [1620304970.939045318]: CameraInfoURL needed for rectification! ROS-Param: '/pylon_cam_1_node/camera_info_url' = '' is invalid!
[ WARN] [1620304970.939081945]: Will only provide distorted /image_raw images!
[ INFO] [1620304970.954873285]: Setting exposure to 1000, reached: 1000
[ INFO] [1620304970.976167873]: Setting gain to: 0.5, reached: 0.5
[ INFO] [1620304970.991467744]: Startup settings: encoding = 'mono8', binning = [1, 1], exposure = 1000, gain = 0.5, gamma = 1, shutter mode = default_shutter_mode
[ INFO] [1620304970.992851635]: Start image grabbing if node connects to topic with a frame_rate of: 20 Hz
[ INFO] [1620304970.993034711]: Camera not calibrated
thank you in advance
Hi @michael1309
Could you please set the frame_rate parameter to 50.0 Hz (under the config/default.yaml file) and report back the new camera frame rate that you are getting.
@michael1309 Hi, you should also check what kind of triggering you are using. That is, when using software trigger, the frame rate may be decreased by 50%. That is why, you should either use free-run (no explicit external triggering), or external hardware trigger. This topic was discussed in different other issues already and there were implementations for that. Regards
@saif-abdullah I have set the frame rate limit in the ros driver to 50 Hz, so I still only get 7-8 FPS.
@m-binev I have just tested hardware triggering.
For this I set the trigger source of the master camera either to Software with 20 FPS Fixed or to Periodic signal with BslPeriodicSignalPeriod=25000.
In both cases a 20 FPS image stream was generated in the Pylonviwer.
The Master Camera uses line 2 as output and the Salve Camera as input.
I have the feeling that the usersets are no tloaded correctly. I use the following command sequence to load the userset
rosservice call /pylon_cam_2_node/stop_grabbing
rosservice call /pylon_cam_2_node/select_user_set 1
rosservice call /pylon_cam_2_node/load_user_set
rosservice call /pylon_cam_1_node/start_grabbing
thank you for your support
Although I'm just in the process of testing configurations for the Ace2 pro, here are my insights so far:
@michael1309 Have you tried setting the parameter enable_current_params_publisher for the node to false? It seems that the publishing of the parameter significantly slows down image publishing (from 33 FPS to 8-9 FPS in my case).
I am using the following setting:
image_encoding: "bayer_rggb8"
gige: mtu_size: 1500 (also set on camera user profile)
startup_user_set: "UserSet3" (select the user set you saved on the camera, can be given to the node or in the config file)
trigger_timeout: 20
grab_timeout: 20
frame_rate: 60
grab_strategy: 0
shutter_mode: "global"
In the User Profile I set the following options:
TransportLayerControl --> Packet Size: 1500
TransportLayerControl --> Inter-Packet-Delay: 1000
AcquisitionControl --> ExposureTime: 30000
AcquisitionControl --> TriggerMode: Off
Analog Control --> Gain: 10db
The user profile can be saved on the camera under "UserSetControl". Make sure you select the correct user set.
When you use bayer encoding, the standard image_proc/debayer and image_proc/rectify nodelets can be used to get a debayered and undistorted image afterwards because the pylon-camera-node seems not to be able to debayer the image inplace.
I hope this setting helps.
If you find a configuration that further improves the framerate or image quality, I would be happy if you share your setting.
Have you tried setting the parameter enable_current_params_publisher for the node to false? It seems that the publishing of the parameter significantly slows down image publishing (from 33 FPS to 8-9 FPS in my case).
This solves my Problem thank you.
I don't close this issue since this is only a workaround not an real fix.
I am closing this issue as it seems the problem is solved.